AI in SDLC Report by IT One and Skolkovo

Alexander opens by noting that a local view — what happens to development here rather than abroad — is what tends to be missing, and hands over to his guest. IT One, in Dmitry's words, is one of the largest custom software developers around, so understanding what AI does to development is a business question: what you do not know at your fingertips you cannot offer partners. The second reason is the hype: studies appear with enviable regularity, everyone shouts in unison that things have become wonderful, while the company's own AI lab, more than two years old and testing Russian and foreign tools alike, keeps showing a wide gap between what is broadcast and what is real. Academic colleagues were brought in to keep the view unbiased. The study, as far as Dmitry remembers, started in May and took nearly the whole summer: twenty-five interviews with the people they wanted, fifty hours in total; September and October releases missed the cut.

Alexander liked the structure of the report: first the global studies, then Russian technologies as publicly announced, then the interviews in which leaders could lower the pitch and say what really works, then forecasts and conclusions. Splitting the solutions across SDLC stages, Dmitry admits, was not the plan from the start — the structure emerged during the analysis, and the main problem turned out to be fragmentation: very few tools close several stages at once. Alexander sees a parallel with platform engineering and with Google's Developer Productivity for Humans series, a paper from around 2023 by his reckoning: what matters to an engineer is the end-to-end job — find information about a system, look at its tests and architecture, write the code — not one convenient tool. Alexander adds that his own company split its SDLC the same way and tied initiatives to stages and professions: engineers, QA, systems analysts, designers. Dmitry replies that the day before the recording their analytics team showed at a regular demo what it had learned to do with an assistant; Alexander calls that literal dogfooding.

Alexander compressed other people's forecasts and reports into a single slide and says he could not tell what premises the estimates rested on: one speaks about his own company, another about the industry, and the scale slides. Dmitry answers that they took sources with a large sample or people with a clear reputation who touch the technology themselves, rather than any passing visionary or futurist. Alexander himself splits productivity measurement into two approaches: surveys — DORA, Stack Overflow, the JetBrains ecosystem survey — and internal activity metrics, where you roll out DX or SPACE and compute DORA from your own releases and failures. What happens inside a company does not extrapolate outward, and a survey thrown at the whole internet yields a weighted average in which trends are hard to find, so he compares within one survey year on year: in Stack Overflow the share of those who neither use the tools nor plan to fell from almost 40 per cent to 20, yet adoption brought an appreciation of the limits with it.

Dmitry adds that the scepticism is falling away, there are simply more solutions and the entry barrier is lower, and a multiple increase in one year suggests the dynamics are underestimated. From DORA Alexander quotes the numbers: 81 per cent say resources in their company are shifting towards AI, 67 per cent that they use tools to improve their code, and adoption in 2025 has reached almost 90 per cent. What people mean by working with code has shifted too: autocompletion is mundane, and generation now means an agentic mode. The key difference between 2024 and 2025, in Dmitry's view, is that the effect has finally become visible: AI is no different from any other new technology, habits and attitudes have to form in teams and in companies alike, and the road will be painful, expensive and long — every leader they spoke to calls it thorny. Alexander closes the thought: expecting that you add AI and all becomes wonderful does not work; next comes a product approach to engineers' jobs and the resistance of people who fear losing their competence.

A storyline of its own is the maturity model the authors found at the British department for environment, food and rural affairs; it sits on GitHub, and both men had the same first reaction — as if our own agriculture ministry had published it. Alexander read up on the department: farming there is heavily digitised, sensors and forecasts are in use, and it has been digging in that direction for some fifteen years, becoming a pilot for digital technology. The second dissection is the METR study of AI's effect on the work of experienced engineers, from which the press concluded that AI slows people down. Alexander first declined to comment, but once colleagues inside his own company started citing it he downloaded all fifty pages of methodology. His objections: sixteen engineers and around 250 tasks, a short horizon, large repositories that do not fit into a model's context, the Hawthorne effect, self-reported time, and reviews in which an agent's code is scrutinised far harder than a familiar colleague's. Dmitry pushes back: is that actually bad? Reading a model's output closely is the right habit for now.

On the report itself Dmitry explains that the list of jobs per stage came from their own experience and from repeating others' experiments: the slide holds artefacts you will, with about 80 per cent probability, do more efficiently — unit tests, which people now simply forget about, and documentation, which has become easy to keep current. The one stage they could not verify is deployment: solutions are few, closed or bespoke, with no mass practice. Alexander confirms it from a panel he watched at the IT Picnic, where his own colleagues and people from Avito and Yandex Cloud said they still want to ship deterministically — canaries, metrics, automatic rollbacks — and that putting AI in there feels scary. Of the trends Dmitry rates the sixth highest: working piecemeal is expensive and thankless, without a platform with centralised control over models no systematic effect appears, yet piloting is a must. Measurement is the sore point: everyone wants to count the effect, but only 23 per cent measure at all, and then by speed, stability and release errors. Alexander invites listeners into his own company's survey, still short of respondents.