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.
The episode mentions a recognizable stack rather than one magic product.
### Models and coding agents
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:
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:
AGENTS.md instructions;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:
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.
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.
### 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:
More useful signals:
### 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:
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.
### 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 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 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.