โ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
New Zealand