Development after AI: Where the Bottlenecks Move

When people wrote code by hand, a shortage of speed was easily framed as a shortage of developers. Assistants accelerated typing and editing, and the queue began moving toward review and testing. Running multiple agents in parallel exposes another limit: does the team have enough worthwhile tasks, and can it verify the final result? Widespread tool use therefore does not establish faster delivery. The previous year's research put AI adoption close to 90%, while effects varied across tasks. AI4SDLC Research 2026 continues that investigation: the talk discusses 91 candidate publications and a DORA-inspired survey. Access, autonomy, and the division of work are examined alongside engineering practices, reliability, and team outcomes. The slides add a necessary qualification: the research corpus is unfinished, and the causal diagram defines an analysis plan. Future findings from a voluntary survey cannot be declared a proven adoption effect in advance.

In a large organization, work moves through product managers, analysts, developers, testers, and operations. Each handoff requires context transfer and waiting for the next participant. Accelerating one stage is insufficient when everything else keeps its old rhythm. T-Bank's bet is an agent-based process in which necessary roles remain, but one person working with agents can cover more activities. The aim is to reduce handoff losses and complete work sooner. Specifications return because product intent must become instructions that an agent can follow, including constraints and acceptance criteria. Polomodov connects this shift to a shorter implementation phase. When coding took months, frequent feedback and small increments were particularly valuable. As implementation becomes faster, explicit specifications and acceptance checks again become a useful working interface. Their purpose is to agree on expected behavior before generation, so rapidly produced code does not simply implement a misunderstood requirement more quickly.

At the scale of ten thousand engineers, the program cannot consist only of distributing subscriptions. Evaluation needs three axes: cycle time and throughput, quality and reliability, and economics. Incidents, rollbacks, and security problems provide guardrails; acceleration achieved by removing checks is not success. Economics includes model and infrastructure costs, infrastructure utilization, and time released for people. Agents also need access to the internal developer platform. Previously, its product centered on screens, buttons, and portal traffic. Now agents need interfaces they can use, while domain logic, policies, limits, and control remain in the platform. T-Bank already has a model gateway, MCP Hub and CLI, the Nessy tool family, and the Spirit platform. The path from a ticket to a pull request has been demonstrated for selected scenarios. The talk does not claim that this workflow already handles every task equally well.

The platform has three distinct layers. A model gateway manages model access, quotas, and budgets; a tool gateway exposes actions; a capability registry describes complete workflows with owners and usage conditions. Consider the talk's example: asking whether your services had problems during the previous day. Given only disconnected APIs, a general agent must identify your team, discover its services and deployments, and retrieve logs and metrics, effectively reconstructing platform logic. A diagnostic capability keeps that work inside the platform and returns a meaningful result. Authority increases gradually: read information, recommend a solution, then act. The last step needs explicit authorization rules, approvals where required, dry runs, rollback, and an emergency stop. Threat modeling helps distinguish actual risks in a particular scenario. Trying to eliminate every conceivable threat before the first pilot can halt adoption; ignoring those risks leaves autonomous action without meaningful control.

The share of generated code is convenient to report, but rewards producing lines while concealing quality, cost, and emerging queues. The talk instead focuses on review waiting time, blockers, rework, and the passage of changes into production. T-Bank used DORA, SPACE, and DevEx before AI adoption, providing a baseline for comparison. Adoption measures help track rollout, but do not replace outcome evaluation. Autonomous agents also need traces and evaluation datasets, or evals. Changing the model, instructions, or context retrieval of a shared code-review agent can alter its quality unpredictably. A test set makes it possible to assess the new version before a broad release. Otherwise, users become the testing environment: the team ships, waits for complaints, and rolls back. The less a person supervises each action, the more valuable advance evaluation becomes, together with telemetry that reveals where the agent goes wrong.

Identical tools produce different team results because the technology is only part of the change. In one example, the product manager moved into GitLab: requirements became documentation changes, then specifications for an agent, followed by acceptance. In another, a team worked together and built a fuel-availability service using transaction data. It reached employees in roughly a week and customers a few days later. Polomodov attributes the acceleration to models combined with a redesigned process; one successful case does not establish a universal productivity multiplier. If the connection between product and engineering remains unchanged, spare time does not automatically turn into useful releases. Engineers increasingly state the goal, assemble context, define completion criteria, coordinate agents, and validate outcomes. Training, pilots, feedback, and help from enthusiastic colleagues support this transition better than slogans. People remain accountable, and understanding the domain and platform becomes more important as the range of tasks they can handle expands.