We stopped reviewing from memory, and let every feature teach the next one instead

the review that depended on who was looking

Every team has a version of this moment. The code is written, the tests are green, and now someone has to decide whether it’s actually ready. In practice that decision rested on a few people, and on how much attention they had left that day. The busiest files got skimmed by tired eyes. A risky change got the same attention as boilerplate, because in a diff they look the same from the outside. And when the review was done, it lived in someone’s head and in a comment thread nobody would ever reread.

Shipping was worse, in a quieter way. The merge happened, the deploy ran, and whatever the team had learned along the way mostly evaporated. The next feature started from the same place as the last one.

We wrote about our agentic SDLC a little while ago: six staged phases, each with its own gate, AI agents doing the volume work while our team makes every call that matters. Our PM wrote the first close-up, on Discover, one of our senior developers followed with Design, and I wrote about Plan and Build, the first two steps of our /implement command. This one covers the last two phases together, Review and Ship, because they belong together: one decides whether the feature is ready, the other decides what the team does with what it just learned.

I’ll be specific about something up front. One of these two phases is built into the harness as commands and skills. The other one isn’t, and I think the contrast is the most useful thing we can share.

what actually changed: from reading everything to reading the reports first

Review is the last step of /implement. By the time it starts, every task has already passed its own independent reviewer inside Build, which catches the bulk of routine issues at the smallest possible scope. So the feature-wide review isn’t starting from zero. It’s the second look, at the scale of the whole feature.

A reviewer subagent reads the spec, every acceptance scenario and the full design folder, then compares the feature branch against the point where it started. It checks four things. Acceptance coverage: every scenario has to map to a passing automated test, and a missing or hollow one is a blocking finding. Design fidelity: nothing may contradict the architecture decisions we wrote down. UX fidelity: the screens, states and access variations from the UX spec actually exist. And correctness, security and quality at a senior bar, including whether permissions are enforced on the server and not just hidden in the interface.

All of that goes into a review report: blocking findings with the file, why it blocks and what would resolve it, advisory notes, and a table mapping every acceptance scenario to the test that proves it. If blocking findings come back, an implementer subagent fixes them and the reviewer runs again. There’s a hard limit here too: five rounds, then the pipeline stops and tells a human.

Review is where I stop trusting the green checkmarks and start asking what nobody thought to check.

you don’t need to read everything to review everything

You need a finished feature branch and the artifacts from the phases before it: the spec, the acceptance scenarios, the design, the plan. That’s the whole prerequisite.

The reviewer reads all of them, so I don’t have to hold them in my head while I look at the code. That’s the part of review that used to depend on memory: remembering what the spec said about permissions, what the third architecture decision ruled out, which scenario was supposed to cover the edge case someone raised weeks ago. Now it’s a table, and the table has a row for every one of them.

There’s also an optional architect-level review by a stronger model, run on demand for features large enough to warrant a second pair of eyes. It’s separate from this loop, and it isn’t what this article is about.

the moment it earns its keep

We ran this on the same P&L engine already familiar from the earlier phases, on the people management module. The feature-wide review usually needed a single round, and my own part of it took about 30 minutes. Review also flagged a migration we didn’t actually need.

We’ve only taken one feature through Review and Ship so far, so this is a single data point, not an average, and I’d rather say that plainly than dress up one run as a trend. But that unnecessary migration is worth a moment. It’s the kind of thing a test suite has no opinion about. Nothing fails. It’s simply extra change that someone would have had to understand and maintain, and the point of reviewing against a design is that “this wasn’t asked for” becomes a visible finding instead of a thing you notice six months later, if ever.

the human layer is not a rubber stamp

People ask, reasonably, whether the agents approve their own work now. They don’t. The human review is the last layer, and its job is different from the others.

I read the agents’ reports first. Then I spend my attention where agents are weakest: on whatever nobody tuned them for. Those 30 minutes aren’t spent re-reading the diff line by line. They’re spent asking what the report couldn’t have known to ask. The gate is concrete: zero blocking findings, a full suite that’s green, every acceptance scenario showing a pass in the coverage table. If I disagree with the agents, I decide, and the disagreement is recorded.

ship: the phase we still run by hand

Here’s the honest part. Phases one through five exist in our harness as commands and skills. Ship doesn’t. There’s no /ship command, no automated progressive rollout, no skill that wires alerts to acceptance criteria. Ship is a human practice, and we run it by hand.

It goes like this. The developer responsible for the ticket merges it, and only a human can: a git hook physically blocks commits to the main branch, so everything reaches it through a pull request that carries the phase checklist and a link back to the feature folder. Then our existing CI/CD takes over. Finally, the Product Owner confirms the feature does what the spec promised, which is the real gate for this phase. On this feature, they did.

I could have left this section out, or dressed it up. But “evidence over claims” is one of the principles this whole methodology runs on, and it would be strange to break it here. Closing that gap is on our roadmap. Until then, we’d rather tell you which phase is manual than let you assume it isn’t.

the retro that ends in a change

The last step of Ship is the retrospective, and it’s where the whole thing earns its name. For us, a retro isn’t a meeting that ends in notes. Its output is a pull request against the harness itself: the conventions file, the skills, the commands, the agents. It’s reviewed like any other code change, and the next feature starts with it already merged.

On this feature, the retro changed how our tickets get generated, so they come out less granular. One change, from one feature. That’s the entire mechanism by which this compounds: not a big transformation, but a small edit every time that the next run inherits automatically. The step in Build that turns acceptance scenarios into real end-to-end tests exists for the same reason. It started life as a retro edit.

what you walk away with: a trail you can follow

Three artifacts come out of these two phases.

A review report. Suite status, blocking and advisory findings, and the coverage table that maps every acceptance scenario to the test that proves it.

A merged pull request. It carries the phase checklist and a link to the feature folder, so anyone can find the reasoning behind it.

A harness edit. The change the retro produced, committed and reviewed like code.

Put together with the earlier phases, the trail is complete: spec, acceptance tests, design, plan, every task’s commit, the review report, the merged pull request. Six months from now, “why does this work the way it does?” has an answer in the repository.

the gate didn’t move, the thinking did

There are two gates in these phases, and both belong to a human. For Review, it’s the senior developer: no blocking findings, a green suite, a fully covered table. For Ship, it’s the Product Owner: the success criteria from the spec are observed in practice, and the retro produced at least one concrete change, or an explicit note that none was needed.

What changed is where the effort goes. Review used to cost attention on remembering and re-reading. Now that cost sits with the reports, and my attention goes to judgment. Ship still costs what it costs, because it’s manual, but the retro makes sure the cost buys something.

doing this as a tech lead

I want to be direct about what this asks of me. In Review, it asks me to be the layer that looks for what no agent thought to flag, and to resist treating a clean report as the end of the job. In Ship, it asks me to be honest about what’s still manual, and to treat the retro as work, not as a ceremony that’s easy to skip when the feature went well.

The retro is the one I’d underline. A feature that went smoothly is exactly when it’s tempting to skip it. It’s also when a small edit is cheapest, because nothing is on fire.

why this matters beyond one phase

Six phases, six gates. Discover gave us a validated spec. Design gave us decisions with reasons attached. Plan gave us an order. Build gave us proof, one task at a time. Review gave us evidence at the scale of the whole feature. And Ship gives us the part that most delivery processes lose: what we learned.

The first five phases make one feature better. The last one makes the next feature better. If I had to pick the single idea behind the whole methodology, it would be that: a process that edits itself a little after every feature, instead of one that stays exactly as good as the day someone wrote it down.

what’s next

This closes our series looking at each phase of our agentic SDLC in turn, each written from the seat of the person who owns that gate.

If you’re a tech lead who has watched a review depend on whoever had time that week, or a leader wondering what “human in the loop” looks like at the end of a delivery, not just the start, we’d be glad to talk.