What working with us looks like
The same senior team from the first conversation to the last release, and your hands on the real thing every week.
Scope
You + us, agents drafting
We work out what you are trying to do and what done looks like, then what it costs. An agent drafts the specification from that conversation, and you and an engineer settle it together. You get it in writing before anything is built.
Design
An engineer, with agents
How it will be put together and what it will look like. Agents draft the plan and name what already exists to reuse. An engineer decides, and agrees it with you. Nothing gets built from a guess.
Build
Agents, tests first
Agents write a failing test, then the code to pass it, in small steps, with an engineer directing. Something you can actually use appears early, not at the end.
Your review
Every week
You use the real thing while it is still being built and tell us what is wrong. What you say goes into the next week's work.
Release
Engineer approves, pipeline deploys
An agent reviews every change against the specification. A named engineer gives the verdict and merges it, and the pipeline deploys it under your keys, in your own accounts. Everything in it is yours.
After
Ours or yours
We stay on for as long as you want us. Or we hand it over and your own team runs it.
Agile, adjusted for agents
The process above is agile, with the cycle shortened and the order changed to suit work that agents do most of. Independent research finds that teams working with AI assistants ship more changes in less time, but that the extra speed brings instability unless the practices around it are strong. The gains go to teams that work in small batches and keep tight control of what changes, so that is the shape we have given ours.
- The cycle is a week, not a fortnight. With agents building, a week is long enough to have something real to look at, and it is as long as we will go without you seeing the work.
- The specification and the tests are written before an agent builds. The practitioners who have done most of this in public, from Kent Beck to Thoughtworks, report that this is what keeps agent-written code on course.
- Human review is the slow step, so work is cut into pieces one engineer can check with confidence. Nothing is merged without that check.
- We do not promise a fixed multiple of speed. The best controlled study so far found experienced developers went slower with early tools, and the picture is still changing. What we promise is the process above, run in the open.
One change, start to finish
This is the route every change takes, and it is the one we run ourselves. Agents are involved at every step: they draft the specification, write the plan, build against failing tests and review the result. An engineer directs each step and gives every verdict, and you see the working preview each week.
- $ git switch -c feat/brief
- ▸ spec by agent · settled with you
- ▸ plan by agent · engineer agrees it
- ▸ failing tests first, then code · agent
- ✓ agent reviewed · engineer's verdict
- ▸ preview up · for this week's review
- ↺ your notes in · plan updated · agent
- ▸ changes built and reviewed again
- ✓ pull request merged · named engineer
- ▸ pipeline deploying · your cloud
You see it every week
The most expensive thing in software is finding out late. So there is nothing to wait for and nothing kept back until a reveal: the work is in front of you the whole way through, and steering it is your job as much as ours.
- A running version you can use, in an environment of your own, from early on.
- A short call every week: what changed, what it cost, what is next.
- What you send back is worked on next, not filed for a later phase.
- Change your mind and we requote the difference rather than argue about the brief.
- You can see the work as it happens, not a status report about it.
What you end up owning
The test of whether something was built properly is whether you could run it without us. So everything needed to do that is handed over as part of the work, not sold back to you afterwards or held as the reason you have to stay.
- The source code, and the rights to it. All of it.
- The tests, so the next person can change it safely.
- How it works and why, written down.
- It running in your own accounts, set up to deploy again.
- What to do when something breaks.
- Time with your team, so they can pick it up.
Where we don't use AI
- Deciding what to build. That is a conversation with you, not a prompt.
- Approving a release. A named engineer does that, every time.
- Anything that touches money or personal data, or that could hurt someone, without a person in the loop.