A fully remote, AI-native build showed how fast a workflow can move, and how fast an unconnected process becomes the bottleneck everyone works around, regardless of who’s running it.

A few months ago, one of DVT’s AI Build Teams ran an experiment on a greenfield build for a DVT client in the UK. The team worked fully remotely throughout, and every person on the project used AI tools to do their job, with the whole build run on AI spec-driven development. It turned into the clearest proof I’ve seen that this isn’t a “nice to have” anymore.

Most of the team leaned into it and moved faster than I’ve ever seen a team move. But the project also showed something else, just as clearly: the moment one process in the chain wasn’t connected to the same AI tooling as the rest, it became the bottleneck the whole team had to work around, almost overnight, and through no fault of the people running that process. As the Delivery Manager on this build, that’s the lesson I want other DVT teams and our clients to take from this before they learn it the hard way: the gap AI creates isn’t about who’s willing to adapt. It’s about which parts of the workflow have been given the tools to keep up.

Working this way, delivering into that DVT client in the UK, my opinion was that the team came in roughly 50% faster than how long this build would have taken without the AI Build Team approach.

What “AI spec-driven” actually means

Spec-driven development (SDD) has become one of the defining AI-native engineering practices of the last two years. Rather than prompting an AI coding agent with loose, ad hoc instructions (“vibe coding”), the team writes a structured, unambiguous specification: inputs, outputs, constraints and edge cases. The AI agent then generates code directly against it. It’s a deliberate middle ground: it keeps the short feedback loops that made agile work, while reintroducing the rigour that vibe coding lacks, because spec drift and hallucination are inherently difficult to avoid once you let an AI agent loose without a clear contract to build against.

Crucially, in a properly AI-enabled workflow, the specification isn’t typed from scratch by a human working from memory or a static file. Modern design tools now let AI agents pull design context directly out of the design source itself, including components, variables, layout and states, so the spec and the underlying source of truth never drift apart. That’s the whole promise of spec-driven development: the spec stays alive on its own, because AI keeps it wired to the source of truth, instead of depending on someone to notice a change and manually update a document.

What embracing it actually looked like

Most of the team leaned into this fully, and it was genuinely energising to watch. When something changed upstream, the relevant piece of the spec, and often a working code scaffold, was regenerated within the same day and ready for review. Planning and stakeholder communication moved at the same pace. Nobody on that side of the team was working harder; they were working with tools that removed the grunt work so they could spend their time on judgement calls instead. The project moved at a pace I haven’t experienced on a greenfield build before.

Where the workflow hadn’t caught up

One process in the workflow hadn’t yet been connected into the AI tooling the rest of the team was using. Requirements and documentation continued to be handled the way they always had: read manually, captured again by hand and rewritten from scratch each time something changed. That’s a well-practiced way of working that has produced good results for years, and there was nothing wrong with how it was being done. The problem was structural, not personal: everyone else’s part of the pipeline was now running at AI speed, and this process simply hadn’t been given the same tools.

Every time something upstream changed, even a small change, the affected documentation had to be manually reopened and rewritten. Every time a requirement shifted, the same manual cycle started again. This is a familiar pattern wherever a process still relies on manual, document-based handovers: the most recent version becomes hard to track down, and feedback gets lost in the shuffle. None of that reflects on the person doing the work. It reflects a gap in what tooling had been extended to that part of the process. What used to be an invisible, tolerated inefficiency became, on this project, visible almost immediately, not because anyone was working less hard, but because the rest of the workflow had sped up around it.

Why this isn’t a story about effort or skill

I want to be precise here: nothing about this project suggested that any particular skill became less valuable, or that anyone wasn’t working hard enough. What changed is that AI tooling removed the cover that used to exist around slower, manual processes. A gap that used to be absorbed quietly by everyone’s patience is now visible within days, sometimes hours.

The judgement, domain knowledge and business context that experienced people bring — knowing which detail matters, which requirement is non-negotiable versus a nice-to-have and what “done” really means — mattered more on this project, not less. A spec is now the direct interface between human intent and an AI coding agent. If it’s wrong, ambiguous or out of date, the AI doesn’t pause to ask for clarification; it builds the wrong thing, fast and confidently. That’s exactly why judgement must be captured through the AI-enabled workflow rather than around it, which means giving people the tools to feed their judgement in at AI speed, not asking them to keep working the old way and hoping they catch up.

This pattern shows up wherever a process sits between a source of truth and a written record, across almost every discipline on a project team. Once someone in that position is connected into the same tooling as everyone else, able to draft the first pass with AI and spend their time validating the substance instead of retyping it, they lose nothing. They get to keep doing the interesting part of the job at the speed the rest of the team now expects.

Why this matters beyond one project

The broader trend backs up what we saw first-hand: organisations further along their AI adoption journey are already seeing more pronounced staffing shifts than those lagging, with reductions outpacing expansions in the enterprises leaning into AI hardest. Left alone, unconnected processes don’t stay quietly tolerated for long. Teams build workarounds, they escalate and work increasingly gets redesigned around whoever has the fastest tools — which is exactly why closing tooling gaps must be a leadership decision, not something left to individual initiative.

That’s not a reason to be cynical about AI adoption. It’s the opposite: it’s the clearest business case I’ve seen for embracing it properly, and for making sure that adoption reaches every part of the workflow, not just the parts that are easiest to change. AI adoption is easy to prove and easy to fake; real value only shows up when the tooling reaches the processes that need it, not when a few enthusiastic people have access to a tool the rest of the workflow can’t use.

The takeaway: don’t leave any part of the workflow behind

If you’re on an AI Native spec-driven project, or about to start one, here’s the honest version of the lesson this project taught us: don’t treat AI tooling as something you roll out to the parts of the workflow that are easiest to convert and leave for later everywhere else. The speed of the fastest-connected parts of the team becomes the new baseline, and every other part of the workflow is measured against it, whether that feels fair or not.

The good news is that this is genuinely an easy problem to fix, and an exciting one to lean into. Connecting every part of the workflow to the source of truth, letting AI draft the first pass of routine documentation and keeping records live instead of static: none of this asks anyone to give up the expertise that makes them good at their job. It means making sure that expertise isn’t being spent on manual re-typing, so it can go toward the judgement calls only a person can make. On this project, that was the difference between a process everyone had to wait on and one that helped set the pace.

The choice to make now isn’t who’s willing to adapt. It’s making sure every part of the workflow has the tools to.