October 2026
The SDLC, reimagined for the post-review era.
When agents write the code, the work moves to the plan.
Coding agents made writing code cheap. In most teams we see, people still supervise the whole lifecycle and spend much of their time reviewing what agents produce. Work often starts before the team has agreed on what to build, so faster coding also means more code to revisit.
We think people should spend more time deciding what to build and let agents handle more of the implementation and review. zeroshot, our open-source runner, runs that work as a graph of coding agents with checks and repair steps the team defines. We expect this to reduce the hours and tokens spent getting a change shipped. Our review-loop study supports that argument.
What we see today
Whether a team works in sprints or follows a longer release cycle, the work includes requirements, design, implementation, testing, review and release. In our experience, many design decisions still get made during implementation. A ticket leaves something open, and someone settles it in the code or the pull request.
Agents can produce a lot of code from a short instruction, including decisions nobody asked them to make. Someone has to check those decisions. A few teams we've talked to say they spend less time writing code but now struggle to keep up with review, testing and release.
Asking the same agent to check its work didn't help in our review-loop study. All 100 small-model sessions given that instruction stopped after one pass and scored no better than a plain single attempt.
Same phases, different jobs
| Phase | Today | With zeroshot |
|---|---|---|
| Planning | People | People, with agents researching and drafting |
| Building | People, with an agent typing | Agents |
| Testing and review | People | Separate agents, running your own tests |
| Release | People | People, or your CI/CD |
| Owning what ships | People | People |
traditional
with zeroshot
The person responsible for a release needs to decide what it should do. Agents can research options and draft a plan, but they don't answer to the customer or get paged when the change breaks something.
We want more human review to happen before implementation, while the team is deciding what to build and how to check it. That can be one backlog item or a project split into smaller tasks. Either way, each task needs criteria the reviewers can test against.
You give zeroshot a task in plain text. A worker agent builds the change, and separate reviewers check it against the task using models you choose. Rejected work goes back to the worker with the findings, up to a retry limit. The runtime enforces the required steps and routes the work between them. Teams can add their own tests and reviewers, define repair paths, and save the graph as a profile to reuse.
A good plan says what to change and what counts as done, in terms a reviewer or a test can check, such as "two copies of the same payment event arriving at once create one booking".
Fewer hours
With agents building, testing and reviewing, people can spend more of their time deciding what to build and choosing the checks it must pass. Planning may take longer than it does today. Our expectation is that less time spent supervising implementation and reworking the result will more than make up for it.
Teams can start by keeping a person on every pull request. zeroshot can stop at a branch or a PR, with the configured reviews and checks already complete. As the team gains experience with the workflow, it can decide which changes may ship without someone reading the diff. A passing run means those checks accepted the change. Its reliability still depends on the criteria, tests and reviewers the team chose.
Fewer wasted tokens
Cheaper models reduce token costs, but so does avoiding a build that has to be redone because the task was unclear. One founder we talked to reviews every spec with other models before writing code and reports almost no regressions. That's one person's experience, but it illustrates why we think planning deserves more attention. Writing the criteria into the task gives the worker and reviewers an agreed target before the build starts.
Model choice can also help. On the 20 tasks in our review-loop study, a small model in a build-and-check loop reached a larger model's single-attempt score at a median 58% of the larger model's cost. It took about six times as long to get there.
Predictable results
The review loop also had fewer badly failed runs in the study. We defined those as runs that scored more than 15 percentage points below their setup's average on the same task. None of the loop's 100 runs fell that far below the average. Every setup without an independent check had some, including the larger model. We'd want to see that consistency on a team's own work before relying on the workflow across the team.
The assumption
The latest models already match or beat developers on small, well-defined tasks. A zeroshot run breaks the work into tasks like that. Each agent in the graph gets one job, such as building, reviewing or repairing the change. If the assumption holds up on a team's work, people can spend less time supervising code and more time deciding what the software should do. They still own what ships, including releases no person reviewed line by line.
Where to start
Pick one backlog item. Write what done means into the task, run it through zeroshot, and stop at a pull request your team still approves. Then compare your team's time on it, from idea to merge, with a similar change built the usual way.