The AI Point Elasticity:

Thomas Malthus is usually remembered for a prediction that did not survive the Industrial Revolution: population could grow faster than the resources needed to sustain it.

The more interesting part of the Malthusian argument is the constraint itself.

A system can increase its capacity and still fail to generate proportional improvements in outcomes. Eventually, something limits the return on additional inputs.

Economic development eventually escaped this trap through technological progress, capital accumulation, human capital, and institutional change. Technology did not simply add more resources to the existing system. It changed what the system could do.

AI creates a similar question for software organizations: the constraint is no longer necessarily how much code developers can produce. It may be how much code, information, decisions, and possibilities the organization can absorb.

Let’s think together… 

• Consider a five-person engineering team.
  • Without AI, the team may have enough capacity to explore three approaches to a new product feature.
  • With AI, they might explore fifteen.

  At first, this looks like pure gain, doesn’t it? More alternatives. More experimentation. More speed. But fifteen alternatives also mean fifteen things to evaluate:

  • More generated code means more code to review.
  • More prototypes mean more decisions.
  • More decisions mean more opportunities for disagreement, context switching, and bad choices.

  The constraint has moved.

  This is already visible in research on AI-assisted development. A 2026 longitudinal study of professional software engineers found that developers spent less time on many development tasks, while their work shifted toward verifying, evaluating, and correcting AI output. The researchers describe this emerging category as:

  → supervisory engineering work.

  Another 2026 study found that developers using AI achieved substantially higher task completeness, but also showed a 12.5% decline in their ability to answer technical questions about the code they had produced.

  The pattern is important.

  AI can remove a production bottleneck while creating an absorption bottleneck.

  

This is where the conventional definition of developer productivity becomes inadequate. If productivity means the amount of code produced per hour, AI looks extraordinary. If productivity means business value created per unit of capacity, the equation becomes much harder.

A recent ACM study found that frequent GenAI users reported faster task completion and greater output, but those gains came with increased code-review burden and persistent cognitive effort spent verifying AI-generated work.

This creates a distinction that businesses need to take seriously:

Output is not the same as value.

A team can generate more code and ship more pull requests while simultaneously increasing technical debt, review costs, and system complexity. At some point, the additional capacity stops producing proportional returns. That is diminishing elasticity.

We can express the basic idea simply:

At the beginning of AI adoption, increasing capacity can produce significant improvements. A developer moves faster. A team can experiment more. A product can reach users sooner.

But the curve does not continue upward indefinitely.

As capacity increases, the organization encounters new constraints. Review. Architecture. Product decisions. Security. Coordination. Human attention.

Eventually, additional AI-enabled capacity produces little additional quality.

The system starts paying for capacity it cannot use.

No.

This is where the Malthus analogy becomes more useful. A constraint doesn’t necessarily mean growth has to stop. It can mean that the system needs to change.

The Industrial Revolution did not solve the Malthusian constraint by simply producing more of the same. It changed the relationship between technology, labor, capital, and output.

AI may require the same kind of organizational transition. If developers can produce five times more code, the answer may not be to ask them to produce less.

The objective is not to stay below the elasticity point. The objective is to move it.

This creates an interesting paradox. The point where additional AI capacity starts generating diminishing returns can also become the starting point for innovation.

Why?

Because the constraint tells you something about the system. If developers are spending too much time reviewing AI-generated code, perhaps code review itself needs to be redesigned.

If product teams cannot evaluate how many ideas engineers can generate, perhaps product discovery needs to move faster.

If architecture becomes the bottleneck, perhaps AI should reason about architecture rather than simply generate implementation.

The organization discovers that its old operating model was designed for a different level of productive capacity. That is not necessarily a problem. It can be a signal.

The elasticity point tells you where the old system stops working.

Innovation begins when you redesign the system around the new capacity.

This distinction also mirrors a broader lesson from economic development.

Development is not simply about accumulating more inputs. It is about building the capabilities that let those inputs generate increasingly sophisticated output.

The same principle applies to AI adoption. A company that adds AI tools to an unchanged development process may get an initial productivity boost and then encounter diminishing returns.

A company that changes its processes, skills, and organizational structures around AI can potentially shift the entire curve. This is the difference between AI adoption and AI transformation.

One increases capacity. The other increases the organization’s ability to convert capacity into value.

The AI conversation is still dominated by questions like:

• How many developers can AI replace?
• How much faster can we code?
• How many AI tools should our team use?

Those are useful questions, but they miss the deeper one.

How much AI-enabled capacity can our organization productively absorb?

That is the beginning of AI elasticity. Because AI’s value depends on what happens to quality when you add it. And that relationship is not fixed.

It depends on the developer, the team, the product, the organization, and the systems surrounding them.

The most advanced companies are therefore not necessarily the ones using the most AI.

They will be the ones that understand where additional AI creates leverage, where it creates friction, and what they need to change when the curve starts bending.

That is the problem we will explore next. Because if AI can accelerate software production, there is another scarce resource we need to understand:

the developer’s ability to absorb that acceleration.

• Can AI make a developer ten times faster?
• And if it can, can a human mind actually operate at ten times the speed?

That question takes us from organizational elasticity to cognitive elasticity.