The Speed Limit of the Developer’s Mind:

Suppose a developer spends eight hours building a feature. An AI coding assistant helps reduce the implementation work to two hours. It is tempting to say that AI made the developer four times more productive.

But what happened to the other six hours?

Perhaps they disappeared. Perhaps they were spent reviewing the generated code, testing edge cases, checking assumptions, comparing alternatives, fixing subtle errors, or understanding what the AI actually produced. Or perhaps the developer used the additional time to explore three other approaches to the same problem.

This distinction matters.

Time saved does not necessarily translate into productive capacity gained.

Economic thought has addressed versions of this problem before. Productivity generally concerns the relationship between inputs and outputs, not simply how quickly one activity can be performed.

AI complicates that relationship because it can dramatically reduce the time required for certain tasks while also increasing the number of tasks, possibilities, and decisions available.

Consider a developer working without AI. They might spend four hours implementing a solution and one hour reviewing it.

With AI, the implementation might take one hour. But now the developer has five possible approaches instead of one. The codebase contains more generated components. There are more assumptions to verify. More edge cases to consider.

The developer may still spend an hour reviewing. The difference is that the developer now has much more output to evaluate. AI has increased production velocity. It has not necessarily increased cognitive velocity by the same amount.

This is where Herbert Simon’s concept of bounded rationality becomes relevant.

Simon argued that human decision-making is constrained by limited information, limited cognitive processing capacity, and limited time. Humans therefore do not optimize every decision. They operate within the boundaries of what they can actually process.

Generative AI changes the first part of that equation dramatically.

It can produce more information. More alternatives. More explanations. More code. More possible solutions. But the human constraints remain. This creates an asymmetry:

AI can expand the possibility space faster than humans can evaluate it.

This is not an argument against AI. Quite the opposite. The most valuable use of AI may come from understanding where the human bottleneck actually sits.

A developer does not need to personally produce every line of code, but they do need to understand enough of the system to decide whether the code should exist. They need to know what problem they are solving. They need to distinguish an elegant solution from an unnecessary one. They need to recognize when an apparently correct implementation violates an important assumption. They need to understand the consequences of a technical decision months later.

Those are not simply production tasks. They are judgment tasks. And judgment has a different relationship with time.

Imagine AI makes every implementation task ten times faster; that doesn’t mean the developer becomes ten times faster at everything.

The developer still has to:

This creates a fundamental asymmetry.

The faster AI becomes at generation, the more important human evaluation becomes.

The bottleneck moves from production to judgment.

This is why traditional productivity metrics can become misleading.

Imagine two teams:

• Team A uses AI to reduce a task from eight hours to two.
• Team B uses AI to reduce the same task from eight hours to two, but then uses the remaining six hours to investigate architecture, run experiments, and improve the product.

Both teams achieved the same apparent productivity gain, but their outcomes are completely different: the difference isn’t AI adoption.

It is what the organization does with the capacity AI creates.

This is the same problem we encountered in the first article. Additional capacity only creates value when the surrounding system can absorb it. At the individual level, the surrounding system is partly the human mind, which gives us a second form of elasticity.

We can think of it as the relationship between additional AI-enabled capacity and the quality of human decision-making.

At first, AI can increase cognitive leverage.

• It removes repetitive work.
• It retrieves information.
• It generates alternatives.
• It gives developers more time to think about higher-value problems.

But eventually, the extra output can overwhelm the person responsible for evaluating it. At that point, the marginal benefit declines.

And beyond a certain point, more AI assistance can actually make the work worse. Not because the AI necessarily becomes less capable. Because the human system becomes overloaded.

This creates a strange paradox. 

The faster we make software production, the more important slowing down in the right places may become.

• If writing code takes minutes, understanding whether the code should be written becomes relatively more important.
• If prototyping becomes almost free, deciding which prototypes deserve attention becomes more valuable.
• If AI can generate ten solutions, selecting the right one becomes the scarce activity.
• If implementation becomes abundant, judgment becomes scarce.

This is why the AI transformation of software development cannot be measured only in lines of code, tickets completed, or hours saved. The scarce resource is moving.

When production becomes cheaper, judgment becomes more valuable.

The real speed limit of software development may therefore have very little to do with typing speed. It may be the rate at which a developer can maintain a sufficiently accurate mental model of a complex system while making good decisions.

That rate is not constant. It depends on experience, context, complexity, attention, and the quality of the tools surrounding the developer.

This is also where human capital becomes important. Technology does not eliminate the value of expertise. In some environments, it can increase it.

An experienced developer may use AI effectively because they can quickly recognize bad assumptions, ask better questions, constrain the solution space, and evaluate trade-offs.

A less experienced developer may generate the same amount of code but have a harder time determining whether that code is actually good.

The difference is not simply technical skill. It is the ability to direct and evaluate additional capacity. AI therefore does not necessarily flatten the value of expertise. It can change where expertise matters.

For decades, software organizations asked:

How long does this take to build?

AI encourages a new question:

How much useful work can we do with the same amount of human attention?

That is a much harder metric, because human attention cannot be scaled in the same way as compute. You can add:

• Another model.
• Another agent.
• Another coding assistant.
• Another automated workflow.

You cannot simply add another unit of human judgment to the same developer.

This is the point where our original Elasticity Curve becomes more interesting. The curve is not only about how much capacity an organization can absorb. It is also about how much AI-generated capacity a human can convert into quality.

This gives us the second piece of the framework. In Blog 1, we asked what happens when AI-enabled production capacity grows faster than an organization can absorb.

Now we can ask a more precise question:

What happens when AI-generated possibilities grow faster than a developer can evaluate them?

The answer is not to use less AI. It is to understand where AI should increase human leverage and where it begins to create cognitive overhead.

The objective is not maximum acceleration. It is Productive Acceleration.

That distinction will become increasingly important as AI moves from assistants that generate code to agents that can independently plan, execute, and iterate across entire development workflows. Because once AI can operate with much greater autonomy, the question changes again.

The scarce resource is no longer simply developer time. It becomes the organization’s ability to direct, supervise, and convert AI capacity into economic value. That takes us to the final piece of the series. Because if an individual developer can become more productive, and a software company can reorganize around that productivity, there is a larger question:

What happens when an entire country’s software industry gains that additional capacity?

• Can AI increase not only developers’ productivity, but an economy’s competitive elasticity?
• And can a country like Uruguay turn that additional capacity into more sophisticated software exports, stronger capabilities, and more business with the United States?

That is where AI elasticity moves from the developer’s mind to the economy.