Back in May, we ran D-Day: five senior developers, one day, AI as the primary driver of output. We wrote up what we found, warts and all, because the honest version was more useful than another polished success story. One thing D-Day didn’t tell us, though, was where the team came from in the first place. We started that experiment with five people already in the room. The real question sitting underneath it was smaller and, in some ways, harder: do you actually need five people to start, or does AI-assisted development work better with almost nobody?
In June, we set out to answer that one specifically.
The hypothesis: start small, stay small, longer than feels comfortable
This time, we built on Matt Pocock’s methodology, adapting it to align with our own workflows and processes. His core claim is that AI coding doesn’t need new magic, it needs classic engineering discipline adapted to how language models actually behave. Two seniors set up the architecture, modularised in a way that keeps it AI-friendly, and then one of them carries the work forward alone as a single thread. You only add people once the codebase has enough independent modules to make parallel work genuinely parallel, not just crowded. The alternative, throwing a full team at a project on day one and immediately negotiating how to split the work, was exactly what we wanted to avoid.
We ran it on a real internal product, using Claude Code together with Pocock’s published workflow: a “grill” session that interrogates the plan before any code gets written, a PRD that marks the destination rather than a contract you re-feed to the model, issues sliced vertically through every layer instead of built up layer by layer, and test-driven development as the guardrail that keeps the model honest. Seven working days in June, two seniors on day one, one senior solo for the rest, closed out with a joint retrospective in early July.
The number that matters: not the cost, but the discipline
Over the course of the experiment, the total API spend remained remarkably low, especially considering the amount of working software that was delivered. In just seven days, we built a functional product increment including CRUD operations, authentication, role-based access control, user management, and list and filter functionality. Compared to the engineering effort it replaced, the API cost was negligible.
But the cost itself isn’t the most interesting finding. What mattered far more was how the AI was used.
One of the clearest insights came from comparing two consecutive development days. The project, tools and developer were exactly the same, yet the cost of one day was almost twice that of the next. On the less efficient day, frontend work became tangled in migration issues, a seemingly simple UI bug spiralled into a long debugging session, and repeated attempts to fix it within the same conversation only made matters worse.
The following day, the approach changed. More time was spent upfront defining the desired behaviour before writing code. Working functionality was committed before addressing bugs, and each issue was resolved and verified individually before moving on. The result was a significantly more efficient workflow, with lower API usage, fewer dead ends and a much smoother QA process.
That contrast—not the absolute cost—is the real finding of this experiment. AI-assisted development is not primarily a question of model pricing; it is a question of developer discipline. As techniques and prompting habits improved throughout the week, efficiency stabilised naturally, demonstrating that effective AI development is driven far more by process than by the underlying technology.
The model is eager to build, and that’s the problem as much as the promise
More than once, the model jumped straight to implementation when it was supposed to be aligning first. On one occasion it skipped the interrogation step entirely and just started writing code; asked why afterwards, it admitted the shortcut. We kept that particular fix rather than rerunning the whole process, because the change was small, but it’s not a habit we want to build a delivery model on.
The more serious version of the same pattern showed up in code review, which we treated as non-negotiable throughout. Human review caught the model quietly using raw connection strings instead of configuration references, and, more seriously, storing authentication tokens in browser local storage, a known security hole that should be handled with http-only cookies or a proper backend-for-frontend layer instead. The model picked the insecure default on its own, without being asked to, and without flagging it. Nothing in the automated flow caught it. A human reading the code did.
We take that as the clearest single argument for why review stays mandatory rather than becoming a spot-check. Left alone, the model doesn’t just make mistakes, it makes confident, plausible-looking mistakes that pass a casual glance.
What we changed because Pocock’s playbook didn’t survive contact intact
A few adaptations turned out to be necessary, not optional. Pocock’s flow assumes you challenge the model’s proposals inside the same alignment session; we found that prolonged back-and-forth derails it instead, and it quietly starts skipping steps it was supposed to follow. Restarting that session fresh, carrying the lessons forward as a note rather than an argument, worked better every time. Vertical slicing, the idea that every unit of work should cut through all layers of the system rather than being built layer by layer, is central to the whole methodology, and the model still defaulted to backend-first unless we said otherwise, explicitly, every time. And after watching a long bug-fixing session turn destructive rather than corrective, we added a rule that wasn’t in the original playbook at all: commit a working version before touching any bug, then fix, verify, and commit each finding on its own, so a bad fix has a trivial way back.
What this means for how we build, sell, and staff
If this holds up, the shape of an early project changes. Two seniors, sometimes just one, carry a codebase through its first phase; a team gets added later, once there’s enough structure to make parallel work real instead of collision-prone. The QA gate doesn’t get lighter because AI is involved, it gets stricter, because we now have direct proof the model breaks working code when nobody is watching closely enough. On the commercial side, having real numbers, real days, real dollars, and real failure modes from an actual product is a more credible story in front of a regulated client than another generic claim about AI-augmented delivery, and it opens the door to fixed-scope and outcome-based pricing conversations that are harder to justify without evidence like this behind them. On the people side, this is unambiguously a senior-level way of working. It rewards someone who can architect, interrogate a design, and review code critically; it does not turn a junior into a senior, and we’re still working out what a fair, structured path into that seniority looks like when the earliest, most junior-friendly phase of a project needs fewer junior hands than it used to.
Where we go from here
While the results have been encouraging, we’re continuing to refine and validate our methodology to ensure it consistently delivers the quality and predictability our clients expect. Our current focus is on three areas: completing an end-to-end feature using the codified workflow without manual intervention, demonstrating that two or more developers can work in parallel and merge their work cleanly without cross-module regressions, and establishing a defect-density baseline that reflects our quality standards.
The next phase of the experiment is intentionally more demanding. Two senior developers will work simultaneously: one on an independent module and the other on shared code, allowing us to test real collaboration and integration challenges rather than avoiding them. We’re also introducing a transfer test, where a second developer follows the documented workflow from the initial alignment session through to a merged implementation using only the written methodology. The objective is to verify that the process is robust, repeatable and transferable across developers—not dependent on individual experience or tacit knowledge.
Ultimately, our goal is not just to accelerate software development, but to build an AI-assisted engineering process that delivers consistent, high-quality results our clients can rely on.
Two experiments in, the pattern hasn’t changed. The technology keeps being the easier half of this. The discipline, the review habits, the willingness to restart instead of argue with a model that’s confidently going the wrong way, is where the real work still is, and where we keep spending our attention. We’ll keep running these and keep publishing what we find, including the parts that didn’t go cleanly. If you’re weighing whether any of this changes how software gets built for your team, that’s a conversation worth having before you find out the hard way what a model does when nobody’s reviewing its choices.
If you want to know more, or want to discuss what you’re seeing with AI-assisted development in your own organisation, get in touch.
Note: Since conducting this experiment, Matt Pocock has further evolved his methodology. That’s exactly what we’d expect in such a fast-moving field. We’re actively incorporating the latest improvements into our own workflow as we continue to refine and validate our AI-assisted development process.
