AI development in 2026 is a workflow problem, not a coding problem

Notes from Kirill Mokevnin’s video Как ИИ меняет разработку в 2026, based on what he heard while speaking, teaching, and facilitating discussions at several Russian IT conferences.

The useful frame is not “which coding agent wins?” Mokevnin’s stronger observation is that code generation has improved faster than the systems around it. Companies now have capable models, agents, MCP servers, skills, project instructions, and internal knowledge—but still struggle to turn them into reliable end-to-end delivery.

The bottleneck has moved from producing code to shaping projects, preserving context, reviewing changes, controlling infrastructure, measuring outcomes, and teaching people to work differently.

TL;DR

• AI adoption is less complete than online discussion suggests. In Mokevnin’s conference audiences, only a minority said agents wrote essentially all of their code.
• Large companies are building closed model environments and internal coding assistants, but these often lag behind Claude and mature external harnesses.
• The conversation is shifting from AI for coding to AI for the full SDLC: requirements, ticket triage, documentation, implementation, review, release, and cross-functional coordination.
• MCP is useful for reading infrastructure state, logs, and context. Giving agents unconstrained write access to clouds or Kubernetes is an anti-pattern when it bypasses Terraform, Helm, auditability, and reproducibility.
• More generated code is not the same as more delivery. Review and release become the bottleneck, so measure completed work and time to market rather than lines of code or individual output.
• High token usage is not a productivity KPI. During adoption it can be a healthy sign of experimentation, but later it should trigger coaching rather than punishment.
• Spec-Driven Development becomes practical when agents continuously extract and update documentation from normal working sessions. It fails when humans must manually maintain a giant speculative document set.
• “Skill hell” is real: too many overlapping internal skills create another discovery and maintenance problem.
• The better long-term move is often to make the project native to the model—standard terminology, standard tools, clear generated-code boundaries, and familiar architecture—rather than covering every inconsistency with another skill.
• With stronger models, explain the problem and constraints first. Do not prematurely dictate the entity model or implementation; let the agent propose alternatives and tradeoffs.

The tool stack Mokevnin sees emerging

The episode mentions a recognizable stack rather than one magic product.

Models and coding agents

• Claude is the reference point for strong external model capability in the episode. Mokevnin says internal corporate systems still often feel roughly a year behind the best external experience.
• OpenCode appears as the practical open-source base that companies can fork rather than rebuilding an agent from zero. He cites Yandex Sourcecraft as an example of this direction.
• Internal assistants and private models are common in banks and other restricted environments. Companies combine local models with a CLI or editor plugin, internal MCP servers, and company-specific skills.
• Slack-integrated Claude is one example from Hexlet: the model can gather context across conversation, interact through MCP, and create tickets.

The underlying lesson is build-versus-fork discipline. If privacy rules require an internal system, start from a capable existing harness when possible. Rebuilding the complete agent runtime from scratch is expensive, and a small internal team is unlikely to match products developed at the frontier.

MCP servers

MCP is becoming the connective tissue between agents and company systems:

• internal knowledge and project context;
• ticket systems and Slack;
• cloud platforms;
• Kubernetes;
• logs and infrastructure state.

But the episode draws a sharp line between observation and mutation.

MCP is excellent for asking an agent to inspect logs, summarize system state, or collect context. It becomes dangerous when developers use natural-language commands to modify production infrastructure directly. If the change bypasses Terraform, Helm charts, or another infrastructure-as-code path, the result may work once but cannot be reliably reviewed, reproduced, rolled back, or reconciled with declared state.

Natural language does not turn an imperative production change into infrastructure as code. It only makes the imperative change easier to issue.

Skills and project instructions

Companies are accumulating:

• reusable agent skills;
• project-level AGENTS.md instructions;
• MCP integrations;
• domain rules and invariants;
• change records and design decisions.

These are useful, but the episode warns about skill hell: every team publishes its own solution, many skills overlap, and evaluating whether a skill fits a particular project costs more than writing another local version.

A skill should therefore earn its place. Prefer a small number of project-specific instructions for genuine exceptions. For common frameworks and tools, use vendor-maintained skills when they match the project. Reject or override them when the project intentionally differs from the vendor’s preferred style.

Mokevnin also mentions emerging tooling that scans Python or Node dependencies and discovers skills published by library authors. The direction is promising: framework knowledge can arrive with the dependency instead of being recreated inside every company. The ecosystem is not yet consistent enough to make this automatic everywhere.

OpenSpec and Spec-Driven Development

Mokevnin describes OpenSpec as one way to organize Markdown artifacts around changes, domain context, ADRs, product requirements, invariants, and business logic.

His earlier objection to Spec-Driven Development was familiar: specifications are expensive to write, unpleasant to read, and become stale. His view changed after adopting a skill-based workflow that continuously asks clarifying questions and turns normal agent sessions into maintained project knowledge.

The important distinction is:

• weak SDD: humans stop and write large documents before doing the work;
• stronger SDD: the agent extracts decisions from conversations, updates structured documents after each session, checks them against later work, and commits the resulting knowledge alongside the code.

This creates a compounding project memory almost “for free,” because the team was already explaining the task to the agent. The conversation becomes an input to documentation rather than disposable context.

The open question is scale. A small project can benefit quickly, but it is not yet clear how well the approach behaves when hundreds of domains, subdomains, specifications, and exceptions compete for context.

ADRs, OpenAPI, and deterministic generators

The episode is unusually positive about traditional deterministic tooling.

• ADRs preserve architectural decisions generated or clarified during agent sessions.
• OpenAPI specifications provide explicit interfaces the model can reason about.
• OpenAPI generators can create DTOs, handlers, and repetitive glue code predictably.
• Other generators should remain the default for mechanical code that has a deterministic source.

An LLM can generate repetitive code, but that does not mean it should. A deterministic generator is cheaper, repeatable, and easier to review. The agent’s job is to understand the generation chain: edit the source artifact, run the generator, then modify only the intended handwritten layer. Generated files should be explicitly marked as off-limits.

The approaches that appear to work

1. Move from coding assistance to the complete delivery system

Optimizing the individual contributor is only the first stage. The larger opportunity—and difficulty—is integrating AI into requirements, triage, documentation, review, testing, deployment, and coordination with product and design.

This is why “ten times more code” is a weak result. If review was already constrained, ten times more pull requests merely move the queue downstream.

2. Measure shipped outcomes, not generated activity

Mokevnin is skeptical of revenue as a direct engineering KPI because product revenue depends on markets, sales, contracts, finance, and timing—not only features.

He finds a delivery-oriented metric more plausible: count work that travels through the complete pipeline and reaches production. The point is closer to time to market than story points themselves.

Weak metrics:

• lines of generated code;
• number of prompts;
• token consumption as productivity;
• number of pull requests opened;
• revenue attributed directly to individual developers.

More useful signals:

• completed changes deployed to production;
• cycle time across the full pipeline;
• review and release latency;
• failure and rollback rates;
• whether the bottleneck moved rather than disappeared.

3. Allow waste during learning, then coach from evidence

Heavy token consumption often signals an inefficient workflow, but limiting it too early teaches people not to experiment.

The approach attributed to Sber is sensible: encourage broad use during the learning phase, observe who consumes unusually large amounts, and later coach those users toward better workflows. Tokens are training material before they become an optimization target.

4. Refactor the project before adding more instructions

When an agent repeatedly misunderstands a codebase, the immediate temptation is to add another paragraph to AGENTS.md or create another skill.

Mokevnin argues for a different diagnostic sequence:

1. Observe where the model repeatedly fails.

2. Ask whether the project uses ambiguous or outdated terminology.

3. Check whether one word means different things in the UI, admin interface, domain model, and code.

4. Rename concepts and refactor architecture where possible.

5. Document only the irreducible exceptions.

At Hexlet, legacy meanings of “course” and a domain object whose name sounded like a person confused the model. A glossary helped, but clearer domain naming and refactoring were better fixes.

This is a useful definition of an agent-operable codebase: not a repository covered in instructions, but one whose concepts, boundaries, and tools are legible to both humans and models.

5. Prefer standard solutions unless custom code is truly the product

Models have seen mainstream frameworks, libraries, and conventional architectures many times. They can use them with less explanation and less context.

Custom infrastructure has a compounding cost:

• the agent needs more documentation;
• every session consumes more context;
• fewer learned patterns transfer from pretraining;
• maintenance remains local;
• the codebase grows faster;
• more custom skills are required to explain the custom code.

AI makes custom code cheaper to produce, but not free to understand or maintain. Standard tools therefore become more valuable, not less.

6. Ask open questions before prescribing implementation

One workshop anti-pattern was giving a strong model the entity model and exact implementation immediately.

Mokevnin recommends starting with the problem, constraints, and intent. Ask the model to propose approaches, explain tradeoffs, and identify a standard solution in the selected stack. Only then converge on entities and implementation.

If the human specifies the solution too early, the best possible result is capped by the human’s current understanding. An open design conversation preserves the possibility that the model knows a newer or more idiomatic option.

Anti-patterns worth remembering

Direct production changes through MCP

The agent changes cloud or Kubernetes state through conversational commands, but no Terraform or Helm artifact records the change. The environment drifts and the next operator cannot reconstruct what happened.

Better: read broadly; write through reviewed, reproducible, least-privilege paths.

Skill accumulation as architecture

Every failure produces another skill or instruction. Soon no one knows which rules are current, overlapping, or project-specific.

Better: minimize skills, improve project semantics, and use standard tool behavior where possible.

“10x code” as “10x company”

Code volume rises while review, testing, deployment, or organizational adoption stays fixed.

Better: follow the complete value stream and find the new bottleneck.

Manual mega-specification

The team writes an exhaustive specification once and expects it to remain the source of truth.

Better: let specifications grow from real sessions and update continuously with code and decisions.

Replacing generators with probabilistic code production

The model rewrites mechanical DTOs or handlers that a generator could produce deterministically.

Better: preserve source-driven generation and teach the agent the chain.

Treating last year’s agent experience as current reality

Some teams formed their opinion using weaker models and kept the same interaction habits.

Better: update both the model and the working method. Stronger models need less micromanagement and benefit more from problem-level discussion.

A practical operating model

A compact workflow distilled from the episode:

1. Choose the strongest permitted model and a mature harness. Fork rather than rebuild when privacy requires internal deployment.

2. Expose context through MCP, but separate read and write capabilities. Keep production mutation behind auditable workflows.

3. Start from the problem. Ask for alternatives and tradeoffs before prescribing implementation.

4. Make decisions durable. Convert sessions into specs, ADRs, glossaries, invariants, and change records.

5. Keep instructions minimal. Fix ambiguous project structure and naming before adding skills.

6. Prefer standard libraries and deterministic generators. Reserve custom code for genuine differentiation.

7. Teach the generation chain. Mark generated files and define which source artifact must change.

8. Verify at the end-to-end level. Review, test, deploy, and measure cycle time—not merely code production.

9. Watch for the displaced bottleneck. More code may create review debt rather than business value.

10. Treat adoption as organizational learning. Permit experimentation first; optimize usage after people have enough experience to benefit from coaching.

The durable lesson

The mature question is no longer whether AI can write code. It can.

The harder question is whether a company can shape its codebase, context, permissions, documentation, metrics, review process, and people so that generated code becomes reliable delivered change.

That is why the most important tools in the episode are not isolated products. They are interfaces between probabilistic models and durable engineering reality: MCP with boundaries, skills with restraint, specifications that update themselves, infrastructure as code, deterministic generators, shared terminology, and end-to-end verification.