This is the complete first chapter of Judgment-Driven Development: Leading Software Teams When AI Does the Work, published here as a free sample.

When execution becomes cheap, the constraint does not disappear. It moves. And what used to be overhead becomes the job. The one constant is the need for human judgment.

Over the years, the main cost of software development was the actual execution. The introduction of higher-level programming languages like Java, JavaScript, and Go lowered the skill floor and increased developer productivity, but building software remained expensive, slow, and dependent on specialized talent. At the median public software company, R&D still consumes about a quarter of revenue.¹

Everything was built around this constraint: teams small enough to be effective and large enough to produce; processes like Waterfall, Scrum, and SAFe that streamlined communication with and within those teams; hiring funnels designed to identify the most talented engineers and reduce churn; and metrics that helped managers evaluate progress against a bottleneck that everyone accepted as fixed.

GitHub Copilot had already shown in 2021 that a model could write usable code.² The introduction of ChatGPT in November 2022 changed that for everyone else.³ Producing a first working version of something that used to take a full team and weeks now takes hours and one person. Shipping it well is a separate question, and most of this book is about why. Execution is becoming cheap, but the constraint is not gone. It has moved.

Where the Constraint Went

Industries that see the cost of a core input collapse tend to go through the same sequence. First, celebration. Then, overproduction. Then, a painful discovery: the thing that used to be the bottleneck was also the thing that forced discipline.

When computing became cheap, we did not get less waste. We got data centers full of workloads nobody could justify. When content became cheap to distribute, we did not get better information. We got an attention crisis. When capital became cheap in the 2010s, we did not get better companies. We got a decade of businesses that never had to answer the question of whether they should exist.

Software execution is now running the same play.

The constraint did not disappear when execution got cheap. It moved upward, to the layer of decisions that execution used to hide: which problem is actually worth solving, whether the spec itself is wrong, what quality means in this specific context, what risk is acceptable, and who owns the consequence if the answer turns out to be wrong.

That layer has a name. It is judgment.

For decades, judgment looked like a soft skill because execution absorbed all the visible cost. A bad decision took weeks to become code, and in those weeks there were review meetings, estimation sessions, and enough friction that someone usually asked the uncomfortable question before the investment became irreversible. Judgment was exercised constantly, but it was buried inside the process. Nobody had to name it because the system enforced it by accident.

Cheap execution removes the accident.

The Friction Was Doing Work

Here is the part most teams have not internalized yet: the slowness of the old world was not pure waste. Some of it was, certainly. But a meaningful share of that friction was performing an invisible function: it was a filter.

When a feature cost three weeks of engineering time, the organization asked hard questions before committing. Is this worth a sprint slot? Did anyone talk to a customer? Are we sure? The questions were not asked because the process demanded rigor. They were asked because the cost of being wrong was painful enough to force them.

Estimation meetings were judgment rituals disguised as planning. Sprint capacity was a judgment mechanism disguised as resource management. Even the backlog, that graveyard of ideas nobody prioritized, was doing judgment work: most bad ideas died there quietly, at zero cost, because execution was too expensive to spend on them.

Remove the cost, and every one of those filters weakens at the same time.

One of my favorite economics journalists posted last year that Claude is his new best friend, that Claude had made him a developer, and that he was publishing apps for people to use. He is not a programmer. He did not become one. What changed is that the filter which used to stand between him and a shipped application stopped being there.

An idea that would have died in the backlog now becomes a working prototype by Thursday. A spec that would have been challenged in estimation now ships before anyone reads it carefully. The prototype looks finished, which is its own trap, because polish has always been our proxy for maturity, and that proxy just broke. AI produces polished output at every stage of thinking, including stages where the thinking is wrong.

Now multiply one skipped question by everything else happening in the organization that week. A dashboard nobody asked to see. A workflow automation nobody tested against edge cases. A customer-facing email nobody proofread for tone. Each one individually looks like a rounding error, a small shortcut that saved an afternoon. None of them alone would sink a company. But they do not happen alone. When execution is free, they happen constantly, in parallel, across every team, and nobody is tracking the sum of them. Technical debt nobody chose to take on. Security exposure nobody signed off on. A product that has quietly drifted away from any coherent vision, not because of one bad decision, but because a thousand small ones each felt too cheap to deserve real scrutiny. The danger of losing judgment was never really about any single ticket. It is about what accumulates when nobody is watching the total.

The uncomfortable conclusion: organizations did not have judgment processes. They had expensive execution, and judgment came along for free. Now execution is cheap, and judgment has to be built deliberately, as a first-class discipline, because nothing enforces it anymore.

That is the entire argument of this book, compressed into one sentence. The rest is mechanics.

The Amplifier Problem

There is a tempting way to misread this moment: AI made us faster, and faster is better, so the teams that adopt fastest win. Every vendor deck says some version of this. It is not that it is wrong, it is dangerously missing a significant part of the picture.

AI does not make teams better. It makes teams more of what they already are.

A team with strong judgment, clear decision ownership, and honest quality standards will use cheap execution to test more ideas, kill bad ones earlier, and ship the survivors with confidence. The same drop in execution cost, handed to a team with weak judgment, produces something very different: more features nobody asked for, more architectural drift, more security surface, more noise in the product, all generated faster than anyone can review it.

Both teams show impressive velocity metrics. Both teams look productive in the dashboard. One of them is compounding value. The other is compounding liabilities, and the liabilities are wearing the costume of progress.

This is why the winners and losers of the AI transition will not be sorted by adoption speed. They will be sorted by judgment quality, because AI is an amplifier, and an amplifier does not care what signal you feed it.

In the old world, weak judgment produced slow failure. You had time to notice, time to correct, time for the friction to save you. In the new world, weak judgment produces fast failure at scale, and the failure arrives polished, tested, and deployed before the question that should have killed it was ever asked.

Cheap execution does not lower the stakes of judgment. It raises them.

What This Looks Like on the Ground

The shift I am describing is not theoretical, and it is not waiting in some agentic future. It is visible today, in ordinary teams, in ordinary weeks. Three scenes.

Scene one. A product manager receives a customer request for an export option on a reporting screen. In 2021, this was a ticket, an estimation, a two-week wait, and somewhere in that pipeline someone would have asked whether the customer actually needed an export or was working around a deeper problem with the dashboard. In 2026, the PM prototypes it in an afternoon and it ships within the week, after which the export gets used once. The deeper dashboard problem, the one the request was actually signaling, remains untouched. Execution succeeded. Judgment never entered the room.

Scene two. An engineer asks an AI assistant to refactor an authentication module. The output is clean, well-commented, and passes every test. It also quietly changes a session-handling behavior in a way the tests do not cover, because the tests were written for the old assumptions. The engineer approves the change in four minutes, because the code looks right, and looking right used to be a reliable signal. Six weeks later there is an incident, and the postmortem cannot identify who decided to change the session behavior, because nobody did. The decision was made by omission, at review speed, by a person whose role had silently shifted from author to approver without anyone updating what approval was supposed to mean.

Scene three. A VP looks at the quarterly dashboard, where deployment frequency is up 3x and cycle time is down 60 percent. Every metric the organization spent a decade learning to optimize is glowing green. And yet customer satisfaction is flat, churn is creeping upward, and the roadmap feels noisier than it did a year ago. The instruments say the team is winning. The instruments were built to measure a constraint that no longer exists. The VP is flying with gauges wired to the wrong engine.

Three scenes, one pattern. In each case the execution layer performed flawlessly and the judgment layer was absent, not because the people lacked judgment, but because nothing in the system asked for it at the moment it mattered. The old system asked automatically. The new one does not.

Now run scene one again with judgment applied. The PM still moves fast on execution. But before anything ships, judgment enters from multiple directions. The PM asks: Is this the right thing to build, or just the one someone requested? What does success look like? Who is accountable for this decision? UX asks: Is the placement right? Does this fit the existing flow or create confusion? Does the prototype actually make sense to someone seeing it for the first time? The developer asks: Does this introduce any security implications? Are we creating debt we will regret? And because a working prototype now exists in hours rather than weeks, the team can put it in front of a solutions engineer, a customer, a skeptic, and get a real signal before a line of production code is written.

Nothing in that version is slower. The export still ships that week. What is different is that somebody asked what it was for.

The Wrong Conclusions

Whenever this argument lands, it tends to generate two opposite and equally wrong responses. Both are worth naming now, because the rest of this book is built between them.

The first wrong conclusion is the brake. If cheap execution is dangerous, slow down. Add approval gates, review boards, and mandatory checkpoints, and restore the friction on purpose. This fails for a simple reason: the friction of the old world was not valuable because it was slow. It was valuable because of the questions it happened to force. Artificial slowness restores the cost without restoring the questions. You get the worst of both worlds, a team that moves slower than its competitors and still ships unexamined decisions, just with more meetings attached. Judgment is not the opposite of speed. Treating it that way is how governance gets a bad name.

The second wrong conclusion is the ostrich. The models will get better, the tools will catch the errors, this is a transition problem that scale will solve. This misreads what judgment is. Better models will absolutely make fewer execution mistakes. But deciding what should exist, what risk is acceptable, and what outcome actually matters is not an execution task that models are temporarily bad at. It is a different category of work. It requires owning consequences, and ownership is precisely the thing that cannot be delegated to a system that does not bear them. Improving models does not shrink the judgment layer. It moves more consequence onto every judgment that remains.

The teams that will define the next decade reject both conclusions. They move at full AI speed on execution while building judgment as an explicit, designed, accountable practice that runs alongside it. Not a gate in front of the pipeline. A discipline inside it.

This book is about how to build that discipline.

What Was Always Scarce

We used to go from intent to instructions to results, with the programmer as the translation layer. Now AI has collapsed that step, and we go straight from intent to results. The translation layer is gone. What remains is what happens before the intent and after the results.

Before the intent, someone has to know what problem they are actually solving. Not what they think they are solving, but what the system actually needs to do, for real users, under real conditions, with real constraints.

After the results, someone has to evaluate whether the output is correct, secure, maintainable, scalable, and appropriate. Whether it handles failure. Whether it makes the right tradeoffs. Whether it survives contact with reality, not just the happy path, but the messy one.

None of this is entirely new. Good engineers and good PMs have always been the judgment layer. What is different is the volume. Judgment used to get exercised at the pace execution allowed, which meant a handful of real decisions per sprint, each one earning the time it took to think it through. Now judgment needs to run at the pace AI allows, which means dozens of decisions a day, most of them small enough that nobody feels justified slowing down for them. The skill is not new. What is new is the demand for it to run continuously instead of occasionally. Most organizations do not have anyone whose job is to supply judgment at that pace, because until recently nobody needed judgment supplied at that pace. That gap is the actual problem this book is about.

Now that everyone can build, the line that matters runs between people who can generate output and people who understand the consequences of that output. Anyone can prompt. Not everyone can make a judgment. And increasingly, the difference between them is not visible until something breaks.

Which brings me back to the journalist. He built the app, and for a while that felt like the whole story. Then someone decided to test it, ran roughly a hundred thousand searches against his site in a deliberate flood, and posted about taking it down. He later said the experience taught him there are different kinds of people on the internet. Alongside the person who attacked him, strangers he had never met, who knew he was not a programmer, found real security vulnerabilities in what he had built and patiently helped him close them, instead of exploiting them the way the first person had.

Both halves of that story make the same point. The vulnerabilities were there either way, put there by nobody with the judgment to see them coming. The outcome was decided by who showed up afterward, and what they chose to do with what they found.

He became a developer the moment execution got cheap enough to hand him the tool. He is not an engineer yet, and the difference between the two was never about who could type the code.

Why the Same Trick Does Not Work Twice

Every reader of the last several pages has just watched a scarcity evaporate. Execution was expensive for decades, then for a few years, then technology made it nearly free. The honest question is why judgment gets to be different, not why it matters. That case has been made. Why does it stay scarce when the last scarce thing did not?

Scarce does not mean rare, and it does not mean valuable in the loose sense the word gets used. It has a narrower meaning, and the narrower meaning is the useful one: a resource is scarce when demand for it exceeds what is available at a price anyone is willing to pay, and the interesting consequence is that price moves until something gives. You can usually tell what an organization has always treated as scarce by looking at what it built machinery to protect. Code review exists to protect against bad code, which used to be expensive to produce and expensive to fix. Estimation exists to protect a sprint’s capacity, which was fixed and finite. Every ceremony this chapter has already named as a casualty of cheap execution was, until recently, guarding something that could run out.

Now ask what happens to the price of a thing when supply expands faster than demand does. It falls, and keeps falling, until the market stops noticing it as a constraint at all. That is the story of execution over the last several years, told in one sentence. A system trained on enough examples of correct output can produce more correct output, on demand, at whatever volume anyone will pay for. Code either compiles or it does not. A test either passes or it does not. Train against a signal that clean and the price of producing it collapses, because the thing being graded can be graded in milliseconds, by something other than a person, the moment it exists.

Judgment is much harder to grade that way, and the obstacle is timing more than technology. The flaws in a decision are usually there the moment it ships, and nothing about the moment of shipping reveals them. They become visible later, to people using the system under conditions nobody simulated. That gap, between when a decision gets made and when its correctness becomes knowable, is not a flaw in how judgment happens to work. It is what judgment is. The results of a decision, good or bad, often do not come into view until months later. Only then can you see whether the call produced the outcome you were trying to produce, and whether the assumptions underneath it held in a context that did not exist when you made it. That does not make outcome a verdict on decision quality: a sound decision can produce a bad result, and a poor one can get lucky. The thing that makes a call a judgment call, rather than a lookup, is that much of the evidence needed to evaluate it arrives late, arrives ambiguous, and arrives addressed to a specific person who has to stand behind it when it does. You cannot train a fast, cheap grader against a signal that is not there at training time. And once the signal exists, it belongs to whoever made the call and lived with what happened, not to whoever is trying to manufacture more calls that resemble it.

None of this means the tools cannot produce plausible decisions. They already do, fluently, on request. It means plausible and verified are different properties, and only one of them was ever actually scarce. Supply expanded for the property that could be checked in milliseconds. It did not expand, and will not, for the property that can only be checked by waiting for the consequence and then answering for it, because waiting does not get cheaper no matter how much compute gets thrown at it.

That is where the value goes, and it is worth being specific about the mechanism rather than asserting the conclusion. Once execution is nearly free, an organization’s output stops being limited by how much it can build. It becomes limited more and more by whether what it built should have existed, and that limit is set by however few people in the building are actually exercising judgment rather than generating plausible work and hoping it holds. Their calls used to be one input among several, competing for attention with a dozen other constraints that were expensive in their own right, a slow build process, a limited testing window, a backlog that forced choices on its own. Much of that friction is gone. Everything downstream of a decision now happens automatically the moment someone says yes, which makes the decision the cheapest place left to catch a mistake before it compounds. Get the call right and the abundance compounds in the organization’s favor. Get it wrong and the abundance compounds against it, faster than it would have when building the wrong thing was still slow enough to notice halfway through.

Multiply that across a company and the effect does not average out. It concentrates. A handful of people making the calls that route everything else now determine more of the outcome than they used to, not because they got smarter, but because there is less friction left anywhere else to absorb what they get wrong. Ten years ago, a bad call from a mediocre engineer moved slowly enough that someone usually caught it before it shipped, simply because everything moved slowly. That protection is gone. The call still gets made by one person. What follows it no longer waits for anyone to check.

That is what it means for scarcity to be where value concentrates. Not a slogan, a mechanism: the scarce input in a chain sets what the rest of the chain is worth, and for the first time in this industry’s history, that input is not execution. Judgment did not become valuable because this book decided to make an argument for it. It became the place value concentrates the moment every other input in the chain stopped being scarce enough to compete for it.

The Shape of the Argument

Judgment-Driven Development, JDD for short, is the operating model this book proposes. It rests on a small number of claims that the following chapters will develop and defend.

First, that judgment is now the scarce resource in software development, and scarcity is where value concentrates. That is the case this chapter has just made.

Second, that judgment cannot remain implicit, because it needs explicit structure: decision boundaries that match authority to consequence, and institutional memory that keeps decisions from evaporating. That structure is the framework at the center of this book.

Third, that every role in the development organization is being redefined by this shift, not replaced. Engineers and product managers each face a version of the same question: what is my craft when the artifact is cheap? The middle of the book takes each role in turn, including the hardest version of the question, which is how can anyone become a senior in a world where AI does the work that used to build seniority.

Fourth, that organizations are structurally rigged against this transition, because every metric, ritual, and incentive they run was built to protect a constraint that no longer exists. Adopting JDD is not a process change. It is a fight with the organization’s immune system, the people, policies, and habits that defend the status quo whether or not the change is good for it, and the later chapters are about how to win it. If you are weighing whether that fight is worth starting, Appendix 1 sets out what a first quarter costs, how to measure it, and how to tell whether it paid.

And finally, that all of this becomes more true, not less, as AI systems become more autonomous. When the agent executes end to end, judgment does not disappear. It moves upstream, concentrates, and carries more consequence per decision than it ever has. JDD is not a coping strategy for today’s tools. It is the operating model for what is coming.

The same shift is visible one level further out, in what companies buy rather than only in how their teams work, and that is where the next chapter goes.

Execution is becoming free. That is not the story. The story is what becomes expensive when it does.

Judgment just became the most expensive thing in your organization. The question is whether you are treating it that way.

In Short. AI has made execution cheap, and the constraint it used to impose has moved to judgment: deciding what to build, whether it is right, and who answers for it. The old friction was doing that judgment work by accident, and cheap execution removes the accident. Judgment is now the scarce input, and the scarce input is where value concentrates.

Sources

  1. Blossom Street Ventures, “Annual R&D SaaS Spend Metrics of 74 Publics,” Medium, August 22, 2025. https://blossomstreetventures.medium.com/annual-r-d-saas-spend-metrics-of-74-publics-4e38c24de0b6 (accessed October 31, 2026)

  2. Nat Friedman, “Introducing GitHub Copilot: your AI pair programmer,” The GitHub Blog, June 29, 2021. https://github.blog/news-insights/product-news/introducing-github-copilot-ai-pair-programmer/ (accessed September 4, 2026)

  3. OpenAI, “Introducing ChatGPT,” November 30, 2022. https://openai.com/index/chatgpt/ (accessed September 4, 2026)

Keep Reading

This chapter makes the case that judgment is now the scarce input. The rest of the book is the mechanics: the JDD cycle and its checkpoints, decision boundaries for people and AI agents, the Judgment Log, what changes for product managers, engineers and juniors, and a roadmap for running JDD in one team for one quarter.

Get the book on Amazon (paperback and Kindle) or see the full contents.