Our Fully Agentic Team Needed More Human in the Loop

Our team shipped fast. Every engineer had their own prompts, their own skills, their own way of deciding what to build. For a while this worked. We were in proof-of-concept mode. Speed was the only question that mattered, and ad-hoc delivered.

Then the codebase grew and the question flipped. Speed stayed constant but alignment fell apart. We shipped roughly 1,700 lines a day with no shared artifact anyone could review before code landed. Rework reached 42.9%. Nearly half of every line we wrote touched something another agent had already touched. The diagnosis was team alignment, plain and simple. The next months we refined our agentic engineering workflow through two deliberate stages. First RPI: Research, Plan, Implement. Then QRSPI ("crispy"), an acronym for: Questions, Research, Structure, Plan, Implement.

Without a shared workflow, our team shipped in different directions

The agents shipped code. A lot of it. Code change was cheap enough that we'd add a feature for a demo and remove it the next week. We'd generate test data, find out it was buggy, and delete it. The architecture was hexagonal, the repo a monorepo. It wasn't chaos. But services still grew in different directions. Frontend components accumulated into oversized files with no consistent structure. The same concept surfaced under different names in different domains.

Team alignment was accidental. You'd catch drift in code review, but that's the most expensive place to discover someone built the wrong abstraction. And it was usually too tedious to review thousands of lines, so most reviews were more lgtm than proper discussions.

We measured after adapting our workflows throughout the different stages and the rework numbers confirmed it: 42.9% of our lines touched code that had been modified in a prior PR. Some was intentional. We churned features, added and removed demo code, generated then deleted bad test data (remember, we were still in a PoC state but that PoC was our foundation for further development). But the rest was structural. Services diverged in how they handled UI. Naming drifted across domains.

A shared plan isn't enough if nobody agrees what "plan" means

After some months, moving out of the PoC into production development, we adopted RPI: Research, Plan, Implement inspired by Dex Horthy. The promise: review a 200-line plan instead of 2000 lines of code. Everyone would write a plan.md first, the team would review it, then the agent would generate code from the approved plan.

For engineers already writing informal plans, formalizing the step cleaned things up. Plans averaged 396 lines, code followed at 3,684 lines. Output was tighter than the ad-hoc baseline but PRs stayed massive and varied in implementation.

It didn't work as promised. Same artifact, same template, completely different standards. Plans helped but were still cumbersome to read. They would mix up implementation details and hallucinate decisions that had no grounding in the codebase.

Even a more refined plan prompt didn't help. To close the interpretation gap we kept adding instructions. What to cover, what not to cover, what format to use. The prompt grew to roughly 85 instructions. An agent can effectively handle around 200. Nearly half that capacity was consumed by meta-instructions before the agent even started reading the ticket.

Rework dropped from 42.9% to 36.5%. Real, but modest for the investment. Planning share rose to only 5.4% (meaning code was still 94.6%). Still, reviewing a short document beat reviewing thousands of lines for every new feature.

QRSPI put more human in the loop, reviewing design before code

QRSPI is the next iteration of the RPI process by Horthy. It isn't a fixed standard, though. Horthy defines seven steps (with Worktree), Alex Lavaee uses eight (adding PR Review), and the community settled on QRSPI as the shorthand, pronounced "crispy." But across all variants, one addition stands out: the Design phase. Separating design from structure gave us the most important checkpoint in the entire workflow. A design document the team could review in minutes, not hours. Ironically, with the design phase being our most important phase, the "D" didn't even make it into the QRSPI-acronym.

One month after adopting RPI, we switched to QRSPI with the phases Questions, Research, Design, Structure, Plan, Implement. Reason was, that RPI had two fatal flaws: instruction overflow in the prompt and premature commitment in the agent. The agent would latch onto the first viable approach because the plan step was a single pass with no structured way to explore alternatives.

The new agentic workflow broke planning into checkpoints. Questions. Research. Design. Structure. Then the plan, built on what we learned at each prior stage. Every checkpoint produced its own reviewable artifact. Every checkpoint was a place where changing your mind cost nothing. You'd read a research summary, realize an assumption was wrong, and steer. That same correction at code review would've been impossible.

QRSPI: Break Up Your Agentic Workflow. Horizontal flow: Questions → Research → Design → Structure → Plan → Implement. Design (green "Team Review Gate") and Implement (green "Code Review") are the two review gates. The Design phase has no letter in the acronym, and that's the point.

The design document became the team's primary checkpoint: roughly 200 lines, purely about tradeoffs, decisions, open risks, and no implementation details. Reviewing that 200-line design document is categorically easier than reviewing a 3,685-line implementation. After design is approved (you would open up a separate PR with it), structure translates those decisions into concrete vertical implementation slices, and the plan becomes execution.

For example, a ticket asked for deduplication in push notifications. The design document skipped implementation and went straight to the decision: should dedup live in the notification service, or in shared infrastructure? Option A put it in the service — one PR, done. But next month two more services would need dedup, each building its own version. Option B built a shared layer once that every service could call. More work today, none tomorrow. The doc recommended B and listed the bugs Option A would ship. Four paragraphs, five minutes, team aligned. Without that checkpoint, the agent would have taken A: the ticket said notifications, so the code went there. Three PRs and a few hundred duplicated lines later, someone would notice the pattern in code review.

Rework fell to 20.5%. Code per PR dropped 71% compared to RPI, yet code per contributor hit an all-time peak. Smaller PRs, more of them, fewer revisions. Planning share jumped to 33.7%. Research alone made up a third of output: 451 lines per ticket. Design reviews caught what code reviews never could.

More to read