“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 parameters and numbers—the metrics most organizations obsess over. At the top are paradigm shifts—fundamental changes in how we think about a problem.

“I tell people, the first thing you should do is read the last chapter about the 12 leverage points,” Ferguson says. “Understand that your leverage point needs to start around the middle—the six or the seven—where we’re changing paradigms, where we’re actually changing how these systems impact each other.”

This systems lens explains why Ferguson believes SDLC transformation is more valuable than any individual technology choice.

“When I come into a company, I’m constantly thinking about the systems I’m observing,” he says. “That’s where I find I can have the greatest impact. I want to operate to make sure we’re making the right operational decisions and process decisions.”

The Factory Metaphor

Perhaps Ferguson’s most useful reframe is viewing software development as factory engineering rather than craft production.

“We’re creating a software factory. The engine in our factory is AI. You have inputs to the system. You have feedback loops to the inputs. You can either impact the feedback loops and get reoccurring results that are virtuous, or you can just fix the toys at the end of the line and never fix the feedback loop.”

In this model, software engineers become process engineers. Their job isn’t primarily to write code—it’s to design, optimize, and govern the system that produces code.

“Software engineers are the process engineers of a factory,” Ferguson says. “I understand how this factory works. I understand the inputs. I understand the outputs. I understand how I can impact the inputs. If you’re gonna build a factory, you better have a systems thinking approach.”

This has significant implications for hiring and team development. Ferguson is actively retraining his developers to think more like product managers—to write excellent requirements, to understand stakeholder needs, to communicate abstractions clearly.

“Writing software’s not the hard part anymore,” he observes. “The value is writing great requirements, great user stories, the use cases, and making sure you’re writing those initial documents correctly.”

Implications for SaaS Selection

Ferguson applies the same thinking to vendor relationships. His first question to potential partners: “How are you writing software?”

“If they’re not using document-driven development and can’t describe that process, they go pretty far down the list,” he says.

His reasoning is economic. As AI capabilities accelerate, vendors with undisciplined development processes will struggle to compete against AI-native startups with fraction-sized teams and radically lower cost structures.

“A startup is gonna run circles around you,” Ferguson warns established players. “And all it is, is marketing at that point. And it’s a price point.”

The implication for CTOs evaluating SaaS purchases: due diligence on a vendor’s development methodology may be as important as feature comparisons. Partners who can’t articulate how they’re adapting to AI-assisted development may face existential pressure in the coming years.

Beyond Software: Enterprise-Wide AI

Ferguson is careful to note that Document-Driven Development is only part of a broader transformation. For CTOs, the mandate extends across the entire organization.

“You can’t just be improving the software side of the shop,” he says. “What are you doing about ordering and marketing and all these other processes?”

His framework for enterprise AI adoption centers on business process mapping—identifying where humans currently insert themselves to make processes work, then asking whether those decision points could be automated.

“Where’s the human inserting themselves to make this process work? Why does that need grease from a human all the time? Do we have the right inputs that an AI could make the same decision?”

The metric Ferguson uses to evaluate progress: how many agents is each team member managing?

“The measurement of the people in your company needs to be, how many agents am I managing? I shouldn’t be doing work. I should be managing my agents that are doing my work for me.”

Getting Started: A Practical Path

For CTOs looking to adopt these approaches, Ferguson offers a straightforward sequence:

First, solve the product-requirements interface. Wherever product specifications are authored in your organization, that’s your entry point. Ensure requirements are structured for AI consumption, with clear acceptance criteria and well-defined boundaries.

Second, prototype and enforce a process. Document-driven development only works if it’s actually used. Model the approach yourself, build governance around it, and resist the temptation to let individual developers freelance.

“Everybody can’t be doing