How the Collapse of Build Time Changes Everything About How We Work
A Note Before I Share My Book
This book started as an exploratory conversation. Not a planned one. The kind that starts somewhere reasonable and ended somewhere I never expect to be.
The conversation started when I read an article about a software team at OpenAI that built a million lines of code with no human-written code.
Along the way, I found myself articulating something I had felt for a long time but never quite named. Something about why meetings feel increasingly pointless, why the people with the best ideas keep losing to the people with the fastest execution, and why the standard playbook for how teams build things together is starting to feel like a costume that no longer fits the body wearing it.
The book that follows is my attempt to put that something into words rigorous enough to be useful. I make no claim that I have all of this right. Some of what I argue here has good evidence behind it. Some of it is inference. I will tell you which is which, because I think you deserve that.
What I am confident about is this: the bottleneck has moved. And when the bottleneck moves, everything that was organized around the old bottleneck needs to be rethought.
That rethinking is what this book is about. And I’m sharing the first chapter.
CHAPTER ONE
The Meeting That Finished Well After the Work Did
The bottleneck was never writing the code. It was always deciding what to write.
Picture a room.
A new business developer sits across a table from a client they have been trying to land for six months. The brief came in three weeks ago. The pitch was sharp. Today is supposed to be the close — the conversation that ends with a signature.
But something is happening in the room that wasn’t in the plan.
The client is talking about what they actually need. Not what’s in the brief. Not what they told the procurement team. The real thing — the competitive pressure they didn’t put in writing, the internal politics around the last vendor, the thing their CEO said at the all-hands that is quietly reshaping every priority they have. The new business developer is listening with a different quality of attention than usual because they know this matters. Every nuance is being tracked.
By the time they shake hands and the client says yes, a product has already been built.
Not metaphorically. Not ‘in concept.’ Actually built. The conversation was being transcribed in real time, fed into a system that understood the context, and while the two people were still in the room negotiating the terms of what they would make together, an agent had already begun making it. By the time the new business developer gets back to their desk, the first version is waiting.
Nobody in the room mentioned this part. It didn’t seem like the moment.
This is not science fiction. The technical infrastructure for this exists today, in rougher form than it will in two years. What doesn’t exist yet is any coherent framework for what it means. For how teams should be organized around it. For what skills it demands, what roles it obsoletes, and what kind of judgment it elevates in ways we have not yet learned to reward.
This book is that framework. Or the beginning of one.
How We Got Here
To understand where we are going, it helps to understand what problem the last methodology was actually solving.
Before agile, there was waterfall. The name comes from a diagram — requirements flowing down into design, design into implementation, implementation into testing, testing into deployment. Each stage completed before the next one began. A project manager’s dream on paper. A developer’s nightmare in practice.
Waterfall wasn’t irrational. It was a rational response to a real constraint: changing software was expensive. If you discovered in month eight that you had misunderstood the requirement in month two, you were facing a rewrite that could consume the entire project budget. So you planned exhaustively before you wrote a line of code. You gathered requirements in excruciating detail. You documented everything. You tried to think of every contingency before the contingency arrived.
The problem was that you were trying to specify the future with precision, and the future declined to cooperate. Requirements changed. Clients changed their minds. The market moved. By the time the software was finished, it was often solving a problem that had evolved past the solution.
The insight that broke waterfall wasn’t philosophical. It was economic.
In the late 1990s, a software engineer named Kent Beck was working on a payroll system for Chrysler — the C3 project, which became one of the foundational case studies in software history. Instead of planning exhaustively before touching the code, he started doing something that looked almost reckless: writing tests before writing the code they were supposed to test, releasing in tiny increments so small they almost seemed trivial, keeping the client physically present with the team rather than at arm’s length behind a requirements document.
He called it Extreme Programming. His contemporaries called it various less polite things.
The core insight was simple: if changing code is expensive, plan before you write it. But what if you could make changing code cheap? What if iteration cost almost nothing? Then the entire justification for exhaustive upfront planning dissolves. You don’t need to get it right the first time if getting it wrong costs almost nothing to fix.
In 2001, Beck and sixteen others gathered at a ski resort in Snowbird, Utah. They were frustrated enough with what they called ‘heavyweight processes’ to write something down. They produced a document that is shorter than most email threads: the Agile Manifesto. Four values, twelve principles. The entire thing fits on a single page.
It changed how software is built.
Not immediately, not universally, not without resistance. Waterfall didn’t die overnight — it retreated into the industries where change was genuinely expensive: defense contracts, regulated financial systems, anything where the cost of a mistake wasn’t just a sprint retrospective but a regulatory investigation or a dead patient. In those domains, waterfall persists today and for some of them, probably should.
But for most software development, agile won. Sprints replaced phases. Backlogs replaced specifications. The daily standup replaced the monthly status report. Velocity became the metric. The scrum master emerged as a new kind of role — part project manager, part process guardian, part therapist for a team under constant deadline pressure.
And for a while, it worked. Better than what came before. The failure rate of software projects, which had been catastrophically high under waterfall, improved. Teams shipped more often. Feedback loops tightened. The gap between what was built and what was needed got smaller.
Agile solved the problem it was designed to solve. The problem is that the problem has fundamentally changed.
The Cost That Is Approaching Zero
In August 2025, a small team at OpenAI began an experiment. They started with an empty repository — no code, no scaffolding, nothing. Their constraint was deliberate and absolute: no human-written code. Every line would be generated by AI agents.
Five months later, the repository contained approximately one million lines of code. Three engineers had driven the process, opening and merging an average of 3.5 pull requests each per day. The product had internal daily users and external alpha testers. It shipped, broke, and got fixed — all through agents.
The team estimated they built in one-tenth the time it would have taken to write the code by hand.
Read that number carefully. Not twice as fast. Not ten percent faster. One-tenth the time.
This is what I mean when I say the cost of building is approaching zero. Not that it costs nothing — there is infrastructure, there is tooling, there are the salaries of three engineers. But the marginal cost of an additional feature, an additional module, an additional layer of the system is now close enough to zero that it changes the math of how you organize around building.
When Kent Beck made changing code cheap, he changed methodology. When AI makes building code cheap, it changes something larger.
It changes what is scarce.
The Scarcity That Remains
Economics is, at its heart, the study of scarcity. Everything else follows from the question of what is limited and what is not.
For most of the history of software development, the scarce resource was execution. There were not enough developers. The ones you had could only type so fast, think so clearly, work so many hours. The methodology problem — waterfall versus agile, scrum versus kanban — was fundamentally a problem of how to allocate that scarce execution capacity most effectively.
If execution is no longer scarce, something else becomes the constraint. The Theory of Constraints, developed by physicist-turned-management-theorist Eliyahu Goldratt in his 1984 novel ‘The Goal,’ makes a simple but powerful observation: every system has one constraint at any given time, and the performance of the system is determined by that constraint. Improving anything that isn’t the constraint doesn’t improve the system. It just moves the bottleneck somewhere else.
The bottleneck has moved.
What is scarce now is the quality of the decision before execution begins. The clarity of what to build. The accuracy of the understanding of who it is for and why they need it. The ability to synthesize the nuance in the room — the thing the client said and the thing they meant, the competitive context that wasn’t in the brief, the organizational constraint that will make a technically correct solution fail in practice.
This is not a new insight about what matters in product development. Good product managers have always known that understanding the problem is harder than solving it. What is new is that the gap between understanding and solution has collapsed to near-zero. Before, you had weeks or months between deciding what to build and having something to test. That gap forced a kind of tolerance for ambiguity — you couldn’t know if your understanding was right until you had built against it, and by then significant resources had been committed.
Now the gap is hours. Sometimes less.
This changes the stakes of the decision. It changes what it means to get the alignment wrong.
What Agile Gets Wrong About This Moment
I want to be careful here, because agile does not deserve dismissal.
The Agile Manifesto’s four values — individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, responding to change over following a plan — these are not wrong. They are, if anything, more true now than they were in 2001. Every one of them points toward the thing that is becoming more important, not less.
What agile gets wrong is structural, not philosophical.
The sprint is a unit of time organized around the assumption that building takes time. If you can build anything in hours, the sprint is no longer a useful unit. You don’t need a two-week container for work that completes in two hours. The standup that checks in on yesterday’s progress is reporting on work that finished before most people got to their desks. The retrospective that examines what slowed you down is examining a bottleneck that has already moved somewhere else.
There is a more pointed version of this observation. The scrum’s daily standup asks three questions: What did you do yesterday? What are you doing today? What is blocking you? These are the right questions for a world where execution is the constraint. In a world where decision quality is the constraint, they are the wrong questions entirely. You don’t want to know what someone built yesterday. You want to know whether the decision that drove that build was any good.
Agile also assumes a certain latency between decision and feedback. The sprint cycle exists partly because you need time to build something, show it to the customer, and incorporate their reaction. Compress that latency to near-zero and the sprint cycle doesn’t accelerate — it becomes structurally irrelevant. You don’t sprint when the finish line is already behind you.
Perhaps most importantly, agile was designed for a team of a relatively fixed composition doing a relatively fixed kind of work. Developers developing, designers designing, product managers managing the product. The roles were legible, the handoffs were defined, the ceremonies were structured around those handoffs.
When a developer and a designer and a business analyst can each, independently, produce a working version of the same product in a morning — and when those versions will be subtly different in ways that reflect the different contexts and assumptions each person brought to the task — the question of how to coordinate is no longer a question of handoffs. It is a question of what happens before anyone opens a laptop.
Back to the Room
Return to the new business developer and the client.
What made that conversation valuable was not that it produced a requirements document. It was that it produced understanding — the kind that lives in the gap between what someone says and what they mean, between the brief that went through procurement and the actual pressure that kept the client’s CEO up last Tuesday night.
Under waterfall, that understanding was captured imperfectly in a specification and then handed to a team that turned it into software over months, losing fidelity at every translation.
Under agile, that understanding was gathered iteratively, in sprints, with the customer checking in every two weeks to course-correct. Better. Slower than necessary. Dependent on the patience of the customer and the discipline of the team.
What I am describing in this book is what comes next. A model where the conversation itself is the specification. Where the understanding reached in that room — if it is rich enough, if it is genuinely shared, if the right people are present and asking the right questions — becomes the direct input to execution that happens in real time.
The discipline this requires is not the discipline of sprinting. It is the discipline of alignment. Of making sure that before a single agent begins executing, the humans in the room have genuinely converged on what they mean.
I call this Deliberate Alignment. Not because the word is elegant — there are more poetic options, and I considered them. But because deliberate carries exactly the weight I need it to. It implies intention, not accident. It implies that alignment is not something you hope happens in the course of a meeting but something you engineer, with rigor, before anything else begins.
The rest of this book is about what that engineering looks like.
A Map of What Follows
Chapter Two traces the history of methodology as a history of bottlenecks — how waterfall made sense given the cost structure of its era and how agile emerged not from philosophical insight but from a shift in economics. Understanding that history is essential to understanding why the current shift is structural rather than incremental.
Chapter Three makes the central argument explicitly: the bottleneck has moved. Execution is no longer the constraint. Decision quality is. I introduce the concept of decision latency — the gap between commitment and validated outcome — as the metric that should replace velocity for teams operating in this new environment.
Chapters Four and Five move from diagnosis to framework. Four examines what agile got right and what was scaffolding for a constraint that no longer exists. Five introduces Deliberate Alignment as a practice: what it is, who belongs in the room, what artifacts it produces, and what it is not.
Chapters Six through Eight address the human dimensions: the transformed client relationship, the organizational coherence problem when everyone has AI, and the diagnostic question of whether your organization is positioned for relief or for panic.
Chapter Nine takes the longest view — the emergence of Personal Software as a Service (PSaaS), and what happens to identity, ownership, and accountability when software becomes biographical. It’ll happen faster than anyone thinks; It’s happening right now.
Chapter Ten maps the landscape by industry: who is most exposed, who has genuine protection, and who is using compliance as cover for a vulnerability they haven’t yet examined.
Chapter Eleven gets concrete: what a Deliberate Alignment session actually looks like in practice, who is in the room, and how its output becomes the input for everything that follows.
Chapter Twelve is the honest reckoning. What I am confident about. What I am inferring. What would falsify the argument. And what the practitioners who live this will know before I do.
We are not at the end of methodology. We are at the end of one bottleneck and the beginning of understanding the next one.
The meeting has already finished.
The question is whether the work it produced was the right work.
That question is what Deliberate Alignment is designed to answer.
