Ship the pipeline, not just the code

At Recur, I stopped shipping features alone. I ship the multi-agent pipeline that ships features.

Here's what that looks like in practice: when I get a new feature request, I don't open my editor and start coding. I define the task, feed it into an orchestration layer, and let a fleet of specialized agents handle the stages — architecture design, implementation, code review, test generation, and QA.

The shift

My unit of output changed from PRs to systems that produce PRs. Each agent has a narrow scope and a clear contract. The architecture agent doesn't write code. The implementation agent doesn't question the design. The reviewer is adversarial by default. The QA agent generates edge cases the implementer didn't think of.

This isn't about replacing developers — it's about compressing the feedback loop. A cycle that used to take days (write, review, revise, test, ship) now takes minutes, with higher consistency and better coverage.

What I learned building this

The hard part isn't the agents — it's the orchestration. Getting agents to work together reliably requires:

• Structured handoffs — each stage produces a well-defined artifact the next stage consumes
• Verification gates — never trust an agent's self-assessment; always verify with a different agent
• Context management — agents need the right context, not all the context
• Failure recovery — when an agent produces garbage, the pipeline needs to detect it and retry or escalate

The result? The team at Recur uses these pipelines daily. Not because they're told to — because the output is genuinely better than doing it manually. That's the bar: if your automation doesn't improve the outcome, it's just overhead with extra steps.

The meta-lesson

The engineers who will matter most in the next decade aren't the ones who write the best code. They're the ones who build the best systems for producing code. The leverage is in the pipeline, not the PR.