How we actually build with AI assistants

This describes our own working method—R&D into how we build, not a client project. Saying “we work with AI” says nothing about quality. What matters is where an assistant sits in the workflow, who checks its output, and what happens when a check fails.

What it is

A documented five-stage workflow in which every stage has one hard gate before the next begins.

• Distillation: client materials become a decision inventory—what to keep, rewrite, merge, or remove.
• Brief: strategic direction and scope; the gate is dated client approval.
• Plan: architecture, data model, milestones with estimates, and delivery ownership.
• Implementation: code, tests, and independent review, milestone by milestone.
• Verification: performance, accessibility, technical SEO, and QA, with one feedback loop to implementation.

The sequence is linear. Fixes return to implementation; new scope returns to the plan, not the brief, unless the business goal changes.

What problem it solves

• “It was fast, but no one knows exactly what it is.” Assistants can generate code faster than it can be reviewed without a procedure. Gates make review mandatory.
• Inconsistent delivery. The same task in two sessions can produce different quality. A definition-of-done checklist maintains a shared minimum and exposes omissions before merge.
• Code without decisions. A decision log records why an option was chosen.
• Building before understanding. The most expensive mistake is correctly building something nobody needed, so the first two stages contain no code.

How we built it

Roles are explicit and asymmetric. One agent coordinates work, divides scopes, and protects the shared contract. Other agents take separate modules or form independent hypotheses when diagnosis stalls. Roles may use Claude Code, Codex, or other tools, but no result bypasses the review of the person responsible for the project.

Important changes receive independent review. The author checks their own work, but another agent or the project owner reviews it too; the human remains responsible for merging.

Parallel tasks normally receive separate file sets. When work meets in an integration file, one owner assembles the change and others pass findings to that owner. Module contracts—types, signatures, and API shape—are set before work diverges.

The quality gate is machine-enforced: CI runs linting, type checks, content validation, and a production build. Performance and accessibility are measured separately in a running environment against thresholds agreed in the brief. Project state lives in durable artefacts: plan and decision log in the repository, code and base content in git, and editor-created content in the database.

This workflow shifts effort to the beginning. Discovery, brief, and planning take time before the first screen exists, and changes to base content need review just like code. For a one-off brochure site, that rigour may not pay back; for an evolving system, it reduces the cost of later misunderstandings.

What it demonstrates

It demonstrates that planning before building is a procedure here, not a slogan—with artefacts that can be opened and checked. It is evidence for design and planning, the stage where we decide what to build and why before estimating full delivery.

The same workflow supports applications built from scratch. The multi-agent layer is described in AI research workflows, and the client-facing version in the process.