Building SaaS with AI coding agents: nine lanes, five audit rounds, one person who accepts every change

Sunny Ray · Oct 29, 2026 · 7 min read

Yes, you can build production software with AI coding agents. We build gtm showrunner that way. On October 27 we shipped campaign learning plus seven more features in one day, built in nine parallel agent lanes, merged, deployed, then audited by a model from a different vendor for five rounds until the last warnings were fixed. The full test suite ended at 7,378 passing, with one flaky test.

The part that makes it safe isn't the agents. It's the rules around them. Agents do the labor. A person decides what ships. And inside the product, the same rule holds for our customers: the software proposes, a person accepts, and the writes that could hurt your sending stay switched off until you turn them on. Here's how a build day runs, and what still breaks.

One day, nine lanes

A lane is one piece of work with a clear outcome, given to one agent, in its own copy of the codebase. On October 27 there were nine. Campaign learning was the big one. Others included a zero-setup onboarding flow, a guest-to-cash path that nudges you when a conversation stalls, a Kanban view for tasks, referral moments, an ask-anything panel, a deliverability autopilot, automatic call prep and debriefs, and a faster phone experience.

Each lane got a brief: what done looks like, what it must not touch, and why the work matters. Not a step-by-step script. The agents plan their own lane. When a lane finishes, it hands back the work and the proof: tests run, pages opened, files changed.

Then the lanes get merged into one branch, the whole suite runs, and only then does anything go to production.

Parallel lanes are where the speed comes from. Nine things that would each take a person a day or two happen in the same day. But parallel also means nine chances to step on each other, which is why lanes never share files and why the merge is its own step.

Audits from a different model family

Here's the rule I'd tell any founder building this way: don't let the same kind of model check its own work. Models from the same family tend to share blind spots. If one misses a class of bug, its sibling often misses it too.

So after the merge, an auditor from a different vendor reviewed the work. It went five rounds. Each round it found issues, the fixes went in, and it looked again. Two separate verifiers from the original family checked the claims as well: does the page render, does the test pass, is the feature live.

The final audit verdict still raised two warnings. Both got fixed before we called it done. One was about making sure the day's learning card stays pinned. The other moved a DNS check inside a timeout so a slow lookup couldn't hang the page.

Along the way, the work also cleared 14 old type errors that had been sitting in the codebase. Two of them were hiding real bugs: one endpoint crashed, and one signal was missing three investor fields. Nobody had noticed because the errors had been there so long they'd become background noise.

Proposals, not autopilot

The biggest design decision in campaign learning is that it never acts on its own. It looks at your campaigns and their outcomes, whether invites turned into bookings, tapings and paid deals, and it suggests changes. A lesson for your targeting filters. A proposal to scale a sending domain. One card a day on your Today page.

Every one of those is a proposal a person accepts. Nothing writes to the sending tool by itself.

That's deliberate. A learning system that changes your campaigns while you sleep will eventually change one wrong, and you'll find out from a burned domain or a strange email to an important guest. A system that proposes and waits costs you a tap. I'll take the tap.

There's also a weekly page that shows booked conversations per 1,000 sends. That's the one number I'd want any founder watching, because it tells you whether the whole engine, list plus copy plus sending, is getting better or worse.

The writes we keep switched off

The deliverability autopilot is the clearest example. It scans every sending domain and mailbox every six hours, checks DNS, and surfaces problems as proposals, with a card for admins and a sending health panel.

It can do two things that change your setup: pause a mailbox, or turn on warmup. Both are off by default. To use them, you have to switch on live mode and then confirm with a tap. Until then, the autopilot tells you what it would do and waits.

Referral asks follow the same rule. The product drafts a one-tap, double opt-in ask, as a Gmail draft. You send it. The ask-anything panel can suggest actions, but anything that writes stays pending until you confirm.

Our position is simple. Agents are great at noticing, drafting and proposing. The send button and anything that touches your reputation belong to a person.

What still breaks

Plenty. Some honest examples from that day:

• One flaky test. A revenue test fails occasionally and passes when run alone. It was already there before the build day. It's still on the list.
• Anonymization was harder than expected. Campaign learning was meant to show anonymized examples across campaigns. Our scrubber failed four audits. So we changed the design: examples of copy now come only from the viewer's own campaigns.
• Onboarding still has a human gate. Zero-setup onboarding goes from your website and Calendly to three drafts. But launching still needs approved guests. Whether to auto-approve the top prospects for a new client's first campaign is still an open decision.
• Some things were verified by tests, not by eye. A few new panels were checked in the test suite but not yet opened in a real browser. They're marked for follow-up rather than called done.

I'd rather write that list down than pretend agents produce perfect code. They don't. Neither do people. The difference is the system around them: small lanes, cross-vendor audits, real tests, a human who accepts the change, and a habit of writing down what isn't verified yet.

How to write a lane brief

Most of the quality comes from the brief, not the model. A good lane brief has three parts. The outcome: what a user can do when this is finished, in one or two sentences. The constraints: which files the lane owns, what it must not touch, what it must never do (for us, that always includes never sending anything and never writing to a customer's sending tool). And the reason: why this matters, so the agent can make sensible calls when the brief doesn't cover something.

What a brief should not be is a script. When you dictate every step, you get exactly what you wrote, including your mistakes. When you give an outcome and a reason, a good agent plans the work and often finds a cleaner path. Then the audit catches the cases where it didn't.

What this means if you're a founder

You don't need a big engineering team to ship serious software anymore. You need clear briefs, small units of work, a way to check the work that doesn't trust the worker, and the discipline to keep the dangerous switches off by default.

That last one is the part most AI products get wrong. They automate the send because it demos well. We automate everything up to the send, and leave the send to you.

If you want to see what that looks like from the user's side, every invite drafted, every reply drafted, nothing sent without you, try the product.

Frequently asked questions