→ Engagement spotlight / Agentic delivery
Two teams built the same field application. The agentic stream ran more than 40% faster
The build phase took 2 weeks agentically, against roughly eight on the client's own stream.
362 test cases were generated alongside the build, putting 40% coverage in place on the first day the application existed.
→ The sequence / how the engagement ran
Six steps, in this order.
01
Discovery, April
We found that QA ran on manual effort and slowed everything behind it, while documentation did the same. Code authoring was keeping pace.
02
Reconstruct the product's knowledge
Almost three weeks rebuilding what the product knew, because the existing artefacts disagreed with each other.
03
Prototype from the spec
The team prompted a working prototype out of the requirements document, then validated on the running thing.
04
Build in a loop
Plan, approve, implement in bounded steps, generate tests, review. The full cycle is set out below.
05
Rebuild rather than patch
The application was rebuilt end to end about five times, roughly a day each. When the specification proved wrong, fixing it and running again cost less than patching.
06
Hand over the comparison
A full-day synthesis workshop in Singapore, where both streams' numbers were presented to twelve client stakeholders and challenged in the room.
Step 04 in detail / the working loop, mint marks a human decision
↻ Loop Change requests were raised into Jira, and the cycle ran again from the context check with the specification updated.
→ The situation
The organisation had a delivery target and no way to measure progress against it.
The client's digital organisation builds field applications for agronomists and distributors. Thirty to forty developers work across three geographies, with much of the delivery going through external partners. Leadership had set a target the organisation could recite: get development timelines from one month down to one week. Nobody could say whether any given change was moving that number.
GitHub Copilot was switched on in part and in daily use, and nothing was being measured about what it returned. The April discovery put the real constraint downstream of code authoring. QA ran on manual effort. Documentation was spread across Confluence pages, Word business requirement documents, Figma files and the memory of individual product owners, one of whom was weeks from leaving.
Agents could write code just fine, but the open question was whether a team could measure the difference in its own codebase, on its own release cadence.
The answer was a controlled comparison. Two streams built the same application to one set of acceptance criteria. Stream one was the client's own engineering team, already underway, which made it the baseline. Stream two was a greenfield agentic build run by MISSION+ under the Agent Centric Development Cycle.
The client's reading of the result
The context now lives in the system instead of in individual heads.
→ What was measured
The numbers, and where they came from.
Build phase, one scope and one set of acceptance criteria for both streams
Elapsed weeks
Agentic streamMISSION+, under ACDC
Traditional streamClient engineering team
Elapsed delivery
A near production-ready application inside an eight-week window, including almost three weeks of specification work before any code was written.
Test cases generated
Produced automatically alongside the build, with 40% coverage available from the first day the application existed. Roughly 47 were implemented in the first build.
Documentation up to date
Of sixteen user manuals reviewed, about 60% were current. That figure is now the baseline the follow-on programme works against.
Two weeks agentically, against roughly eight weeks for the same scope on the traditional stream. This is the comparison the engagement was built to produce.
The client restated the overall result as more than 40% faster, and that restatement compares two streams that did not start from identical positions, so treat it as a direction of travel with a wide margin around it.
The generated suite ran 30 to 40% shallower than the human-written equivalent, and quality was not production-grade at handover. Coverage across the application was there within a day, and getting any of it to real depth took human review, so a QA engineer stayed in the loop throughout.
Where the requirements document contradicted itself, the agent quietly picked a side or dropped the requirement, and QA caught it later. A developer would have raised the contradiction; the agent resolved it silently and carried on.
→ Why it matters
A measured baseline the organisation can plan against.
The client set a one-month-to-one-week target with no way of checking progress against it. It now has a figure for its own codebase, produced by two teams building the same application, along with the specification artefacts, the guardrails and the test scaffolding that produced it. The two-week build phase carries over to the next application, because the artefacts that produced it carry over too.
The durable change is where the product knowledge sits. A requirements document, an API map and a decisions log that both people and agents can read replaces context held by individual product owners, one of whom has since left. The client has commissioned a 90-day Centre of Enablement to take the pattern across the rest of its portfolio.