Jevons Paradox

Give every engineer on a product team a coding agent, and a typical feature that took five engineer-days takes one. The obvious prediction is that the team ships the same work in a fifth of the time. The likelier outcome is that it starts more work. Features that were never worth five days are suddenly worth one, and ideas parked for years come back. The team ends up busier than before, and the people who decide what gets built end up busiest of all.

Jevons argued the same about coal in 1865, and the pattern carries his name. Jevons paradox is the observation that making a resource cheaper to use can increase the total amount of it used, because the lower cost opens up uses that weren't worth it before.

Coal and a confusion of ideas

William Stanley Jevons was 29 when he published The Coal Question in 1865. Britain's industry ran on coal, the cheap seams would run out, and a common answer was that better engines would stretch the supply. Jevons took that answer apart in a chapter called "Of the Economy of Fuel." The quotations here are from the second edition, published the following year.

"It is wholly a confusion of ideas to suppose that the economical use of fuel is equivalent to a diminished consumption," he wrote. "The very contrary is the truth. As a rule, new modes of economy will lead to an increase of consumption according to a principle recognised in many parallel instances."

His evidence was the steam engine's own history. He tabulated the work engines did per bushel of coal from 1769 to 1859 and concluded that "in less than one hundred years, then, the efficiency of the engine has been increased at least ten-fold." Britain did not burn a tenth as much coal. It burned far more, because cheap power let it "drain our towns and lowlands" and "put in motion the great system of our machine labour." His sharpest example was Scottish iron: cutting the coal used per ton of iron "to less than one-third of its former amount, has been followed, in Scotland, by a ten-fold total consumption."

He predicted the same for whatever came next. A better engine "will only accelerate anew the consumption of coal," he wrote, because "greatly extended works will be undertaken by aid of the cheap air-power, which were not commercially possible by the use of the costly steam-power."

The paradox isn't a law. Whether cheaper use raises total use depends on how much demand grows when the price falls, and for many goods it doesn't grow enough. Jevons was arguing about coal in Victorian Britain. The question for any team is whether the thing that got cheap is more like coal.

Code is more like coal

Few product teams run out of things they would build if building were cheap enough. Every backlog has a long tail of features that were good ideas at five engineer-days and obvious ones at one. Jevons's "greatly extended works" that "were not commercially possible" are the backlog's bottom half.

Here is how that could look for one invented team, a year apart. The second column is after every engineer got a coding agent:

The first row is the one in every announcement. Every row after it went the other way, except the last, which didn't move.

So when coding agents make Build cheap, the Jevons prediction is that teams do what Britain did and start more work. Our essay on the modern product development lifecycle describes the result: coding agents work inside one of seven stages, and "the work now piles up at the same review gates, waiting on people." We've written about where that work queues and why throughput doesn't follow. Jevons explains why the pile keeps growing even when the gates work. The cheap input pulls up demand for everything it's combined with.

For product teams, the input that code is combined with is decisions. A feature needs someone to decide who it's for, what it costs, what it won't do, and which earlier commitment it has to respect. Cheaper code doesn't make any of those questions cheaper to answer. It multiplies how many get asked. In the table, decisions per feature stayed about the same, so decisions per week more than tripled, and the three people who make them got no faster.

When that supply runs short, decisions don't stop being made. They get made by default, by whoever is writing the code. An agent given a ticket that says "per-seat pricing" will build per-seat pricing whether or not anyone decided it, and at twenty features a week, the number of choices made that way grows with the code.

Where Brief fits: making decisions as cheap to use as code

Brief is the product strategy agent. The homepage says it "captures decisions where they happen, connects them into one graph, and acts on them." In Jevons's terms, it works on the input that didn't get cheaper. It can't make a hard decision easy, but it can make a decision cheap to record, cheap to find, cheap to check against, and cheap to route to the person who has to make it.

Recording a decision costs less. Brief reads decisions from Slack, Jira, Confluence, and GitLab, self-hosted included, so a call made in a thread doesn't need someone to copy it into a decision log afterwards. In Slack, /decide records a decision from the conversation it was made in. A /decide confirmed without editing saves a placeholder rationale, so the cheapest path still leaves the why to fill in.

A decision made once answers every agent that needs it. This is where Jevons runs in a team's favor. A recorded decision is cheap to reuse, so it gets used more. Coding agents set up with Brief call brief_ask before they write code. On the homepage, an agent asked to add per-seat pricing to the checkout API learns that D-241, the seat-based pricing decision, is pending, holds the change, and flags D-198, a security review that applies. One answer covers every agent and every feature that touches the same question, so twenty features don't need twenty new conversations with the three people in the last row.

More work doesn't have to mean more contradictions. brief ask --mode check checks a proposed change against existing decisions and flags conflicts. At six features a week, a person can remember what was decided. At twenty, the check is what keeps a new feature from quietly undoing an old commitment.

The scarce supply goes where it matters. The PDLC essay's answer to the pileup is that "material decisions go to a named owner, routine ones stay with the team." Brief keeps proposed decisions separate from recorded ones, a proposal can name Who should decide?, and agents can call brief_list_pending_decisions to see what is waiting. The homepage's Friday brief "names the decision holding each late launch and who owns it": D-241 at the top, under Needs your decision, with three launches slipping behind it. With Proactive Brief turned on, Brief can remind people about reviewable items, capped at two interruptions a week. The three people in the last row spend their time on the decisions only they can make, not on answering the same question again.

None of this adds a fourth person to the last row. Brief can't decide pricing, and a team that starts more than three times as much work will still face more real decisions than before. What it changes is how much of each decision gets used. A decision that is recorded, findable and checked against can be applied to every feature it covers, instead of being made again, or made by default, every time the question comes back.

Jevons's question for Britain was what would happen to coal as engines got better. If your team's engines got five times better this year, what happened to the number of decisions waiting on the same three people?

Objections