The promise of liberation, and the reality of heavier work

Every major technological wave arrives with the same hopeful prediction: machines will take over the drudgery, and people will finally gain more free time. That promise accompanied the steam engine, the rise of information technology, and now generative AI. Yet history keeps producing a harsher pattern. Higher efficiency rarely leads to a matching reduction in labor. More often, it rearranges work, intensifies it, and pushes the burden into new forms.

That contradiction is especially visible in software development. AI tools can undeniably shorten the time spent writing code, drafting documentation, or handling repetitive tasks. But many developers are discovering that this does not make the job lighter. It often makes it more complex, more mentally draining, and in the end, longer.

To understand why, it helps to look at two older ideas: Jevons Paradox from economics, and the Red Queen Hypothesis from evolutionary theory. Together, they explain why a tool that improves productivity can still leave workers more tired than before.

The three contradictions at the center of AI productivity

1. Efficiency rises, but so do expectations

Generative AI performs well in programming assistance, document generation, and administrative support. But the time it saves does not automatically return to workers as rest. Organizations tend to absorb the extra capacity immediately. Once output becomes easier, the expected amount of output increases.

This is often described as capacity absorption: the time saved by technology is quickly filled with new work. Instead of reducing the workload, efficiency creates room for additional tasks, tighter schedules, or broader project scope.

If a task that once took an hour now takes five minutes, the remaining fifty-five minutes are rarely treated as earned breathing room. They are treated as available capacity.

2. The job shifts from creating to auditing

AI tools do not simply speed up existing work; they change the nature of the work itself. In software development, many engineers are moving from being code writers to being reviewers of machine-generated logic.

The physical effort may decline. The cognitive burden often does not. In many cases it increases.

Reading, validating, and debugging AI-generated code can be more exhausting than writing code from scratch. Machine output often sounds highly confident even when its logic is flawed. That confidence masks subtle errors, and the cost of finding them later can become much higher than the time originally saved.

This creates a strange inversion: less typing, more vigilance.

3. Once everyone gets faster, nobody gets relief

When AI becomes standard across an industry, productivity improvements stop being an individual advantage and become a baseline requirement. This is where the Red Queen dynamic appears: everyone has to keep running just to stay where they are.

A useful analogy compares this to people standing at a parade. One person standing on tiptoe sees better. But once everyone stands on tiptoe, nobody gains a better view; everyone is simply more uncomfortable.

The same effect shows up in knowledge work:

1. Deadlines shrink. Because AI is fast, managers begin to assume tasks that used to take weeks should now take days.
2. Project scope expands. Once basic implementation becomes cheaper, products accumulate extra features, including nonessential but high-complexity ones.
3. The talent bar rises. Basic coding skill loses value relative to system design, security review, architecture judgment, and cross-functional coordination.

AI does not pause competition. It accelerates the pace at which competition resets its standards.

Why efficiency can intensify labor

Jevons Paradox in the age of code

In 1865, William Stanley Jevons observed something surprising about coal. As steam engines became more efficient, coal use did not fall. It rose. Greater efficiency lowered the effective cost of using steam power, which encouraged broader adoption and expanded total demand.

The same logic applies to AI-assisted software development.

<table> <thead> <tr> <th>Concept</th> <th>19th-century coal industry</th> <th>21st-century software development</th> </tr> </thead> <tbody> <tr> <td>Technological shift</td> <td>More efficient steam engines</td> <td>LLM-based coding assistance</td> </tr> <tr> <td>Efficiency gain</td> <td>Less coal per unit of power</td> <td>Fewer human-hours per feature</td> </tr> <tr> <td>Cost effect</td> <td>Cheaper mechanical power</td> <td>Lower development barrier and cost</td> </tr> <tr> <td>Demand response</td> <td>Expansion of factories, rail, shipping</td> <td>More demand for features, faster iteration, greater complexity</td> </tr> <tr> <td>End result</td> <td>Total coal use increased</td> <td>Total code volume and developer work intensity increase</td> </tr> </tbody> </table>

Jevons Paradox reveals a brutal rule: efficiency does not necessarily reduce demand; it often unlocks more of it.

When writing one API becomes much faster, the natural institutional response is not to let the engineer rest. It is to request more APIs, more integrations, or a larger and more fragile system within the same amount of time.

The Red Queen and the invisible rise in standards

The Red Queen Hypothesis comes from evolutionary thinking, inspired by the line that in some worlds you must run as fast as you can just to remain in place. In biological systems, species are locked in endless competitive adaptation. In the workplace, AI can produce a similar arms race.

Once AI-assisted output becomes normal, individual productivity gains are quickly neutralized by peers using the same tools. Relative advantage disappears, but the pressure remains. The result is a work environment where everyone is expected to do more simply because everyone now can.

That pressure does not only show up in workload. It also reshapes evaluation. Work once considered thoughtful and deliberate may now be judged slow. Time for reflection, recovery, or careful design starts to look like underperformance.

The hidden cost of AI-generated code

One of the strongest arguments against the simplistic "AI saves time" narrative comes from what happens after code is generated.

Comprehension debt

AI-generated code is often syntactically correct while remaining opaque in intent. Teams accept it quickly because it appears competent. But when code enters a system without being deeply understood, it creates a liability that can surface later as maintenance pain.

This can be called comprehension debt: the future cost required to understand, modify, debug, and secure machine-generated code.

Because the developer did not build the logic step by step, their control over the codebase weakens. When subtle defects are buried across thousands of lines of plausible-looking code, they become hard to catch through casual review.

The time saved up front can reappear later with interest.

The “army of juniors” effect

Research has also found recurring architectural weaknesses in AI-generated code. One report examining more than 300 open-source projects identified several common anti-patterns:

<table> <thead> <tr> <th>Anti-pattern</th> <th>Observed rate</th> <th>Effect on work intensity</th> </tr> </thead> <tbody> <tr> <td>Comments everywhere</td> <td>90-100%</td> <td>Adds cognitive noise, obscures actual logic, increases review burden</td> </tr> <tr> <td>By-the-book fixation</td> <td>80-90%</td> <td>Applies textbook patterns mechanically instead of optimizing for context, leading to bloated systems</td> </tr> <tr> <td>Avoidance of refactors</td> <td>80-90%</td> <td>Solves local implementation problems while degrading long-term architecture</td> </tr> <tr> <td>Over-specification</td> <td>80-90%</td> <td>Implements many rare edge cases, enlarging the test surface that must be maintained</td> </tr> </tbody> </table>

The cumulative result is that senior engineers spend more time cleaning up misleading machine output. Instead of focusing on higher-value design or innovation, they become janitors for AI-generated technical debt.

That is not labor elimination. It is labor substitution, often upward onto the most expensive and cognitively burdened workers.

A longer history: technology has never reduced working time by itself

The idea that tools should produce leisure is old. So is the fact that they usually do not unless institutions force the issue.

The Industrial Revolution did not shorten the day on its own

In the late 18th and early 19th centuries, spinning machinery and steam engines greatly increased productive capacity. But factory labor during that period became infamous for brutal conditions, with workers often laboring 14 to 16 hours a day, including children.

The logic was familiar: if machinery made output more efficient, owners wanted workers to spend even more time extracting value from those machines.

Resistance followed. The Luddites, often caricatured as anti-technology, were reacting to displacement, degradation, and alienation under a system that concentrated the gains of mechanization in the hands of capital.

The lesson is clear: without social intervention, productivity gains do not automatically flow to workers.

The eight-hour day was a political achievement

Weekends and the eight-hour day did not emerge because technology benevolently freed people. They were won through long struggle.

• 1817: Robert Owen popularized the slogan, “Eight hours labour, eight hours recreation, eight hours rest.”
• 1856: Building workers in Melbourne won one of the first broadly recognized eight-hour workday victories through organized action, aided by labor scarcity and effective union pressure.
• 1914: Henry Ford introduced the five-day, eight-hour workweek in his factories and significantly raised wages, recognizing that workers also needed time and money to become consumers.
• 1938: The U.S. Fair Labor Standards Act formally established the 40-hour workweek.

The historical pattern is difficult to miss: technological progress may be a necessary condition for shorter work because it creates surplus, but social struggle and legal intervention are what turn possibility into reality.

Is AI liberating workers or tightening control?

The debate is not one-sided. There are serious arguments on both sides.

The optimistic case

Supporters of AI argue that it can remove repetitive work. Boilerplate code, data formatting, routine summaries, and basic documentation can be handled by machines, leaving people to focus on architecture, coordination, and creative problem-solving.

Some research also suggests that AI-assisted workers show greater enthusiasm and lower anxiety in idea generation and complex problem solving. There is also a democratizing argument: AI tools lower technical barriers and allow non-specialists to build useful systems, potentially reducing dependence on large centralized institutions.

A third optimistic claim concerns flexibility. Remote collaboration and asynchronous workflows, strengthened by AI, can theoretically give workers more control over time. Some organizations have used productivity gains to support four-day workweeks without output loss.

The pessimistic case

The darker view is that AI deepens alienation. When workers lose visibility into the processes that produce their outputs, work becomes psychologically thinner and less satisfying. In AI-assisted programming, developers may no longer feel that they truly understand the systems they are responsible for.

There is also the problem of surveillance. AI is not only a productivity tool; it is also a management tool. Automated metrics around code volume, responsiveness, and activity can be inserted into development workflows, shrinking the space for reflection and treating anything not visibly measurable as wasted time.

Finally, overreliance on AI can erode foundational skill. If newer developers stop learning how to trace deep bugs or design efficient algorithms, they may become permanently dependent on machine-generated patterns and bounded by machine assumptions.

What the recent data suggests

The current evidence does not support a simple story of either liberation or disaster. It points instead to a mixed reality in which local speed gains coexist with broader systemic costs.

<table> <thead> <tr> <th>Area</th> <th>Finding</th> <th>Implication</th> </tr> </thead> <tbody> <tr> <td>Development speed</td> <td>Task completion improved by 55% in GitHub research</td> <td>Individual productivity gains are real</td> </tr> <tr> <td>Code volume</td> <td>Duplicate code blocks in repositories increased 10x over the past two years</td> <td>Systems are expanding, and technical debt may be accelerating</td> </tr> <tr> <td>Debugging cost</td> <td>67% of developers reported spending more time debugging AI-generated code</td> <td>Downstream friction can erase upstream speed gains</td> </tr> <tr> <td>Delivery stability</td> <td>Organization-level delivery stability fell by 7.2%</td> <td>Faster individual output can still make systems more fragile</td> </tr> <tr> <td>Perceived work time</td> <td>41% of respondents said new technology made them work longer hours</td> <td>Productivity gains are often converted into longer work</td> </tr> </tbody> </table>

These numbers matter because they challenge the most seductive version of the AI narrative. Faster production at the task level does not guarantee healthier work at the system level.

How to resist the efficiency trap

If AI alone will not produce a shorter workweek, then escaping the trap requires deliberate action at several levels: individual, organizational, and political.

Redefine the developer’s role

The most useful shift may be from code generator to orchestrator.

1. Keep architecture under human control. AI should execute within a structure defined by the engineer, not decide the structure itself.
2. Invest in verification and security skills. In an AI-heavy environment, the ability to audit becomes at least as valuable as the ability to write. Formal verification, static analysis, and AI review platforms can reduce the cost of blind trust.
3. Move toward work that resists automation. Understanding user needs, designing experience flows, reasoning about business trade-offs, and making ethical judgments remain areas where humans outperform systems trained on structured pattern repetition.

Change how organizations use productivity gains

Reducing work hours is an administrative choice, not a natural side effect of better tools.

Organizations that want AI to improve work rather than intensify it need to act intentionally:

• Cut meeting noise. Use AI to summarize meetings, reduce attendance requirements, and protect blocks of deep work.
• Measure outcomes, not output theater. Counting lines of code is especially misleading in the age of machine generation. Business impact and system stability are more meaningful metrics.
• Reinvest saved time in recovery and learning. Continuous acceleration leads to AI fatigue and turnover. Rest is not waste; it is part of sustaining long-term performance.

If AI produces 1,000 lines of code that introduce three bugs, that should not be treated as productivity. It should be treated as a loss.

Rebuild the social contract

History suggests that the final balance cannot be left to market dynamics alone.

1. Collective worker action may return in new forms. Just as other professions have begun negotiating over AI-related rights and compensation, technology workers may need stronger forms of coordination to resist AI-driven overwork and invasive monitoring.
2. A right to disconnect matters. Legal protection against after-hours AI-generated notifications could help prevent work from spilling endlessly into private life.
3. The gains of automation need distribution mechanisms. Whether through shorter legal working hours or broader debates over taxes tied to automation, the surplus created by AI should not flow only to top shareholders while workers absorb the strain.

The real question is not whether AI is powerful

It clearly is. The harder question is who controls the lever, and toward what end.

Right now, AI often functions inside a logic of maximum output. Under that logic, the stress many developers feel—harder competition, painful debugging, rising expectations—is not an accident. It is the contemporary form of an old pattern.

Technology has never arrived with a built-in moral direction. The same tool can help someone finish a day’s work by noon and reclaim the afternoon, or it can be used to demand three times as much work in the same day.

Escaping the cycle requires several acts of clarity:

• recognizing that efficiency alone does not guarantee a better life,
• treating reduced working time as a social goal rather than a technological byproduct,
• and preserving human skepticism when AI delivers answers with unwarranted confidence.

The core challenge of the AI era is not simply how to move faster. It is deciding what is worth doing, what should not be done at all, and when to stop running.