How we work
AI writes a lot of our code. The hard part is now the planning.
The work left over is scoping and writing instructions precise enough for a model to follow. That is where we spend our time, and a person makes every call that is expensive to reverse.
The cycle
Six stages, and we take all of them
The stages are not new. What changed is how much of each one a small team can carry, and where the effort now goes.
-
Pitch
We gather the problem with your product people and, where we can, with your customers. The pitch sets an appetite, meaning how much time the problem is worth, and lists the no-gos that this work will not touch. AI is useful here as an interrogator. Asked what is unclear, it lists questions faster than we can reread the brief, and we keep the few that matter.
-
Fat-marker sketch
A drawing too rough to argue about pixels, so the conversation stays on flow and scope. We agree the shape of the solution with your team before anyone opens Figma.
-
Prototype
A clickable demo, often built with AI in a day, that we review with your team. It is meant to be thrown away. A working version now costs less than a long argument over a description.
-
Grill the spec
We write the RFC with the approach, the alternatives we rejected, the migration and the rollback, then stress-test it in "grill me" sessions where AI questions each assumption until the gaps show. Every slice is tied to a key result, and the spec lists the events that slice must emit. A spec that survives this is an instruction a model can follow. A vague one is an invitation to invent.
-
Build behind a flag
Small changes against the agreed spec, tests in each change, and the repository's own conventions holding the shape. AI writes a lot of this code, and a person reviews it like code from anyone else. Everything ships behind a feature flag and rolls out tenant by tenant, with agent-run QA on staging before each step. The flags, migration and rollback are written down for your team, so nobody has to explain them on a call.
-
Measure
The events named in the spec feed dashboards that show whether the key result moved. We read them and we say when the answer is no. If the number did not move, the dashboard shows where users drop off, and that becomes the next pitch. That is where the loop closes.
Try it
What skipping a stage costs
Turn stages off, press Ship it, and watch one example project play out week by week. The simulator also has a page of its own.
AI in the loop
Four places AI carries the work
None of these replaces a reviewer. Each one moves effort from typing to deciding.
- A prototype built with AI, often in a day, so your team reacts to something it can click.
- "Grill me" sessions in which AI questions the spec and hardens it before the build starts.
- Claude Code implementing fixes from a context file we write, so the model works from our account of the problem and not its own guess.
- A reusable QA skill that drives end-to-end tests on staging in the browser and files the report.
Control
Where a human decides
AI takes part in every stage and a person signs off each one. The table below shows how the work splits.
| Stage | What we hand to AI | What a person decides |
|---|---|---|
| Pitch | Drafting the problem statement, listing the questions and edge cases nobody has raised | The appetite, the no-gos, and which questions are worth your team's time |
| Fat-marker sketch | Rough alternative shapes to put side by side | Which shape goes forward to the prototype |
| Prototype | Building the clickable demo, several versions if the argument needs them | Whether the thing is worth building at all |
| Grill the spec | Questioning the RFC in "grill me" sessions, arguing both sides, finding the failure modes | Which trade-off we commit to, the key result each slice serves and the events it must emit |
| Build behind a flag | Most of the code and tests, fixes from our context file, QA runs on staging | The interface, the data model, what gets merged, and which tenant gets the flag next |
| Measure | Queries, aggregation, summarising what the dashboards show | Whether the key result moved, and what goes into the next pitch |
Discipline
Hallucination is a specification problem
Obviously bad generated code gets caught in review in a minute. The costly case is tidy, tested code built on a requirement the model misread, which gets through because the code itself is fine.
The fix is upstream. A bad result usually starts with an ambiguous instruction, a scope too large for one step, or a repository with no written conventions to anchor to. So that is where we put the work.
Written conventions and a record of architecture decisions, kept in the repository, give the model something to follow. New engineers read the same documents, so the work pays off twice.
What that looks like in practice. Style guide and conventions committed to the repository where everyone can read them. Changes small enough that a reviewer can hold each one in mind, with the tests in the same change. Any change that touches money, personal data or a public interface goes through a grilled spec before the build.
And what stays off limits. We do not let generated code touch production without a person reading it. We do not paste client code or customer data into a tool the client has not approved. Report figures and audit findings come from our own checks, never from a model.
We spend more time on the pitch, the sketch and the grilled spec, and less on typing. A person makes each decision that would be costly to undo.
Run this process inside your team
We can set this up in your repositories and train your engineers to run it without us.