AI Economic Impact: Why Labor Value Persists

The prevailing narrative that LLMs will simply delete millions of jobs misses a critical macroeconomic loop: if AI replaces the worker, it also replaces the consumer. Cory Doctorow’s take on this is a necessary reality check for those of us obsessed with AI workflow optimization. The technical capability of an LLM agent to write a function isn't the same as the economic viability of a world where no one has a salary to buy the software that function powers.

The Productivity Paradox

From a developer's perspective, we see the gains immediately. I can use Claude Code to refactor a legacy module in minutes instead of hours. That is a massive win for individual velocity. However, there is a difference between "efficiency" and "value creation." When we use AI to compress the time it takes to complete a task, the market often responds by simply increasing the volume of work expected or lowering the price of the output.

If we treat AI as a tool for augmentation, we get a productivity boost. If we treat it as a replacement for human judgment, we risk "enshittification"—a term Doctorow uses to describe the decay of digital platforms. In coding, this looks like the proliferation of mediocre, AI-generated boilerplate that no one actually understands, which eventually creates a maintenance nightmare that only a highly skilled (and expensive) human can fix.

Integrating AI without Devaluing the Craft

To avoid the trap of becoming a mere "prompt operator," I've shifted my AI workflow to focus on architectural decisions rather than just code generation. Instead of asking an AI to "write this feature," I use it to stress-test my logic.

Here is a practical approach to using an LLM agent as a peer reviewer rather than a ghostwriter:

# System Prompt for Architectural Review
You are a senior staff engineer. Do not write the code for me. 
Instead, analyze my proposed implementation for:
1. Time and Space Complexity (Big O)
2. Potential edge cases in a distributed system
3. Maintainability and technical debt risks
Challenge my assumptions and provide three alternative patterns 
that could solve this problem more efficiently.

The Real-World Deployment Gap

The gap between a successful demo and a production-ready system is where human labor remains indispensable. An AI can generate a Python script that looks perfect, but it cannot navigate the political landscape of a corporate stakeholders' meeting or understand the nuanced legacy constraints of a 10-year-old database schema.

The danger isn't that the AI is "too smart" to need us, but that companies might mistake the appearance of productivity for actual value. If we optimize for the shortest path to a "working" feature without investing in the human expertise required to sustain it, we aren't innovating; we're just accelerating the rate of technical debt. For those of us building the future, the goal should be leveraging these tools to elevate the ceiling of what we can build, not lowering the floor of what we consider "good enough" work.