How we build with AI, and what stays with a person
Quantum Craft is a software and AI development agency in London. AI does much of our coding, and a person keeps the last word on anything an investor or regulator could ask about. Every change starts from a written specification and ships only after senior review and automated tests.
AI-native delivery is AI-assisted software development in which AI does much of the coding while engineers own the specification and approve every change before it merges.
Last reviewed
- Discovery
- One to two weeks
- Review
- A senior engineer, before any merge
- Tests
- Must pass before anything ships
- Your code
- Yours on full payment
The four phases of an AI-assisted software project
The phases are older than AI coding tools, and we kept them on purpose. With AI doing much of the typing, the specification is worth more than it was: AI builds exactly what it is told, mistakes included.
Discovery and specification
One to two weeksWe work through the product with you and write it down: user flows, acceptance criteria, architecture, estimate and risks. You agree it before any code is written, and you keep it whoever builds.
- AI's part
- Drafts sections from workshop notes and points out gaps; people decide what goes in.
Kickoff
First week of the buildRepositories, environments, the test pipeline and a milestone plan, all working before any feature code. The code can go into your own repository from the first commit.
- AI's part
- Generates repetitive setup, which an engineer reviews like any other change.
Build
Two-week cyclesEach cycle ends with a demo of working software, the test results and a note of decisions and open risks, so you judge progress by using the product.
- AI's part
- Drafts code and tests against the specification, including wide, repetitive changes, each reviewed by a senior engineer before it merges.
Launch and handover
Final cycleRelease to production, performance and security checks, then documentation another team could work from.
- AI's part
- Drafts documentation and helps check the release against the specification. It never touches production.
How we review AI-generated code before it ships
A senior engineer reads every change AI drafts against the specification before it merges, and the automated tests must pass first. AI is quick at work that is wide and well specified, and poor at noticing when it is wrong, so the judgement in every row stays with a person.
| Work | AI's part | An engineer's part |
|---|---|---|
| Specification | Drafts sections and points out gaps | Agrees scope with you and writes the acceptance criteria |
| Architecture | Sets out options when asked; never chooses | Chooses, and records why |
| Code | Drafts much of it, including wide changes such as a rename across the codebase | Reviews each change before it merges |
| Tests | Drafts tests from the acceptance criteria | Decides what must be tested and reviews the tests |
| Merges and releases | Never | Merges after review and passing tests; runs every release |
| Production and client data | No production credentials, and no client personal data | Operates production and decides who sees what |
Some actions stay with a person whatever the task: writes to version control, operations on running infrastructure, new dependencies and changes to sign-in or permissions. An AI use policy for a 30-person company shows how to draw the same line in your own business.
Seven commitments you can hold us to
Most of them govern how each change is made. The rest cover what you own and where your product runs.
Specification first
Nothing is built until the specification is written down and you have agreed it.
AI under business terms, and never in production
AI works on your code only through business accounts whose terms bar training on it. It never holds production credentials, and client personal data stays out of it.
Senior review on every change
A senior engineer reviews every change before it is merged, whether a person or an AI tool drafted it.
Automated tests on every change
Automated tests run on every change. A failing build does not ship.
Decisions written down
Decisions are written down with their reasons, so the next engineer, yours or ours, can follow them.
The code is yours
The code we write for your project is yours on full payment, and it is documented so a competent team can run it without us. Our own tools and methods stay ours.
UK hosting when your data needs it
BlueWave and Karu run in Google Cloud's London region, and your product can too.
Where does AI run, and can it see our data?
AI runs under business accounts whose terms bar training on your code, and it sees what a task needs: the code and the specification. It never holds production credentials, so it has no route into your live systems.
Client personal data stays out of it. Production stays with people: releases, infrastructure changes and anything touching live customer data are handled by an engineer and never delegated to AI.
We do not list our AI tools on this site. They change every few months; the commitments on this page do not.
What evidence do you get?
Three records, kept as the work happens rather than written up at the end. A due diligence reviewer will ask for all three.
The specification
What was agreed before anything was built, including the acceptance criteria each feature is tested against.
Decision records
Each architecture decision, the options considered and the reason one won. BlueWave's build has ten.
Test results
A test run for every change, including the one that shipped. BlueWave has more than 1,000 automated tests; NForge has 1,258 backend tests.
If you are raising, the technical due diligence checklist shows where investors use each record, and seven red flags that stop a funding round shows what missing ones cost.
Vibe coding vs AI-assisted development: how our way differs
The difference is who reads the code before it ships, and what is on record afterwards.
Vibe coding is building software by prompting an AI tool and shipping what it produces without anyone reading the code or taking responsibility for it.
Many teams sit between the two, with engineers writing the code and AI suggesting as they go. All three have their uses, and the last row includes our own weak spot.
| Question | Vibe coded | AI suggestions only | AI-native, as we work |
|---|---|---|---|
| Who writes the specification? | Nobody; the prompt stands in for it | Engineers or analysts, to varying depth | Engineers, agreed with you before any code exists |
| Who writes the code? | An AI tool | Engineers, with AI suggestions | AI drafts much of it, against the specification |
| Who reads each change? | Usually nobody | Depends on the team | A senior engineer, before it merges |
| Automated tests | Rare | Varies by team | On every change; a failing build does not ship |
| Evidence for due diligence | Little; nobody knows who wrote what | Whatever the team kept | Specification, decision records and test runs |
| Where it fits | Demos and experiments you will throw away | Existing teams adding AI a step at a time | Products you will sell, raise on or put regulated data through |
| Weak spot | Security, data isolation and maintenance | Quality varies with each engineer's habits | Slower than a vibe-coded demo to the first screen |
Who owns AI-generated code? Your code, and leaving us
Ownership passes to you on full payment, and the code can sit in your own repository from the first commit if you want it there, so the history is yours as well.
We write the documentation as we build. Left to the final week, it turns into a summary of whatever people still remember.
Leaving should be dull. If you take the work in-house or to another supplier, they start from the same specification, decision records and tests we worked from, and nobody has to guess what we meant.
What we need from you
Builds slip more often waiting for an answer than waiting for code.
A decision owner
One person who can agree the specification and make scope calls without convening a committee.
Access
To the systems we integrate with, test accounts and existing code, before the build starts rather than halfway through.
Test users
A few real users who will try each fortnight's build. Confusion found in week four costs far less than confusion found after launch.
Response times
Answers to blocking questions within two working days. We will always say which questions are blocking.
How are engagements priced?
Pricing follows how well the work is understood before it starts.
| Model | When we use it | How it works |
|---|---|---|
| Fixed price | Work with an agreed specification | One price, paid against milestones; scope changes agreed in writing first |
| Time and materials | Discovery-heavy work, where the problem is still moving | Billed for the days worked |
| Retainer | Ongoing product work after launch | A set amount of senior time a month; BlueWave's runs at two to three days a week |
Most engagements begin with a first step at a published fee, excluding VAT: a specification sprint at £4,500 for one week or £8,500 for two, an AI readiness assessment from £4,950, an AI-built app audit at £3,500, or technical due diligence for startups from £6,500.
For scale, a single-workflow MVP built to production standard typically costs £35,000 to £80,000 over 6 to 12 weeks. BlueWave and Karu, both larger, each had a core build of about 14 weeks, and every case study publishes the band for its shape.
AI has taken cost out of writing code. It has taken none out of building the wrong thing, so the specification and the review are the parts we will not cut.
How we take the risk out of a first step
Each of these is a promise made elsewhere on this site or in our terms.
- The first call is free, with no sales pitch.
- Every first step has a published fee. Where it starts from a figure, the exact one is fixed in writing before any work starts.
- The fee does not move with the answer: it is set before either of us knows what the work will find.
- You can stop after any step, and keep what it produced.
- The code we write for your project is yours on full payment.
- Delivered work carries a defect warranty: typically 30 days, set in each project agreement. During it, we fix bugs in that work at no extra cost.
Questions about AI and your code
Do you use AI to write our code?
Yes, much of it: first drafts of code and tests, and the wide, repetitive changes that touch many files at once, all worked from a specification you have agreed. People choose the architecture, review every change before it merges and run every release. A change whose tests fail goes no further.
Will our data be used to train AI models?
No. Your code and data do not go into AI tools that train on them. AI works on your code only through business accounts whose terms bar training on it. It never holds production credentials, and client personal data stays out of it.
Who owns code written with AI?
You do. The code we write for your project is yours on full payment, whether a person or an AI tool drafted it. Our own tools and methods stay ours, and the code does not need them to run.
Is AI-generated code secure?
Not by default. In Veracode's 2026 GenAI Code Security Report (opens in a new tab), published in July 2026, about 44% of benchmark coding tasks produced code with a known security flaw, much as a year earlier. The tasks are short test functions and Veracode sells security tools, so read the figure as a warning. Nothing we build ships on AI output alone: a senior engineer reviews every change against the specification, and the tests must pass first.
What is the difference between AI-assisted and AI-generated code?
AI-generated code is whatever a model produced. AI-assisted code is code a person specified, read and took responsibility for, whoever typed it. The difference is the review and the record: on our builds every change passes a senior engineer's review and the automated tests before it merges, and the specification it was checked against stays in your repository.
Is spec-driven development just waterfall?
No. A specification covers the piece of work in front of us, and the build runs in two-week cycles you click through, so what you learn in week four changes week six. What we keep from the old way is agreeing things in writing before code exists, because an AI tool given a vague brief will build the vague version.
Can our own team keep working this way after handover?
Yes. The specification, decision records and tests stay with the code, and they carry most of the method. Your team can use whichever AI tools it trusts, provided the gates stay: review before every merge, and tests on every change. Nothing in the handover depends on our own tools.
Tell us what you're building or deciding.
Tell us about a product you want built, or a decision about AI you need to make, and we'll set up a 30-minute call. You'll get a straight answer on what it would take, including when the answer is that you don't need us.
What happens after you get in touch
We reply within one working day
By email, to arrange a time for the call.
A free 30-minute call
With a senior engineer, not a salesperson, about what you are building or deciding.
The fee in writing first
If a first step is worth taking, you get its exact fee in writing before any work starts.