TinyComputers.io (Posts about jevons paradox)

The Feedback Loop That Jevons Couldn't Name

A.C. Jokela — Fri, 27 Mar 2026 13:00:00 GMT

In 1865, William Stanley Jevons published The Coal Question and identified a paradox: James Watt's more efficient steam engine didn't reduce coal consumption. It increased it. The efficiency gain made coal-powered industry more profitable, which drove more investment, which consumed more coal. The per-unit savings were overwhelmed by the expansion in total units demanded.

In 1948, Norbert Wiener published Cybernetics: Or Control and Communication in the Animal and the Machine and described a mechanism: systems that feed their outputs back into their inputs will either stabilize (negative feedback) or accelerate (positive feedback). A thermostat is negative feedback: the output (heat) reduces the input (the gap between current and target temperature). A microphone pointed at a speaker is positive feedback: the output (sound) amplifies the input (sound), and the system screams.

Jevons saw what happened. Wiener explained why.

They never met. Jevons died in 1882, twelve years before Wiener was born. Their fields barely overlapped. Jevons was an economist and logician working in Manchester. Wiener was a mathematician and engineer at MIT. Neither cited the other. Neither would have had reason to. But they were describing the same phenomenon from different sides: Jevons from economics, Wiener from control theory. Jevons identified the paradox. Wiener provided the mechanism. Together, they explain something about AI that the current conversation consistently misses: the reason demand expands when cognitive tools get cheaper isn't economic irrationality. It's positive feedback. It's the system doing exactly what feedback systems do.

Wiener's Machines

Wiener was not an abstract theorist. He built anti-aircraft fire control systems during World War II, predicting the future position of enemy aircraft based on their observed trajectories. The mathematical problem was filtering signal from noise in real-time feedback data, and the solution required treating the human pilot as a component in a mechanical system: a system that could be modeled, predicted, and countered.

This experience shaped everything he wrote afterward. In Cybernetics, Wiener argued that communication and control were fundamentally the same problem, whether the system involved nerves, wires, or social institutions. A factory is a feedback system. An economy is a feedback system. A conversation is a feedback system. The mathematics of regulation and stability apply to all of them.

In 1950, he published The Human Use of Human Beings, a book aimed at general readers. Its central argument: automation would transform society not by replacing humans but by changing the feedback loops that humans operate within. The automated factory doesn't just make products without workers. It creates a system where the speed of production is no longer limited by human labor, which means the system's dynamics shift to whatever the next bottleneck happens to be.

Wiener's most famous warning was blunt: "The automatic machine is the precise economic equivalent of slave labor. Any labor which competes with slave labor must accept the economic conditions of slave labor." He predicted that automation would produce unemployment that would make the Great Depression "seem a pleasant joke." He wrote this in 1950, when computers filled rooms and could barely calculate ballistic tables.

The Jevons Mechanism

Jevons didn't have the vocabulary of cybernetics. He described his paradox in economic terms: efficiency improvements reduce per-unit cost, lower cost increases demand, increased demand outweighs the efficiency gain, total consumption rises. He was observing a positive feedback loop, but he described it as a paradox because the economic framework he was working within predicted the opposite. If coal becomes more efficient, you should need less of it. The loop that amplifies demand was invisible in the model.

Wiener's framework makes the loop visible. Here's the cybernetic translation of Jevons:

A system component becomes more efficient (Watt's steam engine, a cheaper semiconductor, an AI model).
The efficiency reduces the cost of the system's output.
Lower cost makes new applications viable that were previously too expensive.
New applications create new demand for the now-cheaper component.
The new demand feeds back into step 1 as pressure for more efficiency, more production, more investment.
The loop accelerates.

This is a positive feedback loop. The output (cheaper goods, more applications) amplifies the input (demand for the efficient component). There is no negative feedback mechanism to stabilize the system. The loop runs until it hits an external constraint: a physical limit on the resource, a regulatory intervention, or the saturation of all possible demand.

Jevons observed steps 1 through 4 with coal. He didn't have the mathematical framework to describe steps 5 and 6 as a feedback loop. Wiener had the framework but was focused on machines and automation, not on resource economics. The connection between them is that Jevons Paradox is a specific instance of positive feedback in economic systems, and positive feedback is the phenomenon Wiener spent his career analyzing.

The AI Loop

I've been writing about Jevons Paradox and AI for months. The argument: AI makes cognitive output cheaper, demand for cognitive output expands beyond the efficiency gain, and the expansion concentrates pressure on the one input that can't scale: human judgment. The Vampire piece described the human cost. The Excavator piece described the software quality cost. The split piece described how the craft concentrates in the judgment layer.

What I didn't do was explain the mechanism. Why does demand expand when a cognitive input gets cheaper? Why doesn't the system reach equilibrium at lower total consumption, the way classical economics predicts? What force drives the expansion?

Wiener's answer: positive feedback.

Here's the AI loop, stated in cybernetic terms:

AI makes code generation cheaper (the efficiency gain).
Cheaper code generation makes new software projects viable (the demand expansion).
New projects produce software that requires review, testing, debugging, and maintenance (the output).
Review and debugging create demand for more AI assistance (the feedback).
The loop accelerates: more projects, more software, more review, more AI, more projects.

At no point does the loop include a mechanism for slowing down. There is no thermostat. The "temperature" (volume of software in production) rises without limit until it hits an external constraint.

I can see this loop operating in my own work. I built DirtScout, a full-stack land acquisition platform, in a series of conversations with Claude Code. 29,000 lines of code across Python, TypeScript, and infrastructure-as-code. The project would have taken months to type by hand. With AI, I built it in days. But building it in days meant I immediately started adding features: soil analysis, environmental assessments, auction tracking, deal pipeline management, offer letter generation. Each feature was a conversation. Each conversation produced code that needed to be reviewed, tested, and maintained. The faster I built, the more I wanted to build, and the more I built, the more review work accumulated. The loop ran. I didn't notice it running until the maintenance surface area was larger than anything I'd built before.

That's Wiener's loop at the individual level. At the organizational level, the same dynamic plays out with more people and higher stakes. Every developer using AI-assisted tooling ships more code, which creates more surface area for bugs and security vulnerabilities, which creates more demand for review, which creates more demand for AI-assisted review tooling, which ships more code.

The external constraint, as I've argued in previous pieces, is human judgment. The three-to-four-hour ceiling on deep work is biological. It doesn't expand because the feedback loop demands more of it. It's a fixed resource being consumed by an accelerating process. In Wiener's terms, the human component in the feedback loop is a bottleneck with a fixed maximum throughput. The system can't route around it (the judgment is necessary) and can't expand it (the biology doesn't scale). So the system does the only thing a positive feedback loop can do when it hits a fixed constraint: it overloads the constraint.

That's burnout. That's what Steve Yegge described in "The AI Vampire." Wiener would have recognized it instantly. The human component in an accelerating feedback loop reaches its throughput limit and degrades. The system doesn't stop. The system doesn't care. The system is a feedback loop, and feedback loops don't have preferences about their components.

Wiener's Warning, Updated

Wiener warned that automation would make human labor economically equivalent to slave labor. He was wrong about the specifics (manufacturing employment declined but didn't collapse) but right about the dynamic. The feedback loop he described (automation reduces labor cost, which drives more automation, which further reduces labor cost) played out exactly as predicted. It just played out over decades instead of years, and the economy adapted by shifting labor to sectors that weren't yet automated.

The AI version of this warning is different in a way that matters. Wiener's automation loop operated on physical labor. Muscle has substitutes: machines. When the feedback loop overloaded the human muscle component, the system routed around it with hydraulics, robotics, and assembly lines. The human moved to cognitive work, where machines couldn't follow.

AI's feedback loop operates on cognitive labor. Judgment does not have substitutes. When the feedback loop overloads the human judgment component, the system can't route around it the way manufacturing routed around physical labor. There is no higher-order activity to retreat to. Judgment is the top of the stack. The feedback loop either overloads it (burnout) or degrades it (review quality drops, software slop accumulates, the Excavator scenario plays out).

Wiener saw this possibility in the abstract. In The Human Use of Human Beings, he wrote: "The world of the future will be an even more demanding struggle against the limitations of our intelligence, not a comfortable hammock in which we can lie down to be waited upon by our robot slaves." He was pushing back against the utopian narrative of his own era: the idea that automation would create leisure. His counterclaim was that automation would shift the struggle to a harder domain. He was right, and the harder domain turned out to be exactly the one AI is now pressuring: the limits of human cognition.

The Speed Problem

There's a dimension of the AI feedback loop that Wiener's industrial-era examples didn't anticipate: speed.

Wiener's factory automation loop ran at the speed of manufacturing. It took years to design a new factory, months to retool an assembly line, weeks to train workers on new processes. The feedback loop was real, but it operated on a timescale that allowed human institutions (unions, regulations, education systems) to adapt. Walter Reuther, the president of the United Auto Workers, received Wiener's 1949 letter warning about automation and had years to develop a response. The loop was slow enough for governance.

The AI feedback loop runs at the speed of software. An operations manager can go from "I have an idea" to "it's in production" in an afternoon. A developer can ship ten features in the time it used to take to ship one. The loop cycles in hours, not years. Human institutions that adapted to the manufacturing automation loop over decades don't have decades to adapt to the AI loop. They have the time between one deployment and the next.

This is the Jevons Paradox running at software speed. Coal consumption took decades to double after Watt's engine. Computing demand took years to double after each semiconductor generation. AI-assisted software production can double in months. The feedback loop is the same. The clock rate is different. And the human component's clock rate (the biological ceiling on judgment) hasn't changed at all.

The supply side is contracting at the same time. After sixteen consecutive years of growth, undergraduate computer science enrollment turned negative in 2025. The Computing Research Association found that 62% of computing departments reported declining enrollment for 2025-26. Students and their parents are reading the headlines about AI replacing developers and steering toward fields they perceive as more durable. The feedback loop produces an ironic secondary effect: the fear of automation reduces the supply of the human component that the accelerating system needs most. The loop runs faster. The pipeline of people qualified to govern it narrows. Wiener's warning about building governance structures before the loop overloads becomes more urgent as the pool of people who could build those structures shrinks.

Wiener and Heidegger

Wiener and Heidegger never engaged with each other's work, as far as I know. They were writing at the same time (late 1940s, early 1950s), about the same phenomenon (technology reshaping human life), and they arrived at complementary conclusions from completely different starting points.

Heidegger, as I wrote in the Enframing piece, argued that technology changes how we see the world. Everything becomes standing reserve: raw material to be ordered and consumed. The river becomes a power source. The specification becomes code. The transformation is ontological: it changes what things are, not just what we do with them.

Wiener argued that technology changes the dynamics of the systems we operate within. Feedback loops accelerate. Bottlenecks shift. Components that were adequate at one cycle speed become inadequate at a faster one. The transformation is mechanical: it changes the forces acting on us, not necessarily how we understand them.

The two frameworks aren't contradictory. They're describing different aspects of the same process. Heidegger explains why we treat the Zilog manual as raw material for code generation (Enframing). Wiener explains what happens when we do it at scale (positive feedback, demand expansion, bottleneck overload). Jevons measured the economic result (total consumption rises despite efficiency gains).

There's a useful way to layer them. Heidegger describes the precondition: technology must first transform how we see the world (specifications become standing reserve) before the feedback loop can operate. You can't accelerate production of something you don't yet see as producible. Enframing opens the door. Wiener's loop walks through it. Jevons counts what's on the other side.

The sequence matters for AI. First, we began seeing cognitive tasks as automatable (Heidegger's shift in perception). Then, AI tools made the automation practical and cheap (Wiener's efficiency gain). Then, demand for cognitive output expanded beyond what anyone predicted (Jevons' paradox). Each step enables the next. The feedback loop couldn't run until the Enframing was in place, and the economic expansion couldn't happen until the loop was running.

Three disciplines. One phenomenon. The feedback loop that Jevons couldn't name, Wiener formalized, and Heidegger diagnosed as a transformation in our relationship to the world.

The Missing Thermostat

Every stable system has negative feedback. A thermostat, a voltage regulator, a population predator-prey cycle: something measures the output and adjusts the input to keep the system within bounds. Positive feedback without negative feedback is, by definition, unstable. The microphone screams until someone unplugs it.

The AI feedback loop currently has no thermostat. There is no mechanism that measures the volume of unreviewed software in production and slows the rate of production accordingly. There is no mechanism that measures developer burnout and reduces the demand for cognitive output. There is no mechanism that measures the ratio of AI-generated code to human-reviewed code and raises an alarm when it crosses a threshold.

Wiener would argue that this is the actual problem. Not AI itself (a tool, a component, an efficiency gain), but the absence of negative feedback in the system that AI accelerates. His entire career was about designing feedback systems that stabilize rather than explode. His warning about automation wasn't "don't build machines." It was "build the governance structures that keep the feedback loop from overloading its human components."

In 1949, Wiener wrote a letter to Walter Reuther, president of the United Auto Workers union, warning him about the coming wave of industrial automation. He didn't tell Reuther to smash the machines. He told him to prepare the workforce and the institutions for a system that would accelerate beyond their current capacity to manage. The letter went largely unheeded.

We're in the same position now. The feedback loop is running. The human component is approaching its throughput limit. The thermostat doesn't exist. Someone needs to build it, and the people best positioned to do so are the ones inside the loop: the developers and decision-makers who can see the acceleration because they're experiencing it.

Wiener died in Stockholm in 1964 at the age of sixty-nine, two decades before the personal computer and six decades before large language models. He never saw the system he described reach the scale it's reaching now. But the mathematics he wrote down in 1948 describe it precisely. Positive feedback without negative feedback is unstable. The system will find its constraint and overload it. The only question is whether we build the thermostat before or after the overload.

What makes Wiener worth reading today isn't his specific predictions (some were right, some were wrong, the timeline was consistently too compressed). It's his framework. He understood that technological change is not a series of discrete events but a system of coupled feedback loops. Each efficiency gain changes the dynamics of the system it operates within. Each change in dynamics creates pressure on whatever component is now the bottleneck. And each bottleneck, when overloaded, produces consequences that feed back into the system and accelerate the next cycle.

That framework applies to coal in 1865, to factory automation in 1950, and to AI-assisted cognitive work in 2026. The specific resources change. The specific bottlenecks change. The feedback dynamics don't.

John von Neumann, Wiener's contemporary and one of the minds his work most influenced, once said that young mathematicians should not worry about whether their work would be useful because "truth is much too complicated to allow anything but approximations." Wiener's approximation of the feedback dynamics of technological change was good enough that it still describes the system seventy-eight years after he formalized it. Whether it's good enough to help us build the thermostat before we need it is the question his work leaves us with.

What a Thermostat Might Look Like

Wiener didn't just diagnose problems. He designed solutions. His entire field was about building systems that regulate themselves. If he were alive today, he'd be asking: what does negative feedback look like in an AI-accelerated software economy?

Some possibilities:

Mandatory review ratios. For every N lines of AI-generated code deployed to production, M lines must be reviewed by a qualified human. The ratio creates a coupling between the production rate and the review rate, forcing the system to slow down when review capacity is saturated. This is a thermostat: the output (deployed code) is measured against a constraint (review capacity), and the input (generation rate) is throttled accordingly.

Liability assignment. If AI-generated code causes a data breach or financial loss, who pays? Currently, nobody in particular. Assigning liability to the person who deployed the code (not the person who prompted the AI) creates negative feedback: the cost of deployment failure feeds back into the decision to deploy, making people more cautious about shipping unreviewed code. Insurance markets would price this risk and create their own feedback mechanisms.

Institutional adaptation. This is what Wiener actually advocated. Not technical solutions but organizational ones. He told Walter Reuther to prepare the workforce for automation. The equivalent today: companies need to build review capacity at the same rate they build production capacity. Every developer who ships AI-generated code needs a corresponding increase in testing, security review, and architectural oversight. The organizations that treat AI as free productivity without investing in review are the ones that will hit the overload first.

Cultural awareness. Tristan Harris and the Center for Humane Technology have been arguing since 2023 that AI is being deployed faster than any technology in history under maximum incentives to cut corners on safety. Harris makes a distinction that Wiener would have appreciated: the difference between the "possible" (AI's theoretical benefits) and the "probable" (what actually happens given current incentive structures). The probable outcome, without intervention, is that companies race toward capability because the competitive feedback loop punishes restraint. Harris's proposed response is building global consensus that the current trajectory is unacceptable, the way the nuclear test ban and the Montreal Protocol established consensus before those feedback loops ran to their conclusions. In Wiener's terms, Harris is trying to build the thermostat at the cultural level: changing the system's objective function so that it optimizes for something other than pure output volume.

None of these exist at scale today. The thermostat is unbuilt. The loop runs open.

Jevons told us what happens. Wiener told us why. The question that remains is whether anyone is building the feedback mechanism that prevents the system from screaming.

Enframing the Code

A.C. Jokela — Sun, 22 Mar 2026 13:00:00 GMT

I asked Claude to build a Z80 emulator. The constraint was explicit: no reference to existing emulator source code. The inputs were the Zilog Z80 CPU User Manual, an architectural plan I wrote, and the test ROMs to validate against. Claude produced 1,300 lines of C covering every official Z80 instruction, undocumented flag behaviors, ACIA serial emulation, and CP/M support. It passed 117 unit tests. It boots CP/M and runs programs.

The emulator works. The question is what it means that it exists.

The Clean Room That Wasn't

"Clean room" is a legal term borrowed from semiconductor fabrication. In software, it describes a methodology where developers build from specifications and documentation without ever examining existing implementations. The purpose is to produce code that is legally independent of prior art. If you've never seen the original code, you can't have copied it.

The clean-room process was designed for human cognition. A developer reads a specification, forms a mental model, and writes code that implements the behavior the specification describes. The legal fiction is that the developer's mental model is informed solely by the specification, not by any existing implementation. In practice, developers have seen other implementations, read blog posts, studied textbook examples. The clean room is a discipline, not a guarantee: you follow the process, document that you followed it, and hope that's sufficient if someone challenges you.

When Claude writes a Z80 emulator from the Zilog manual, the clean-room concept doesn't dissolve because the AI is better at following the rules. It dissolves because the framework doesn't apply. Claude's training data includes dozens of Z80 emulators. The model has seen MAME's Z80 core, it has seen Fuse, it has seen whatever antirez published. The question of whether a specific output is "derived from" a specific input is unanswerable, because the model's internal state isn't decomposable into "I learned this from source A" and "I learned this from source B." The provenance that clean-room law requires you to demonstrate doesn't exist in a form that can be demonstrated.

But here's what's interesting: the emulator I directed Claude to produce is not a copy of any specific emulator. The architecture is mine. The bit-field decoding strategy (x/y/z/p/q decomposition of opcode bytes) was specified in my architectural plan. The test suite structure, the ACIA emulation interface, the system emulator's callback design: all specified by me and implemented by Claude from those specifications plus the Zilog manual. The output is an original assembly of knowledge. It's also an output of a system that has seen the source code it was told not to reference.

The law has no category for this. It's not a copy. It's not independent. It's something else.

The Language That Doesn't Exist

The Z80 case is complicated by the fact that prior implementations exist. Somebody could, in theory, diff my emulator against MAME's and look for structural similarities. (They won't find meaningful ones, because the architecture is different, but the argument could be made.) The more interesting case eliminates this possibility entirely.

Lattice is a programming language I designed. It has a novel feature called the phase system: mutability is not a static attribute but a runtime property that values transition through, like matter moving between liquid and solid. You declare a value in flux (mutable), freeze it to fix (immutable), thaw it back if needed. The language has forge blocks for controlled mutation zones. None of this exists in any other language.

Claude writes Lattice code. It writes it well. It produces correct programs using the phase system, the concurrency primitives, and the bytecode VM's 100-opcode instruction set. It does this despite the fact that Lattice does not appear in its training data. The language was designed after Claude's knowledge cutoff. There is no Lattice source code on GitHub, no Stack Overflow answers, no blog posts (other than mine) explaining the syntax.

How does Claude write Lattice? Because Lattice's syntax looks like Rust. The curly braces, the type annotations, the pattern matching: Claude recognizes the structural similarity and maps its understanding of Rust-like languages onto the Lattice grammar. The phase-specific keywords (flux, fix, freeze, thaw, forge) are new, but they appear in contexts that are syntactically familiar. Claude doesn't need to have seen Lattice before. It needs to have seen languages that smell similar.

This is a fundamentally different kind of creation than what copyright law contemplates. Claude didn't copy Lattice code (none exists to copy). It didn't copy Rust code (Lattice isn't Rust). It transformed a grammar specification and a set of examples into working programs in a language that has no prior art. The specification became the implementation without passing through any intermediate step that could be called "copying."

Heidegger Saw This Coming

In 1954, Martin Heidegger published The Question Concerning Technology. His central argument: modern technology is not just a set of tools. It is a way of seeing the world. He called this way of seeing Enframing (Gestell): the tendency of modern technology to reveal everything as standing reserve (Bestand), raw material ordered into availability.

The example Heidegger used was a hydroelectric dam on the Rhine. The river is no longer a river in the way a bridge reveals it (something to cross, something to contemplate, something with its own presence). The dam reveals the river as a power source. The water is standing reserve: ordered, measured, extracted. The river hasn't changed physically. What changed is how technology frames it.

This is exactly what happens when Claude reads the Zilog Z80 CPU User Manual.

The manual is a specification: 332 pages of timing diagrams, instruction tables, register descriptions, and pin assignments. When a human developer reads it, the manual is a guide. The developer forms an understanding, makes design choices, writes code that reflects their interpretation of the specification. The manual and the implementation are connected through the developer's comprehension. The developer is present in the code in a way that matters both legally and philosophically.

When Claude reads the same manual, the specification becomes standing reserve. The timing diagrams are not studied; they are consumed. The instruction tables are not interpreted; they are transformed. The manual is raw material, ordered directly into code, the way the dam orders the river into electricity. There is no intermediate step of "understanding" in the human sense. There is a transformation from one representation (specification) to another (implementation), and the transformation is mechanical in a way that human interpretation is not.

This is what Heidegger meant by Enframing. Technology doesn't just use resources; it changes what counts as a resource. The Zilog manual was written as a reference for engineers. Enframing reveals it as raw material for code generation. The specification was always latently an implementation; the AI just makes the transformation explicit.

What Copyright Was Protecting

Copyright law protects "original works of authorship fixed in a tangible medium of expression." The key word is "original." A Z80 emulator is copyrightable because the programmer made creative choices in expressing the specification as code. Two programmers given the same Zilog manual will produce different emulators: different variable names, different control flow structures, different optimization strategies, different architectural decisions. The specification constrains the behavior. The expression is where the creativity lives.

This framework assumes that the gap between specification and implementation is where human creativity operates. The specification says "the ADD instruction sets the zero flag if the result is zero." A hundred programmers will write a hundred slightly different implementations of this behavior. Each is an original expression. Each is copyrightable.

What happens when the gap closes? When the transformation from specification to implementation becomes mechanical, when there is no creative gap for originality to occupy, what is left to protect?

Claude's Z80 emulator makes specific structural choices: the x/y/z/p/q bit-field decomposition, the callback-based system bus interface, the T-state tracking architecture. These choices came from my architectural plan, not from Claude's autonomous creativity. I specified the structure; Claude filled it in from the Zilog manual. The "creative choices" that copyright relies on were mine (the architecture) and the specification's (the behavior). Claude's contribution was the transformation between the two, and that transformation is closer to compilation than to authorship.

Lattice pushes this further. Claude writes programs in a language with no training data, from a grammar specification and examples I provided. The output is correct Lattice code. But who is the author? I designed the language. Claude learned it from my spec. The programs it produces are implementations of tasks I described. At no point did Claude exercise the kind of independent creative judgment that copyright assumes. It transformed a task description into code in a grammar it learned from me. The entire chain from specification to implementation is mechanical, even though the output looks exactly like something a human programmer would write.

The Dissolution

Clean-room reverse engineering was a legal ritual designed to prove that a human developer's mental model was not contaminated by existing code. The ritual made sense when the concern was human memory: a developer who has read source code might unconsciously reproduce it.

AI makes the ritual meaningless in two ways.

First, provenance is undemonstrable. You cannot prove that Claude's output is or isn't derived from a specific piece of training data, because the model's internal representations don't maintain source attribution. The clean-room question ("did the developer see the original code?") has no answerable equivalent for an LLM. The model has seen everything in its training data simultaneously. It cannot unsee selectively.

Second, the distinction between "specification" and "implementation" is collapsing. When the transformation between them is mechanical and instantaneous, the specification is the implementation in a meaningful sense. The Zilog manual contains the Z80 emulator the way an acorn contains an oak tree. The transformation from one to the other requires energy and process, but the information content is the same. Copyright protects the expression, but when the expression is a deterministic function of the specification, the creative contribution approaches zero.

This doesn't mean all AI-generated code is uncopyrightable. If I write a detailed architectural plan, direct Claude to implement it, review and revise the output, and make structural decisions throughout the process, the result reflects my creative choices expressed through an AI tool. The tool is more sophisticated than a compiler, but the relationship is similar: I made the design decisions; the tool translated them into a lower-level representation. The copyright, if it exists, is in my architectural choices, not in Claude's line-by-line implementation.

But if someone asks Claude to "write a Z80 emulator" with no architectural plan, no structural constraints, and no iterative review, and Claude produces a working emulator from its training data, who owns that code? Not the person who typed the prompt; they made no creative contribution beyond the request. Not Anthropic; they built the tool but didn't direct the output. Not the authors of the Z80 emulators in the training data; their code wasn't copied in any legally meaningful sense. The code exists in a copyright vacuum: produced by a process that doesn't have an author in the way the law requires.

Why This Matters Now

The velocity of AI-assisted code production is accelerating. Every developer using Claude, Copilot, or Cursor is producing code whose provenance is uncertain. The code works. It passes tests. It ships to production. And its relationship to the training data that informed it is, in a strict legal sense, unknown and unknowable.

The current legal frameworks (copyright, clean room, fair use) were designed for a world where code was written by humans who could testify about their creative process. "I read the specification. I designed the architecture. I wrote the code. I did not reference any existing implementation." This testimony is the foundation of clean-room defense. An LLM cannot provide it, and the human directing the LLM can only testify about their own contributions (the prompt, the architectural plan, the review), not about what the model drew from.

I took a CS ethics course as an undergraduate. The cases we studied (Compaq's clean-room reimplementation of the IBM PC BIOS, SCO's claim that Linux contained UNIX code, DeCSS and the DMCA's prohibition on circumventing copy protection) all assumed a human author whose creative process could be examined and whose sources could be traced. Every one of those cases would be decided differently if the defendant had said "I told an AI to implement the specification and it produced this code." The existing precedent doesn't apply, and the new precedent doesn't exist yet.

The Acorn and the Oak

Heidegger would say that the danger of Enframing is not that it's wrong but that it's totalizing. When technology reveals everything as standing reserve, we lose the ability to see things as they are. The river becomes only a power source. The specification becomes only raw material for code generation. The act of programming becomes only a transformation pipeline from input to output.

What gets lost is what the clean-room process was actually designed to protect: the space between specification and implementation where human understanding operates. That space is where a developer reads "the ADD instruction sets the zero flag if the result is zero" and decides how to express that in code. The decision is small. The creativity is modest. But it's real, and it's human, and it's the entire basis of software copyright.

AI doesn't eliminate that space. My Z80 emulator project included genuine creative decisions: the architecture, the test strategy, the system emulator design. Lattice exists because I designed a novel type system that no AI would have invented from existing languages. The creative space still exists for the people who operate at the design level.

But for the implementation level, for the transformation from "what this should do" to "code that does it," the space is closing. The specification is becoming the implementation. The acorn is becoming the oak without passing through the seasons of human comprehension. And the legal and philosophical frameworks we built for a world where that transformation required human creativity haven't caught up.

They will. The question is how much code ships before they do.

The Excavator and the Foundation

A.C. Jokela — Sat, 21 Mar 2026 13:00:00 GMT

Jason Fried posted a sharp critique of the "bespoke software revolution" narrative this week. His argument: most people don't like computers, don't want software projects, and won't become builders just because AI hands them better tools. The three-person accounting firm wants the paperwork gone, not a new system to maintain. The logistics company wants optimized routes, not Joe's side project. The law firm wants leverage on their time, not a codebase.

His metaphor is good: "A powerful excavator doesn't turn a homeowner into a contractor. Most people just want the hole dug by someone else."

He's right about who builds. He's wrong about what happens next.

The Echo Chamber Is Real

Fried's observation about the software community talking to itself lands because it's obviously true. Open any tech feed and the bespoke software excitement is coming from people who already build software for a living. They're excited because AI makes their work faster and more interesting. They project that excitement onto everyone else and conclude that everyone will want to build. This is like assuming everyone wants to change their own oil because you enjoy working on cars.

Most people have no interest in building software. Not because they lack intelligence or creativity, but because software is a means to an end and they'd rather focus on the end. The accounting firm wants to close the books faster. The logistics company wants fewer empty miles. These are domain problems, not software problems, and the people who understand them best have spent their careers on the domain, not on code.

Fried identifies the outliers correctly: the people who go deep with AI building tools were already dabblers. The curiosity was already there. AI didn't create new builders; it gave existing builders a power tool. This is an important observation that the tech community consistently ignores because it's less exciting than "everyone becomes a developer."

Where Fried Stops

But Fried's analysis ends at "most people won't build," and that's where the interesting question starts. Because some people will try.

Not the majority. Not the three-person accounting firm drowning in paperwork. But the accounting firm's nephew who's "good with computers." The operations manager at the logistics company who watched a YouTube tutorial on Cursor. The paralegal at the law firm who built a spreadsheet macro once and now has access to tools that can generate entire applications from a text description.

These people exist in every organization. They're not professional developers. They don't think of themselves as builders. But they have just enough technical confidence to be dangerous, and AI tools have just lowered the barrier enough to let them act on it.

This is not a hypothetical. It's already happening. People are building internal tools with AI assistance, deploying them to their teams, and running business processes on software that no one with software judgment has reviewed. The tools work on the happy path. They do exactly what the builder asked for. The problem is what the builder didn't ask for.

The Happy Path Is All You Get

When a non-developer builds software with AI, they describe what they want: "I need a tool that takes client intake forms, extracts the relevant fields, and puts them in a spreadsheet." The AI builds it. It works. The builder is thrilled.

What the builder didn't specify, and the AI didn't volunteer:

What happens when a client submits a form with special characters that break the parser? What happens when two people submit simultaneously? What happens when the spreadsheet hits the row limit? Where are the backups? Who has access? What happens when the API key expires? What happens when the builder leaves the company and nobody knows how the tool works?

These aren't obscure edge cases. They're the standard failure modes of every software system ever built. Professional developers think about them not because they're smarter, but because they've watched systems fail in these exact ways. That accumulated experience of failure is what I've been calling the judgment layer: the part of building that AI can't replace because it requires contact with the consequences of getting it wrong.

The operations manager building a routing tool in Cursor has domain judgment about logistics. She knows which routes are efficient and which constraints matter. She does not have software judgment about error handling, data integrity, concurrent access, or failure recovery. Professional developers fail at these things constantly too. The difference is that professionals recognize the failure when it happens and have the skills to iterate toward a fix. The operations manager's tool breaks the same way, but she doesn't know it broke, doesn't know why, and doesn't know what to do about it. The AI gave her a tool that satisfies her domain judgment perfectly and her software judgment not at all, because she doesn't have any, and she doesn't know she doesn't have any.

This Has Happened Before

The counterargument writes itself: people have been building bad mission-critical software forever. Hospitals tracked patient records in Access databases. Small banks ran loan portfolios in Excel. Supply chains depended on macros that one person understood. When that person left, nobody could maintain it. The world survived.

This is true, and it's important to take seriously. "Bad software" and "functional software" are not mutually exclusive. The accounting firm's Access database was terrible by every engineering standard and it ran their business for fifteen years. The nurse's Excel tracker was a data integrity nightmare and it kept patient appointments from falling through the cracks. Fried is right that custom software has always been "bloated, confusing, and built wrong in all the ways." He's also right that it existed and that people used it.

So if bad software has always existed and the world kept turning, what changes with AI?

Velocity

The change is speed.

Access took months to build something broken. You had to learn Access first, or find someone who knew it. You had to build the forms, design the tables, write the queries. The pace of construction imposed a natural speed limit on how fast bad software could enter production. By the time you finished, you'd encountered at least some of the failure modes, because the slow process forced you through enough iterations to stumble into them.

AI removes that speed limit. The operations manager can go from "I have an idea" to "it's running in production" in an afternoon. The intake form tool is live before lunch. The routing optimizer is deployed by end of day. The contract parser is running by Friday. Each one works on the happy path. Each one has the same class of unexamined failure modes that Access databases had. But Access databases took months to accumulate. AI-built tools accumulate in days.

More attempts. Same failure rate. More failures. Compressed into a shorter timeline. By the time the first tool breaks, three more have been deployed. By the time someone realizes the intake form tool is silently dropping records with special characters, the routing optimizer and the contract parser are already load-bearing parts of the business.

This is Jevons Paradox applied to the failure mode itself. When building software gets cheaper, you don't get the same amount of bad software for less effort. You get vastly more bad software for the same effort. The per-unit cost of production drops, total production expands, and the total volume of unreviewed, unexamined software in production grows faster than anyone anticipated.

The Judgment Bottleneck

I've argued in previous pieces that human judgment is the binding constraint in AI-augmented work. AI makes the labor cheaper; demand expands; the expansion concentrates on the one input that can't scale: the human capacity for deep, focused evaluation. The three-to-four-hour ceiling on cognitively demanding work is biological, not cultural, and no productivity tool changes it.

Software judgment is a specific instance of this general constraint. Reviewing code for failure modes, reasoning about edge cases, thinking through data integrity, anticipating what happens when components interact in unexpected ways: this is deep work. It requires the kind of sustained attention that depletes on a fixed biological schedule. And the supply of people who have this judgment is not growing. Computer science enrollment is up, but software judgment comes from experience, not coursework. You develop it by watching systems fail, and that takes years.

AI expands the rate at which software enters production. It does not expand the rate at which qualified people can review it. The production side scales. The judgment side doesn't.

And the judgment side may actually be contracting. After sixteen consecutive years of growth, undergraduate CS enrollment turned negative in 2025. The Computing Research Association (CRA) found that 62% of computing departments reported declining enrollment for 2025-26, while only 13% saw increases. At University of California campuses, CS enrollment fell 6% in 2025 after declining 3% in 2024: the first drops since the dot-com crash. Students and their parents are reading the headlines about AI displacing entry-level developers and steering toward fields they perceive as more durable.

The irony is thick. The fear that AI will replace software developers is reducing the supply of software developers at the exact moment that AI is massively expanding the demand for software judgment. Students are fleeing the field because they think AI can do the work. AI is simultaneously creating more work that only humans with software judgment can evaluate. The enrollment decline doesn't just fail to solve the judgment bottleneck; it tightens it.

The gap between "software that exists" and "software that someone qualified has evaluated" widens from both directions: production accelerates while the pipeline of qualified reviewers narrows. Something has to give, and what gives is the review.

Software Slop

I wrote an essay about what makes AI-generated content "slop": superficial competence masking an absence of substance. The text looks right. The grammar is clean. The structure is logical. But it doesn't commit to anything, doesn't engage with anything, doesn't mean anything. It fills the container without filling it with content.

AI-generated software has the same property. The code is syntactically correct. The UI has proper styling, responsive layouts, loading spinners, appropriate error messages. It passes every visual inspection. A manager looking at a demo sees a professional application. A user running through the standard workflow sees something that works.

Underneath: no input validation beyond what the framework provides for free. No error handling beyond try/catch blocks that swallow exceptions. No concurrency protection. No backup strategy. No audit trail. No security beyond defaults. The software is superficially competent and structurally hollow, and you cannot tell the difference by looking at it.

This is what distinguishes the AI-built software problem from the Access database problem. Access databases looked like Access databases. The limitations were visible in the interface. The grey forms, the flat tables, the clunky queries: everyone could see they were using a tool that was not designed for what they were doing with it. The expectations were calibrated, even if the risks weren't.

AI-built software looks like real software. The surface quality has been democratized. What hasn't been democratized is the structural integrity underneath. And because the surface looks professional, the people using it have no signal that anything is missing. The feedback loop that would normally tell you "this is a prototype, not a product" has been severed. The prototype looks like the product, and nobody in the room can tell the difference except the people with software judgment, who weren't in the room when it was built.

What Fried Misses

Fried's framework has one gap. He says the demand for bespoke software won't grow because people don't want software projects. But the demand is already growing, not because people want to build, but because AI collapsed the apparent cost of building to near zero. The operations manager didn't set out to start a software project. She set out to solve a routing problem, and the software was a side effect that happened so fast she didn't register it as a project.

This is the mechanism Fried doesn't account for. The excavator doesn't turn the homeowner into a contractor. But it does let the homeowner dig a hole so fast that they're standing in it before they realize they don't know what they're doing. The question isn't whether they wanted to dig. It's what happens now that the hole exists and the house is being built on top of it.

The bespoke software revolution won't come from people deliberately choosing to become builders. It will come from people accidentally becoming builders because the tools made it so frictionless that building happened before the decision to build was consciously made. And the software they produce will be the fastest-growing category of technical debt in history, because it was created without judgment, deployed without review, and adopted without anyone understanding what's underneath.

Who Benefits

Fried is right that the excitement about bespoke software comes from software makers. What he doesn't say is why they should be excited. It's not because everyone becomes a builder. It's because everyone becomes a client.

Every operations manager who builds a broken routing tool and discovers it doesn't handle the edge cases is a future client for someone who can build it properly. Every accounting firm that deploys an AI-built intake system and loses data is a future client for someone who understands data integrity. The DIY phase doesn't replace professional software development. It creates demand for it, at a scale and urgency that didn't exist before, because now the potential clients have firsthand experience with why the problem is hard.

The judgment bottleneck doesn't prevent the Jevons expansion. It shapes it. More software gets attempted. More software fails. The failures create demand for the constrained resource (qualified judgment) at a rate that exceeds supply. The people who have software judgment become more valuable, not less, because the volume of work that needs their attention has exploded.

Fried's excavator metaphor is correct. Most homeowners won't become contractors. But the excavator lets them dig enough bad foundations that the contracting business booms. AI doesn't democratize building. It democratizes demand.

The Forecast

I'll make a prediction specific enough to be wrong about. Within three years, the majority of data-loss and security incidents at small and mid-sized businesses will trace back to AI-assisted internal tools built without professional review. Not because the AI wrote bad code (the code will be syntactically fine), but because the person directing the AI didn't know what to ask for and didn't know what they were missing. The failure mode won't be dramatic. It will be silent: records that were never backed up, access controls that were never configured, race conditions that corrupt data once a month in a pattern nobody notices until the audit.

There is an irony here that I should name. The people who most need to read this are the ones who never will. The operations manager vibing a routing tool into production this afternoon is not reading a blog about Jevons Paradox and GPU inference. She's solving her problem, and it feels like it's working, and no article on a site called Tiny Computers is going to reach him before the first silent failure does.

The bespoke software revolution is real. It's just not the revolution anyone is advertising. It's not a million people building great custom tools. It's a million people building adequate tools with invisible structural deficiencies, deployed to production at a velocity that outpaces the world's capacity to review them. The excavator is powerful, the foundations are being dug, and most of them are too shallow.

The Split Isn't Between People, It's Between Tasks

A.C. Jokela — Thu, 19 Mar 2026 13:00:00 GMT

Les Orchard's "Grief and the AI Split" identifies something real. AI tools have revealed a division among developers that was previously invisible, because before these tools existed, everyone followed the same workflow regardless of motivation. Now the motivations are exposed. Some developers grieve the loss of hand-crafted code as a practice with inherent value. Others see the same tools and feel relief: the tedious parts are handled, the interesting parts remain. Orchard frames this as a split between people. Craft-oriented developers on one side, results-oriented developers on the other.

He's right that the split exists, and the piece clearly resonated with software creators because it names something people have been feeling but couldn't articulate. The observation is sharp. Where I think it can be extended is in where the line falls.

Orchard draws the line between people. I think it falls between tasks. The same person crosses that line dozens of times a day, moving between work that demands human judgment and work that doesn't, between moments where the craft concentrates and moments where it was never present in the first place. The split is real. It's just not an identity.

The Kernel I Didn't Write

JokelaOS is a bare-metal x86 kernel: 2,000 lines of C and NASM assembly, booting from a Multiboot header through GDT (Global Descriptor Table, which defines memory segments and access rights) and IDT (Interrupt Descriptor Table, which maps interrupt vectors to service routines) setup, paging, preemptive multitasking with Ring 3 isolation, a network stack that responds to pings, and an interactive shell. No forks. No libc. Every memcpy, every printf, every byte-order conversion written from scratch.

I didn't write most of it. Claude did.

In Orchard's framework, this should place me firmly in the "results" camp. I used AI to produce 2,000 lines of systems code; clearly I care about the outcome, not the process. But that framing misses what actually happened during the project.

The decisions that made JokelaOS work were not typing decisions. They were sequencing decisions: bring up serial output first, because without it you have no diagnostics for anything that follows. Initialize the GDT before the IDT, because interrupt handlers need valid segment selectors. Get the bump allocator working before the PMM (Physical Memory Manager), because page tables need permanent allocations before you can manage dynamic ones. These choices come from understanding how x86 protected mode actually works, which subsystems depend on which, and what the failure modes look like when you get the order wrong.

Claude generated the GDT setup code. I decided what the GDT entries should be, caught the access byte errors, and debugged the triple faults when segment selectors were wrong. Claude wrote the process scheduler. I determined that the TSS (Task State Segment, which tells the CPU where to find the kernel stack when switching privilege levels) needed updating on every context switch and diagnosed the General Protection Faults that occurred when it wasn't. Claude produced the RTL8139 network driver. I decided to bring up ARP before ICMP, caught a byte-order bug in the IP checksum, and validated that the packets leaving QEMU were actually well-formed.

The typing was delegated. The architecture, the sequencing, the diagnosis, the validation: those were mine. If you asked me whether JokelaOS involved craft, I would say yes, more than most projects I've done. If you asked me where the craft was, I would not point at any line of code.

The Board That Failed Twice

The Giga Shield tells a longer version of the same story, and it's messier, because hardware involves the physical world in a way that software doesn't.

The project started with a $468 Fiverr commission. I gave a designer in Kenya the spec documents, the components I thought should be used, and the form factor requirements: an Arduino Giga R1 shield with bidirectional level shifters, 72 channels of 3.3V-to-5V translation, KiCad deliverables. He produced a clean design. Nine TXB0108PW auto-sensing translators on a two-layer board. PCBWay fabricated it. Professional work, quick turnaround, and PCBWay sponsored the fabrication.

Then I plugged in the RetroShield Z80 and the board was blind.

The TXB0108 detects signal direction automatically by sensing which side is driving. For most applications, that's a feature. For a Z80 bus interface, it's fatal. During bus cycles, the Z80 tri-states its address and data lines. The pins go high-impedance: not high, not low, floating. The TXB0108 can't determine direction from a floating signal. It guesses wrong, and the Arduino reads garbage. I'd paid $468 for a board that couldn't see half of what the processor was doing.

Nobody caught this in the design phase. Not the Fiverr designer, who was working from the spec I gave him. Not me, when I reviewed the schematic. The TXB0108 datasheet doesn't scream "incompatible with tri-state buses"; you have to understand what tri-stating means in practice and recognize that auto-sensing can't handle it. That understanding came from plugging the board in and watching it fail.

The redesign used Claude to replace all nine auto-sensing translators with SN74LVC8T245 driven level shifters. Driven shifters have an explicit direction pin: you tell them which way to translate, and they do it regardless of whether the signal is being actively driven. Claude wrote Python scripts that pulled apart the KiCad schematic files, extracted all 72 signal mappings across 9 ICs, and generated new board files with the correct components and pin assignments.

I was about to submit the revised design to PCBWay when I realized we needed a tenth level shifter. The original nine covered not just the digital pins that map to the Z80 RetroShield but all of the analog pins on the Giga, giving complete 3.3V-to-5V coverage across the board. But with driven shifters, each IC has a single direction pin controlling all eight channels. Signals that need to travel in opposite directions at different times can't share an IC without creating bus contention. Some of the channel assignments had conflicting direction requirements, and the only fix was a tenth IC to separate them.

Adding one more TSSOP-24 package to an already dense two-layer board broke the trace routing. The board that had been routable with nine ICs was unroutable with ten. Moving to four layers helped but still left two to four traces with no viable path. The solution was a six-layer stackup, which needed a copper pour layer to act as a common ground plane. The open-source autorouter Freerouting couldn't handle a full copper pour; its architecture has no concept of flood-fill connectivity. So I used Quilter.ai, an AI trace router, to route the six-layer board with the ground plane that the open-source tooling couldn't represent.

Count the layers of delegation and intervention in this project. I delegated the initial design to a human professional. Physics revealed the flaw. I delegated the redesign to an AI. I caught the missing tenth shifter before it went to fabrication. I delegated the trace routing to another AI. PCBWay is currently manufacturing these boards. At every stage, the work alternated between labor that could be delegated and judgment that couldn't. The Fiverr designer did skilled labor. Claude did skilled labor. Quilter.ai did skilled labor. The craft was never in the labor. It was in knowing when the labor was wrong.

Where the Craft Actually Lives

Both of these projects point at the same thing. The craft isn't in the typing, the routing, or the code generation. It's in a layer that sits above and around all of that: the judgment layer.

The judgment layer is where you decide what to build next. Where you recognize that the output is wrong before you can articulate why. Where you sequence subsystems based on dependency chains that aren't documented anywhere. Where you plug a board in and notice that the readings don't make sense. Where you catch a missing component that the AI, the designer, and the autorouter all missed because none of them were thinking about the problem at that level.

This layer has specific properties. It requires contact with the problem domain, not just the code or the schematic but the actual behavior of the system under real conditions. It depends on accumulated experience: understanding what tri-stating means in practice, knowing that x86 protected mode has forty years of backward-compatible traps waiting for you. And it's the part that AI is worst at, precisely because it requires grounding in physical or logical reality that language models don't have access to.

The TXB0108 failure is the clearest example. The information needed to predict this failure existed in the datasheets. But recognizing its relevance required understanding what a Z80 bus cycle actually looks like at the electrical level, which required either experience with the hardware or a simulation environment that nobody had set up. No amount of language model capability substitutes for plugging in the board and watching it fail.

The Same Person in Both Modes

Orchard describes himself as results-oriented. He learned programming languages as "a means to an end" and gravitated toward AI tools because they let him focus on the outcome. He acknowledges that craft-oriented developers experience genuine loss. His framing is empathetic, but it still draws the line between people.

The line doesn't hold, because I'm both of his archetypes depending on the hour.

On Tuesday I might use Claude to generate a hundred lines of systemd service configuration because I need Ollama running on a machine and I don't care about the elegance of the unit file. On Wednesday I might spend three hours hand-debugging why rocm-smi reports GPU utilization at zero percent: reading kernel logs, checking DKMS module versions, testing HSA_OVERRIDE_GFX_VERSION values, loading the amdgpu module manually because it didn't auto-load at boot. The first task is pure delegation. The second is pure craft. Both are mine. Both happened this week.

When I wrote the economics piece, I used Claude to draft sections and I measured real power draw with nvidia-smi and rocm-smi at 500-millisecond intervals. I let AI handle the prose scaffolding and I personally caught that Ollama on the Strix Halo had been running entirely on CPU because the systemd service file was missing an environment variable. Every benchmark I'd trusted before finding that bug was wrong. No AI caught it. I caught it because the numbers felt off.

These aren't different people. They're different tasks. The identity framing ("I'm a craft developer" or "I'm a results developer") obscures what's actually a task-level decision that experienced people make constantly: this piece of work benefits from my full attention; this piece doesn't.

What the Grief Is About

The craft-grief that Orchard describes is real and worth taking seriously. Part of it targets the wrong thing. Part of it doesn't.

What's being mourned is typing as the bottleneck. For forty years, the primary constraint on software projects was the speed at which a human could produce correct code. Design mattered, architecture mattered, but someone still had to sit down and type it. The typing was slow enough that it forced a certain kind of attention. You couldn't write a function without thinking about it, because writing it took long enough that thinking was unavoidable. The bottleneck created the conditions for craft, and it felt like the craft itself.

AI removes the bottleneck. Code appears in seconds. The thinking isn't forced by the typing anymore; it has to be deliberate. And that shift feels like a loss, because the rhythm of the work has changed. The long, meditative stretches of writing code, where your understanding deepened as your fingers moved, are replaced by short bursts of generation followed by review. The texture is different.

But the craft didn't live in the texture. It lived in the judgment that the texture incidentally supported. The experienced developer who hand-writes a function isn't doing craft because the typing is slow. The typing is slow, and the craft happens during the slowness, but the craft is the decisions: what to name things, what to abstract, what edge cases to handle, when to stop. Those decisions haven't gotten easier. If anything, they've gotten harder, because AI lets you attempt projects that would have been too large to type by hand, which means you hit the judgment bottleneck more often and at higher stakes.

JokelaOS would have taken me months to type by hand. I probably wouldn't have attempted it. With AI handling the code generation, I attempted it in days and spent the entire time making architecture and debugging decisions. The project had more craft in it than most things I've built, precisely because the typing wasn't the bottleneck. The judgment was.

The Biological Ceiling

I wrote in the AI Vampire piece that human judgment is the binding constraint in a Jevons cycle operating on cognitive output. AI makes the labor cheaper; demand expands; the expansion concentrates on the one input that can't scale: human attention and judgment. The three-to-four-hour ceiling on deep work is biological, not cultural, and no amount of productivity tooling changes it.

The task-level split is where this plays out in practice. AI compresses the labor side of every project: the code generation, the trace routing, the prose drafting, the schematic extraction. What remains is denser, harder, and more consequential. Every hour of work has a higher ratio of judgment to labor than it did before AI. That's why Yegge's developers feel burned out, not because they're working more hours, but because every hour is now a judgment hour.

The craft isn't disappearing. It's being compressed into a smaller, denser layer. The typing is gone. The design reviews are shorter. The code appears instantly. What's left is the part that was always the actual craft: deciding what to build, recognizing when it's wrong, knowing what to test, catching the missing tenth level shifter. That layer is entirely human, it's harder than it used to be because the projects are bigger, and it's the only part that matters.

Orchard identified the split correctly. The grief is real, the division is real, and the piece resonated because it named something that software creators recognized immediately. The refinement I'd offer is that the line doesn't separate two kinds of people; it separates two kinds of tasks. The craft was never in the code. It was in the decisions that surrounded the code. Those decisions haven't gone anywhere. They've just lost the slow, meditative typing that used to accompany them. What remains is craft at higher concentration, with no filler.

There was something cathartic about the old way. The hours of typing weren't just production; they were a complete experience. You conceived the idea, worked through the logic, typed every character, fought the compiler, and watched it run. The whole arc from intention to execution passed through your hands. That totality had a satisfaction to it that reviewing AI-generated output doesn't replicate, even when the output is correct.

And there was something else: the syntax was a sacred tongue. Not everyone could read it. Not everyone could write it. The curly braces, the pointer arithmetic, the register mnemonics formed a language that belonged to the people who had invested years learning to speak it. That exclusivity wasn't gatekeeping for its own sake; it was the mark of hard-won fluency, and it meant something to the people who had it. Now anyone can describe what they want in English and get working code back. The priesthood dissolved overnight.

I feel that loss. I still create. I still orchestrate. I still catch the errors that the tools miss. But I no longer speak a language that most people can't. The judgment layer is real, and it's where the work that matters happens. But it doesn't carry the same weight as mastery of a difficult notation. Orchestrating a process is not the same as performing it, even if the orchestration requires more skill.

The grief is real. It's not about the wrong thing. It's about something that actually disappeared.

The Economics of Owning Your Own Inference

A.C. Jokela — Tue, 17 Mar 2026 13:00:00 GMT

I own $5,500 worth of GPU hardware dedicated to running AI models locally. I also pay for a Claude Max subscription that I use for nearly everything that matters. If that sounds like a contradiction, it is the entire subject of this article.

The local inference conversation online is dominated by two positions. The first: why pay for API calls when you can run models on your own hardware? The second: local models are worse, so just pay for the good ones. Both are correct. Both are incomplete. The interesting question is where the boundary falls between them, and the answer turns out to depend less on cost-per-token arithmetic than on what kind of work you are doing.

The Split

I use Claude for research, code review, writing feedback, technical analysis, and anything that used to be a Google search. The frontier models are better at all of these tasks than anything I can run locally. Not marginally better; categorically better. An 8B parameter model running on my hardware is not in the same conversation as Claude Opus or GPT-5.4 for anything requiring reasoning, nuance, or broad knowledge. The subscription cost is fixed regardless of volume, which eliminates per-query friction entirely. For interactive, quality-sensitive work, I pay for the best model available and I do not think about it.

Local inference handles everything else: the batch jobs, the grunt work, the high-volume tasks where model quality matters less than model availability. The work that would be expensive at cloud API rates not because any single call costs much, but because the calls number in the tens of thousands.

This is not a temporary arrangement while local models catch up. It is a structural split. Frontier models are getting better. Local models are also getting better. The gap is not closing in the ways that matter for my usage, because the tasks I send to each side are fundamentally different. I do not need my local 8B model to reason better. I need it to process text cheaply and without metering.

What the Local Hardware Actually Does

Three workloads. All batch. All quality-tolerant.

Text-to-speech. Every post on this site has an AI-generated audio narration. This is the workload that justifies the hardware on its own. Google Cloud Platform has superior TTS voices; Chirp3-HD sounds noticeably more natural than any open-source model I have tested. I ran a novel through it once: 82,000 words, 500,000 characters, $17.25. That is reasonable for a one-off project.

It is not reasonable for a library of blog posts that I revise and regenerate periodically. At GCP rates ($16 per million characters, more for premium voices), narrating every post on this site would cost $200 to $400, and that bill resets every time I edit an article and regenerate the audio. Open-source TTS (F5-TTS and Qwen TTS) mispronounces technical terms. The prosody goes flat on dense jargon. But it is good enough for blog narration. "Good enough" at zero marginal cost beats "excellent" at $4 to $10 per post when you are generating audio daily.

Code scanning. Running local models over source files for pattern detection, documentation extraction, and automated analysis. These jobs produce high token volume at low quality requirements. An 8B model is adequate. The token count across a full codebase makes API pricing add up in a way that individual queries do not.

Infrastructure work. Benchmarking hardware (as in this article), testing prompt structures across quantization levels, evaluating model behavior under different configurations. These queries have no value individually. They are the test drives, not the commute. Paying per-token for test drives is paying per-mile to drive your own car around the block.

None of these workloads require a frontier model. All of them generate enough volume to make metered pricing uncomfortable. That is the boundary.

The Machines

Two machines. Both mine. Both running Ollama.

A four-GPU Tesla P40 server: Penguin Computing 2U chassis, Xeon E5-2697A v4, 252GB DDR4 ECC, four Tesla P40s with 24GB GDDR5X each. Ninety-six gigabytes of VRAM. Pascal architecture, 2016 vintage. Built from eBay parts for about $2,500. Lives in an unheated shop building in Minnesota.

A Bosgame M5 mini desktop: AMD Ryzen AI MAX+ 395, Strix Halo APU with integrated RDNA 3.5 graphics. No discrete GPU. CPU and GPU share 128GB DDR5, roughly 60GB addressable as VRAM through ROCm 7.2. Cost about $3,000. Fits on a desk.

What They Cost to Run

I logged GPU power draw at 500-millisecond intervals during inference using nvidia-smi on the P40 server and rocm-smi on the Strix Halo. Same prompt, same models, same Ollama configuration. All models ran 100% on GPU.

Model	P40 tok/s	P40 GPU Power	Halo tok/s	Halo GPU Power
Llama 3.2 3B	91.2	170W avg	78.4	64W avg
Llama 3.1 8B	47.5	278W avg	40.2	82W avg
Llama 3.1 70B (4K ctx)	6.3	278W avg	5.6	81W avg

The P40 is 15-18% faster in raw throughput. It draws 3-4x the power. The 3B model lives on a single P40; the other three cards idle at ~9W each but still cost electricity. The 8B and 70B models span two GPUs while two idle. You always pay for cards that are not working. The Strix Halo has one GPU. No idle penalty.

GPU power is not total system power. The P40 server's Xeons, 252GB of RAM, dual PSUs, and fans add roughly 200W to the GPU figures. The Strix Halo's APU and DDR5 add roughly 40-60W. Conservative estimates for total system draw: 500W for the P40 under load, 120W for the Strix Halo.

At Minnesota residential electricity rates ($0.157/kWh), the cost per million tokens:

Machine	3B	8B	70B
P40 Server	$0.19/M	$0.46/M	$3.47/M
Strix Halo	$0.06/M	$0.13/M	$0.94/M

Why the Per-Token Number Is Misleading

Those numbers look competitive with hosted inference, which runs $0.05 to $0.20 per million tokens for 8B-class models through providers like Together AI or Groq. The Strix Halo at $0.13/M sits squarely in that range. The P40 at $0.46/M does not.

But per-token cost during active inference is the wrong metric for two reasons.

Hardware amortization changes the math. The P40 server cost $2,500. The Strix Halo cost $3,000. Amortized over two years, that adds $0.14/hr and $0.11/hr respectively. On the 8B model, the all-in cost per million tokens rises to about $1.28 for the P40 and $0.90 for the Strix Halo. Both are more expensive than every hosted inference API for the same model.

Idle power is the dominant cost. The P40 server draws roughly 340W at idle: $38.50 per month whether I run a single query or not. The Strix Halo draws roughly 35W at idle: $4.20 per month. Over a year, idle electricity alone costs $462 on the P40 and $50 on the Strix Halo. If you are not using the hardware frequently, idle power overwhelms everything else in the cost model.

Per-token math at load flatters local inference by ignoring the hours when the hardware is doing nothing. It is like calculating your car's fuel economy only during highway driving and ignoring that it sits in the driveway 22 hours a day with the engine running.

Why I Run Both Anyway

The per-token economics favor API providers. The per-workload economics favor local hardware for specific tasks. TTS is the starkest example.

Generating a 20-minute blog narration on the Strix Halo takes about 45 minutes of inference at roughly 85W above idle power. The incremental electricity cost is about $0.02. The same narration through Google Cloud TTS would cost $4 to $10 depending on character count and voice tier.

That is a 200-to-500x cost difference on the marginal unit. And the marginal unit is what matters, because the question is never "should I generate TTS at all?" It is "should I regenerate the audio for this post I just edited?" or "should I try a different voice on this article?" or "should I narrate this niche post about PCB trace routing that maybe fifty people will listen to?"

At $4 to $10 per narration, the answer to all of those is "probably not." At $0.02, the answer is "why wouldn't I?" That shift from "probably not" to "why not" is the entire economic argument for owning TTS hardware. It is not about the average cost. It is about the marginal decision.

Before running local TTS, I narrated posts selectively with Google Cloud's Text-to-Speech. Some were too long or too niche to justify the GCP cost. Now every post gets audio. I regenerate after revisions without thinking about it. I have run the same post through three different TTS models to compare voice quality. I experiment with speaker voices, pacing parameters, and chunk sizes. The total volume of audio I have generated locally exceeds what I would have purchased from Google at any price point. This is Jevons Paradox at the smallest possible scale: make TTS cheap enough and I do not produce the same amount of TTS for less money; I produce vastly more TTS for slightly less money.

The same logic applies to code scanning. Any individual scan is cheap enough through an API. But the friction of metered pricing discourages the kind of speculative, exploratory analysis that turns up unexpected findings. When the marginal cost is zero, I scan more freely and more often. The value is not in any single scan; it is in the scans I would not have run otherwise.

The Strix Halo Problem

The most surprising result in the benchmarks is the Strix Halo's efficiency. An integrated APU with no discrete GPU delivers 40.2 tokens per second at 82W of GPU power. The P40 server delivers 47.5 tokens per second at 278W of GPU power. The P40 is 18% faster. The Strix Halo uses 70% less power. In performance per GPU watt, the Strix Halo (0.49 tok/s per watt) is nearly three times more efficient than the P40 (0.17 tok/s per watt).

This creates a problem for the P40 server's economics. The server's advantage is VRAM: 96GB lets it run 120B MoE models that the Strix Halo cannot fit. For the gpt-oss 120B model, the P40 server is the valid option. But for everything 8B and below, the Strix Halo is cheaper to buy ($2,000 vs. $2,500), cheaper to idle ($4.20/month vs. $38.50/month), cheaper per token ($0.13/M vs. $0.46/M), quieter, smaller, and only 18% slower.

If I were building a local inference setup today from scratch and my workload was 8B models and TTS, I would buy the Strix Halo and nothing else. The P40 server justifies its existence only for the large models that need its VRAM and the fact that I put it together well before the current RAM price spike.

This is worth sitting with for a moment, because it inverts the conventional wisdom about inference hardware. The enterprise GPU server that looks impressive on paper (four GPUs, 96GB VRAM, 2U rack mount) loses on total cost of ownership to a $3,000 mini desktop for the workloads that dominate my actual usage. The P40's raw throughput advantage is real but small. Its power cost advantage is negative. The VRAM advantage matters only for models most people do not run.

The Maintenance Tax

The per-token calculations ignore the cost of keeping these machines running. It is not zero.

I have had two kernel updates break the NVIDIA DKMS module on the P40 server. The AMD machine requires specific pre-release PyTorch wheels and environment variable overrides for ROCm to function on gfx1151 hardware. While running the benchmarks for this article, I discovered that Ollama on the Strix Halo had been running entirely on CPU because the systemd service file lacked the HSA_OVERRIDE_GFX_VERSION=11.5.1 variable. Every benchmark I had run on that machine prior to catching this was measuring CPU inference, not GPU inference. The fix took two minutes. Finding it took longer.

The P40 server's fans run at full speed from October through April because the BMC interprets Minnesota winter temperatures as a hardware malfunction. The noise is audible from the house, 150 feet away.

None of this is catastrophic. All of it is time. And time spent debugging DKMS modules or adding environment variables to systemd units is time not spent on the work that the hardware is supposed to enable. A Claude Max subscription requires zero maintenance. The local hardware requires ongoing attention. That asymmetry does not show up in per-token cost tables, but it is real.

Who This Is For

Most people should not build a local inference server. If you use AI for interactive tasks (questions, code, analysis, writing), a frontier model subscription is a better product at a lower total cost than any local setup. The quality gap between a local 8B model and Claude or GPT-5.4 is not closing in the ways that matter for conversational use. Pay for the good models. Use them freely.

Local inference makes economic sense when you have a specific, high-volume, quality-tolerant workload that you will run often enough to justify hardware sitting on 24/7. TTS is the clearest case. Batch code analysis is another. If you cannot name the workload, you do not have one, and the hardware will cost you $40 to $50 per month in idle electricity to find out.

The split between frontier subscriptions and local batch processing is not a compromise. It is, for my usage, the correct architecture. The frontier model handles the work where quality determines value. The local hardware handles the work where volume determines cost. Neither replaces the other. The mistake is thinking they compete.

Investing in the Jevons Expansion

A.C. Jokela — Thu, 05 Mar 2026 14:00:00 GMT

This is the sixth piece in a series applying the Jevons Paradox framework to AI economics. The prior five built the theoretical case:

The Paradox of Cheap Compute established the historical pattern: every time the cost of compute fell by an order of magnitude, total consumption expanded far beyond the efficiency gain.
The Jevons Counter-Thesis argued that AI displacement models systematically undercount the demand expansion that follows when cognitive labor gets cheaper.
Moore's Law for Intelligence mapped the inference cost curve and showed it mirrors early Moore's Law.
Something Big Is Happening, And Something Big Is Missing applied the framework to a specific displacement scenario and showed where the analysis breaks down.
The AI Vampire Is Jevons Paradox identified the binding constraint: human judgment doesn't scale the way compute does.

This piece asks the practical question: if you believe the framework, what follows?

I should be clear about what this is and what it isn't. This is not financial advice. I'm not recommending specific trades, allocations, or timing. What I'm doing is mapping a structural argument (Jevons-style demand expansion in AI) onto the physical and economic layers that expansion must pass through. The goal is to identify where expansion creates bottlenecks, because bottlenecks are where pricing power concentrates.

The key insight is that you don't need to pick which AI company wins. You don't need to know whether OpenAI, Anthropic, Google, or some company that doesn't exist yet captures the application layer. What you need to identify are the fixed-supply inputs that every AI company needs regardless of who wins. The expansion has to flow through certain physical chokepoints, and those chokepoints are investable.

The Framework in One Paragraph

For readers coming to this series fresh: Jevons Paradox describes what happens when a critical input gets dramatically cheaper. The intuitive expectation is that total spending on that input falls. The historical reality is the opposite: demand expands beyond the efficiency gain, and total consumption increases. Coal in the 19th century (as Jevons himself documented in The Coal Question), transistors in the 20th, bandwidth in the 21st. The prior pieces in this series argue that AI inference costs are following the same curve, with the same structural conditions that produced Jevons outcomes in every prior case. If that argument holds, then what matters isn't whether AI gets more efficient; it's where the resulting demand expansion hits physical constraints.

The Objection That Isn't

The most common pushback I get on this series is some version of: "GPUs are hitting diminishing returns, capex is already enormous, and there's a natural ceiling on how far the expansion can go." Variations appear in coverage from Northeastern and illuminem, often framed as a correction to the Jevons thesis.

It's a reasonable-sounding objection. It's also wrong, and understanding why it's wrong actually strengthens the Jevons case.

The objection treats a technology-specific constraint as an input-level constraint. GPUs hitting diminishing returns doesn't mean inference is hitting diminishing returns. It means GPUs are reaching the end of their particular S-curve. But GPUs aren't the only way to run inference. Custom ASICs, TPUs, NPUs, and novel architectures are opening entirely new cost curves below the GPU curve. The GPU plateau isn't a ceiling; it's a handoff.

The numbers are already visible. Broadcom controls roughly 70% of the custom AI ASIC market, reporting \$5.2 billion in AI semiconductor revenue in Q3 alone, with five major hyperscaler customers driving demand. Marvell's custom XPU pipeline spans AWS, Google, Meta, and Microsoft, with AI revenue reaching \$2.6 billion in FY2026. Google's TPU transition from v6 to v7 delivered a roughly 70% cost-per-token reduction. Taalas, a startup building hardwired inference chips, claims 1000x performance per watt versus general-purpose GPUs. Custom ASICs handle an estimated 20% of inference workloads today and are projected to reach 70–75% by 2028, with custom ASIC shipments growing at 44.6% annually versus 16.1% for GPUs.

Every prior Jevons cycle worked exactly this way. Newcomen's engine didn't just get incrementally better; it was replaced by Watt's engine, then Corliss, then turbines. Each new technology started a fresh S-curve before the previous one fully flattened. Moore's Law didn't ride a single technology either. As Chris Miller chronicles in Chip War, bipolar gave way to NMOS, then CMOS, then FinFET, now gate-all-around. The pattern is always multiple overlapping S-curves, each beginning before the last one peaks.

The data supports the mechanism: every 50% reduction in inference cost has been associated with a 200–300% increase in deployment. That's textbook Jevons elasticity.

"Diminishing returns on GPUs" isn't a ceiling on inference. It's the moment the next technology takes over. That's the mechanism of Jevons Paradox, not a counterpoint to it.

The Investment Layers

If Jevons-style expansion is real, it has to flow through physical infrastructure. I think about this in four layers, ordered from deepest (most expansion-certain) to shallowest (most speculative).

Layer 1: Energy and Power

Energy is the binding constraint. If AI demand expands at anything close to Jevons rates, someone has to generate the electricity. Data center electricity demand is on track to double this year, with the sector's total consumption surpassing Canada's national usage.

The structural problem is deeper than just demand growth. As Vaclav Smil details in Energy and Civilization, energy transitions are slow precisely because the physical infrastructure is massive and long-lived. Roughly 70% of the U.S. electrical grid was built between the 1950s and 1970s. Much of it is approaching end-of-life at the exact moment AI is driving the largest incremental demand increase in decades. This isn't a problem that resolves quickly. Power plants take years to permit and build. Grid transmission upgrades take longer.

Nuclear is where the smart money is moving. Constellation Energy's merger with Calpine creates a fleet of 21 nuclear reactors plus 50 natural gas plants, essentially a baseload power platform positioned for AI demand. Amazon signed a 1.92 GW power purchase agreement at Susquehanna and committed \$500 million to small modular reactor development. These aren't speculative bets on future demand; they're capacity commitments predicated on demand that's already contractually visible.

Hyperscaler capital expenditure tells the same story: \$602 billion planned for 2026, roughly 75% tied to AI infrastructure. Goldman Sachs estimates cumulative AI infrastructure spending of \$1.15 trillion between 2025 and 2027. That capital has to buy electricity, and the electricity has to come from somewhere.

Layer 2: Physical Infrastructure

Between the power plant and the GPU sits an enormous amount of physical equipment: transformers, switchgear, power distribution units, cooling systems, racks, cabling. This is the picks-and-shovels layer; it benefits regardless of which AI stack wins.

Eaton reported data center orders up 70% year-over-year. Transformers have become a bottleneck, with lead times stretching to 18+ months for large power transformers. Vertiv, which makes power management and thermal systems, is sitting on a \$9.5 billion backlog. Liquid cooling, once a niche technology, is becoming standard for high-density AI compute racks.

Grid transmission and distribution may be the most underappreciated bottleneck. You can build a data center in 18 months. Getting grid interconnection can take three to five years. The physical infrastructure required to move power from generation to consumption is the constraint that's hardest to accelerate, and it benefits from AI expansion regardless of which models, chips, or cloud providers ultimately dominate.

Layer 3: Custom Silicon

The GPU-to-ASIC transition described above isn't just evidence that the Jevons expansion continues; it's itself a Jevons trigger. Each new silicon architecture that enters production at lower cost-per-token reopens the demand curve.

Broadcom's AI semiconductor revenue is doubling year-over-year to roughly \$8.2 billion in Q1 FY2026. Marvell's custom XPU pipeline is expanding across all major hyperscalers. Both companies are positioned on the ASIC side of the GPU-to-ASIC transition, the side that's growing at 44.6% versus 16.1%.

Nvidia still dominates training workloads, and Blackwell delivers a 10x cost-per-token reduction for open-source inference models, which is itself a massive Jevons input. But inference is bifurcating. Training demands flexibility and programmability (Nvidia's strength). Inference at scale demands efficiency and cost optimization (where ASICs excel). The market is splitting, and both sides drive expansion.

Layer 4: The Application Tier

This is where it gets speculative. Cloud providers and hyperscalers function as toll booths; they collect revenue proportional to total compute consumed, making them natural beneficiaries of demand expansion. But the application tier above them is where you're picking winners, not betting on expansion itself.

AI-native companies become viable only at cheaper inference price points. The legal tech startup that can offer document review at one-tenth the cost of a junior associate doesn't exist at \$20 per million tokens. It might exist at \$2. It definitely exists at \$0.20. Each step down the cost curve unlocks a new tier of applications.

The contrarian opportunity in this layer is latent demand: the markets that don't exist yet because the service was too expensive for most people. Roughly 80% of Americans who need a lawyer can't afford one. Most small businesses can't afford financial planning. Most students can't afford tutoring. If inference costs follow a Jevons trajectory, these aren't aspirational markets; they're inevitable markets. But investing in them means picking which company captures each one, which is a fundamentally different bet than investing in the infrastructure that serves all of them.

Who Else Is Making This Bet

This framework isn't contrarian anymore. Satya Nadella tweeted "Jevons paradox strikes again!" when DeepSeek demonstrated cheaper inference without reducing demand. Microsoft's AI revenue hit \$13 billion, up 175% year-over-year. Fortune noted that Nadella's optimism was explicitly grounded in the paradox: cheaper AI means more AI, not less.

Andreessen Horowitz made the economic case directly: cheaper tokens unlock more demand than efficiency saves. Their thesis is that foundation model economics follow the same curve as prior compute economics: falling costs expand the addressable market faster than they reduce per-unit revenue.

NPR's Planet Money covered the thesis in mainstream terms, bringing Jevons Paradox from an obscure 19th-century economic observation to a household framework for understanding AI economics. Nathan Witkin's analysis showed that employment in software development, translation, and radiology increased after GPT-3, exactly the demand expansion the model predicts. Markman Capital called the "flawed consensus" of GPU diminishing returns "one of the most dangerous misreadings of the current market."

Deloitte, McKinsey, and Bain are all projecting massive infrastructure buildout. McKinsey's \$7 trillion estimate for data center scaling reflects the same underlying logic: if demand expands as costs fall, the physical infrastructure to support it is the bottleneck.

Jevons went from an obscure economics reference to a mainstream investment framework in roughly twelve months. That's not because it's trendy; it's because the data keeps confirming the pattern.

Where the Thesis Could Be Wrong

Intellectual honesty requires mapping the failure modes.

Demand elasticity might be lower than historical precedent. Every prior Jevons cycle involved inputs with massive latent demand: coal for industrial heat, transistors for consumer electronics, bandwidth for media. AI inference might not have the same depth of latent demand. If the tasks AI performs well are narrower than the tasks coal or transistors enabled, the expansion could stall earlier than the model predicts.

Regulatory intervention could cap the expansion. Energy policy, AI regulation, data center permitting restrictions. Any of these could artificially constrain the physical infrastructure that the expansion requires. Jevons Paradox describes an economic dynamic, not a law of physics. It can be overridden by policy.

The biological ceiling is real. As I argued in The AI Vampire Is Jevons Paradox, human judgment is the input that doesn't scale. If every Jevons expansion in AI ultimately concentrates demand on human decision-making, and human decision-making has genuine cognitive limits, the expansion hits a different kind of constraint, one that can't be solved with more silicon or more power.

Timing risk is the most likely failure mode. The direction of the thesis could be correct while the timeline is wrong. Infrastructure bottlenecks might resolve more slowly than demand builds, creating periods of overinvestment followed by correction. The historical base rate favors Jevons, but base rates describe probabilities, not certainties. Plenty of investors have been right about the direction and still lost money because they were wrong about the timing.

The Physical Footprint of Expansion

The deepest layers (energy and physical infrastructure) are the safest Jevons bets. They benefit from AI demand expansion regardless of which models, chips, or companies win. You don't need to know whether GPT-7 or Claude 6 is the better model to know that both of them will need electricity, transformers, cooling, and grid capacity.

The further up the stack you go, the more you're picking winners rather than betting on expansion. Custom silicon is a strong middle ground: the GPU-to-ASIC transition is structural, and the companies positioned on the right side of it have visible demand. But the application tier is where the uncertainty concentrates, and that's where most retail investors focus their attention.

The expansion has a physical footprint. Every token generated requires electricity. Every data center requires grid interconnection. Every custom ASIC requires a fab slot. Every cooling system requires water. The Jevons expansion, if it plays out as the framework predicts, will be visible not in stock prices or earnings calls but in the physical world: in power generation capacity, in transformer lead times, in grid interconnection queues, in cooling system orders.

Jevons won't announce itself. It never does. It shows up in electricity bills, in transformer backorders, in cooling system lead times, in the quiet scramble to secure power purchase agreements years in advance. The signal isn't in what people say about AI. It's in what they're building to support it.

The AI Vampire Is Jevons Paradox

A.C. Jokela — Wed, 04 Mar 2026 14:00:00 GMT

Steve Yegge's "The AI Vampire" has been circulating among developers and managers for the past few weeks, and it's striking a nerve. The core argument: AI makes you dramatically more productive (Yegge estimates 10x or more) but companies capture the entire surplus. You don't get a shorter workday. You get 10x the output at the same hours, with the cognitive load compressed into pure decision-making. The result is burnout on a scale the industry hasn't seen before. His prescription is blunt: calculate your \$/hr, work three to four hours a day, and refuse to let the vampire drain you dry.

It's a compelling piece, written with Yegge's characteristic directness and self-awareness. And it describes something real. But as I read it, I kept seeing something he doesn't name, a pattern I've been writing about for months.

This is the fourth piece in what has become a series on Jevons Paradox and AI economics. The first traced the paradox through the semiconductor industry. The second argued that AI displacement scenarios systematically undercount demand expansion. The third explored what happens when the cost of intelligence follows a Moore's Law trajectory. Along the way, I responded to Matt Shumer's displacement argument with the same framework.

Those pieces all looked at the macro picture: markets expanding, new industries forming, total economic activity growing. Yegge is describing the micro picture. What it actually feels like to be a human worker inside a Jevons expansion. And what he's describing, whether he uses the term or not, is Jevons Paradox operating on human attention.

The Jevons Pattern, One More Time

The pattern is simple enough to state in a sentence: when a critical input gets cheaper, demand expands beyond the efficiency gain. Total consumption of the input rises, not falls.

Coal got cheaper per unit of useful work. Total coal consumption surged as new applications became viable. Transistors got cheaper per unit of compute. Total compute spending grew by orders of magnitude. Bandwidth got cheaper per unit of data. Total data consumption exploded. The per-unit savings are overwhelmed by the explosion in total units demanded.

In my previous pieces, I applied this at the macro level. Cognitive output gets cheaper through AI. New industries emerge. Demand for cognitive work expands. The economy restructures around abundant, cheap intelligence. That argument is about markets, GDP, and employment categories: the aerial view.

But Jevons has always had a micro counterpart. When coal got cheaper, individual mines didn't shut down early; they ran harder, longer, extracting more because the economics now justified it. When compute got cheaper, individual developers didn't write less code; they wrote vastly more, because the constraints that had limited what was practical evaporated. The expansion creates pressure at every level of the system, not just at the top.

The macro story is about new markets forming. The micro story is about what happens to the people at the point of production, the ones whose labor is the input that just got cheaper.

What Yegge Is Actually Describing

Yegge's framework centers on a value-capture trap. He presents two scenarios:

Scenario A: AI makes you 10x more productive. Your company captures the surplus. You now produce 10x the output at the same salary and hours. The company benefits. You burn out.

Scenario B: You recognize the \$/hr math. If you were worth \$150/hr before AI and now produce 10x the output, your effective rate should be \$1,500/hr, or equivalently, you should work one-tenth the hours for the same salary. You work three to four hours a day, produce what used to take a full day, and keep your sanity.

He frames this as a choice between being exploited and being strategic. And he's honest about the difficulty of Scenario B; most people can't negotiate a three-hour workday, most companies won't accept it, and the competitive dynamics push relentlessly toward Scenario A.

Yegge's most vivid metaphor is that "AI has turned us all into Jeff Bezos." At Amazon, Bezos sat atop a machine that handled volume (logistics, warehousing, customer service, shipping) while he focused exclusively on high-leverage decisions. AI does the same thing for individual workers. It absorbs the volume work (the boilerplate code, the routine analysis, the standard responses) and leaves you with a residue of pure judgment calls. Every decision is consequential. Every hour is cognitively expensive.

He also has an important moment of self-awareness. Yegge acknowledges that his own experience (forty years of engineering, unlimited AI tokens, deep familiarity with the tools) represents "unrealistic beauty standards" for the average developer. He's the equivalent of the fitness influencer whose workout routine is their full-time job. Most people don't have his context, his autonomy, or his leverage to negotiate Scenario B.

And he identifies a crucial accelerant: the startup gold rush. AI has made it cheap enough to launch a company that "a million founders are chasing the same six ideas." This intensifies competition, which intensifies the pressure to push the output dial higher, which feeds the vampire.

The Jevons Connection

Here's what Yegge is describing in Jevons terms.

AI makes cognitive output dramatically cheaper. Jevons predicts that demand won't fall in response; it will increase. That's exactly what happens. Companies don't say "same output, fewer hours." They say "10x the output, same hours." The efficiency gain doesn't reduce consumption of the input. It increases consumption. This is the paradox, and it is playing out precisely as the model predicts.

But there's something different about this Jevons cycle, something that doesn't have a precedent in the historical cases.

Coal doesn't get tired. Transistors don't burn out. Bandwidth doesn't need a nap. Every prior Jevons cycle involved an inert input. You could mine more coal, fabricate more chips, lay more fiber. When demand expanded, supply expanded to meet it, and the system found a new equilibrium at higher volume. The input didn't resist. It didn't have a biological ceiling.

Human attention does.

AI creates a concentration effect that Yegge describes precisely: it absorbs high-volume, routine work and leaves humans with a residue of pure judgment. The judgment work is, by definition, the most cognitively expensive kind of work, the kind that requires deep focus, contextual understanding, and the willingness to be wrong. And demand for this judgment work expands Jevons-style as AI makes the overall process cheaper. More projects get launched. More code gets written. More decisions need to be made. The volume of judgment calls scales with the volume of output, even as AI handles everything else.

The problem is that the biological supply of deep, focused judgment is fixed. The deep work literature (Cal Newport and others have documented this extensively) converges on roughly three to four hours per day as the upper bound for sustained, cognitively demanding work. This isn't a cultural preference or a lifestyle choice. It's a constraint imposed by neurobiology. Attention is a depletable resource that recovers on a fixed biological schedule.

This is the first Jevons cycle where expanding demand hits a hard biological ceiling on the input.

Yegge's startup observation is also a Jevons phenomenon. AI made starting a company cheaper, so the number of startups exploded. More startups means more competition. More competition means more pressure to maximize output per person. The expansion creates its own acceleration, a feedback loop where cheaper cognitive output produces more ventures, which produce more demand for cognitive output, which increases the pressure on the humans in the loop.

And the "unrealistic beauty standards" problem has a Jevons name too: it's the efficiency benchmark effect. In every Jevons cycle, the most efficient user of the cheaper input sets the competitive pace for everyone else. The factory that adopted steam power first forced every competitor to adopt it or die. The company that adopted AI first forces every competitor to match its output-per-employee or lose. Yegge, with his forty years and unlimited tokens, is the equivalent of the first factory with a Watt engine. His output level becomes the standard against which everyone is measured, even though most people can't replicate his efficiency.

Where the Ceiling Matters

In every prior Jevons cycle, the resolution was supply expansion. Coal demand surged; mine more coal. Compute demand surged; fabricate more chips. Bandwidth demand surged; lay more fiber. The system found equilibrium at higher volume because the input could scale.

Human cognitive capacity doesn't scale. You can't mine more judgment. You can't fabricate more attention. The three-to-four-hour ceiling on deep work isn't going to move because a company's OKRs demand it.

This means a Jevons expansion in demand for human judgment has to resolve differently than prior cycles. There are really only three paths:

Better tooling that reduces the judgment burden. AI gets good enough to handle more decisions autonomously, pushing the human-in-the-loop threshold higher. The frontier of what requires human judgment retreats as AI capability advances. This is already happening; the boundary between "AI can handle this" and "a human needs to decide" is moving rapidly. But it's not moving fast enough to outpace the demand expansion, which is why Yegge's burnout observation is accurate right now even if the long-term trajectory favors less human involvement.

Organizational restructuring. More people, fewer high-stakes decisions each. Instead of one developer making judgment calls on 10x the output, you have three developers each handling a manageable portion. This is the "hire more" response, and it pushes back against the cost-reduction motive that drives Scenario A. Companies that pursue this path may produce better outcomes but at higher cost, which competitive dynamics tend to punish.

Cultural pushback. Yegge's \$/hr formula. Workers internalize the fixed-supply economics of their own attention, price it accordingly, and refuse to let demand expansion drain it below sustainable levels. This is individually rational but collectively difficult; it requires either enough leverage to negotiate, or enough cultural shift to change expectations.

Yegge's \$/hr formula is, in Jevons terms, an attempt to set equilibrium for a fixed-supply resource. It is the cognitive equivalent of OPEC production quotas, an effort to prevent the price of a scarce input from being driven to zero by unconstrained demand. And like OPEC quotas, it works only if enough participants enforce it.

What This Means for the Macro Picture

I want to be honest about what Yegge's observation adds to the framework I've been building.

My previous pieces argued that when cognitive output gets cheaper, demand expansion will create new economic activity that exceeds the displacement. I stand by that argument. But I underweighted the human-in-the-loop constraint. The demand expansion is real: new markets form, new companies launch, total economic activity grows. But every unit of that expanded activity still requires some quantum of human judgment, and that judgment runs on biological hardware with a fixed daily capacity.

This doesn't invalidate the macro Jevons argument. Demand will expand. New industries will form. Total employment will restructure, not collapse. But the human attention constraint acts as a speed governor on the expansion. The economy can't scale cognitive output infinitely by just pushing the existing workforce harder, because the existing workforce has a biological ceiling on the input that matters most.

This argues for Yegge's three-to-four-hour workday not as a lifestyle aspiration but as something closer to an economic inevitability, the natural equilibrium point for a Jevons cycle operating on a fixed-supply input. When demand for an input exceeds the maximum sustainable rate of supply, the system must either find a substitute (AI handling more decisions autonomously), expand the supplier base (more workers, shorter hours each), or accept a constrained equilibrium (the three-hour workday). Some combination of all three is likely.

The interesting implication is that the Jevons expansion and the burnout crisis are not contradictory phenomena. They're the same phenomenon viewed from different vantage points. The macro analyst sees demand expanding and new economic activity forming. The individual worker sees an unsustainable cognitive load. Both are correct. They're describing different aspects of the same system adjusting to a radically cheaper input.

The Vampire and the Paradox

Matt Shumer worries about displacement, losing your job to AI. Steve Yegge worries about what happens to the people who aren't displaced, who keep their jobs but get vampired. Both are describing real phenomena. Neither is the whole picture.

The Jevons framework encompasses both. Demand expansion creates new work, answering Shumer's displacement concern: the economy doesn't contract, it restructures. But the expansion concentrates cognitive load on the humans who remain in the loop, confirming Yegge's burnout observation, because the one input AI can't replace is the one input that can't scale.

Shumer's error is modeling only the displacement side. Yegge's error is modeling only the extraction side. The full picture includes both: an economy producing vastly more cognitive output, creating genuinely new economic activity, while simultaneously pushing the humans at the center of it toward a biological wall.

The vampire is real. It's also, like every Jevons cycle, a signal that something genuinely new is being created, that demand is expanding into territory that didn't exist before. The burnout isn't incidental to the expansion. It's a symptom of it. And like every prior Jevons cycle, the system will find an equilibrium, not because anyone plans it, but because a fixed-supply input eventually forces one. The question is how much damage the vampire does before we get there.

Something Big Is Happening, And Something Big Is Missing

A.C. Jokela — Sun, 01 Mar 2026 14:00:00 GMT

Matt Shumer's "Something Big Is Happening" has been making the rounds, forwarded by founders, reposted by VCs, shared by worried parents and recent graduates. If you haven't read it, the core argument is straightforward: AI capabilities are advancing at an unprecedented pace, the public doesn't appreciate how fast things are moving, and roughly half of entry-level white-collar jobs will be displaced within one to five years. He frames this as a personal warning to the non-technical people in his life, drawing an explicit parallel to February 2020, the moment before COVID when the warnings were there but most people weren't listening.

It is a well-written, earnest piece, and it resonated for a reason. The capability gains are real. The perception gap is real. The practical advice is genuinely useful. Shumer deserves credit for engaging seriously with a question that most people in his position (CEO of an AI company) have financial incentives to either hype or deflect.

But the piece has a hole in the center of it, and it's the same hole that appears in nearly every AI displacement argument I've encountered. I've written about this through the lens of Jevons Paradox, explored it as a direct counter-thesis to displacement scenarios, and examined what happens when you apply Moore's Law to the cost of intelligence itself. The pattern is consistent, and Shumer's piece reproduces the analytical error at its core: it models what AI replaces without modeling what AI creates.

The Steelman

Before critiquing the piece, I want to present its strongest version in good faith, because Shumer gets several important things right, and dismissing the argument wholesale would be intellectually lazy.

The capability curve is real. METR benchmarks show AI task completion doubling roughly every seven months, possibly accelerating. Shumer cites this data, and it's legitimate. I've experienced the curve firsthand. Over the past year and a half, I've built a high-performance Rust-based ballistics engine and Lattice, an entire programming language with a novel phase-based type system, working across GPT-4, GPT-4o, Claude Haiku, Opus, and most recently Opus 4.6 with Claude Code. The progression itself is the data point. Early models could help with fragments. Today's frontier models reason across thousands of lines of interconnected code, tracking type systems, managing compiler passes, understanding how changes in one module ripple through the rest. These aren't toy demos. They're production-quality projects where the AI operated at the architectural level. The capability gap between late 2024 and early 2026 is genuinely striking.

The perception gap is real too. Shumer makes a point that doesn't get enough attention: most people's experience with AI is limited to free-tier models that lag frontier capabilities by twelve months or more. Someone who tried ChatGPT once in 2024 and found it mediocre is extrapolating from hardware that's already obsolete. The gap between the free experience and the paid frontier experience is larger than most people realize, and Shumer is right to flag it.

The self-improvement feedback loops are real. OpenAI has stated that GPT-5.3 Codex was "instrumental in creating itself." Anthropic's training pipeline uses prior Claude models to evaluate training examples. Dario Amodei predicts AI autonomously building next-generation versions within one to two years. These aren't speculative claims; they're descriptions of current practice, and they compress the improvement timeline.

Shumer's practical advice is sound: use paid tools, select the best available models, spend an hour a day experimenting, build financial resilience, develop adaptability as a core skill. This is good counsel regardless of how the macro picture unfolds.

And the urgency is not manufactured. Whatever you think the economic consequences will be, the pace of capability improvement is unprecedented in the history of technology. Shumer is right that most people are not paying attention. Where he goes wrong is in what he concludes from that observation.

The Substitution Fallacy

Here is Shumer's core analytical error, and the one that most critiques of his piece also miss.

He treats "AI can do X" as equivalent to "AI will replace all humans doing X." His piece moves through a list of job categories (legal work, financial analysis, software engineering, medical analysis, customer service) and for each one, the logic is: AI can now perform this work at a level that rivals human professionals, therefore the humans performing this work are at risk. Implicit in this framing is the assumption that the economy stays roughly the same size, with machines doing work that humans used to do. The number of legal analyses needed stays constant. The number of financial models stays constant. The amount of software stays constant. AI just does it cheaper.

This is the substitution frame, and it has been wrong by orders of magnitude at every prior technological inflection point.

I explored this in detail in my Jevons counter-thesis. The mechanism is straightforward: when a critical input becomes dramatically cheaper, the addressable market for everything that uses that input expands. New use cases emerge that were previously uneconomical. Existing use cases scale to populations that were previously priced out. Total consumption of the now-cheaper input rises even as the per-unit cost falls.

The numbers on latent demand are not speculative. Roughly 80% of Americans who need legal help cannot afford it. Personalized tutoring is a luxury good; \$50 to \$100 per hour puts it out of reach for the average family. Custom software development, at \$50,000 or more per engagement, is inaccessible to most small businesses. Personalized financial planning is available only to households with six-figure investable assets. These aren't hypothetical markets. They are documented, unmet demand suppressed by the cost of the human intelligence required to serve them.

When Shumer writes that his lawyer friend finds AI "rivals junior associates" for contract review and legal research, the Jevons question is: what happens when legal analysis costs one-hundredth what it costs today? The answer isn't "lawyers lose their jobs." It's "hundreds of millions of people who currently have zero legal representation suddenly have access to it." The total volume of legal analysis performed doesn't shrink. It explodes. Whether that explosion employs as many human lawyers as today is a genuine question, but it's a very different question from "AI replaces lawyers," and Shumer's piece never asks it.

The same logic applies to every category on his list. If financial modeling becomes 100x cheaper, every small business gets CFO-grade analysis, a market expansion of orders of magnitude relative to the current financial services industry. If software development becomes 100x cheaper, the barrier between "person with an idea" and "working application" functionally disappears, and the total volume of software produced doesn't shrink; it expands to include millions of applications that nobody would build at current costs.

The Pandemic Analogy Problem

"Think back to February 2020." It's an emotionally effective opening, and it does exactly what Shumer intends; it activates the memory of a time when the warnings were there but most people didn't act until it was too late. As a rhetorical device, it works. As an analytical framework, it's misleading.

COVID was a pure externality. It destroyed without creating. A virus doesn't generate new economic activity as it spreads. It imposes costs, disrupts supply chains, and kills people. The appropriate response was defensive: stockpile supplies, get vaccinated, stay home. The framing of individual survival (how do I get through this) was correct for a pandemic because a pandemic doesn't create opportunity. It just destroys.

Technology transitions are categorically different. They create as they destroy, and historically, the creation overwhelms the destruction. The better analogy (the one Shumer doesn't use) is the semiconductor revolution. Computing destroyed millions of clerical, typist, switchboard operator, and filing clerk jobs. It also created the software industry, the internet economy, the mobile ecosystem, social media, cloud computing, e-commerce logistics, and millions of roles that had no conceptual precursor in the prior economy. Total employment didn't shrink. It restructured and grew.

The pandemic analogy does something else that's analytically costly: it frames the correct response as individual survival. How do I prepare? How do I stay ahead? This is the right question for a virus. It is the wrong question for a technology transition, where the correct frame is not "how do I survive displacement" but "what new things become possible?" Shumer's advice (use the tools, build adaptability, experiment daily) is good advice. But it's embedded in a survivalist frame that misses the larger economic picture. The person who learned to build websites in 1995 wasn't surviving the death of typesetting. They were participating in the creation of something that would be orders of magnitude larger than the industry it disrupted.

A Founder's Experience Is Not the Economy

"I describe what I want built, in plain English, and it just appears."

I believe him. I've had similar experiences. When I built the ballistics engine and Lattice, there were moments where the workflow felt qualitatively different from anything I'd experienced in over three decades of writing software. The capability is real and it's striking.

But Shumer is generalizing from the thinnest part of the adoption curve. A startup founder building prototypes with frontier AI tools is the absolute highest-leverage, lowest-friction use case for current technology. There are no compliance departments. No regulatory review. No integration with legacy systems built on COBOL. No liability frameworks that require a human signature. No union contracts. No procurement cycles measured in fiscal years.

The gap between "a founder can build a prototype in an afternoon" and "a hospital deploys AI-driven diagnostics at scale" is measured in years, not months. Regulatory friction, institutional inertia, liability requirements, and cultural resistance are real. The FDA doesn't move at startup speed. Neither do insurance companies, government agencies, or school districts. These aren't trivial obstacles; they're the mechanisms through which society manages risk, and they exist for reasons.

I don't want to overweight this argument. Institutional friction can be overstated, and appeals to regulation can become a way of avoiding engagement with the underlying capability shift. The important point is narrower: Shumer extrapolates from his personal productivity gain to "nothing done on a computer is safe," and that's an extrapolation error. A founder experiencing sudden personal leverage and projecting that curve onto civilization is a recognizable pattern in tech commentary. It's usually too bullish on the timeline and too narrow on the mechanism.

What Gets Created

This is the biggest gap in Shumer's piece, and the biggest gap in most commentary on AI and employment. He spends thousands of words on what AI can replace. He spends zero words on what AI makes possible for the first time.

I examined this through the Moore's Law for Intelligence framework: the 10x / 100x / 1,000x staircase of what becomes viable as the cost per unit of machine intelligence drops. The historical pattern from semiconductors is unambiguous: each order-of-magnitude cost reduction didn't just make existing applications cheaper. It created entirely new categories of economic activity that were literally unimaginable at the prior price point.

Nobody in 1975 predicted Instagram, Uber, or Spotify. Not because they required new physics; they required compute cheap enough to fit in a pocket. The applications were latent, waiting for the cost curve to reach them.

The same is true for intelligence. We can identify the structural conditions for demand expansion even if we can't predict the specific applications:

Small businesses with CFO-grade financial analysts, not because they hire CFOs, but because AI makes that analysis accessible at \$50 per month instead of \$200,000 per year. Personalized tutoring for every student, not an incremental improvement on existing education, but a qualitative shift in how learning works for the 95% of families who can't afford human tutors. Legal help for the 80% of Americans currently priced out. Preventive medicine embedded in every checkup, where an AI has read every relevant paper published in the last decade and cross-referenced it against the patient's complete history.

And the nature of software engineering itself is changing, not replacing engineers but redefining the skill. The workflow is already shifting from "write code line by line" to "describe architecture, direct implementation, review output." At 100x cheaper inference, small teams build products that previously required departments. At 1,000x cheaper, the barrier between having an idea and having working software effectively disappears. That's not displacement of engineers; it's an explosion in the total volume of software that gets built, and it requires people who know what to build and why.

We can't predict the Instagram of cheap cognition. But we can observe that the structural conditions (massive latent demand, rapidly falling costs, intense competition distributing gains to consumers) are identical to the conditions that preceded every prior wave of demand-driven economic expansion.

The Speed Question: Where Shumer Is Strongest

The legitimate uncertainty in Shumer's argument isn't whether displacement will happen. It will. The question is whether it happens faster than demand expansion can absorb.

Prior Jevons cycles unfolded over decades. Agricultural mechanization displaced 90% of farm workers over a century. Computerization restructured white-collar work over roughly forty years. If AI compresses displacement into two to three years, the question of whether demand expansion keeps pace becomes genuinely urgent. This is where Shumer's urgency has teeth, and it's the argument I take most seriously.

I was honest about this in both the counter-thesis and the Moore's Law piece: the speed of this transition is unprecedented, and historical analogy doesn't fully resolve the timing question. The transitional pain for people whose livelihoods depend on cognitive labor that AI can replicate is real and potentially severe.

But notice the asymmetry in Shumer's framing. Disruption happens at AI speed: step-function capability jumps, immediate adoption, rapid displacement. Demand expansion, on the other hand, is treated as essentially static or non-existent. The economy absorbs the shock and contracts. End of story.

This asymmetry isn't supported by the evidence. The smartphone created a trillion-dollar app economy in under five years. Cloud computing spawned tens of thousands of SaaS companies within a decade. When a critical input becomes 100x cheaper, entrepreneurs move fast, because the profit opportunity is enormous. Shumer's own experience is evidence of this: he's a founder building products at unprecedented speed using AI tools. Scale that behavior across millions of entrepreneurs who suddenly have access to capabilities that were previously reserved for well-funded teams, and the demand side moves faster than any prior technology transition.

The honest answer is that we don't know whether demand expansion will keep pace with displacement. That's a genuine uncertainty. But Shumer presents it as a foregone conclusion in one direction, displacement wins, full stop, and that's not an evidence-based position. It's a bet against the strongest empirical pattern in economic history.

What to Take from This

Shumer's practical advice to individuals is sound even if his macro analysis is incomplete. Use the tools. Build adaptability. Experiment daily. Don't ignore the capability curve; it's real, it's fast, and it will restructure how cognitive work gets done.

But don't mistake a substitution-only model for the full picture. The most consistent empirical pattern in economic history is that when a critical input gets dramatically cheaper, total consumption increases and the economy restructures around the cheaper input. Coal. Transistors. Bandwidth. Lighting. Every time, the predictions that efficiency would destroy demand were wrong, not because displacement didn't happen, but because demand expansion overwhelmed it. Betting that this pattern has finally broken requires an extraordinary burden of proof that Shumer's piece (eloquent, urgent, and emotionally resonant as it is) does not meet.

Something big is happening. What's missing from the conversation is the other half of it.

Moore's Law for Intelligence: What Happens When Thinking Gets Cheap

A.C. Jokela — Sat, 28 Feb 2026 14:00:00 GMT

I have written about Jevons Paradox twice now, once through the history of the semiconductor industry, and once as a broader examination of what happens when the cost of a critical economic input collapses. The pattern is consistent: demand expands to overwhelm the savings. Coal. Transistors. Bandwidth. Lighting.

Those pieces looked at the pattern itself. This one is different. I want to run a thought experiment forward, not backward.

I've also spent a lot of time on this site looking backward at computing history, watching Stewart Cheifet walk viewers through the early personal computer revolution on The Computer Chronicles, examining how word processing went from a curiosity to a necessity in a single decade, tracing George Morrow's role in making personal computing real, and following CP/M's arc from operating system of the future to historical footnote. I've run CP/M on physical RetroShield hardware, explored the Motorola 68000 that powered a generation of machines, and dug into how Infocom turned text adventures into a business at a time when 64K of RAM was generous. That immersion in where computing came from is exactly what makes the forward question so vivid, because at every stage, the people living through the transition couldn't see what was coming next. The engineers building CP/M didn't anticipate DOS. The engineers building DOS didn't anticipate the web. The engineers building the web didn't anticipate the iPhone. The pattern is always the same: cheaper compute enables things that were unimaginable at the prior cost.

The question isn't "will AI destroy jobs?" or "is the doom scenario wrong?" The question is: what becomes possible when thinking gets cheap?

Because AI compute is following a cost curve that looks remarkably like the early decades of Moore's Law. And if that continues (if the cost per unit of machine intelligence drops by an order of magnitude every few years) the consequences extend far beyond making today's chatbots cheaper to run.

The Cost Curve

Moore's Law, in its original formulation, described the doubling of transistors per integrated circuit roughly every two years. But the economic consequence that mattered wasn't transistor density; it was cost per unit of compute. From the 1960s through the 2010s, the cost per FLOP declined at a compound rate that delivered roughly a 10x improvement every four to five years. A computation that cost \$1 million in 1975 cost \$1 by 2010. That decline didn't just make existing applications cheaper. It created entirely new categories of computing that were inconceivable at the prior cost structure.

AI inference costs are now following a similar trajectory, but faster. OpenAI's text-davinci-003, released in late 2022, cost \$20 per million tokens. GPT-4o mini, released in mid-2024, delivers substantially better performance at \$0.15 per million input tokens, a 99% cost reduction in under two years. Claude, Gemini, and open-source models have followed similar curves. DeepSeek entered the market in early 2025 with pricing that undercut Western frontier models by roughly 90%, compressing the timeline further through competitive pressure.

The GPU hardware underneath these models is on its own Moore's Law trajectory. GPU price-performance in FLOP/s per dollar doubles approximately every 2.5 years for ML-class hardware. Architectural improvements in transformers, mixture-of-experts routing, quantization, speculative decoding, and distillation compound on top of the hardware gains. The result is a cost curve where the effective price of a unit of machine reasoning is falling faster than the price of a transistor did during the semiconductor industry's most explosive growth phase.

This matters because we know, empirically, what happens when the cost of a foundational input follows an exponential decline. We have sixty years of data on it. The compute industry went from a few thousand mainframes serving governments and large corporations to billions of devices in every pocket, every appliance, every traffic light. Total spending on computing didn't shrink as costs fell; it expanded by orders of magnitude, because each 10x cost reduction unlocked categories of use that didn't exist at the prior price point.

The thought experiment is straightforward: apply that pattern to intelligence itself.

Today's Price Points Create Today's Use Cases

At current pricing (roughly \$3 per million input tokens for a frontier model like Claude Sonnet), AI is economically viable for a specific class of applications. Customer support automation. Code assistance. Document summarization. Marketing copy. Translation. These are the use cases where the value generated per token comfortably exceeds the cost per token, and where the interaction pattern involves relatively short exchanges.

But there are vast categories of potential use where current pricing makes the math uncomfortable or impossible. Consider:

Continuous monitoring and analysis. A financial analyst who wants an AI to continuously watch SEC filings, earnings calls, patent applications, and news feeds across 500 companies (analyzing each document in full, cross-referencing against historical patterns, and generating alerts) would consume billions of tokens per month. At current prices, this costs tens of thousands of dollars monthly. At 100x cheaper, it costs the price of a SaaS subscription.

Full-codebase reasoning. This one is already arriving. Anthropic's Claude Opus 4.6, working through Claude Code, can operate at the repository level, reading files, understanding architecture, running tests, and making changes across an entire codebase in a single session. I've used it to build a high-performance Rust-based ballistics engine and to develop Lattice, an entire programming language with a bytecode VM compiler, projects where the AI wasn't autocompleting fragments but reasoning across thousands of lines of interconnected code, tracking type systems, managing compiler passes, and understanding how changes in one module ripple through the rest. The constraint today isn't capability; it's cost. These sessions consume large volumes of tokens, which means they're viable for serious engineering work but not yet cheap enough to run continuously on every commit, every pull request, every deployment. At 100x cheaper, that changes. At 1,000x cheaper, every codebase has an always-on collaborator that has read everything and forgets nothing.

Personalized education at scale. A truly personalized AI tutor that adapts to a student's learning style, tracks their understanding across subjects, reviews their homework in detail, explains mistakes with patience, and adjusts its teaching strategy over months, this requires sustained, high-volume token consumption per student. Multiply by millions of students and the current cost structure breaks. At 100x cheaper, it's viable for a school district. At 1,000x cheaper, it's viable for an individual family.

Preventive medicine. Analyzing a patient's complete medical history, genetic data, lifestyle information, lab results, and the current research literature to generate genuinely personalized health recommendations (not the generic advice a five-minute doctor's visit produces, but the kind of comprehensive analysis that currently only concierge medicine patients paying \$10,000+ per year receive). At current token prices, this is prohibitively expensive for routine use. At 100x cheaper, it could be embedded in every annual checkup.

Ambient intelligence. The concept of AI that runs continuously in the background of your life (understanding your calendar, email, documents, and goals, proactively surfacing relevant information, drafting responses, scheduling meetings, flagging conflicts) requires sustained inference at volumes that would cost hundreds of dollars per day at current prices. At 1,000x cheaper, it costs less than your phone bill.

These aren't science fiction scenarios. They're applications of current model capabilities at price points that don't yet exist. The models can already do most of this work. The cost curve is the bottleneck.

The 10x / 100x / 1,000x Framework

Moore's Law didn't deliver its benefits in a smooth, continuous flow. It came in thresholds, price points at which qualitatively new applications became viable. The pattern with AI compute is likely to follow the same staircase function.

At 10x cheaper (plausible within 1-2 years): AI becomes viable for tasks that are currently "almost worth it." Small businesses that can't justify \$500/month for AI tooling find it worthwhile at \$50/month. Individual professionals (accountants, lawyers, doctors, engineers) integrate AI into their daily workflow not as an occasional tool but as a constant companion. The volume of AI-mediated work increases dramatically, but the character of work doesn't fundamentally change. This is the equivalent of the minicomputer era: the same kind of computing, available to more people.

At 100x cheaper (plausible within 3-5 years): The applications listed above become economically viable. Continuous analysis, full-codebase reasoning, personalized education, preventive medicine at scale. At this price point, AI stops being a tool you use and starts being infrastructure you run on. Every document you write gets reviewed. Every decision you make gets a second opinion. Every student gets a tutor. Every patient gets a diagnostician. The total volume of inference consumed per capita increases by far more than 100x, because new use cases emerge that weren't contemplated at the prior price. This is the personal computer moment: qualitatively new categories of use.

At 1,000x cheaper (plausible within 5-8 years): Intelligence becomes ambient and disposable. You don't think about whether to use AI for a task any more than you think about whether to use electricity for a task. Every appliance, every vehicle, every building, every piece of infrastructure has embedded reasoning running continuously. Your home understands your patterns and adapts. Your car negotiates traffic in real time not just with sensors but with models that predict the behavior of every other vehicle. Agricultural equipment analyzes soil conditions at the individual plant level. Supply chains optimize in real time across thousands of variables. This is the smartphone moment: computing so cheap and pervasive that it becomes invisible.

The Compounding Effect

There's a dynamic in AI cost reduction that didn't exist with traditional Moore's Law: cheaper inference enables better models, which enables even cheaper inference.

When inference is expensive, researchers are constrained in how they can train and evaluate models. Each experiment costs real money. Each architecture search consumes significant compute budgets. When inference costs drop, researchers can run more experiments, evaluate more architectures, and discover more efficient approaches, which further reduces costs. Distillation (training a smaller model to mimic a larger one) becomes more practical when the larger model is cheaper to run at scale. Synthetic data generation (using AI to create training data for other AI) becomes more economical. The cost reduction compounds on itself.

This is already happening. GPT-4 was used to generate synthetic training data for GPT-4o. Claude's training pipeline uses prior Claude models to evaluate and filter training examples. Google's Gemini models help design the next generation of TPU chips that will run future Gemini models. The AI equivalent of "using computers to design better computers" arrived in year three of the current wave, decades earlier in the relative timeline than it took the semiconductor industry to reach the same recursive dynamic.

The implication is that the cost curve isn't just declining; it's declining at an accelerating rate because each improvement enables the next one. The semiconductor industry saw this acceleration plateau after about fifty years as it approached physical limits of silicon. AI has no equivalent physical constraint on the horizon. The limits are architectural and algorithmic, and those limits have been falling faster than hardware limits ever did.

What the Semiconductor Analogy Actually Predicts

In 1975, a Cray-1 supercomputer delivered about 160 MFLOPS and cost \$8 million. In 2025, an iPhone delivers roughly 2 TFLOPS of neural engine performance and costs \$800. That's a 12,500x performance increase at a 10,000x cost decrease, a net improvement of roughly 100 million times in price-performance over fifty years.

Nobody in 1975 predicted Instagram, Uber, Google Maps, or Spotify. Not because these applications required fundamentally new physics; they just required compute that was cheap enough to run in a device that fit in your pocket. The applications were latent, waiting for the cost curve to reach them.

The history is instructive at each threshold. When a capable computer crossed below \$20,000 in the early 1980s, it unlocked small business accounting, the same work mainframes did, just for smaller organizations. When it crossed below \$2,000 in the mid-1990s, it unlocked home computing, and with it the web browser, email, and e-commerce. When capable compute crossed below \$200 in the smartphone era, it unlocked ride-sharing, mobile payments, and social media, none of which had any conceptual precursor at the \$20,000 price point. Each 10x reduction didn't just expand the existing market. It created a market that was literally unimaginable at the prior price.

The same principle applies to intelligence. We are in the mainframe era of AI. The applications we see today (chatbots, code assistants, image generators) are the equivalent of payroll processing and scientific computation on 1960s mainframes. They are real and valuable, but they represent a tiny fraction of what becomes possible when the cost drops by five or six orders of magnitude.

What are the Instagram and Uber equivalents of cheap intelligence? By definition, we can't fully predict them. But we can identify the structural conditions that will enable them:

When intelligence costs less than attention, delegation becomes default. Today, the cognitive cost of formulating a good prompt, evaluating the output, and iterating often exceeds the cost of just doing the task yourself. As models get cheaper, faster, and better at understanding context, the threshold shifts. Eventually, not delegating a cognitive task to AI becomes the irrational choice, the way not using a calculator for arithmetic became irrational.

When intelligence costs less than data storage, everything gets analyzed. Today, most data that organizations collect is never analyzed. It's stored, archived, and forgotten, because the cost of human analysis exceeds the expected value of the insights. When AI analysis is effectively free, every dataset gets examined. Every log file gets reviewed. Every customer interaction gets analyzed for patterns. The volume of insight generated from existing data increases by orders of magnitude.

When intelligence costs less than communication overhead, organizations restructure. This is already starting. A significant fraction of white-collar work is coordination: meetings, emails, status updates, project management. These exist because humans need to synchronize their mental models of shared projects. AI tools are already compressing this layer: meeting summaries that eliminate the need for half the attendees, project dashboards that maintain themselves, codebases where an AI agent tracks the state of every open issue so developers don't have to sit through standup. When AI can maintain a comprehensive, always-current model of a project's state, much of the coordination overhead that justifies entire job categories (project managers, program managers, business analysts, internal consultants) begins to evaporate. An organization that currently needs 50 people to coordinate a complex project might need 10, with AI handling the information synthesis that previously required human intermediaries. That's a genuine productivity gain. It's also 40 people who need to find something else to do, and the honest answer is that we don't yet know how fast the demand side creates new roles to absorb them.

The Demand Expansion Is the Story

The instinct when hearing "AI gets 1,000x cheaper" is to think about cost savings. That's the substitution frame: doing the same things for less money. And yes, that will happen. But the semiconductor analogy tells us that cost savings are the boring part of the story.

When compute got 1,000x cheaper between 1980 and 2000, the interesting story wasn't that scientific simulations got cheaper to run. It was that entirely new industries (PC software, internet services, mobile apps, social media, cloud computing) emerged to consume orders of magnitude more compute than the entire prior industry had used. The efficiency gain on existing applications was dwarfed by the demand expansion from new applications.

The same will likely be true for intelligence. Consider bandwidth as a parallel case. In 1995, a 28.8 kbps modem made email and basic web pages viable. Nobody was streaming video; it was physically impossible at that bandwidth, not merely expensive. By 2005, broadband had made streaming music viable. By 2015, streaming 4K video was routine. By 2025, cloud gaming and real-time video conferencing were infrastructure-level assumptions. Total bandwidth consumption didn't decline as it got cheaper. It increased by roughly a million times, because each generation of cost reduction enabled applications that consumed orders of magnitude more bandwidth than the previous generation's entire output.

The interesting story isn't that customer support gets cheaper. It's the applications that are currently impossible (not difficult, not expensive, but literally impossible at current price points) that become not just possible but routine.

A world where every small business has a CFO-grade financial analyst. Where every patient has a diagnostician who has read every relevant paper published in the last decade. Where every student has a tutor who knows exactly where they're struggling and why. Where every local government has the analytical capacity currently reserved for federal agencies.

And the nature of building software itself is changing in ways that go beyond "engineers with better tools." For most of computing history, writing code meant a human translating intent into syntax, line by line, function by function. AI assistance started as autocomplete: suggesting the next line, filling in boilerplate. But that phase is already ending. Today, with tools like Claude Code, the workflow has inverted. The human describes what they want (an architecture, a feature, a behavior) and the AI writes the implementation across files, runs the tests, and iterates on failures. The engineer's role shifts from writing code to directing and reviewing it, from syntax to judgment. At 10x cheaper, this is how professional developers work. At 100x cheaper, it's how small teams build products that previously required departments. At 1,000x cheaper, the barrier between "person with an idea" and "working software" functionally disappears. The entire concept of what it means to be a software engineer is being rewritten in real time, not by replacing engineers, but by redefining the skill from "can you write this code?" to "do you know what to build and why?"

These aren't efficiency improvements on existing systems. They're new capabilities that create new categories of economic activity, new forms of organization, and new kinds of products and services that don't have current analogs, just as social media, ride-sharing, and cloud computing had no analogs in the mainframe era.

The Question That Matters

I should be honest about what I don't know. The displacement scenarios for white-collar labor are not fantasy. AI is already capable enough to handle work that was solidly middle-class professional territory two years ago: document review, financial analysis, code generation, customer support, content production. The scenarios where this accelerates faster than the economy can absorb are plausible, and anyone who dismisses them outright isn't paying attention. When a technology can replicate cognitive labor at a fraction of the cost, the transitional pain for the people whose livelihoods depend on that labor is real and potentially severe. The speed matters: prior technology transitions unfolded over decades, and AI compression of that timeline into years is a genuine uncertainty that historical analogy doesn't fully resolve.

But there is a question that displacement scenarios consistently underweight, and it's the one I explored in my Jevons counter-thesis: what happens on the demand side? Every model that projects mass unemployment from cheap AI is implicitly assuming that the economy remains roughly the same size, with machines doing the work humans used to do. That's the substitution frame. And the substitution frame has been wrong at every prior technological inflection point, not slightly wrong, but wrong by orders of magnitude.

The semiconductor industry's answer, delivered over sixty years of data, is unambiguous. Every order-of-magnitude cost reduction generated more economic activity, more employment, and more total compute consumption than the one before it. The economy didn't shrink as compute got cheaper. It restructured around cheap compute and grew. Roughly 80% of Americans who need legal help can't afford it today. Personalized tutoring is a luxury good. Custom software is out of reach for most small businesses. These aren't speculative markets; they're documented unmet demand suppressed by the cost of human intelligence. When that cost collapses, the demand doesn't stay static.

The honest answer is that both things will happen simultaneously. Jobs will be displaced, some permanently. And new categories of economic activity will emerge that are currently inconceivable, just as social media and cloud computing were inconceivable in the mainframe era. The question is which force dominates, and how fast the transition occurs. I think the historical pattern favors demand expansion, but I hold that view with the humility of someone who knows the speed of this particular transition is unprecedented.

AI inference costs are following the same curve as semiconductors, possibly faster. The tokens-per-dollar ratio will improve by orders of magnitude. And when it does, the applications that emerge will make today's AI use cases look as quaint as running payroll on a room-sized mainframe.

The thought experiment ends where all Jevons stories end: with more consumption, not less. More intelligence deployed, not less. More economic activity built on cheap cognition, not less. The cost curve is the enabling condition. What gets built on top of it is the part we can't fully predict, and historically, that's always been the most interesting part.

The Jevons Counter-Thesis: Why AI Displacement Scenarios Underweight Demand Expansion

A.C. Jokela — Tue, 24 Feb 2026 14:00:00 GMT

Citrini Research recently published a piece called "The 2028 Global Intelligence Crisis", a thought experiment modeling a scenario in which AI-driven white-collar displacement triggers a cascading economic crisis. In their telling, AI replaces workers, spending drops, firms invest more in AI to protect margins, AI improves, and the cycle repeats. They call it the "Intelligence Displacement Spiral" and project a 57% peak-to-trough drawdown in the S&P 500. No natural brake. No soft landing.

It is a well-constructed stress test, and worth reading on its own terms. But the scenario achieves its conclusion by modeling only the displacement side of an efficiency revolution while treating the demand-expansion side as essentially zero. This is the core analytical gap, and it is precisely the gap that Jevons Paradox addresses.

I have written about Jevons Paradox before in the context of the semiconductor industry, specifically how improvements in energy efficiency from the transistor through GPUs have consistently driven more total energy consumption, not less, by making computing cheap enough to permeate every corner of the economy. The same framework applies to AI and cognitive labor, and the Citrini piece is a useful foil for exploring why.

What Jevons Paradox Actually Says

In 1865, the English economist William Stanley Jevons observed something counterintuitive about coal consumption in Britain. James Watt's steam engine had made coal use dramatically more efficient; you could extract far more useful work per ton of coal than before. The intuitive expectation was that Britain would use less coal. The opposite happened. Total coal consumption surged, because the efficiency gains made coal-powered activities so much cheaper that entirely new applications emerged. Factories that couldn't justify coal-powered machinery at the old efficiency levels now could. Industries that had never used steam power adopted it. The per-unit savings were overwhelmed by the explosion in total units demanded.

This pattern has recurred across nearly every major input cost reduction in economic history. Semiconductor efficiency improved by roughly a trillionfold over six decades, and total spending on computing did not decline; it expanded from a niche military and scientific expenditure to a multi-trillion-dollar global industry. Bandwidth costs collapsed through the 1990s and 2000s, and total bandwidth consumption didn't decrease; it increased by orders of magnitude as streaming video, social media, cloud computing, and mobile internet emerged. LED lighting is roughly 90% more efficient than incandescent bulbs, and total global illumination has increased, not decreased, as cheap lighting enabled new architectural designs, 24-hour commercial operations, and decorative applications that were uneconomical before.

The mechanism is straightforward: when a critical input becomes dramatically cheaper, the addressable market for everything that uses that input expands. New use cases emerge that were previously uneconomical. Existing use cases scale to populations that were previously priced out. The total consumption of the now-cheaper input rises even as the per-unit cost falls.

The Citrini piece implicitly models AI as a substitution technology: it replaces human cognitive labor, and that's the end of the transaction. Jevons Paradox suggests AI is simultaneously, and perhaps primarily, an expansion technology: it makes cognitive services so cheap that demand for them can grow faster than the displacement effect.

Latent Demand Is Enormous and Unmeasured

The Citrini scenario treats the economy as having a fixed quantity of cognitive work. AI absorbs that work, the workers who performed it lose their income, and aggregate demand collapses. But the reason cognitive work costs what it does is that human intelligence has been scarce and expensive. This scarcity has suppressed enormous categories of demand that simply don't show up in current GDP accounting because they've never been economically feasible.

Consider education. The average American family cannot afford personalized tutoring. A human tutor at \$50-100 per hour is a luxury good. If AI reduces the cost of competent, personalized educational support to near zero, the addressable market isn't the current tutoring market; it's every student in the country. That is a market expansion of potentially 50x or more relative to the existing tutoring industry. The humans who previously worked as tutors are displaced, yes, but the economic activity generated by tens of millions of students receiving personalized education (and the downstream productivity gains from a better-educated workforce) is a new demand category that didn't exist before.

The same logic applies across dozens of sectors. Legal services: roughly 80% of Americans who need legal help cannot afford it. Personalized financial planning: currently available only to households with six-figure investable assets. Preventive health analysis: limited by the number of available clinicians. Custom software for small businesses: a \$50,000 engagement is out of reach for a business generating \$300,000 in annual revenue. Architecture and design services for middle-income homeowners. Personalized nutrition and fitness programming. Translation and localization for businesses that currently operate only in one language.

These are not speculative categories. They are documented, unmet needs constrained by the cost of the human intelligence required to serve them. When AI collapses those costs, the question is whether the demand expansion across all of these categories (and others we haven't imagined) can offset the displacement in existing roles. The Citrini piece assumes the answer is no without modeling the question. Jevons Paradox, and the historical base rate, suggests the answer is more likely yes.

The Citrini Piece's Own Evidence Supports Jevons

The piece acknowledges two canonical examples of technological displacement that didn't produce net job losses: ATMs (bank teller employment rose for 20 years after their introduction, because cheaper branch operations led to more branches) and the internet (travel agencies, the Yellow Pages, and brick-and-mortar retail were disrupted, but entirely new industries emerged in their place). It then dismisses both by asserting that "AI is different because it improves at the very tasks humans would redeploy to."

But this is precisely what critics said at every prior inflection point. When mechanized looms were introduced in the early 19th century, displaced textile workers could not "redeploy" to weaving; the machines did the very thing they were trained for. What actually happened was that radically cheaper cloth created demand for fashion, retail distribution, global trade logistics, cotton cultivation, and marketing, categories that scarcely existed at the prior cost structure. The weavers didn't get their old jobs back. They moved into an economy that had been restructured around abundant, cheap textiles, and that economy was far larger than the one it replaced.

The Citrini piece's own scenario contains evidence of Jevons-style expansion that it frames exclusively as destruction. The section on agentic commerce describes consumers using AI agents that eliminate friction: price-matching across platforms, renegotiating subscriptions, rebooking travel. The article frames this as the death of intermediation moats. But it is equally a story of market expansion. When an AI agent assembles a complete travel itinerary faster and cheaper than Expedia, the result isn't just that Expedia loses revenue. It's that people who previously found trip planning too cumbersome or too expensive now take trips. Total travel volume can increase even as per-trip intermediation costs fall.

The DoorDash example is even more explicit. The article describes vibe-coded competitors passing 90-95% of delivery fees to drivers, and AI agents shopping across twenty platforms for the best deal. Delivery becomes cheaper for consumers and more remunerative for drivers. The article frames this as destruction of DoorDash's moat. From a Jevons perspective, it's a textbook demand expansion setup: cheaper delivery means more people order delivery, more restaurants offer delivery, and total delivery volume grows.

The Feedback Loop Has a Natural Brake

The article's most powerful rhetorical device is the claim that the Intelligence Displacement Spiral has "no natural brake." This is the critical assertion on which the entire doom scenario depends, and it is the assertion most directly challenged by Jevons Paradox.

The natural brake is price-driven demand expansion. As AI makes cognitive services cheaper, consumers gain access to goods and services they couldn't previously afford. This is true even for displaced workers operating at lower income levels. A former product manager earning \$45,000 as an Uber driver cannot afford a human financial advisor, but can access AI-driven financial planning for near zero cost. They cannot afford a human tutor for their children, but can access AI tutoring. They cannot afford custom software to start a small business, but can build an application using AI tools. The consumption basket shifts: less spending on expensive human-mediated services, more consumption of cheap AI-mediated services that were previously unattainable.

This doesn't make the individual worse off on net; it partially offsets the income decline through dramatically lower cost of living for intelligence-intensive services. The article's "Ghost GDP" concept (output that shows up in national accounts but doesn't circulate through the real economy) assumes that the efficiency gains accrue entirely to capital owners. But the article itself documents intense competition. Dozens of vibe-coded delivery startups competing for share. Agentic shoppers forcing prices down across every category. Stablecoin payment rails bypassing card interchange fees. In competitive markets, efficiency gains don't stay with producers; they flow to consumers through lower prices. That flow is the transmission mechanism through which Jevons effects operate, and the article describes it vividly while somehow not recognizing it as a countervailing force.

The OpEx Substitution Framing Conceals the Demand Side

The article makes an astute observation that AI investment increased even as the economy contracted, because companies were substituting AI OpEx for labor OpEx. A company spending \$100M on employees and \$5M on AI shifts to \$70M on employees and \$20M on AI, so total spending falls while AI spending rises. This explains why the AI infrastructure complex continued performing even as the broader economy deteriorated.

This is a credible supply-side analysis. But it omits the demand-side consequence. If a company produces the same output with fewer workers at lower total cost, competitive pressure pushes the price of that output down. Falling prices expand the addressable market. A SaaS product that cost \$500,000 annually and was affordable only to the Fortune 500 now costs \$50,000 and is accessible to mid-market companies. A consulting engagement that cost \$2 million and was reserved for large enterprises now costs \$200,000 and is available to growth-stage companies. The total number of transactions can grow even as per-transaction revenue falls.

The article models a world where output stays constant, prices stay constant, costs drop, and the entire surplus accrues to shareholders. In practice, the intense competition the article itself describes (incumbents in knife-fights with each other and with upstart challengers) is precisely the mechanism that prevents this. Competition distributes efficiency gains through lower prices, and lower prices expand markets.

The Intelligence Premium Unwind Is Also a Jevons Story

The article's most compelling framing is that human intelligence has been the scarce input in the economy for all of modern history, and AI is unwinding that premium. Every institution (the labor market, mortgage underwriting, the tax code) was designed for a world where human cognition was expensive and irreplaceable. As AI makes intelligence abundant, these institutions crack.

Jevons Paradox applied to this framing produces a different conclusion. When intelligence becomes abundant and cheap, the economy doesn't just produce the same cognitive output more efficiently; it restructures around consuming vastly more intelligence. We don't merely replicate the existing quantity of analysis, decisions, creative output, and coordination at lower cost. We produce orders of magnitude more of it.

The article's own data point supports this: by March 2027 in their scenario, the median American was consuming 400,000 tokens per day, a 10x increase from the end of 2026. The article cites this as evidence of disruption, but it is fundamentally a Jevons data point. People are consuming more intelligence, not less. That consumption drives economic activity; someone is building the products and services that consume those tokens, maintaining the infrastructure, curating quality, arbitrating edge cases, and inventing new applications.

The question is whether that new economic activity employs enough people at high enough wages to offset the displacement. The article assumes it doesn't. History suggests it tends to, though the transition period can be painful and the new employment categories often look nothing like the old ones.

The GDP Composition Argument Cuts Both Ways

The article makes much of the fact that 70% of US GDP is consumer spending, and that white-collar workers drive a disproportionate share of that spending. When those workers lose income, the consumption base collapses, and GDP follows. This is mechanically sound as far as it goes.

But Jevons Paradox suggests that the composition of GDP shifts during efficiency revolutions, not just the level. When agricultural mechanization displaced 90% of farm workers over the course of a century, it did not produce a permanent 90% unemployment rate. GDP restructured around manufacturing and services, categories that were economically marginal when most human labor was occupied with food production. The displaced agricultural workers didn't return to farming. They moved into an economy where cheap food freed up income and labor for other activities.

The analogous question for AI is: when cognitive labor becomes cheap, what does the economy restructure around? The Citrini piece doesn't attempt to answer this, which is understandable, since predicting the specific industries of the future is a fool's errand. But the pattern is well-established. Cheap food led to a manufacturing economy. Cheap manufacturing led to a services economy. Cheap cognitive services leads to something else. The article's scenario assumes the chain terminates with "cheap cognitive services leads to nothing," which is historically unprecedented.

One plausible direction: the economy shifts toward activities where physical presence, human trust, and embodied experience carry a premium precisely because cognitive tasks are commoditized. Healthcare delivery (not diagnosis, but care), skilled trades, experiential services, community-oriented businesses, and creative work that is valued specifically for its human origin. These are not futuristic speculations; they are existing sectors where human presence is intrinsic to the value proposition. As AI deflates the cost of cognitive services, the relative value of irreducibly human activities increases, and spending may shift toward them.

Another direction, potentially larger: entirely new categories of economic activity that we cannot yet name, because they only become viable when intelligence is cheap and abundant. The internet didn't just make existing activities more efficient; it created social media, the gig economy, e-commerce logistics, content creation as a profession, and cloud computing as an industry. None of these were predicted in advance. The equivalent AI-native industries may already be emerging in nascent form, invisible to a GDP accounting framework built for the prior economic structure.

Where the Speed Concern Is Legitimate

The strongest element of the Citrini scenario is the speed argument. Prior Jevons cycles unfolded over decades, long enough for institutions, education systems, and labor markets to adapt. The article's timeline compresses displacement into roughly 18-24 months, far faster than the demand-expansion side can respond.

This is a legitimate concern, and it's where the Jevons counter-argument is weakest. If displacement is fast and demand expansion is slow, the interim period can be genuinely severe, even if the long-run equilibrium is positive. Policy response, education, and institutional adaptation all operate on timescales measured in years, not quarters.

However, the article makes an asymmetric assumption on this point. It models disruption happening at AI speed: step-function capability jumps, immediate corporate adoption, rapid layoff cycles. But it models demand expansion as essentially static, only emerging when government intervention eventually arrives. This ignores that entrepreneurial response to dramatically cheaper inputs has historically been fast. The smartphone created a trillion-dollar app economy in under five years. Cloud computing spawned tens of thousands of SaaS companies within a decade. When a critical input becomes 100x cheaper, entrepreneurs move quickly to build products that exploit the new cost structure, because the profit opportunity is enormous.

The article's scenario includes dozens of vibe-coded delivery startups appearing rapidly, which is itself evidence of fast entrepreneurial response to cheaper intelligence. It just doesn't extend that observation to other sectors.

Where the Counter-Argument Must Be Honest

Jevons Paradox is not a universal law. It describes a tendency (a strong historical pattern) not an iron guarantee. The Citrini piece's most potent rebuttal is that prior Jevons cycles involved specific resource inputs (coal, compute, bandwidth, lighting), while AI targets the general-purpose input of intelligence itself. If AI can perform not only existing cognitive tasks but also the new tasks that would emerge from demand expansion, then the rebound effect could be muted or eliminated entirely. A coal-fired loom couldn't design fashion or run a retail chain. But an AI that can code, analyze, write, plan, and reason might well be capable of staffing the very industries that Jevons expansion would create.

This is a genuine uncertainty, and intellectual honesty requires acknowledging it. The question reduces to whether human judgment, taste, coordination, creativity, physical presence, and social trust constitute a durable residual demand (activities where humans remain preferred or necessary even when AI is technically capable) or whether those too get absorbed over time. The honest answer is that we don't know.

What we do know is that the historical base rate strongly favors Jevons over the doom loop. Every prior prediction that a general-purpose technology would produce permanent mass unemployment (mechanized agriculture, factory automation, computerization, the internet) has been wrong, and wrong for the same reason: the predictions modeled displacement without modeling demand expansion. The Citrini piece, for all its sophistication, repeats that analytical pattern.

The Bottom Line

The Citrini piece is worth reading as a risk scenario. The transitional pain it describes is plausible, and portfolio construction should account for it. But as a base case for the future of the economy, it requires assuming that the most consistent empirical pattern in economic history (that radically cheaper inputs generate demand that exceeds displacement) has finally broken. That's a bet against a very long track record.

For more on the mechanics of Jevons Paradox and how it has played out across the semiconductor industry from vacuum tubes to modern AI accelerators, see my earlier piece: Jevons Paradox and the Semiconductor Industry.

The Paradox of Cheap Compute

A.C. Jokela — Sat, 03 Jan 2026 16:00:00 GMT

In 1961, if you wanted to perform one billion floating-point calculations per second (one gigaflop), you would have needed to spend approximately \$18.7 billion. Today, that same computational power costs about two cents. That's not a typo. The cost of compute has fallen by a factor of nearly one trillion over sixty years.

A floating-point operation is simply a mathematical calculation involving numbers with decimal points, the kind of math that powers everything from spreadsheets to video games to weather simulations. When your computer renders a 3D scene, calculates a mortgage payment, or trains an AI model, it's performing millions or billions of these operations every second. The "FLOP" has become the standard yardstick for measuring computational power, and tracking its cost over time reveals one of the most dramatic price collapses in economic history.

You might expect that as something becomes a trillion times cheaper, we'd use less of it. After all, we don't need as much anymore, right? But that's not what happened. Not even close.

Instead, humanity's consumption of computational power has exploded beyond anything the pioneers of computing could have imagined. We went from a world where only governments and the largest corporations could afford to compute, to a world where the phone in your pocket contains more processing power than all the computers that existed in 1960 combined, and we still want more.

This phenomenon has a name: Jevons' Paradox.

The Coal Question

In 1865, the English economist William Stanley Jevons published The Coal Question, in which he made a counterintuitive observation. As steam engines became more efficient at converting coal to useful work, coal consumption didn't decrease; it increased. Dramatically.

Jevons' reasoning was elegant: when something becomes more efficient, it becomes more economical. When it becomes more economical, people use it for more things. New applications emerge that weren't feasible before. The efficiency gains are swamped by the explosion in demand.

"It is wholly a confusion of ideas to suppose that the economical use of fuel is equivalent to a diminished consumption," Jevons wrote. "The very contrary is the truth."

What Jevons observed about coal in the 19th century applies with uncanny precision to computation in the 20th and 21st centuries. Every order of magnitude drop in the cost of compute has triggered an explosion in what we use it for, from calculating artillery trajectories to streaming video, from running payroll to training artificial intelligence.

Let's trace this paradox through the history of computing.

The Era of Scarcity: 1960s-1970s

The first electronic computers were, quite literally, priceless, not because they were invaluable, but because there was no market for them. ENIAC, completed in 1945, cost about \$400,000 (roughly \$7 million in today's dollars) and consumed 150 kilowatts of power. It was built to calculate artillery firing tables for the U.S. Army, and it remained in military hands.

By the early 1960s, commercial computing had arrived, but it remained extraordinarily expensive. The IBM System/360, announced in 1964, represented IBM's famous "\$5 billion gamble," the largest privately funded commercial project in history at that time. The smallest System/360 Model 30 rented for \$2,700 to \$20,000 per month; more powerful configurations could cost \$115,000 monthly.

At these prices, computing was rationed. Universities developed time-sharing systems that allowed dozens of users to share a single machine, each getting small slices of processor time. Programmers submitted jobs on punch cards and waited hours, sometimes days, for results. Computing cycles were tracked and allocated like a precious resource.

The machines themselves were monuments to computational scarcity. A computer room required raised floors for cooling ducts, dedicated electrical systems, and climate control. The IBM 7090, the fastest computer of the early 1960s, performed about 100,000 floating-point operations per second and cost millions of dollars. To achieve one gigaflop of performance in 1961, you would have needed to operate roughly 10,000 such machines simultaneously, an impossibility even for governments.

The CDC 6600, designed by Seymour Cray and released in 1964, claimed the title of world's fastest computer with performance of up to 3 megaflops, or three million floating-point operations per second. It cost \$9 million, roughly equivalent to \$90 million today. At that price, a single gigaflop of sustained performance would have cost \$3 billion. Only a handful of institutions could afford one: national laboratories, major research universities, and aerospace companies working on space programs and defense contracts.

Yet beneath the surface, miniaturization was beginning its relentless march. The transistor, invented at Bell Labs in 1947, had replaced vacuum tubes. In 1958, Jack Kilby at Texas Instruments and Robert Noyce at Fairchild Semiconductor independently invented the integrated circuit, putting multiple transistors on a single chip. In 1965, Gordon Moore made his famous observation: the number of transistors on an integrated circuit was doubling roughly every two years.

The implications were staggering. If transistor density determined computing power, and density was doubling every two years while costs remained roughly constant, then computing was about to become very, very cheap.

The Microcomputer Revolution: Late 1970s

The microprocessor changed everything. Intel's 4004, released in 1971, put an entire CPU on a single chip. Its successors (the 8008, 8080, and eventually the 8086) brought enough processing power to enable a new category of machine: the personal computer.

In 1977, the trinity of the Apple II, Commodore PET, and TRS-80 brought computing to the home. These machines cost between \$600 and \$1,300, expensive, but within reach of middle-class families. For the first time, ordinary people could own a computer.

The Apple II is a useful marker of the era's economics. Priced at \$1,298 for a base configuration, it offered roughly 0.5 MIPS (million instructions per second). By our gigaflop metric, that works out to roughly \$100 million per GFLOP, still astronomical, but already three orders of magnitude cheaper than the mainframe era.

This first Jevons moment transformed computing. When you had to rent time on a shared mainframe, you used it for serious business: scientific calculations, financial modeling, database management. But when you owned the machine outright, you could use it for anything.

VisiCalc, released in 1979 for the Apple II, demonstrated the power of cheap ownership. Dan Bricklin and Bob Frankston created the first spreadsheet program, a concept that simply didn't exist before. Accountants and business planners who would never have rented mainframe time bought Apple IIs specifically to run VisiCalc. The software created its own demand, and that demand consumed the newly affordable compute.

This pattern, the "killer app" that justifies hardware purchases and consumes available resources, would repeat throughout computing history. Games appeared immediately. Atari and Commodore built empires on entertainment software. Educational programs promised to teach children everything from typing to calculus. Each application justified the purchase of hardware, and each new user created demand for more software.

New applications emerged that no one had anticipated. Hobbyists wrote software for fun. Children learned programming. Bulletin board systems connected users over phone lines, creating the first online communities, the proto-internet. Word processing moved from dedicated Wang machines to general-purpose computers, democratizing document creation.

The machines were also shrinking. The Apple II contained about 14,000 transistors and fit on a desktop. The mainframes it aspired to replace filled rooms. This miniaturization wasn't just about convenience; it was about cost. Smaller meant cheaper to manufacture, cheaper to ship, cheaper to operate.

The IBM PC and the Clone Wars: 1980s

When IBM entered the personal computer market in 1981, it conferred legitimacy on an industry that many had dismissed as a hobbyist toy. The IBM PC wasn't technically superior to its competitors, but it carried the IBM name, and in corporate America, "nobody ever got fired for buying IBM."

More importantly, IBM made a fateful decision: it published the technical specifications of the PC and used off-the-shelf components. This openness, unusual for IBM, enabled an explosion of compatible clones. Compaq, Dell, and dozens of others built machines that ran the same software as the IBM PC, and competition drove prices down relentlessly.

The result was the second Jevons moment. When only IBM made PCs, prices stayed high. When everyone could make PCs, prices collapsed. By the end of the decade, a capable PC could be had for under \$1,000.

The Intel 80386, released in 1985, was the first mass-market 32-bit processor. It could address 4 gigabytes of memory, far more than anyone could afford to install at the time, and ran at up to 33 MHz. By 1990, a 386-based PC cost roughly \$2,000-3,000 and delivered performance that would have cost millions a decade earlier. The cost per GFLOP had fallen to roughly \$1 million.

Corporations responded to falling prices by putting a computer on every desk. In 1980, the concept of "one computer per worker" was absurd. By 1990, it was becoming standard practice in white-collar industries. Personal computing had become business computing.

The software industry exploded to match. Microsoft, founded in 1975, grew from a startup to a behemoth. Desktop publishing, computer-aided design, databases, and networking all found mass markets. Each application consumed the cheaper compute and demanded more.

The Internet Era: 1990s-2000s

The 1990s brought the "megahertz wars" between Intel and AMD. Clock speeds climbed from 25 MHz to 100 MHz to 500 MHz and beyond. Each generation brought not just speed but integration: math coprocessors, cache memory, and eventually multiple cores all moved onto the main processor die.

In 1997, Intel's ASCI Red at Sandia National Laboratories became the first computer to achieve one teraflop, one trillion floating-point operations per second. It cost \$55 million and consumed 850 kilowatts of power. The cost per GFLOP had fallen to roughly \$30,000.

But the real story of the 1990s wasn't the supercomputers; it was the network connecting all the ordinary ones. The World Wide Web, invented by Tim Berners-Lee in 1989, went mainstream in the mid-1990s. Suddenly every connected computer could communicate with every other.

This was the third Jevons moment. The internet didn't just use computing resources; it multiplied the uses for them. Email replaced letters. Websites replaced catalogs. Search engines made information universally accessible. E-commerce created entirely new markets.

Each of these applications consumed compute at both ends of the connection. A web server needed processing power. So did the browser displaying the page. Multiply by millions of users, and the aggregate demand for computing grew exponentially even as the cost per unit plunged.

By 2000, a capable desktop PC cost around \$1,000 and delivered roughly 1 GFLOP of performance. The cost per GFLOP had crossed below \$1,000. The entire computing power of ASCI Red, the world's fastest supercomputer just three years earlier, now cost less than \$100 million in commodity hardware.

By 2010, the cost had fallen to roughly \$1 per GFLOP. Smartphones had arrived, putting general-purpose computers in billions of pockets worldwide. Each one streamed video, played games, ran apps, and synced to cloud services, all consuming compute at unprecedented scales.

GPUs and the AI Explosion: 2010s-Present

While CPUs followed Moore's Law in a measured march, graphics processing units took a different path. GPUs were originally designed for one task: rendering pixels for video games. This required performing the same mathematical operations on thousands of data points simultaneously: massively parallel computation.

In 2007, NVIDIA released CUDA (Compute Unified Device Architecture), which allowed programmers to use GPUs for general-purpose computing. What had been a gaming component became a scientific instrument. Tasks that were computationally intractable on CPUs became feasible on GPUs.

The cost per GFLOP for GPU computation fell to roughly \$48 in 2007. By 2013, it was \$0.12. By 2017, it was \$0.03. Today, it hovers around \$0.02.

This unleashed the fourth, and most dramatic, Jevons moment: artificial intelligence.

Neural networks had existed since the 1950s. The theory was understood. What was missing was compute. Training a neural network requires performing billions or trillions of mathematical operations. At 1990s prices, training a modern large language model would have cost more than the entire GDP of most countries.

But at 2020s prices, it became merely expensive rather than impossible. OpenAI's GPT-3, released in 2020, was trained using approximately 3,640 petaflop-days of compute, roughly the equivalent of running 10,000 high-end GPUs for 14 days straight. By one estimate, the compute for training cost around \$4.6 million.

That sounds like a lot, but consider what that buys: a system that can write essays, answer questions, generate code, and engage in conversation. Just thirty years earlier, the same computation would have cost trillions of dollars, more than the entire world economy.

The AI industry responded to cheap compute exactly as Jevons would have predicted: by consuming vastly more of it. GPT-4 reportedly used 10-100 times more compute than GPT-3. Each generation of models grows larger. Each company trains more models. Each application uses more inference.

Training is only half the story. Every time someone asks ChatGPT a question or generates an image with Midjourney, that's "inference," running the trained model to produce output. A single trained model might serve millions of users, each query consuming GPU cycles. The aggregate inference compute now exceeds training compute by orders of magnitude.

NVIDIA, the primary supplier of AI training hardware, saw its market capitalization rise from \$150 billion in early 2023 to over \$3 trillion by late 2024. The company couldn't manufacture GPUs fast enough to meet demand. Datacenters expanded. Power grids strained under the load. Microsoft, Google, and Amazon raced to build facilities that consume as much electricity as small cities, all to serve the insatiable demand for AI computation.

The physical infrastructure tells the story. A modern AI datacenter requires megawatts of power and sophisticated cooling systems. Server racks packed with GPUs generate heat densities that would have been unimaginable a decade ago. Companies are exploring nuclear power plants, offshore platforms, and even orbital datacenters to feed the demand.

The cost of compute had fallen by twelve orders of magnitude, and humanity's total spending on compute had never been higher.

The Paradox in Numbers

Let's put some numbers to this paradox:

Year	Cost per GFLOP	Approximate Global Computing Capacity
1961	\$18,672,000,000	~10 GFLOPS (total)
1984	\$18,750,000	~100 GFLOPS
1997	\$30,000	~100 TFLOPS
2007	\$48	~1 PFLOPS
2017	\$0.03	~1 EFLOPS
2023	\$0.02	~10+ EFLOPS

The cost fell by a factor of nearly one trillion. The total capacity grew by a factor of at least one trillion. We didn't save any money; we spent it all on more computation.

This is Jevons' Paradox in its purest form. Efficiency gains don't reduce consumption; they enable it. The cheaper compute becomes, the more uses we find for it, until we've consumed every efficiency gain and then some.

Miniaturization: The Engine of the Paradox

Underlying this entire history is miniaturization, the relentless shrinking of transistors that drives both efficiency gains and cost reductions.

In 1971, Intel's 4004 contained 2,300 transistors on a chip fabricated with a 10-micrometer process. Today, Apple's M-series chips contain over 100 billion transistors fabricated at 3 nanometers, more than 3,000 times smaller. Each generation of shrinkage brings more transistors per dollar, more operations per watt, and more capability per cubic centimeter.

This shrinkage is why your smartphone is more powerful than the supercomputers of the 1990s. It's why a \$500 graphics card can train machine learning models that would have required national laboratories thirty years ago. And it's why the economics of computing have followed Jevons' prediction so precisely: smaller transistors mean cheaper computation, and cheaper computation means more computation.

The industry euphemistically calls the end of Moore's Law, the point where further shrinkage becomes physically or economically impractical, "the wall." Various experts have predicted its arrival for decades. Yet the wall keeps receding. New techniques (multi-chip packages, 3D stacking, specialized accelerators) continue to deliver more compute per dollar even as individual transistor shrinkage slows.

What Comes Next?

If history is any guide, the future holds more of the same: continued cost reduction, continued demand growth, and continued surprise at what becomes possible.

Quantum computing looms on the horizon, promising exponential speedups for certain problems. If quantum computers become practical and affordable, they will trigger another Jevons moment. Problems that are currently intractable (drug discovery, materials science, cryptography) will become computable. New applications will emerge. Demand will explode.

Some argue that AI itself represents a new kind of computing, one that produces not calculations but intelligence. If artificial general intelligence arrives, it may consume computational resources at scales we can barely imagine, with each AI agent requiring the equivalent of human-brain-level compute, running continuously, at massive scale.

The pattern is remarkably consistent. In 1965, computing was so expensive that only mission-critical calculations justified the cost. In 1985, it was cheap enough for word processing and spreadsheets. In 2005, it was cheap enough for social media and video streaming. In 2025, it's cheap enough to generate human-like text and photorealistic images on demand.

At each stage, we found new uses for the cheaper compute. At each stage, we consumed more total computation than before. At each stage, we spent more money on computing even as the cost per unit plummeted.

This is not a failure of planning or a lack of conservation. It is the predictable outcome of making something useful cheaper. The more valuable computation becomes per dollar, the more dollars we are willing to spend on it.

Jevons would not be surprised. "It is the very economy of its use," he wrote of coal, "which leads to its extensive consumption."

The same is true of compute. We have made it cheap beyond the wildest dreams of the 1960s pioneers, and we have consumed every bit of savings in an insatiable hunger for more.

The paradox endures.

Data sources: AI Impacts, Human Progress, Epoch AI, and historical hardware records.

Jevons Paradox

A.C. Jokela — Tue, 15 Apr 2025 23:23:01 GMT

The Jevons Paradox, a concept coined by economist William Stanley Jevons in the 19th century, describes a seemingly counterintuitive phenomenon where improvements in energy efficiency lead to increased energy consumption, rather than decreased consumption as might be expected. At first glance, this idea may seem outdated, a relic of a bygone era when coal was the primary source of energy. However, the Jevons Paradox remains remarkably relevant in today's technology-driven world, where energy efficiency is a key driver of innovation. As we continue to push the boundaries of technological progress, the Jevons Paradox has been repeatedly demonstrated in various industries, from transportation to computing. In the semiconductor industry, in particular, the Jevons Paradox has had significant impacts on energy consumption and technological progress, shaping the course of modern computing and driving the development of new applications and industries. The Jevons Paradox, first observed in the 19th century, has been repeatedly demonstrated in various industries, including the semiconductor industry, where it has had significant impacts on energy consumption and technological progress.

William Stanley Jevons was born on September 1, 1835, in Liverpool, England, to a family of iron merchants. He was educated at University College London, where he developed a strong interest in mathematics and economics. After completing his studies, Jevons worked as a chemist and assayer in Australia, where he began to develop his thoughts on economics and logic. Upon his return to England, Jevons became a lecturer in economics and logic at Owens College, Manchester, and later, a professor at University College London. As an economist, Jevons was known for his work on the theory of value and his critiques of classical economics. One of his most significant contributions, however, was his work on the coal industry, which was a critical component of the British economy during the 19th century. In his 1865 book, The Coal Question, Jevons examined the long-term sustainability of Britain's coal reserves and the implications of increasing coal consumption. Through his research, Jevons observed that improvements in energy efficiency, such as those achieved through the development of more efficient steam engines, did not lead to decreased coal consumption. Instead, he found that increased efficiency led to increased demand for coal, as it became more economical to use. This insight, which would later become known as the Jevons Paradox, challenged the conventional wisdom that energy efficiency improvements would necessarily lead to reduced energy consumption. Jevons' work on the coal industry and the Jevons Paradox continues to be relevant today, as we grapple with the energy implications of technological progress in various industries.

The Jevons Paradox, as observed by William Stanley Jevons in his 1865 book The Coal Question, describes the phenomenon where improvements in energy efficiency lead to increased energy consumption, rather than decreased consumption as might be expected. Jevons' original observations on the coal industry serve as a classic case study for this paradox. At the time, the British coal industry was undergoing significant changes, with the introduction of more efficient steam engines and other technological innovations. While these improvements reduced the amount of coal required to produce a given amount of energy, Jevons observed that they also led to increased demand for coal. As coal became more efficient and cheaper to use, it became more economical to use it for a wider range of applications, from powering textile mills to driving locomotives. This, in turn, led to increased energy consumption, as coal was used to fuel new industries and economic growth. Jevons' observations challenged the conventional wisdom that energy efficiency improvements would necessarily lead to reduced energy consumption. Instead, he argued that increased efficiency could lead to increased demand, as energy became more affordable and accessible. The underlying causes of the Jevons Paradox are complex and multifaceted. Economic growth, for example, plays a significant role, as increased energy efficiency can lead to increased economic output, which in turn drives up energy demand. Technological progress is also a key factor, as new technologies and applications become possible with improved energy efficiency. Changes in consumer behavior also contribute to the Jevons Paradox, as energy becomes more affordable and accessible, leading to increased consumption. Furthermore, the rebound effect, where energy savings from efficiency improvements are offset by increased energy consumption elsewhere, also plays a role. For instance, if a more efficient steam engine reduces the cost of operating a textile mill, the mill owner may choose to increase production, leading to increased energy consumption. The Jevons Paradox highlights the complex and often counterintuitive nature of energy consumption, and its relevance extends far beyond the coal industry, to various sectors, including the semiconductor industry, where it continues to shape our understanding of the relationship between energy efficiency and consumption.

The invention of the transistor in 1947 revolutionized the field of electronics and paved the way for the development of modern computing. The transistor, which replaced the vacuum tube, offered significant improvements in energy efficiency, reliability, and miniaturization. The reduced power consumption and increased reliability of transistors enabled the creation of smaller, faster, and more complex computing systems. As transistors became more widely available, they were used to build the first commercial computers, such as the UNIVAC I and the IBM 701. These early computers were massive, often occupying entire rooms, and were primarily used for scientific and business applications. However, as transistor technology improved, computers became smaller, more affordable, and more widely available. The improved energy efficiency of transistors led to increased demand for computing, as it became more economical to use computers for a wider range of applications. This exemplifies the Jevons Paradox, where improvements in energy efficiency lead to increased energy consumption. In the case of transistors, the reduced power consumption and increased reliability enabled the development of more complex and powerful computing systems, which in turn drove up demand for computing. The early computing industry, which emerged in the 1950s and 1960s, was characterized by the development of mainframes and minicomputers. Mainframes, such as those produced by IBM, were large, powerful computers used by governments, corporations, and financial institutions for critical applications. Minicomputers, such as those produced by Digital Equipment Corporation (DEC), were smaller and more affordable, making them accessible to a wider range of customers, including small businesses and research institutions. The growth of the mainframe and minicomputer markets drove the demand for semiconductors, including transistors and later, integrated circuits. As the semiconductor industry developed, it became clear that the Jevons Paradox was at play. The improved energy efficiency of transistors and later, integrated circuits, led to increased demand for computing, which in turn drove up energy consumption. The development of the microprocessor, which integrated all the components of a computer onto a single chip, further accelerated this trend. The microprocessor, introduced in the early 1970s, enabled the creation of personal computers, which would go on to revolutionize the computing industry and further exemplify the Jevons Paradox. The early computing industry, driven by the transistor and later, the microprocessor, laid the foundation for the modern computing landscape, where energy consumption continues to be a major concern. As the semiconductor industry continues to evolve, understanding the Jevons Paradox remains crucial for predicting and managing the energy implications of emerging technologies.

The personal computer revolution of the 1980s had a profound impact on the semiconductor industry, driving growth and transforming the way people worked, communicated, and entertained themselves. The introduction of affordable, user-friendly personal computers, such as the Apple II and the IBM PC, brought computing power to the masses, democratizing access to technology and creating new markets. As personal computers became more widespread, the demand for semiconductors, particularly microprocessors, skyrocketed. The microprocessor, which had been introduced in the early 1970s, was the brain of the personal computer, integrating all the components of a computer onto a single chip. The improved energy efficiency of microprocessors, combined with their increased processing power, enabled the development of more capable and affordable personal computers. This, in turn, led to increased demand for PCs, as they became more suitable for a wider range of applications, from word processing and spreadsheets to gaming and graphics design. The Jevons Paradox was evident in the personal computer revolution, as the increased energy efficiency of PCs led to increased demand, driving growth in the semiconductor industry. As PCs became more energy-efficient, they became more affordable and accessible, leading to increased adoption in homes, schools, and businesses. This, in turn, drove up energy consumption, as more PCs were used for longer periods, and new applications and industries emerged that relied on PC technology. The microprocessor played a key role in this growth, enabling the development of new applications and industries that relied on PCs. For example, the introduction of the Intel 80386 microprocessor in 1985 enabled the creation of more powerful PCs, which in turn drove the development of new software applications, such as graphical user interfaces and multimedia software. The growth of the PC industry also led to the emergence of new industries, such as the software industry, which developed applications and operating systems that ran on PCs. The PC industry also spawned new businesses, such as PC manufacturing, distribution, and retail, which further accelerated the growth of the semiconductor industry. As the PC industry continued to evolve, the Jevons Paradox remained at play, with each new generation of microprocessors and PCs offering improved energy efficiency, but also driving increased demand and energy consumption. The personal computer revolution of the 1980s demonstrated the Jevons Paradox in action, highlighting the complex and often counterintuitive relationship between energy efficiency and consumption.

The development of Graphics Processing Units (GPUs) has been a significant factor in the evolution of modern computing, with GPUs becoming increasingly important for a wide range of applications, from gaming and graphics rendering to artificial intelligence (AI) and machine learning (ML). Initially designed to accelerate graphics rendering, GPUs have evolved to become highly parallel processing units, capable of handling complex computations and large datasets. The improved energy efficiency of GPUs has been a key driver of their adoption, with modern GPUs offering significantly higher performance per watt than their predecessors. As a result, GPUs have become ubiquitous in modern computing, from consumer-grade gaming PCs to datacenter-scale AI and ML deployments. The Jevons Paradox is evident in the rise of GPUs, as their improved energy efficiency has led to increased demand for AI, ML, and other applications that rely on GPU processing. The increased processing power and energy efficiency of GPUs have enabled the development of more complex AI and ML models, which in turn have driven up demand for GPU processing. This has led to a significant increase in energy consumption, as datacenters and other computing infrastructure have expanded to support the growing demand for AI and ML processing. The impact of the Jevons Paradox on the semiconductor industry in the 2020s is significant, with the growth of datacenter energy consumption being a major concern. As AI and ML workloads continue to grow, the demand for specialized AI hardware, such as GPUs and tensor processing units (TPUs), is expected to continue to increase. This has led to a new wave of innovation in the semiconductor industry, with companies developing specialized hardware and software solutions to support the growing demand for AI and ML processing. The increasing demand for AI and ML processing has also driven the development of new datacenter architectures, such as hyperscale datacenters, which are designed to support the massive computing demands of AI and ML workloads. As the demand for AI and ML processing continues to grow, the Jevons Paradox is likely to remain a significant factor, driving increased energy consumption and pushing the semiconductor industry to develop more efficient and powerful processing solutions.

The Jevons Paradox, first observed by William Stanley Jevons in the 19th century, describes the phenomenon where improvements in energy efficiency lead to increased energy consumption, rather than decreased consumption as might be expected. This paradox has been repeatedly demonstrated in various industries, including the semiconductor industry, where it has had significant impacts on energy consumption and technological progress. Throughout this blog post, we have explored the Jevons Paradox in the context of the semiconductor industry, from the invention of the transistor to the rise of GPUs and AI processing in the 2020s. We have seen how improvements in energy efficiency have driven increased demand for computing, leading to increased energy consumption and the development of new applications and industries. The implications of the Jevons Paradox for future technological progress and energy consumption are significant. As we continue to push the boundaries of technological innovation, it is likely that energy consumption will continue to grow, driven by the increasing demand for computing and the development of new applications and industries. Understanding the Jevons Paradox is crucial in this context, as it highlights the complex and often counterintuitive relationship between energy efficiency and consumption. By recognizing the Jevons Paradox, we can better anticipate and prepare for the energy implications of emerging technologies, and work towards developing more sustainable and energy-efficient solutions. Ultimately, the Jevons Paradox serves as a reminder that technological progress is not a zero-sum game, where energy efficiency gains are directly translated into reduced energy consumption. Rather, it is a complex and dynamic process, where energy efficiency improvements can have far-reaching and often unexpected consequences. By understanding and acknowledging this complexity, we can work towards a more nuanced and effective approach to managing energy consumption and promoting sustainable technological progress.