How AI Changes Engineering Culture and What It Means for Team Leads and Engineers

The research grew out of losing sight of how the company compares with the rest of the world: there is plenty of external work on how AI affects development and almost none from Russia. So the team began with a meta-analysis of more than fifty studies published between 2023 and the end of 2025, over half a million respondents in total, though the speaker warns that samples cannot simply be added up. It covers large-scale surveys such as DORA, Stack Overflow and JetBrains; repository telemetry, where a Stanford productivity group asks companies for data access and watches commits, pull requests and rework; field experiments; and internal corporate research with interviews. The loudest of them was METR: sixteen developers solved real tasks with AI and ended up slower, though the experiment gave them unfamiliar tools and a maximally awkward repository. He had already shown the results at the company's February conference; before that there had only been posts.

Their own survey followed the DORA methodology: about 80,000 people saw it, roughly a thousand started filling it in, some eight hundred answered and 350 reached the end; the causal part is due in April, leaving descriptive analysis for now. The speaker states the limits himself: self-assessment, a sample that drifts from question to question, process changes inside companies, no market consensus on productivity metrics, and a novelty effect that fades within a quarter or six months. The picture: adoption in the big surveys has passed 90%, coding got faster while delivery did not, DORA 2024 showed throughput falling, the 2024 and 2025 reports showed more instability in production, 30 to 40% did not trust AI output, and a meta-analysis by an MIT unit found only 5% of initiatives finish successfully, the rest stalling at consideration, pilot or scaling. The Russian data repeats this with a lag: quality improved for 32% and worsened for 14%, 49% do not trust AI, and across the meta-analysis and the survey together 58% generate code often or always.

To show the difference, the speaker drew two diagrams on an internal whiteboard. On the left is the classic process: a product manager with hypotheses, designers beside him, analysts writing specifications, developers, QA, SRE with the deployment, and support handling problems. In 2025 the company entered AI exactly this way: the leaders of each profession — systems analysis, development by language, testing — worked out how to speed up their own stretch. More ideas, faster documentation, faster code, tests generated automatically. Every internal loop got faster, but the handoffs jammed: the motorway still runs into the same bottleneck, and end-to-end delivery did not grow as much as hoped. In the autumn, when the new OpenAI and Google models arrived, agent scenarios began to work autonomously enough that a human in the loop is no longer always required; over the last three months the speaker wrote plenty of code with agents and calls the difference night and day.

On the right is a loop with fewer handoffs: a product manager takes an idea through to requirements and a prototype using an in-house equivalent of Lovable or Replit that builds the interface to your guidelines and deploys into your infrastructure, while an engineer asks agents to write tests, deploy and help with operations. Inside the company that means IDE plugins, a CLI like Claude Code and a home-grown front-end generator. The speaker grounds his belief in this loop in the papers he reads: Google now fixes the developer scenarios that hurt most instead of spreading developer tools evenly; Meta described just-in-time tests, ephemeral ones generated for a specific change, because the accumulated suites are large and catch little; and at AWS, after a run of outages, a memo leaked saying senior engineers must now approve newcomers' AI-assisted changes. He retells the recent DORA report as the Matthew effect: AI helps a strong engineering base, while a weak one merely generates random code and rework, whose growth is also visible in the Stanford data. Hence the prescription: pilot the new mode on greenfield and carry practices both ways with brownfield.

Org design is tied to processes and architecture, so as roles compress the management layers compress too: a long hierarchy means slow decisions, and fast code does not help when a change travels up a chain of approvals to the chief executive. Financial pressure adds to it: numbers are counted per head — do you need a stadium of people where another company manages with a hundred? He lists the market signals in a row: Meta has an applied engineering team with one manager per fifty engineers, Huang has a similar ratio ("I don't know how he manages, but presumably, judging by the market cap, well"), Amazon wanted 15% more individual contributors, Intel talks about flattening, and a guest on his podcast who moved from senior manager to staff or principal engineer at Microsoft said he no longer answers for people's growth. Yet a flat structure without a platform, paved paths and automatically enforced policy fails: the bottleneck slides further down the pipeline and senior engineers act as half-managers instead of designing architecture.

The team lead's job therefore shifts from handing out tasks, hiring and running rituals to designing a system where people and agents both work: team rules and product knowledge move out of the wiki into the repository, tasks split into those an agent may take, those that need deep review and those that cannot be delegated, and the teams he has spoken to try to check acceptance and definition of done automatically. Metrics come from the corporate stack — DORA, SPACE, DevEx — or the lead invents his own. He names the risks plainly: skill erosion among juniors, the illusion of speed, and distrust that easily turns into sabotage. After the talk came the question of whether AI devalues people who know the history of a codebase. His answer: betting on a monopoly of knowledge ("only one person can touch that module") is a poor bet, the knowledge is being made explicit for people and agents, and value moves to deciding what to build and verifying the result. He now prepares an ADR in tens of minutes rather than a week, but warns there are not that many brilliant money-making hypotheses.