State of AI4SDLC: from AI assistants to agentic development

The host introduced Alexander as an old friend and a new member of the programme committee: he called the channel of research reviews with its distilled selection a legacy of the speaker's book club, and owning SDLC company-wide a large responsibility with no direct reports — a leadership challenge in its own right. Alexander explained where the topic came from: at the start of the year he moved into artificial intelligence in development, and one task was to set the year's goals — where the company is going and why; the talk became his answer to that question. He split thirty minutes into five parts: the research done late last year, the shift of software engineering 1.0 towards 2.0, the change in how work itself is managed, spec-driven development, which he billed as the empire striking back, and evaluating the quality of autonomous agents.

The research combines a review of the global picture, a meta-analysis of major studies over three years, and their own survey inside Russia: at some point public foreign studies stopped reporting on Russia and often became unreachable without special means. The headline number is roughly 90% adoption of AI in development by the end of last year, going by the DORA, Stack Overflow and JetBrains surveys. Scenarios felt it very differently, though: code was already generated often, while code review and security were far from universal, so coding sped up while delivery did not, or not always. Alexander stated the caveats up front: surveys are self-reported, the effect depends on a company's processes and tasks, and team-level results often did not move, because a developer was answering about his own personal use of the tools. The management question surfaced at the same point: how do we measure that the process is on plan, and it needs a smarter answer than counting burned tokens or lines of generated code.

The conclusions of the external work and the internal survey agreed: quality improves ambiguously, trust in AI tools is not high enough, ROI is hard to compute, and handing out licences is not enough — the development processes themselves have to be rebuilt. Hence the move to the software engineering 1.0 diagram, where every role has its own people: product managers, analysts, developers, QA and SRE engineers. In 2025 AI was rolled out inside those professions, and almost everyone produced more output — requirements, code, tests for coverage — yet end-to-end work did not accelerate: the losses sat in the handovers, and each person optimised their own metric rather than the through one. This year's bet is different: the roles remain, but platform tools should help cover the roles' responsibilities. His examples: a code-review agent, covered in this conference's own podcast; an agent for requirements; and an agent around the observability platform that tracks problems and works out the causes of incidents.

On greenfield projects they tried agentic development, where the engineer's role widens: framing the task, stating the goal, limiting the context so the agent does not burst, setting boundaries and completion criteria, orchestrating the parts of a big task and checking the result. A team needs repository context, architectural rules, mature practices around CI/CD — where they were already strong, this is picked up easily — and agreements that keep parallel agents from making conflicting changes, or the bottleneck simply moves to review. Managing the work changes too: instead of a board where a human writes tasks and context is smeared across chats and wikis, agents become team members tied to workflow stages — the picture Jira and especially Linear paint — the latter declared classic task management dead, as Alexander recounted it. His example is an agent that sweeps up bugs: it watches tasks typed as bugs, checks the description, picks them up and carries them to a pull request. The tasks themselves may be filed by another agent off the back of a grooming session, but a mixed team holds together only on shared rules and guardrails: otherwise the agent burns the token budget and the approach turns into unmanageable chaos.

The fourth part he billed as the empire striking back: he recalled the V-model he started out with — requirements, architecture, detailed design, a large implementation stage, and the upward half of the letter with verification and validation. It gave traceability from business expectations to the result, but the documents were written for people, turned into memoranda of intent, and the code drifted away from them — by the end of a project they were fit only as museum exhibits. Now a specification is an interface between people and agents, an executable context: what to do, what not to do, which acceptance criteria to check against. That works only if the artefacts are tied together: what must change, what must not break, how readiness is proved. An agent told to build a feature or to do it well will probably build the wrong thing; implementation is no longer the problem, verification is.

There is no single framework inside the company, teams experiment: Alexander named GitHub's agent-agnostic Spec Kit with its chain of spec, plan, tasks, implementation and checklists; a more product-shaped approach from another vendor with documents such as design.md and tasks.md; and Codex with AGENTS.md, which he uses on personal projects. The hype alone does not help: without worked-through acceptance criteria the agent confidently reports that it did well, and tons of code get reviewed by hand. Hence the fifth part, evals: change the agent's version or the model underneath, and you need to know whether things got better. He suggests assembling a set the way benchmarks are built: a frozen state of repository, task and environment, a contract of what the agent may do, and a hidden judge of regression tests — on bugs, the version, the reproduction steps, the expected behaviour, and the test written by whoever once fixed that bug. At the end the audience — Maxim, Egor Gavrilov, Sergey — piled in with questions about frameworks such as Superpowers, Open Spec, GSD and Taskmaster; Alexander answered that nothing is rolled out centrally: the industry moves so fast that nobody knows which is best, so he gathers what works for which team and passes it on.