Impact of Generative AI in Software Development

Alexander opens the second conversation with Igor Kurochkin about this year's DORA report: last time they took apart the methodology, now it is the findings and the questions the researchers asked. Igor, who helps large companies develop engineering culture and reviews industry reports, recalls that the document grew out of the State of DevOps 2024 survey, extended with in-depth interviews and insights from teams inside Google.

Alexander adds that it came out in 2025; by his reckoning it runs to about sixty pages and eight sections, among them the DORA approach, understanding the landscape and ways to measure AI's impact, the effect on engineers' work, a large block on trust, adopting the technology, and a closing list of actionable items.

By the third or fourth section Alexander could not shake the feeling of reading the same thing from different angles. Igor agrees: these are different views over the same material, and the structure reminded him of the book Technology Strategy Patterns with its split into guiding principles and actionable items.

Then comes the individual level. Igor explains that the authors work with constructs, and AI adoption is a construct too: there is no question asking you to rate adoption as a percentage, the level is assembled from five or six questions. The main hypothesis is phrased as what happens if AI adoption grows by 25%, and the simulation shows what that does to burnout, flow, productivity and two kinds of work — valuable work and toil.

In the simulation, flow, job satisfaction and productivity go up, while the share of valuable work, oddly enough, goes down; the authors explain it with a vacuum hypothesis: the freed time may be spent on technical debt, learning and the like. Alexander adds that this is an attempt at causation rather than mere correlation, and that the mixed direction of the effect is what pushed the authors into inventing explanations.

He recalls a talk by Andrew Ng, who once created Coursera: in his fund's startups the ratio of product people to developers has shifted from one to three towards one to one, because the bottleneck is now inventing hypotheses, not implementing them.

Igor defines toil as unproductive, wearying work: the share of time spent on manual tasks that lend themselves to automation but carry no lasting value — operational chores that eat into features and hypothesis testing. The term, by his account, first appeared in the first SRE book, which described how to measure and fight it.

Alexander calls it the routine of keeping a service running and notes that DORA has been part of Google Cloud since 2018, where the aim is self-healing and autonomy: otherwise a team grows in proportion to the number of services rather than the number of changes.

At the organisational level the authors look at how generative AI affects code complexity, technical debt, review and approval speed, cross-functional team coordination, code quality and documentation quality.

In the results only documentation quality improves sharply; Alexander adds that code quality and speed also rise, and puts that down to code-review agents — you can hand them your quality criteria and get something close to fitness functions.

Technical debt is among the laggards. Alexander links this to companies abandoning small batches and trying to generate a whole feature in one request, producing code that is hard to maintain. Delivery stability and throughput suffer too.

Igor warns that SonarQube and GitLab measure complexity and debt differently. Alexander clarifies that the survey captures perceived obstacles to work, rather than those tools' metrics.

The delivery model has changed too: recovery time has moved into speed, and stability has gained rework rate. Igor cannot find its source in the questionnaire. Alexander tentatively links it to unplanned tasks and promises to check; the passage leaves the exact source unresolved.

A separate table splits engineers' values into five types — utilitarian, reputational, economic, intrinsic and hedonic — and shows where generative AI raises them, where it lowers them and where it is neutral. Igor reads the matrix this way: AI can undercut reputational value by casting doubt on authorship and contribution, and hedonic value by taking the interesting tasks for itself. He also points out that this part, and the five strategies for reinforcing value, came not from the survey but from in-depth interviews with engineers.

To Alexander the table looked like a manager's instrument: allow the tools for those who care about doing more; recognise the contribution regardless of who generated the code; assess the outcome rather than the time spent; frame AI as a reason to learn; and leave tasks where models are still weak to those who care about interesting work. He has never worked that way himself, assuming engineers would figure it out, but found it curious reading: the hypothetical colleague in his example wants recognition, money or interesting work.

Alexander finds the trust block especially interesting: the perceived effect diverges from the real one, and if an assistant is right half the time people start treating it as a slowdown. In his own company the feedback depends on the language — suggestions in Python are trusted, while a rare language with complex syntax draws complaints — and the report does not break such factors down.

In the figures discussed, about 60% report a productivity gain and some 30% see no effect; the authors conclude that the more trust in the output, the higher the productivity, and that trust is problem number one in Stack Overflow's research too. This part was done together with the Engineering Productivity team at Google.

Alexander calls the action plan workable: explicitly permit the tools by policy, embed them where feedback is fast, provide a decent assistant for the language in use, and nudge rather than force — his company hands out badges for active use.

Igor notes that the four proposed scaling strategies look like rolling out any platform service, while Alexander, reading the simulation distributions, sees adoption goals and usage policies land on the weak side of the chart: what works is the advice broad enough to fit any internal developer platform.

What was new to Igor was renaming capabilities as conditions and adding a service level; both find the closing framework too generic.