Habr: AI agents change delivery, and teams must rebuild the entire development cycle

On Habr, there was a breakdown of why with the arrival of AI agents, engineering teams are hitting a bottleneck not in the speed of code writing, but in the cost of review and context transfer. The author references DORA 2025, where 90% of technology specialists use AI at work, and more than 80% link it to productivity growth. But the faster code, ADR, and documentation are created, the stronger the load grows on review and stability control.

Therefore, AI is proposed to be viewed not as another tool within the old process, but as a reason to reassemble the entire change delivery cycle. The article distinguishes three modes of operation. The first is AI-assisted development, where the model helps faster gather requirements, write ADR drafts, test cases, or documentation, but the process itself remains the same.

The second is agentic delivery, where the agent reads the repository, prepares changes, runs checks, and opens PRs, while humans get involved in escalations. The author mentions the rollout of GitHub Copilot coding agent to general availability as an example of such a shift. The third mode is AI-native SDLC: here the LLM stops being a "chat on the side" and becomes an interface to the working loop, through which the team moves a task from idea to release.

The main thesis of the text is that the economics of such a transition is built not around code, but around communication. In real delivery, what is expensive is not only the changes themselves, but also the transfer of work between analytics, development, testing, and operations, the rebuilding of knowledge, and constant clarifications. When generation accelerates, the bottleneck shifts to agreements, validation, and risk control.

Therefore, teams need an external, machine-readable context available to both people and agents: goals, constraints, risks, readiness criteria, ADRs, API contracts, security rules, local validation teams, and rollout notes. If critical knowledge continues to live in chats, calls, and the memory of individual developers, the agent simply works with an incomplete picture. This leads to a new focus on harness—the agent execution environment.

It is no longer about a large system prompt, but about a set of rules and constraints built into the process. The repository should have explicit instructions for agents, build teams and tests, readiness criteria, architectural and security constraints. Repeatable scenarios are proposed to be formatted as skills, playbooks, and repo rules, rather than explained anew in each chat.

Moreover, constraints should not only be textual: the system should be able to stop risky actions, prohibit merges without confirmations, and route disputed steps to humans. The author separately discusses the control layer. Review should not receive just a diff, but an evidence pack: what exactly changed, which scenarios are covered, which checks were run, which risks remain, and how to roll back the change.

On top of this, quality gates are needed—limits on change size, mandatory validate commands, checking of architectural constraints, and synchronous documentation updates. Another layer is evals for repeating tasks. They allow explicitly fixing the expected behavior of the agent and checking whether the workflow remains stable after each change, rather than sliding into an expensive version of vibe coding with a stream of noisy PRs.

After release, according to the author, one should monitor not only the product but also the delivery process itself. The team should analyze where the agent lacked context, which rules turned out to be weak, which tasks were too large for safe delegation, and where review drowned in noise. This directly affects the organization: the value of broad-profile engineers grows, the role of platform engineering and internal tools strengthens, and junior onboarding stops being a natural side effect of work.

If this is not done, the team risks growing not engineers, but operators of autocomplete. The practical conclusion from the Habr text is that AI agents by themselves do not make delivery mature. They only amplify the strengths and weaknesses of the existing engineering system.

Therefore, the next stage for teams is not just to generate code and documents faster, but to build a process in which context is exposed, the execution environment is constrained, checks are formalized, and each failure improves not only the product, but also the way it is delivered.