We’re a tech house, we build next level tech. We’ve been watching the AI-assisted development conversation play out for the past two years: the breathless predictions, the cautionary takes, the LinkedIn posts where everything either works perfectly or fails catastrophically. We wanted actual data. So in May 2026, we stopped talking about it and ran an experiment.
We called it D-Day.
Five people. One full working day. A real product with real complexity. AI tooling, specifically Claude, SpecKit, and Claude Code, as the primary driver of output. No client pressure, no production risk. Just: can a senior team sustain meaningful development velocity using this model, and what breaks along the way?
Here’s what we found.
It worked. Up to a point.
The honest headline is that development velocity velocity was significantly bigger than what we’d expect from the same team in a conventional sprint. That’s not a small number. Three stories of medium complexity, running in parallel, with substantial output by end of day. If you’d told us at the start of the day that’s what we’d see, we would have called it a success.
But the full picture is more interesting than the headline.
The first hour was consumed almost entirely by discussion, not implementation. Even with specs prepared in advance, parallel development at velocity creates collision surface area. Database modelling, entity relationships, API contracts, UX flows: all of it needed verbal alignment before a single line of code could be written. The faster you move, the more coordination overhead you generate. That’s not a bug in the model; it’s the model behaving correctly.
By mid-morning, the pace picked up. Code was being generated at a rate none of us had experienced before. By 11:30, the first pull requests were appearing. The first PR passed review with minor bugs. The second introduced architectural inconsistencies that were only visible once the pieces were placed next to each other. The third hit merge conflicts from three branches touching overlapping code simultaneously. What became clear is that parallelising smaller work chunks with AI is harder than it looks. The speed gains are real, but so is the coordination tax that comes with them.
The afternoon was where the limits showed up clearly. Claude session windows were at 97% usage by lunchtime. One developer’s story had to be abandoned entirely because a specification error, caught only at the planning stage, had sent the implementation in the wrong direction. The recovery attempt failed. The branch was discarded.
The root cause, when we traced it back, was simple: that story had gone through the full specification process without a proper product owner review. That review gate is not optional.
Despite one story being abandoned, the experiment delivered exactly what we were looking for: meaningful output, valuable lessons, and a much clearer understanding of where AI-assisted development creates leverage and where it still requires human discipline.
What the team actually said
We collected candid, unfiltered feedback from every participant. A few things came up repeatedly enough to be worth sharing.
Specifications are load-bearing. If the spec is wrong and you don’t catch it until implementation begins, you don’t fix it mid-flight. You restart. The cost of a bad spec in AI-assisted development is higher than in traditional delivery — not lower.
Model selection matters more than you’d expect. One developer observed that using a lighter model at the implementation stage produced noticeably worse output, even when the planning phase had been done with a stronger model. Good context doesn’t fully compensate for a weaker model at execution time.
The Product Owner role is transformed. In a traditional sprint, a developer blocked on a clarification can context-switch and come back. In an AI-assisted flow, the model can’t wait. The PO is needed simultaneously by multiple developers, in real time, continuously. This is a qualitatively different demand — and it requires someone who can operate at that pace without introducing errors.
AI amplifies seniority. The experiment was run with a hand-picked senior team under low-stakes conditions. Replicating the same setup with junior contributors, client pressure, or an unfamiliar domain will produce different results. AI doesn’t make junior developers senior. It makes senior developers faster — and it makes junior developers’ mistakes larger and harder to catch.
What it means for how we work
The experiment wasn’t just a technical exercise. It surfaced implications across every dimension of how we operate.
On the operations side, an eight-hour AI development day is probably one to two hours too long. Fatigue materializes visibly by mid-afternoon, and the quality of decisions degrades in the final stretch. Six focused hours with structured breaks likely produces better net output than eight hours of diminishing returns.
On the delivery model side, this approach is best suited to fixed-scope, time-boxed projects, particularly greenfield builds where the domain is defined and the scope is bounded. Extended time-and-materials engagements are a poorer fit. The velocity gains are front-loaded; they’re most visible in the build phase, after a thorough upfront definition phase.
On the HR side, this is perhaps the most structurally significant conclusion: AI-assisted development at this level is not a productivity tool you can hand to any developer. It requires a specific kind of person, one who can prompt effectively, evaluate AI output critically, catch silent errors, and manage context across long sessions without cognitive fatigue degrading their judgment. That profile is rare. Finding it is hard. Retaining it once found is a priority.
And on the process side, Agile as currently practiced doesn’t map cleanly onto this delivery model. Sprint ceremonies, story sizing conventions, and velocity tracking were all built for a different pace. Something more hybrid, with structured, waterfall-style definition upfront, followed by intensive AI-assisted build cycles, fits the shape of the work better.
What we’re doing next
This was a baseline experiment, deliberately run under favorable conditions. The next step is to run it again, harder. With a client-adjacent problem, with at least one less-favorable variable introduced, and with the process improvements from this round applied. We’ll publish what we find.
We’re sharing this because the conversation needs more honest data points. Most of what gets written about AI-assisted development is either promotional or catastrophising. The reality is more nuanced: real gains, real limits, real process changes required, and real implications for how software teams need to be structured going forward.
The experiment also reinforced something we already suspected: the technology matters, but the people matter just as much. None of this would have been possible without a team that was fully invested in the outcome. Not just in the coding, but in challenging assumptions, improving the process, and openly sharing what worked and what didn’t.
If you’re evaluating whether this model fits your team or your next build, talk to us. We’ve done the experiment so you don’t have to start from zero.
