Engineers Becoming Product People

“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 their own thing,” Ferguson emphasizes. “We’re not building ET’s software factory and Matt’s software factory and John’s software factory. We’re building a software factory. Everybody’s following the same process.”

Third, extend the thinking beyond engineering. Look for high-value business processes where AI agents could replace human decision-making. Invest in frameworks that allow non-programmers to build and manage their own agents.

The Energy Question

When pushed to imagine the far future—a world where AI can generate any software on demand—Ferguson lands on an unexpected constraint: energy.

“The answer to the question is the cost of energy,” he says. “If I wrote the same thing in assembly language, it would be far less energy intensive than writing in Java. The same thing is moving up the stack all the way to AI—worst case scenario, I’m burning more electricity to do the same thing.”

In a world of abundant, cheap energy—fusion power, orbital data centers—Ferguson sees no reason to maintain software at all. Everything becomes real-time interpretation. But until that day: “The economics will answer that question for us.”

The Bottom Line

Document-Driven Development isn’t magic. It won’t transform every team overnight, and the research suggests productivity gains are real but more modest than the hype implies—typically 20-30% improvement, not 10x.

But Ferguson’s underlying insight is sound: in an age of AI-assisted coding, the bottleneck shifts from implementation to specification. The teams that invest in better inputs—clearer requirements, stronger governance, reproducible processes—will capture more value from AI than those who simply give developers access to Copilot and hope for the best.

“If the cost of software goes to zero, you got no more excuses,” Ferguson says. “Domain-driven design, test-driven development, service-oriented architectures—these are the patterns we should be based on. Anything else has always been cutting corners.”

The corners are getting harder to cut.

Matt Ferguson is CTO of Roof Maxx, the nation’s leading provider of sustainable roof restoration solutions. Prior to Roof Maxx, he served as Director of Data Engineering, AI, and Machine Learning at Simple Technology Solutions and was CTO of Galley Solutions.

For more on Document-Driven Development, visit DocDD.ai or explore Ryan Vice’s YouTube channel.

Donella Meadows’ “Thinking in Systems: A Primer” is available wherever books are sold.

Key Takeaways:

* Document-Driven Development inverts traditional software processes—invest 90% of effort in requirements, 10% in code review

* The “one-shot” goal means extensive AI-assisted iteration on documents, not a single prompt-to-production attempt

* Systems thinking provides the intellectual framework—focus on leverage points 6-7 (paradigms and feedback loops), not just parameters

* Software engineering is becoming process engineering—the factory metaphor reframes what CTOs should optimize

* Vendor due diligence should include questions about AI-assisted development methodology

* Enterprise-wide AI extends beyond engineering—map business processes to identify automation opportunities

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit www.ctopod.com