← Blog

What we mean when we say AI coding agents build it

When we say that AI coding agents build the software, we are describing a delivery method, not a product. The product is the portal, the middleware, the migration, the web application. The method is how it gets written, reviewed, and shipped.

The agent we use is Anthropic's Claude. A senior U.S. engineer directs it. That direction is the work. Claude writes the change on a branch. The change is reviewed as a pull request. The pull request carries tests, linting, and release notes. A senior engineer reviews it and decides. Then it is released, with a note on what changed.

That sequence — branch, pull request, tests, linting, senior engineer review, release — is not a formality. It is the reason the method works at the speed it does, and the reason it can be trusted.

An agent can write a large amount of code quickly. Left on its own, it can also write a large amount of code that nobody has read. The pull request is where that stops. Every change is read by a senior engineer before it ships. Every change carries tests, so the behaviour it claims is the behaviour that is checked. Every change is linted and typechecked, so the code that ships is the code that passes the checks. And every release carries a note, so the business knows what changed and when.

HaulOS is the place where this method has been measured. HaulOS is our own product: a logistics operations portal with AI agents on text and voice, built by devKore. It was built in 6 weeks against a 46 developer-week estimate — 7.7x the pace. 190 pull requests have been merged on HaulOS since May 2026.

Those figures are worth reading carefully. The 6 weeks is the time it took to build the portal and its agents. The 46 developer-weeks is what the same work was estimated at. The 7.7x is the pace, measured against that estimate. The 190 pull requests are the count of reviewed, merged changes since May 2026. None of those figures is a claim about a client, a market, or a future project. They are a record of one product, built in this way, in this time.

What the method changes, day to day, is the shape of the work. A request from a client becomes a card on the board, written by the client or by us. The agent writes the change and its tests on a branch. The senior engineer reviews the pull request and decides. Checks run — lint, typecheck, tests, build. The change is deployed, with a note on what changed. Then the next card is taken up.

What it does not change is accountability. The senior engineer is still the person who decides what ships. The tests are still the proof that the change does what it says. The release notes are still the record of what went out. The agent does the writing. The engineer does the directing, the reviewing, and the deciding.

There are places where this method is the wrong choice, and we say so when we see them. A change that needs a judgement about the business, a change that touches a system nobody has mapped yet, a change where the right answer is to stop and ask — those are not jobs for an agent working alone on a branch. They are jobs for a discovery call, and a decision, first.

But for the work that is well understood — a portal, a migration, a middleware, a web application to replace a worksheet — the method is the fastest honest way we know to build it. The code is written by an agent, read by a senior engineer, checked by tests, and shipped with a note. That is the whole claim. It is also, as HaulOS shows, enough.

Book a discovery call