Habr: AI agents are reshaping delivery, forcing teams to rebuild the entire development cycle

A new analysis on Habr explains why, with the arrival of AI agents, engineering teams are no longer bottlenecked by how fast they write code, but by the cost of verification and of passing context along. The author cites DORA 2025, which found that 90% of technology professionals use AI at work and more than 80% credit it with higher productivity. But the faster teams produce code, ADRs and documentation, the heavier the load on review and stability control. The author's proposal: treat AI not as one more tool inside the old process, but as a reason to rebuild the entire change delivery cycle.

The article distinguishes three modes of work. The first is AI-assisted development: the model helps teams gather requirements, draft ADRs, write test cases or documentation faster, but the process itself stays the same. The second is agentic delivery: the agent reads the repository, prepares changes, runs checks and opens PRs, while a human steps in on escalations. As an example of this shift, the author points to GitHub Copilot coding agent reaching general availability. The third mode is the AI-native SDLC: here the LLM stops being a "chat on the side" and becomes the interface to the working loop through which the team moves a task from idea to release.

The piece's central argument is that the economics of this transition revolve around communication, not code. In real-world delivery, the expensive part isn't just the changes themselves, but the handoffs between analysis, development, testing and operations, the repeated reassembly of knowledge, and the constant back-and-forth clarifications. When generation speeds up, the bottleneck moves to approvals, validation and risk control. That's why teams need external, machine-readable context accessible to both people and agents: goals, constraints, risks, definitions of done, ADRs, API contracts, security rules, local validation commands and rollout notes. If critical knowledge keeps living in chats, calls and individual developers' heads, the agent simply works from an incomplete picture.

This leads to a new focus on the harness — the environment in which agents execute. The point is no longer a big system prompt, but a set of rules and constraints built into the process. Repositories should gain explicit instructions for agents, build and test commands, definitions of done, and architectural and security constraints. Recurring scenarios should be codified as skills, playbooks and repo rules instead of being re-explained in every chat. And the constraints can't be purely textual: the system must be able to stop risky actions, block merges without approvals, and hand contentious steps over to a human.

The author devotes a separate section to the control layer. Review should receive not just a diff but an evidence pack: what exactly changed, which scenarios are covered, which checks ran, what risks remain and how to roll the change back. On top of that, teams need quality gates — limits on change size, mandatory validate commands, checks against architectural constraints, and documentation updated in lockstep. Another layer is evals for recurring tasks. They let teams pin down the agent's expected behavior explicitly and check whether the workflow stays stable after each round of changes, rather than sliding into an expensive form of vibe coding with a stream of noisy PRs.

After release, the author argues, teams need to monitor not only the product but the delivery process itself. They should analyze where the agent lacked context, which rules proved weak, which tasks were too large to delegate safely, and where review drowned in noise. This directly affects the organization too: generalist engineers become more valuable, platform engineering and internal tooling take on a bigger role, and onboarding juniors stops being a natural byproduct of everyday work. If teams don't address this, they risk raising not engineers but autocomplete operators.

The practical takeaway from the Habr piece is that AI agents don't make delivery mature on their own. They only amplify the strengths and weaknesses of the existing engineering system. So the next step for teams isn't simply generating code and documents faster, but building a process where context is externalized, the execution environment is constrained, checks are formalized, and every failure improves not just the product but the way it gets delivered.