Path dependence
The choice your agent makes on the first day does not stay a choice. Everything built on top of it turns a guess into a foundation.
Look at the keyboard in front of you. The top row of letters starts QWERTY, an arrangement chosen in the 1870s for a machine that no longer exists, the mechanical typewriter, where the layout is generally credited with keeping the type bars from jamming. The layout is still here, on your laptop, on your phone, on a device with no type bars to jam. It stayed not because anyone decided it was best but because, by the time it could have changed, everything had been built around it: every typist trained, every keyboard manufactured, every habit formed. To switch, all of that would have had to move at once, so none of it moved at all.
The economics of the road you are already on
Economists have a name for this. Paul David used the QWERTY story in 1985 to describe path dependence, and Brian Arthur built the deeper theory around it: in systems with increasing returns, small early choices get amplified over time until they lock in. Each new adopter of a standard makes that standard a little more valuable and the alternatives a little more costly to reach. The choice compounds. History stops being background and becomes a constraint, because where you can go next is decided by the road you are already on, not by the map of all possible roads.
The subtle part is that lock-in does not require the original choice to have been correct, or even good. It only requires that things got built on top of it. A locked-in default is not a verdict that the default was right. It is a measure of how much now depends on it. Those are completely different facts, and path dependence is what lets us mistake the second for the first.
The default that becomes a foundation
Now watch a coding agent set a path. It hits a fork the ticket never specified, picks the most common answer from its training because it cannot see the decision you would have made, and moves on. On day one that pick is weightless. It is one function, one shape, one guess, and if it is wrong you fix it in a line.
But code has increasing returns too. The next change imports that function. The one after assumes its shape. A test encodes its behavior. Another service starts calling it. Each of those is an adopter, and each one raises the cost of going back, exactly the way each trained typist raised the cost of leaving QWERTY. By the time anyone asks whether the original guess was right, the honest answer no longer matters, because forty other things now depend on it. The guess has become a foundation, and you do not renegotiate a foundation, you build on it.
This is what makes a ghost decision expensive in a way its first appearance hides. It does not sit quietly where it was made. It sends roots. The wrong identity model, the arbitrary limit, the storage assumption that only works on one machine, each of them is cheap on the day the agent writes it and ruinous on the day you finally have to unwind it, and the distance between those two days is measured in everything that got built in between.
The agent pours the concrete faster
An agent makes path dependence worse, not because it locks in more often than a person would, but because of how it treats what it finds. It has no memory of which existing patterns were deliberate and which were arbitrary. To the agent, every line already in the codebase is precedent. It reads the shape that a past run guessed into being, takes it as the established convention, and faithfully extends it, because matching the surrounding code is exactly what you want it to do almost all of the time. So the early guess does not just persist. It propagates, at machine speed, into every new file that touches it, and the installed base that would take a market years to build accretes in an afternoon.
The cheapest moment is the first one
Path dependence has a brutal implication and a hopeful one. The brutal one is that the cost of fixing a decision rises with time and cannot easily be brought back down, so review, which happens after the code exists, is already on the expensive side of the curve. The hopeful one is that there is a moment when the cost is nearly zero: the fork itself, before anything has been built on the choice. Get it right there and you never pay the compounding at all.
That is the moment Brief is built for. It is a product navigator: it holds the decisions your code cannot, the real limit a contract set, the real way your users are identified, the real scale you run at, and it puts them in front of the agent at the fork, before the guess becomes a foundation. It does not stop your codebase from locking things in, nothing does, that is just what building is. It changes what gets locked in, so the thing forty other files come to depend on is your actual decision instead of the average answer from the internet.
Why the enterprise is the deepest well
An enterprise is path dependence stacked decades deep. Every system it runs is sitting on a pile of choices most of which no one still remembers making, each expensive to revisit, many still shaping decisions long after their reasons expired. This is not a flaw, it is what it means to have survived long enough to matter. But it means an enterprise has the least room to absorb new arbitrary lock-in, and it is precisely the place now pointing agents at everything at once, letting them set fresh paths across every system daily, at a speed no one can review into correctness after the fact. The one enterprise that cannot afford more locked-in guesses is the one generating them fastest.
What this does and does not claim
A few limits, because the concept is often overstated. Path dependence does not mean choices are permanent, only that reversing them gets costlier as things build on them; teams do pay to switch, and sometimes should. I am also not leaning on QWERTY being provably worse than the alternatives, which is a genuinely contested claim, economists have argued for decades about whether the market really locked in an inferior design. What is not contested, and all I need, is the mechanism: early choices accumulate dependents and become expensive to reverse. Nor am I claiming every default an agent picks is wrong. Most are fine, and lock-in is only a problem when the locked-in thing was a guess that happened to matter. And Brief does not abolish lock-in; it moves the decision earlier, to the one moment when getting it right is cheap, which is the only leverage this particular problem offers.
So the next time an agent hands you a clean diff and you are deciding whether the small, unremarkable choices inside it are worth stopping for, do not ask whether they look fine today, because they will. What will it cost to change them once everything you build next is standing on top of them?
Frequently asked questions
What is path dependence? Path dependence is the idea that the choices available to you now are constrained by the path you have already taken, because early decisions accumulate dependents and become expensive to reverse. The economist Paul David described it using the QWERTY keyboard, and Brian Arthur developed the underlying theory of increasing returns: in systems where each adoption makes a standard more entrenched, small and even arbitrary early choices can lock in and persist long after their original reasons are gone.
How does path dependence apply to AI coding agents? A default an agent picks at an unspecified fork is trivial to change on the day it is written, but code has increasing returns: later changes import it, extend it, test it, and depend on it. Each dependency raises the cost of reversing the original choice, so a weightless day-one guess hardens into a foundation. The decision was never re-examined; it simply became too expensive to touch.
Why do coding agents make lock-in worse? Because an agent treats every existing pattern as precedent. It cannot tell which parts of the codebase were deliberate and which were arbitrary guesses, so it faithfully extends whatever shape it finds, propagating an early default into new files at machine speed. The installed base that entrenches a choice, which would take a market years to build, can accrete across a codebase in a single session.
When is the cheapest time to fix an AI agent's decision? At the fork, before anything is built on the choice, when the cost of getting it right is close to zero. After the code exists and other code depends on it, the cost only rises. This is why supplying the agent with real context up front, rather than reviewing its output afterward, is the only intervention that avoids paying the compounding cost. A product navigator like Brief exists to put that context at the fork.
← Back to Blog