How We Use AI to Build Software Safely: Agents, Gates & Review

AI can write code fast. That was never the hard part. The hard part is shipping AI-written software you can actually trust — code that's tested, reviewed, and safe to put in front of real users. On a recent large product build, we built an AI engineering system to solve exactly that: AI does the heavy lifting across research, development, and testing, but a pipeline of automated guardrails, independent review, and human approvals makes sure nothing unsafe ever ships. Here's how it works.

AI as focused workers, not one all-knowing chatbot

The mistake most teams make is treating AI as a single oracle — one chat that's supposed to do everything from planning to production. We do the opposite. Our system is a pipeline of focused AI workers, each with one narrow job and a clear specification. Documents are the hand-off between stages, the orchestration is plain code (not the AI deciding what happens next), and a named human approves every gate. Intelligence lives inside the workers; control lives in the system around them. That separation is what makes it safe.

The research half: from idea to a buildable spec

Before a line of product code is written, the work moves through a research pipeline with a human gate at each step:

• Discovery — an analyst worker drafts requirements and clarifies the actual problem, benchmarked against how the best products in the space solve it.
• Design — a design worker turns approved requirements into user experience and interface specs, checked against a written design standard.
• Architecture — an architecture worker proposes the technical approach and trade-offs, captured as decision records a human signs off on.
• Hand-off — the output is a self-sufficient ticket an engineer can build from, with every decision already made and approved.

AI accelerates each of these — but a human approves the requirement, the design, and the architecture before anything proceeds. Bad software usually traces back to a decision no one actually made; this pipeline makes those decisions explicit and owned.

The build half: test-first, with anti-cheat guardrails

Development runs test-first — a failing test defines "done" before the code exists, and the AI implements until the test passes. The twist is a set of automated guardrails that make it impossible to cut corners:

• The tests can't be edited during implementation — so the AI can't "pass" by weakening the test. Done means the real test is green.
• Secrets and sensitive data are blocked automatically before they can ever land in code.
• Structural rules are enforced mechanically — schema changes require a recorded decision, and protected files stay protected.

These aren't guidelines a reviewer has to remember — they're hooks that physically stop the wrong thing from happening. A guardrail that depends on someone remembering it isn't a guardrail.

Adversarial review: a second AI whose job is to break it

Once a change is built, it goes to a separate reviewer worker with fresh context — it sees only the change and the specification it was supposed to meet, never the reasoning of the AI that wrote it. Its entire job is to find what's wrong: missed edge cases, spec violations, quiet bugs. Because it starts from a clean, skeptical perspective, it catches the things the author (human or AI) is blind to. It's the same reason a good code review works — independence beats familiarity.

Evidence, not vibes

Every change ships with a pull request that reads as an evidence packet: what was asked, what was built, which tests prove it, and what the review found. Nothing merges on a claim of "it works." And the AI workers themselves are tested — each one has a golden set of examples with deliberate traps, and its output is graded against that set before its instructions are ever allowed to change. The system is versioned, reviewed code — not a loose folder of prompts that quietly drift.

The one rule that never bends: a human approves every merge

The AI never merges its own work, never approves a review, and never closes a ticket on its own. A named engineer signs off on every merge. Think of the AI as the fastest, most tireless junior on the team — it produces enormous output — while a senior engineer stays accountable for what actually ships. That single rule is the difference between AI that accelerates a serious engineering team and AI that quietly fills a codebase with plausible-looking problems.

Why this matters for you

This is the machinery behind "AI speed, human craft." It's why we can move fast without the failure mode everyone's rightly worried about — AI slop shipped to production. You get the speed of AI-assisted engineering across research, build, and testing, the quality of a test-first, independently reviewed process, and a full evidence trail for every change. Fast, and safe to trust — because the system is built so it can't be otherwise.