Same Developer, Different Floor, 30x Different Outcome

Two developers. Same company. Same skills. Same AI tools on their machines. Same codebase.

Developer A has a manager who says: "Take two weeks to experiment. I will cover your sprint commitments."

Developer B has a manager who measures weekly velocity and follows up on missed story points.

After 100 work rounds, the simulation results:

Developer A: $72,055 net value.
Developer B: $2,320 net value.

Same person, different conditions. Factor of 31.

The Burn Budget

The model from the previous analysis introduced a concept called the burn budget: the maximum cumulative loss a developer can absorb before being forced back to manual work. Not the company's financial loss tolerance. The developer's perceived loss tolerance. How many rounds of zero output can they survive before consequences arrive?

Developer A has an unlimited burn budget. Their manager explicitly told them: failure is expected. Experiment. The loss tolerance is not infinite in theory, but it is long enough for the math to take over.

Developer B has a burn budget of roughly $100. One bad week, maybe two, before the sprint retrospective turns into a performance conversation. Their manager did not tell them to stop experimenting. Nobody had to. The measurement system said it for them.

Here is what the budget constraint does to outcomes:

A $100 burn budget: 27% of developers stay with AI long enough to see the returns. The rest get forced back to manual. Median final value: $2,320. They capture 3.2% of what was available.

A $250 budget: 61% stay. Median: $59,290. They capture 82%.

A $500 budget: 86% stay. Median: $69,480. They capture 96%.

No budget constraint: 100% stay. Median: $72,055. Full value captured.

The jump from $100 to $250 of loss tolerance moves the outcome from 3% to 82%. That gap is not about ability. It is about floor.

Why the $100 Is Rational

The developer who takes the guaranteed $100 is not being stupid. They are being rational within their constraints.

Consider the original thought experiment: $100 now, or a 10% chance at $1,000. Same expected value. Most people take the guaranteed money. Kahneman's research explains why: loss aversion, probability distortion, the asymmetry of how gains and losses feel.

But there is a simpler explanation for many of them. They need the $100. Not abstractly, not eventually. Now. The person who has to put dinner on the table tonight does not care about expected value over 100 rounds. They need calories today. The $100 buys dinner. The 10% chance at $1,000 buys a 90% chance of going hungry.

That is not a cognitive bias. That is arithmetic applied to a constraint. The "irrational" choice is perfectly rational when the downside is not survivable.

Map this to the developer. A developer on a Friday afternoon sprint review with two stories incomplete does not care about cumulative value over 100 rounds. They care about Monday morning. The guaranteed $100 of manual output means the stories ship. The AI lottery means a 67% chance of showing up empty-handed at the review.

The developer is not choosing wrong. They are choosing from a different menu than the developer whose sprint commitments are covered.

The Mechanism That Makes Poverty Compound

The severity is not comparable. A developer missing a sprint commitment is not a family missing a meal. But the mathematical structure of the trap is identical, and naming the structure matters.

When you cannot afford short-term losses, you cannot access long-term gains. When you cannot access long-term gains, the gap compounds. When the gap compounds, catching up gets harder.

A constrained developer stays manual. An unconstrained developer builds AI capability. Next quarter, the unconstrained developer is operating at 30% probability and $2,000 payoff. The constrained developer is still at zero AI capability. The gap is not just "I am behind." It is "I am behind AND closing the gap now costs more than it would have cost three months ago, because three months of learning are baked into the other person's numbers."

The same structure repeats at every scale. The developer on a sprint deadline who cannot afford one bad week. The startup burning runway that cannot absorb a productivity dip. The company with thin margins that cannot fund a learning period. In every case, the people who most need the upside are the least able to afford the path to it.

The steam engine created this exact trap 250 years ago. Workers who could afford to retrain for the new machines thrived. Workers who could not were ground through a transition that took 150 years to resolve with labor laws, safety regulations, public education and social safety nets. We built the floor after the fact, slowly, at enormous human cost. We know the mechanism now. The question is whether we build the floor before the cost arrives.

The Price of the Floor

The break-even point in the simulation is 7 rounds of AI experimentation. Seven rounds where the developer produces less than their manual baseline.

The full cost: roughly $945 in the model. Seven rounds of foregone manual output plus API costs. Against a median payoff of $72,000 over 100 rounds, that is a 76-to-1 return. The cost is not dramatic. The barrier is not the money.

The barrier is the two weeks of visible underperformance. Every system that evaluates developers on short cycles penalizes the investment period. Not all short-cycle measurement is misguided. Some organizations have contractual delivery obligations or client SLAs that make the learning valley genuinely unaffordable in certain sprints. But the developer who internalizes "I cannot afford to fail this week" and generalizes it to every week has closed the door permanently. The measurement system does not need to tell them "don't experiment." It says it by existing.

What the Floor Looks Like

For the individual developer. Find 7 rounds of slack. A side project between sprints. A hack day. This usually requires some form of managerial permission, which is itself part of the structural problem. But many developers have more margin than they realize, particularly in the gaps between sprints or during lower-priority work.

For the engineering manager. Budget the valley. Tell your team: "I expect two weeks of reduced output from each of you as you onboard to AI. That is not a failure. That is the investment. If I punish that period, I am buying $2,500 of visible output at the cost of $72,000 of eventual value." Say it out loud. Put it in the sprint planning. Make it structural, not a favor.

The organizational levers, measurement changes and leadership signaling that set the floor at a higher level, are a separate and larger argument.

Learning rate varies. Slow learners still win: one quarter of the conservative rate produces 6.3x, one tenth still produces 3.7x. But slow learners need more runway. Budget accordingly.

The Trap and the Door

The structural trap is not a character flaw in the people caught inside it. It is a system design flaw in the environments they work in. The developer who takes the $100 is not making the wrong choice. They are making the only choice available to them given a floor that is set too low.

The floor is set by managers, measurement systems and organizational culture. At the individual and manager level, raising it costs two weeks of reduced output per developer. The cost is small. The difference in outcome is 30x.