AI writes a great deal of it.
None of it ships unverified.

Long before anybody was generating code, the research on where software goes wrong kept arriving at the same place. Between half and sixty percent of all defects trace back to the requirements, and about half of those to requirements that were ambiguous, incomplete, or simply wrong. A problem caught while the requirement is still being written costs a fraction of what the same problem costs after delivery, and the multiple is closer to a hundred than to two.

None of that says anything about AI, which is part of why we trust it. What AI changed is the ratio. When writing the code was most of the work, an imprecise specification was expensive without being the most obvious thing in the room, and now that the code comes back in an afternoon, the vagueness is the only part left that still costs real money.

So we start there. A request gets turned into a specification precise enough that the next step does not have to guess, and AI does much of that work, because turning a rough idea of what somebody wants into something exact is a thing it is genuinely good at. A person holds the gate on anything that matters, and what they are holding it on is the specification rather than the code. When something arrives that nobody has pinned down, it goes back to be specified rather than forward to be built, because a request nobody has pinned down is unfinished, whatever size it looks.

It is also the cheapest place in the whole engagement to change your mind.

Google's DevOps research group looked at this in 2025 with nearly five thousand professionals, and two of its findings are inconvenient for anyone hoping that the tools are the thing that makes the difference. The first is that AI amplifies whatever is already in place rather than fixing anything, so a team with unclear work and a fragile pipeline ends up with more unclear work arriving faster. The second is that the return does not come from the tools. It comes from the quality of the platform underneath, the clarity of the workflow, and how well the team is aligned.

That matches what we see. A very good model inside a company that has built nothing for it to work in behaves like a bad one, and the model is not the part that is failing.

So what we built is not a collection of tools. It is the thing the work runs through, from the first client meeting to a running system: the interview, the specification, the technical plan, and a repository that arrives with its structure, its pipeline, and its standards already in place rather than written down somewhere and hoped for. Years went into that rather than into any particular tool, because the tools keep being replaced and this carries across whatever replaces them.

It is also where the time goes. The first weeks of a build go into your system rather than into standing one up, because a build here starts from something that already runs rather than from an empty repository.

There are two kinds of rules in a system like this, and the difference between them is most of the answer to whether any of it is safe. The first is written down for the model to read: conventions, the decisions already made, the context it needs before it starts. That works most of the time, but when the work gets difficult or the instructions conflict, it can be set aside, because it is advice sitting in the same context as everything else the model is weighing up. The second kind is not written anywhere the model can read it. It is enforced by the system around it, and it stands whatever the model concludes it ought to do.

So the things that matter most are not asked for. Nothing reaches a running system on an agent's own judgement: there are checks in between that a person has to clear and that the automated ones have to pass, and they live outside the agent's instructions, in the system around it. Agents also work without access to secrets or the infrastructure that holds them, which is a property of where they run rather than a rule they have been told to follow.

Testing is the clearest case. Weakening a failing test to make a build go green is the obvious move for anything under pressure, and it is one of the first things you see once agents are doing real work. It is also the failure that would undo everything else here without anybody noticing.

We handle it in three layers, and the order matters more than any one of them. There is a rule the model reads, which tells it to leave existing tests alone and put the work into the code. There is a block it does not get consulted about, which does not allow test files to be changed at all. And there is a check before the work is accepted, confirming that the tests are still there, still running, and still able to fail when they should.

That last one is where the usual measure lets you down. Test coverage counts the lines your tests touched, and a suite can touch every line in a system while checking almost nothing about what those lines did, so we do not lean on it alone. Where it matters, we check the tests by breaking the code on purpose and seeing whether they fail, which is a much harder thing to fake.

Underneath all of it is one review standard applied to everything, regardless of who or what produced it. Nothing reaches a product unreviewed, and nothing ships that somebody here cannot explain. We would rather be held to that than to any claim about how quickly we work.

What that leaves for the people here is a different job from the one it used to be. An engineer briefs the work, reads what comes back, and when something gets through, fixes whatever let it through so that it does not get through again. The time that gets saved is saved before any of that, in the specification and the scaffolding and everything that used to be typed out by hand. None of it comes from making sure what ships actually works.

The question we get is how much we let a machine do on its own, and the honest answer is that it does not depend on the model. It depends on how quickly we can tell whether the work is right. Where the feedback loop is fast and can be believed, an agent can be handed a whole task and come back with something finished, because it corrects itself against real results instead of against somebody's patience. Where the loop is slow, or the tests inside it cannot be trusted, it gets very little, and a better model does not change that. Each time a better one arrives, the limit tends to stay where the loop put it.

We keep up with the research here, and most of what it says is about what happens when that loop is missing.

In one controlled trial, experienced developers working on codebases they had contributed to for years came out nineteen percent slower with AI tooling while believing they had been about a fifth faster. The authors are careful that this is one narrow setting rather than a finding about everybody, and that is fair. The part that matters to us is that the people doing the work could not tell which direction they had moved in. A separate study of two hundred and eleven million changed lines, across five years, found copied blocks rising steadily while refactoring fell from a quarter of changed lines to under a tenth, which is what happens to a codebase when generating something is cheap, and nothing is watching the shape of what comes out.

Those two results are why we would rather measure than ask, and why everything gets reviewed regardless of what produced it.

Nothing you give us is used to train a model. We do not use any provider in a configuration that trains on customer data. The model itself is chosen per client, so where it needs to sit inside the EU, that can be arranged. We sign your own data processing agreement.

Custom work runs wherever your compliance requires it to run. Our own default is inside the EU, and every client sits in an isolated environment of its own.

Keys are handled by not being there. Nothing permanent is present where an agent works. What it gets is issued for the one job in front of it, stops working on its own afterwards, and opens nothing else while it lasts, so the leak everybody worries about is not something we are trusting it to avoid.