Work that once took days can now take hours, but delivery controls were designed for human speed. AI leaves the existing risks of software delivery in place and moves the bottlenecks, so the controls have to move too. When implementation gets much faster, context, specification, validation and human judgment have to come in earlier and be built into the process itself.
Project context becomes engineering infrastructure
The faster the implementation, the more expensive ambiguity becomes
Validation has to come from outside the session
The practices below come from Sigma Software’s delivery work. Which of them a team uses depends on the project and, for client work, on the client’s process. One control is constant: every AI-generated change is approved by a human before it is merged.
Project context becomes engineering infrastructure
Beyond its training data, an AI agent knows only what is in its context: what it is given and what it finds in the repository. The code shows what was built, but not why, or which patterns are current and which are legacy. Without explicit context, the agent treats architecture and code style as open choices, produces work that has to be redone, and spends tokens rediscovering the codebase on every task.
On one project, a monotonous UI task, laying out components across a large set of screens, took four working days before AI automation and four hours once the team built a workflow around it.
Context also has limits. With too many constraints the agent cannot work, with too few it drifts. And as a long session fills the context window, the agent starts to lose earlier instructions. So each session stays focused on one task, and a fresh one starts when the task changes or the agent starts to drift.
The faster the implementation, the more expensive ambiguity becomes
An agent rarely stops to ask. A developer working through a vague requirement could notice a contradiction and raise a flag. An agent fills the gap with an assumption and turns it into working code. AI materializes wrong assumptions as fast as right ones. A typical scenario: a product manager generates a specification with AI, it looks complete, and the agent implements exactly what it says. The feature still fails because the specification itself is wrong.
Once the team has reviewed the specification, the agent drafts an implementation plan, and a human approves it. The agent starts coding only when every open question is answered or recorded as an explicit assumption.
Validation has to come from outside the session
Ask an agent to review a feature it has just built in the same session, and it reads the code through the context that produced it. The assumptions behind a bug are already there and look justified, so it concludes the work is done.
The most independent check does not depend on a model at all: acceptance criteria become tests, and every change passes tests, type checks, linters, and static analysis in CI. Review should run in a separate agent with a clean context, never in the session that wrote the code. That sub-agent gets the same project rules and context as the coding agent, but not the session or reasoning in which the code was produced, and it often finds what the coding agent missed. For larger tasks, the agent first submits a plan with its open questions, and the developer approves it before execution starts.
Human review shifts to engineering judgment
AI multiplies pull requests, but not reviewer attention. On one project, the number of pull requests roughly doubled while reviewer capacity stayed the same, and review became the bottleneck.
Review is split into layers. An AI agent pre-reviews each pull request, and the human reviewer starts with its comments. The human reviewer then focuses on the issues that require engineering judgment: whether the change solves the intended problem, its logic and architecture, edge cases, high-risk changes such as migrations and authentication, and whether tests or CI have been weakened.
Pre-review is only as good as the project context behind it. The reviewing agent relies on the same project rules as the agent that wrote the code, though not on its session, and it does not replace human review.
Where the controls sit
Each of these problems is still there, and the process catches them at three points. Before generation, they are caught in the context the agent receives and the specification it follows. After generation, tests and checks in CI as well as an independent agent review the output. Before integration, a focused human review and final human approval before merging provide the last safeguard against issues that remain.
The aim is to rebuild the process so that its controls work at the new speed, without slowing AI down to the pace of the old one. That is the principle behind Sigma Software’s AI-native SDLC: https://sigmasoftware.ai/
