Workflow mastery for AI engineering.
For engineering leaders. Agentic SDLC.
Adoption is settled. The 2025 DORA report found that 90% of technology professionals use AI at work and more than 80% believe it has made them more productive. The same study found that higher AI adoption raises software delivery throughput and software delivery instability at once. DORA's own summary puts it plainly: time saved writing code is being spent auditing it, and AI amplifies whatever system it lands in.
So the question for a CTO is no longer whether to use coding agents. It is what the surrounding method has to look like before agent output is safe to merge. Krithi, the coding agent behind our Velocity Pods, answers that with one workflow and five gated stages: requirements extraction, planning, coding, testing, production. A human signs off at each gate. This piece walks through why each gate exists, using the evidence on how models actually behave and the workflow shape Matt Pocock laid out in his 2026 AI coding workshop.
One workflow, five gated stages
Every pod runs the same sequence end to end, from legacy code and customer input to production. An orchestration agent sits behind all five stages and keeps ticket and status data in sync with the client's Jira, or with our tracker when they prefer it.
| Stage |
What happens |
Gate |
| Requirements extraction |
Reads the legacy codebase and customer voice, then drafts requirements with full traceability |
Human review |
| Planning |
Turns approved requirements into a sprint plan and per-sprint tickets |
Plan approval |
| Coding |
Builds each ticket into working code, then merges it to the dev branch |
Repeats each sprint |
| Testing |
Runs automated UI, API and regression checks, then opens the PR to main |
QA sign-off, repeats each sprint |
| Production |
Merged to main by a human reviewer, live in the client's own environment |
Human merge |
Why the stages are small, and why they are gated
A model does its best work at the start of a session, when its context is clean. Quality then falls away as the window fills. Chroma tested 18 frontier models, including GPT-4.1, Claude 4, Gemini 2.5 and Qwen3, and found that none of them use context uniformly: reliability drops as input length grows, even on tasks whose difficulty is held constant. Practitioners tend to put the noticeable cliff somewhere near 100,000 tokens, well short of the advertised limit.
Coding agents are the worst case for this. Every file read, every grep result and every failed attempt stays in the window for the rest of the session, and code search returns many near-identical candidates. A larger context window does not fix it. Anthropic's engineering team calls the same problem context pollution and recommends treating context as a finite resource to be curated, using compaction, external notes and subagents that keep their search noise to themselves.
That is what the five stages are for. Each stage is a bounded task with its own clean context, and each gate is the point where a human decides whether the next stage should start from what the last one produced.
The same constraint shapes ticket size inside a sprint. If a unit of work cannot be finished in one clean session, it is not a ticket yet. Splitting it is planning work, and planning is gated for a reason.
Stage one: requirements extraction, and the human review gate
The failure mode we see most often in enterprise pilots is a brief going straight into an agent. A Slack message becomes a plan, the plan becomes ten files, and the first real conversation about scope happens in code review. Krithi starts further back: it reads the legacy codebase and the customer input, then drafts requirements that trace back to both, so every line of the specification has a source you can check.
Traceability is what makes the review gate quick. Before the draft, the agent interviews the requester, one branch of the design tree at a time, and every question it asks comes with its own recommended answer. You spend your attention accepting, rejecting or amending rather than generating. The session ends when both sides hold the same picture of the feature, what Frederick Brooks called a shared design concept, and it surfaces the questions that otherwise appear late: does this apply retroactively to existing records, who owns the reconciliation job, where does the interface live.
The document that comes out carries the problem statement, the user stories in plain language, the data and schema decisions, how the feature will be verified, and an explicit out-of-scope list that defines done. Review it for correctness, not for prose. If the interview was honest, this is a check on alignment rather than the artifact that carries it.
Stage two: planning, and the plan approval gate
Approved requirements become a sprint plan and a set of tickets. Left alone, an agent plans in layers: all the schema work, then all the API work, then the interface. It reads well as a project plan and it is the wrong shape, because nothing runs end to end until the last phase. Feedback arrives at the point where it is most expensive.
Each ticket should instead cut through every layer: one field, its migration, its route, its test, and something visible in the interface. Each slice compiles, runs and proves a path through the stack, so the work either passes end to end or it does not. That is what the approval gate checks first, before it checks estimates.
The plan also records what blocks what. A flat list can only be worked in sequence by one agent. A dependency graph tells the orchestration agent which tickets are independent, and independent tickets run in parallel workspaces. Once you approve the plan, the backlog stops being documentation and becomes the scheduler.
Stage three: coding, which repeats every sprint
Implementation runs without you. Each agent works in a sandboxed container against a clean worktree, so it can install packages, run migrations and execute the suite without touching anything shared, and merges to the dev branch when the ticket passes. Work is picked in a fixed order: critical fixes, then developer infrastructure, then feature slices, then cleanup.
Inside a ticket the loop is ordinary test-driven development. Write the failing test first, so you know the harness can detect the missing behavior. Implement the smallest change that turns it green. Then clean up, fix the type errors and run the checks again. None of this is new, which is the point: the discipline that made human teams fast is what makes an agent's output verifiable.
Your feedback loop is the ceiling on agent quality. Weak coverage, slow suites and no type checking put a hard limit on how good the generated code can be, no matter which model you buy.
DORA reached the same conclusion from the other direction. Without strong automated testing, mature version control and fast feedback, a rise in change volume produces instability. Agents raise change volume by design, which is why coding sits between two gates rather than after the last one.
Stage four: testing, and the QA sign-off gate
Automated UI, API and regression checks run against the dev branch, and a pull request to main opens only when they pass. The checks are necessary and they are not sufficient, so two things sit alongside them.
The first is review in a fresh context. Asking an agent to review its own work in the same session is the weakest review available: it is deep in a polluted context and already committed to its choices. Open a new session on a stronger model and give it the diff plus your standards and nothing else. Implementation pulls context as needed; review pushes it. Security rules, architecture boundaries and house conventions belong in the reviewer's system prompt, not in a document it might read.
The second is a person running the software. GitClear's analysis of four years of commit data shows what gets skipped when nobody does: duplicated blocks rose from 40.3 to 73.0 per million changed lines between 2023 and 2026, refactored line moves fell from 21% of changed lines in 2022 to 3.8%, and cross-file function calls, a proxy for reuse, dropped 35% over the same window. Code that compiles and passes tests can still be code nobody can maintain, and no automated check will tell you that the flow feels wrong.
Stage five: production, merged by a person
The merge to main is a human action, into the client's own environment. That is a deliberate limit on the automation: the last decision about what reaches users belongs to someone who can be asked why. Anything found after release goes back on the board as a ticket rather than getting patched by hand, which keeps the loop closed and keeps the backlog the single record of what the agents work on next.
Architecture decides how far this scales
Codebases made of hundreds of thin files, each exporting a little, are hard for agents in a specific way: the dependency graph is the work, and tracking it burns the context budget before any code is written. Testing them means mocking everything, and mocks are what agents quietly break. John Ousterhout's deep modules are the better target. A wide body of internal logic behind a narrow interface gives the agent one contract to satisfy and gives you a clean boundary for integration tests with no mocking at all.
That also settles the division of labor across the five stages. Your architects own the interfaces and the boundaries between modules, which is most of what the planning gate is really approving. The agent implements what sits behind them. You keep an accurate map of the system in your head, which is what makes review possible at speed.
What the evidence supports, and what it does not
Be careful with the numbers in either direction. METR's randomized trial remains the most rigorous field measurement available: 16 experienced developers, 246 real tasks in repositories they had worked in for about five years. Allowing AI made them 19% slower, while they believed it had sped them up by 20%. METR has since qualified that result. Its February 2026 update reports selection effects in the follow-up cohort, weaker evidence than they wanted, and a belief that developers are more sped up in 2026 than in 2025.
Read together, the honest summary is narrow. Perceived speed is an unreliable measure. Individual output rises. Delivery stability does not follow on its own. Nothing in the record supports the claim that buying agents raises engineering performance, and nothing supports the claim that it cannot. The gates are how we take the first half of that seriously.
Start here
- Name the five gates in your own process, and name the person who holds each one.
- Ban the brief-to-agent path. Every feature starts with an interview and ends with traceable requirements.
- Re-cut the next two sprints as vertical slices, and record the blocking graph so independent tickets can run in parallel.
- Measure your feedback loop before buying more agent capacity: coverage, suite runtime, type checking, and how long a red build stays red.
- Keep the merge to main and the manual QA pass with named humans, and put every defect back on the board.
Sources
- DORA, State of AI-assisted Software Development 2025, and Balancing AI tensions, Google Cloud, September 2025.
- Chroma, Context Rot: how increasing input tokens impacts LLM performance, July 2025.
- Anthropic, Effective context engineering for AI agents, September 2025.
- Becker, Rush, Barnes and Rein, Measuring the impact of early-2025 AI on experienced open-source developer productivity, METR, July 2025, and the February 2026 design update.
- GitClear, The Maintainability Gap, 2026.
- Matt Pocock, Full Walkthrough: Workflow for AI Coding, AI Engineer, April 2026, for the smart zone framing, credited by Pocock to Dex Horthy, and the interview-first alignment step.
- John Ousterhout, A Philosophy of Software Design, on deep modules. Frederick Brooks, The Design of Design, on the shared design concept.
Rejith Krishnan is founder and CEO of lowtouch.ai. Krithi runs this workflow on client engagements in regulated environments.
