AI is the tool.
We are the engineers.
We use AI heavily and we say so, because a process you can describe is a process you can audit. The design, the tradeoffs and the sign-off stay human.
"We use AI" is either a boast or a confession, depending entirely on whether the person saying it can describe what the machine is allowed to decide. So here is ours, in detail, including the parts that are uncomfortable.
The short version: we write the design, AI writes a first draft against it, AI reviews that draft for gaps and for the specialist concerns — security, performance, documentation — and then a named human reads it, runs it, and approves it. AI moves faster than we do in several of those steps. It does not get the last word in any of them.
What that looks like in practice
Before any code exists, we write down the design: the state model, the boundary between components, the failure modes that matter, and what "done" means in terms we can test. That note is the artefact everything else is measured against. It is also the thing AI is worst at producing, because it requires deciding what to build and what to leave out.
Only then does generation start. The brief constrains the output; without it you get plausible code for a problem nobody specified.
Generation against a design
AI writes the first draft of the implementation against our written intent and target. We review it for whether it solves the stated problem, not whether it looks clever.
Review for intent and gaps
A separate pass asks whether the change actually matches expectations, and hunts for what slipped through: the unhandled error path, the case the tests skip, the config that only works on a laptop.
Security and vulnerability
Injection surfaces, authorisation checks, secret handling, unsafe deserialisation, dependency risk. This is the review AI is genuinely best at, because it does not get bored on the eleventh file.
Performance
Query plans and index coverage, N+1s, allocation in hot loops, payload sizes and render cost — reviewed against the actual access pattern rather than in the abstract.
Documentation
READMEs, runbooks, architecture notes and the rationale behind a decision, drafted from the diff and then edited by us for the things a diff cannot tell you.
Human sign-off
Every change has a named person who read it, ran it and approved it. That person is accountable for it. No exception, and no "the model wrote it" defence.
What AI does not do
- Decide what to build. Requirements, scope and tradeoffs are decided by people who can be held to them.
- Own a decision. When an architecture choice turns out to be wrong, there is a human who made it and can explain why.
- Replace running the software. Tests, a real environment and a real load profile still decide whether something works.
- Get trusted blindly on the irreversible. Migrations, credential handling, payment paths and anything that destroys data get line-by-line human reading.
The honest risk
Generated code is confidently plausible. It compiles, it reads well, and it can be wrong in a way that only shows up in production three weeks later. The mitigation is not a better prompt — it is review against a written intent, and a test that fails before the fix and passes after it. Everything else is vibes.
That is also why we write the design down first. If the intent only exists in a conversation, there is nothing to review the output against, and the review becomes "does this look reasonable" — which is exactly the review that lets gaps through.
Your code and your data
Where a client's source, infrastructure or data is involved, what may go to a third-party model is agreed in writing before any of it does. Credentials and secrets never go to a model, full stop. If your constraints mean a given tool is off the table, that is a requirement we work within rather than a problem we work around.
Where you can see the result
This is not a hypothetical process. Everything on this site was built with it, and two of the products are public:
- NanoGenesis — a browser idle game with a sixty-element economy, a ten-star progression and an offline simulation. The design and the direction are ours; AI carries the implementation and the artwork.
- MochaFlux — an invite-only data platform that ingests Amazon reports into Snowflake, where the failure modes are expensive and the review discipline is not optional.
If you want the same process applied to your project, the contact form is the place to start.
Common questions
Does AI write your code?
It writes first drafts against a design we wrote. The design, the review and the sign-off are human, and no change ships without a named engineer who read and ran it.
Who is accountable for a change?
A person, by name. "The model wrote it" is not a defence we accept internally, and it is not one we would offer a client.
Is client code or data sent to a model?
Only what is agreed in writing beforehand. Credentials and secrets never go to a model under any circumstances.
Does this replace testing?
No. Tests, a real environment and a real load profile still decide whether something works — AI is a faster way to get to the review, not a substitute for it.
Want to see the process up close?
Tell us what you're building and we'll show you how we'd approach it — including where we'd use AI and where we wouldn't.
Start a Conversation