Integration Guys Ltd

Two to four weeks, or four hours

The teams getting the most from AI coding agents are not the best prompt writers. They are the best spec writers.

In August I built a working demo of LogisticsHub, a control tower for B2B logistics. It ingests transport messages, maps them into a single ontology, records every message in an immutable ledger, reads proof-of-delivery documents with AI, and answers plain-English questions about the supply chain. It also has multi-tenant access, geofencing and an MCP server.

My own planning document estimated two to four weeks. The core build happened over four days, and I spent no more than an hour a day on it. That is roughly 6,200 lines of TypeScript across three applications, delivered in twelve pull requests.

The speed did not come from clever prompting. It came from writing the spec first.

What I wrote before any code

The first real commit in the repository is not code. It is two short documents and a spreadsheet of message types.

The scope and architecture document makes the big decisions so the agent does not have to:

• Locked decisions. A table of eight choices made up front: the storyline (domestic road freight, end to end), which data feed is real and which is simulated, a bespoke but standards-aware ontology, the stack, an immutable ledger with reprocessing, the control-tower actions, the AI provider, and real multi-tenancy.
• The 23 message types. Every event in the lifecycle, from Order Received to Freight Invoice Matched, with the system that sends it and why we track it. This became the state machine.
• A three-layer architecture. Integration layer, hub core, control tower, with what each one owns.
• A draft ontology. The core entities and what every canonical event must carry.
• A build sequence. Seven steps, from the spine to demo polish.
• Open dependencies. What was not yet known, written down rather than guessed.

The discovery document lists everything still to get from a real customer: sample ERP payloads, SLA data, an OTIF definition, real proof-of-delivery documents. Each item is rated by how much it blocks or reshapes the model, and each one says what we mocked in its place. That last part matters. When a demo works, everyone forgets which parts are fake. The spec does not.

None of this is new. It is the design document I would have written for a human team in 2005. The difference is what happens next.

The loop: read, question, build

I did not ask the agent to build LogisticsHub. I asked it to read the spec and come back with questions. The prompt was close to this:

Please review the spec and tell me what I have missed, or what questions you would ask me if you wanted me to build this application.

That one step did more than any clever prompt. It turns the agent from a code generator into a reviewer, and its questions show you where the spec is ambiguous before any code depends on the ambiguity. Each answer went back into the spec, and each answer became a feature.

From there the rhythm was simple:

1. One feature, one branch, one pull request. Twelve in total: the core spine, configuration, proof-of-delivery management, multi-tenant auth, natural-language query and the MCP server, geofencing, AI reading of delivery documents, international legs, and the demo run-sheet.
2. The agent reports what it verified. Its commit messages say what it checked, for example a clean type-check and a reseeded simulation that raised the expected exceptions.
3. I review the diff and merge. About an hour a day was enough, because I was reviewing decisions I had already made, not making them on the fly.
4. Real feedback goes into the spec. The proof-of-delivery work came straight from a prospect: some customers are a data "black hole", proof-of-delivery rules differ by customer and nobody knows them all yet. That went into the spec as a requirement to build for flexibility, and the agent built a data-driven rules engine rather than hard-coded checks.

What I kept, and what still went wrong

I kept the contracts. I wrote the first draft of the ontology and the tenancy model myself, then iterated on them with the agent rather than handing them over. Everything else depends on them: every adapter maps into the ontology, and every screen and query is filtered by tenancy. As I argued in MCP is the new EDI, the contract is the product. The agent can propose changes to it. It does not get to own it.

Review still matters. On day two it turned out that a clean clone of the repository would not build. A leftover .NET rule in the .gitignore, **/[Pp]ackages/*, had silently excluded the entire ontology package, so the most important code in the project had never been committed. It was fixed within a day. But it is exactly the kind of thing that works perfectly on one machine and nowhere else. A later fix dealt with timestamps that rendered differently on the server and in the browser. Small things, caught because someone was reading the diffs.

And there are no automated tests yet. That was a deliberate trade for a demo, and it is the part of this story I would not copy into production. Before LogisticsHub touches a customer's real data, I would insist on 95% test coverage with full automation. As last week's post argued, the first draft is now nearly free. Proving it is right is still the job.

What I would tell other teams

1. Write the spec before the prompt. Decisions, not prose: what is locked, what the states are, what the architecture owns, what is still unknown.
2. Let the agent interrogate it. Ask for questions before code. Every question it asks is an ambiguity that would otherwise have become a bug.
3. Write down what is mocked. A demo that works hides its fake parts. The spec should not.
4. One feature per pull request. Small diffs are reviewable diffs.
5. Keep the contracts human. Ontology, tenancy, data contracts and security boundaries are drafted and owned by people.
6. Budget for tests before production. Speed in the build is not speed to production. The test pack is what makes it safe to ship.

The skill that matters most with coding agents turns out to be an old one: being able to say clearly, in writing, what you want and why. The agents have made that skill more valuable, not less.

If you are deciding how your team should work with coding agents, I am always happy to compare notes.

Previously in this series: MCP is the new EDI and The Mapping Took Four Minutes.

Next week: from 24 hours to under five minutes. How we automated financial statement spreading for credit decisions.