State of AI4SDLC: How AI Changes Development Processes in Large Companies

Mass adoption has happened: every survey shows penetration above 90% — DORA across tens of thousands of engineers, Stack Overflow. The effect is uneven: for one engineer it is visible at once, at team level questions appear, at organisation level it is hard to say it exists. At the end of last year the team assembled a meta-study of other reports and ran its own DORA-style survey of the Russian market, since global surveys no longer carry a line for Russia. The picture looked similar but a quarter to six months behind on adoption: everyone had tried coding, yet the other lifecycle scenarios were covered far less. New results are promised by autumn, with the survey form opening at the IT Picnic event. The bottleneck has meanwhile moved: implementation used to be slow, and now the question is how to review, how to test and where to release. Judging by their plans, GitHub and GitLab already feel the load from generated code and are preparing a redesign.

In March or April Alexander defended an internal strategy for where the SDLC is heading. The old paradigm was stages and roles, and in a large company each role is a separate person: analyst, developers of various kinds, tester, SRE. In 2025 every profession accelerated its stretch: the analyst generated requirements faster, the developer did not read them and threw the task into the IDE with a "write the code" instruction, the tester chased coverage with generated tests. Everyone had more work, yet end-to-end efficiency did not move — handoff losses ate it, leaving a local optimisation. The target picture differs: roles and stages remain, but fewer people can cover them. People used to talk about T-shaped engineers; now the letter looks inverted: a developer who admitted he writes tests poorly gets an agent. RUP and the V-model return from the early 2000s in new clothes as spec-driven development, where the specification is no longer a contract for a developer but a contract for the agent.

The company's context: tens of thousands of engineers, thousands of services, money and critical-infrastructure status, and strict security demands. In under a year in the new role Alexander has talked to security more than in the previous nine years, because threat models multiply: prompt injection, poisoned external tools, context exfiltration, access rights inside internal search. The development platform was long built as a product — pretty windows, dashboards, click-through scenarios an agent does not need. Systemic impact starts where the IDP treats the interface as an option and convenience for agents as the priority. Such a platform needs three layers: a model gateway (a self-written LLM proxy rather than LiteLLM, with quotas, cost accounting and secret stripping), a tool gateway (basic tools baked into the terminal client, the rest in an MCP Hub and blocked on delegated tokens), and a registry of intents with owners and evaluation sets, still embryonic. In place: Nessy across terminal, chat and IDE, and the Spirit platform with a code reviewer plus testing, SRE and data agents of differing maturity — only the code reviewer and the development agents are rolled out to everyone, the rest piloted by lead adopters; the adoption spike came in March, after Qwen 3 was rolled out internally.

The share of AI code is a tempting and harmful metric: easy to collect, it grows by itself, invites gaming and says nothing about quality, risk or cost. Alexander cites a talk by engineers from a foreign social network: up to 30% generated code has no effect on productivity, since it still has to be reviewed and fitted in; a noticeable effect starts past 60%. Instead the company has long combined DORA, SPACE and DevEx — a colleague, Anya Gromova, has a separate talk on the approach — and watches onboarding time, time to first merge request, MR sizes, failing pipelines and incidents; insights come not from averages but from cuts by language and by greenfield versus brownfield. Agentic scenarios need telemetry from intent to outcome: which user, which agent, which model, which tool. Evaluation sets need no PhD in ML: travelling through git history to the moment a bug was fixed and tests written gives a hidden judge.

The company hands out the same tools, yet team results differ several-fold, and it seems not to be the models: the winners rebuild the process, often forced to by hard product deadlines. A team from the investments area moved product requirements into git — the task arrives from the product manager as a merge request, with the controls there too. They knew the old process would not meet the deadline; it worked well, and Alexander now sends other teams to them. Those who fail usually installed a plugin or opened a terminal client and work as before. Three kinds of agents appear in an engineer's day: in the editor (select a block, ask for a rewrite), in the terminal for multi-file tasks and research, and in the background — a code reviewer on every change, library version bumps, bug-fix triage. The engineer feels like an orchestrator: parallelising tasks, validating results, pushing problems into tests and evals. The fatigue is greater: an engineer's day now resembles a manager's.

More questions came from the floor than the three promised. On practices for improving quality, Alexander described working groups around professions, hackathons and training for business managers, who were shown that the terminal client with MCP covers not only the platform but the messenger and mail. Asked about architects, he admitted that an assistant for reviewing architecture decisions merely automated the old process, while an "architect mode" that helps design against constraints and platform capabilities was never built centrally: divisions have implementations, none has won out. Kirill from VK asked what changes when the AI tooling is itself built by agents; conceptually almost nothing — the LLM proxy team writes specs and validates results with the same agents. Asked about Backstage, Alexander explained that their own platform was meant to be contract-first, but product managers of the previous generation pulled it towards UI-first, so a scenario now has a screen and APIs underneath but no semantic intent, and product owners must learn the humility of a gatekeeper. Dmitry Simonov asked about context owners: Alexander does not believe in a shared store — it would be a dump; the domain answers and measures the quality of its own answers, and with twenty or a hundred engineers it is an order of magnitude simpler.