The Software Factory: Why Document-Driven Development Is Reshaping How CTOs Build

“We’re not doing software development anymore. We’re engineering a factory.”

That single line from Matt Ferguson captures a fundamental shift happening in technology leadership. As CTO of Roof Maxx—a nationwide roofing brand with 385 dealerships—Ferguson has spent the past year transforming how his team builds software. The methodology he’s championing isn’t new, but its implications in the age of AI are profound.

It’s called Document-Driven Development. And if you’re still measuring your engineering team by lines of code, you may be optimizing for the wrong century.

The Cost of Software Is Collapsing

Ferguson opens with a provocative claim: “The cost of software goes to zero.”

He’s quick to acknowledge this is a euphemism—a deliberate exaggeration meant to spark conversation. But the directional truth is harder to dispute. When a team that once needed 100 engineers can now accomplish the same work with 10, or when the same team can produce 10x the output, the economics of software fundamentally change.

“If they’re not taking into consideration the risk of their business when the cost of software goes to zero,” Ferguson says of potential vendor partners, “then they’re not gonna be a partner in two years because they’re gonna be out of business.”

The data on AI-assisted coding tells a more nuanced story. A recent randomized controlled trial from METR found that experienced developers were actually 19% slower when using AI tools—despite believing they were 20% faster. Meanwhile, studies from GitHub and Microsoft show gains of 20-55%, with the strongest improvements among junior developers tackling well-defined tasks.

The takeaway isn’t that AI doesn’t help. It’s that how you use it matters enormously. And that’s where Document-Driven Development enters the picture.

What Is Document-Driven Development?

At its core, Document-Driven Development flips the traditional software process. Instead of diving into code and documenting later (or never), teams invest heavily upfront in requirements, specifications, and architectural documentation—then use AI to generate code from those artifacts.

“Our document-driven development is the concept of writing down what you want to do, what your problem is that you want to solve, in a descriptive enough way that the AI can interpret and plan the work, and through that plan can execute the code,” Ferguson explains.

The approach has been championed by Ryan Vice, CEO of Vice Software, through his DocDD.ai methodology. GitHub recently validated the concept with their “Spec-Driven Development” toolkit, and AWS published their “AI-Driven Development Lifecycle” framework—both emphasizing documentation as the critical input to AI-assisted coding.

Ferguson’s team has taken this further than most. His developers now spend roughly 90% of their time writing and refining requirements, and only 10% reviewing code.

“Documents are your new code,” he says. “Treat them like code, put them in your GitHub repository as code, and iterate on them as your source code.”

The Goal: One-Shot Code Generation

The ambition behind Document-Driven Development is what Ferguson calls “one-shotting” the code—generating production-ready software on the first attempt.

“We’re not here to pull the old slot machine and see what we get,” he explains. “Oh, all jacks. That’s wonderful. Oh, we didn’t win that one. Try again. Until AI gives us the right answer. That’s not what we’re after.”

This stands in stark contrast to “vibe coding”—the practice of giving AI a rough prompt and iteratively debugging whatever emerges. Ferguson sees this as a recipe for unreproducible results and mounting technical debt.

“If you’re not putting time into governance and you’re giving everybody free reign to do whatever they want,” he warns, “you’re gonna get different results. And when you try to build that piece of software six months from now, you might get a different result—which is not acceptable.”

The key insight is that the “one shot” doesn’t mean one interaction with AI. It means extensive iteration on the documents—using AI to stress-test requirements, identify edge cases, and refine specifications—before any code is written.

“We probably did a lot of interactions with AI, conversations with a highly intelligent, highly well-reasoning system,” Ferguson clarifies. “Just so that we’re getting to that point where we think a one shot is possible.”

Systems Thinking: The Intellectual Foundation

Underneath Ferguson’s methodology lies a deeper framework: systems thinking, particularly as articulated by Donella Meadows in her seminal work “Thinking in Systems: A Primer.”

Meadows identified 12 leverage points for intervening in complex systems, ranked from least to most powerful. At the bottom are parameter