When I led development teams, I always believed that the ability to build was our edge. Give the team room and flexibility and we could make almost anything ourselves. But building was never the real question. Every serious feature came down to build versus buy, and the deciding factor for me was always the same: was this core business logic that actually differentiated us? If it was, we built it and owned it. If it was not, buying was almost always the smarter call. What has changed is not that logic. It is that the cost of building has fallen so far that the temptation to build everything is stronger than ever, even when it is not the right decision.
Last month I watched a mid level engineer stand up a working service in about forty minutes. Authentication, a REST layer, input validation, a test suite, and a passable README. Two years ago that was a sprint. What struck me was not the speed. It was the silence in the room afterward, because the hard conversation had not even started. Should this service exist? Should it own that data? Was REST the right call, or did we just build the thing the assistant was fastest at generating?
That gap between “we can build it” and “we should build it, this way, now” is where engineering work is quietly relocating. For most of our careers, implementation was the expensive part. That assumption no longer holds, and a lot of team design is built on top of it.
The old bottleneck is collapsing
The cost of turning an idea into running code has been falling for a long time. High level languages, package managers, cloud primitives, and copy paste from the wider internet all chipped away at it. AI coding assistants and agentic workflows have turned that slow decline into a cliff. A prototype that used to take a week takes an afternoon. A one off migration script that used to take a day takes ten minutes.
When you cut the price of something dramatically, you get more of it. Teams are now generating more candidate implementations, more branches, more prototypes, and more “what if we just tried it this way” experiments than ever before. That is genuinely good. Cheap building means cheap exploration.
But cost does not disappear. It moves. And it has moved to the one part of the pipeline that no assistant has automated away: deciding.
When building gets cheap, deciding gets expensive
Consider what actually happens now when a team picks up a feature. The assistant can produce three plausible designs before lunch. Now someone has to choose. Which data model do we commit to? Do we accept the coupling this introduces? Is this a change we can walk back next quarter, or are we about to bake it into a public API that a dozen downstream teams will build on?
Those questions were always there. What changed is their share of the total effort. When building was 80 percent of the work, deciding was a rounding error you could absorb in a hallway conversation. When building drops to 20 percent, deciding becomes the main event, and most teams have no process for it beyond that same hallway conversation, now hopelessly overloaded.
This is the shift in one sentence: the scarce resource is no longer the ability to produce a working artifact. It is the judgment to know which artifact is worth keeping and what it commits you to.
Why decisions are now the constraint
Three forces make decisions the binding constraint rather than just a cost that grew.
More options per unit time. Every generated alternative is a decision you now owe. Ten prototypes is not ten times the progress. It is ten times the deciding, and deciding does not parallelize the way generation does. A single senior engineer or architect becomes the queue that every branch waits in.
Decision debt compounds quietly. We talk endlessly about technical debt. Decision debt is worse because it is invisible until it detonates. It is the accumulation of choices made implicitly, by default, or by whoever’s code got merged first. When building was slow, the pace of code creation throttled how fast you could accrue this debt. Remove the throttle and you can bury a team in unexamined commitments in a single quarter.
Alignment becomes the real work in progress. Watch where things actually stall today. Rarely at the keyboard. Usually in the review queue, the design doc waiting for comments, the Slack thread where three staff engineers disagree about an approach and nobody owns the tiebreak. That is decision latency, and it is now the dominant term in your cycle time.
What good looks like
The teams pulling ahead are the ones treating decision making as a first class engineering discipline, not an afterthought. A few patterns are doing real work.
Classify the door before you walk through it. The most useful frame I know separates reversible decisions from irreversible ones. Cheap to reverse? Do not convene a committee. Let an engineer pick, ship, and learn. Expensive or impossible to reverse, like a public API contract, a data retention model, or a security boundary? That earns real deliberation. The failure mode I see most is teams applying heavyweight process to reversible choices and no process at all to the irreversible ones. When building is cheap, most decisions become more reversible, which means you should be pushing far more of them down and out.
Write the decision down, lightly. A short architecture decision record captures the context, the options, the choice, and the tradeoff accepted. Two paragraphs beats a forty page design doc nobody reads. The point is not ceremony. It is that six months from now, when someone asks “why is it like this,” the answer exists and does not require archaeology. In a world where the code was half generated, the reasoning behind it is the artifact worth preserving.
# ADR 042: Event sourcing for the ledger service
Status: Accepted
Context: We need an auditable history of balance changes.
Decision: Append only event log as the source of truth.
Tradeoff accepted: Higher read complexity now, in exchange for
a complete audit trail we cannot reconstruct later.
Reversibility: One way door. Revisit only with a migration plan.
Assign the owner, not the committee. Every consequential decision needs a name attached, someone accountable for making the call and living with it. Consensus feels safe and is usually just diffused ownership. Fast teams name a decider, gather input on a clock, and move.
Attack decision latency directly. Measure how long a design sits in review. Put a timebox on it. Make “we decided” a visible event, not something that emerges by attrition when the loudest person tires out.
Implications for technical leaders and topologies
If deciding is the new bottleneck, the job of a technical leader changes. The highest leverage senior person on a team used to be the one who wrote the trickiest code. Increasingly it is the one who makes the tricky calls fast and well, and who builds the machinery for the rest of the team to do the same.
That means leaders shift from code reviewers to decision enablers. Reviewing every line does not scale when the line count explodes. What scales is establishing the guardrails, the defaults, and the patterns that let engineers decide safely on their own. Think guardrails over gatekeeping. A paved road that makes the safe choice the easy choice removes a thousand small decisions from the queue before they ever form.
It also means we invest deliberately in judgment and taste, the things assistants do not have. Knowing that the elegant abstraction is premature. Sensing that a dependency will hurt in a year. Feeling when a design is too clever. That intuition is now the differentiated skill, and it is developed by giving engineers real decisions to own early, then reviewing the outcomes together.
The edge is decision velocity and decision quality
The comfortable metric for a decade was output. Story points, PRs merged, features shipped. When output was expensive, output was a fine proxy for progress. It is not anymore. A team that generates twice the code but takes three weeks to decide what is worth keeping is slower than a team that generates half as much and decides in a day.
The competitive edge is moving to decision velocity multiplied by decision quality. Deciding fast, deciding well, and knowing which decisions deserve which level of care. Building is nearly free now. What you choose to build, and who gets to choose, is the whole game.
Further reading worth your time: the reversible and irreversible decisions framing, Michael Nygard’s original ADR write up, and the Team Topologies material on cognitive load and team design.