What does “built by AI agent fleets” actually mean?

Several AI coding engines work in parallel on isolated branches, each on one bounded task. I direct them: I decompose the work, set the acceptance criteria, review what comes back, and decide what merges. The engines type faster than a team; the judgement about what to build and what to accept stays human, and it stays with one accountable person.

How do I know the software actually works?

Nothing certifies itself. The engine that writes a change never reviews it - a different engine attacks every diff looking for failure modes, and a change ships only after that independent review passes and a repeatable test proves the behaviour. Every claim of done is backed by a proof artifact you can inspect, not by a status update.

What do you need from me to scope a sprint?

A clear outcome and access to whatever the software must touch. The first conversation turns the outcome into a written scope with acceptance criteria - what will exist at the end, and how we will both know it works. The scope is fixed before anything starts; if the work reveals the scope was wrong, we stop and re-agree rather than drift.

Who owns what gets built?

You do. The deliverable is a repository you own, with its history, its tests, and its documentation - not a deployment you rent access to. Handover includes a walkthrough of how it is put together and how to run it without me.

Is my code and data used to train anything?

No. Work runs on commercial AI accounts whose terms exclude training on customer content, in isolated working copies, and credentials are never committed to the repository. Anything sensitive can be discussed before scoping and excluded from what the engines ever see.

Fixed-Scope Build Sprint

Software built by AI fleets. Judged like it was built by hand.

A defined outcome, built by AI coding engines working in parallel under my direction — and held to a harder standard than most human teams hold themselves: one engine builds, a different engine attacks the diff, and nothing merges on its own say-so. At the end you own working software and the evidence that it works.

A fixed scope, then the thing itself

scope agreed up front · built · proven · handed over

What a sprint is

One bounded piece of production software, taken from a written scope to a working, tested, handed-over result. Not a prototype, not a demo that dies when I leave — a repository you own, with tests that pass and documentation that tells the next person how it works.

The build itself is done by a fleet of AI coding engines working in parallel, each in its own isolated branch on one bounded task. I direct the fleet: I decompose the scope, set acceptance criteria per task, review what comes back, and decide what merges. The typing is machine-speed. The judgement is not delegated.

Why it holds up

The honest risk of AI-built software is not that it fails — it is that it looks finished while being wrong underneath. The whole method exists to attack that risk:

Nothing self-certifies. The engine that writes a change never reviews it. A different engine — a different vendor's model, with no stake in the work — attacks every diff looking for the ways it fails in production.
Done means proven. Every completed task carries a proof artifact: the test that demonstrates the behaviour, the review verdict, the output on record. A claim without evidence does not merge.
Scope is written, then fixed. What will exist at the end, and how we will both know it works, is agreed before anything starts. If the work reveals the scope was wrong, we stop and re-agree — no silent drift.

This site, its sister site, and the tools that built them were all produced this way — the same seed set goes into every product.

What you get

The software, working, in a repository you own outright
A test suite that fails when the software breaks — the gate, not decoration
The review record: what was attacked, what was found, what was fixed
Documentation and a handover walkthrough — how it runs without me

Who it is for

A founder with a defined product slice that needs to exist properly, not eventually
A team with a bounded internal tool, integration or migration that never reaches the top of the backlog
Someone with an AI-built prototype that proved the idea and now needs the real version

Who it is NOT for

Open-ended product exploration — that is a fractional conversation, not a sprint
Work whose scope cannot be written down — if we cannot agree what done means, I will say so at the fit check
Anyone who wants a body shop. The sprint ships an outcome, not hours

How it works

Fit check. Email what you want built. If it is not sprint-shaped, I say so and point you somewhere honest.
Scope. One conversation becomes a written scope with acceptance criteria, agreed by both of us before anything starts.
Build. The fleet builds in parallel; every change passes independent cross-engine review and its own test before it merges.
Handover. You get the repository, the proof record, and a walkthrough. It runs without me — that is part of done.