Cory Doctorow has a useful way to talk about AI at work: stop asking whether AI is good or bad in the abstract. Ask who controls it.
In this conversation with Josh Goldberg, Doctorow distinguishes between a worker using a machine and a machine reorganizing the worker. That difference explains why one developer can find AI genuinely helpful while another watches it create technical debt, surveillance, and impossible review workloads.
Centaurs and reverse centaurs
A centaur is a person assisted by a machine. The person still decides what to do, where the tool belongs, and whether its output is good enough.
A reverse centaur is the opposite. The machine sets the pace, and the person becomes its peripheral.
That worker might review generated code, resolve exceptions, correct hallucinations, or take responsibility when an automated system fails. The company cuts staffing, increases volume, and calls the remaining person the “human in the loop.”
Doctorow puts it bluntly: the worker is “not just being used by a machine, but being used up by the machine.”
This is a better framework than arguing about whether AI “works.” The same model can produce two very different workplaces:
- A developer asks it for a first draft of a test and checks the result.
- A developer is measured by generated code volume and buried under changes nobody has time to understand.
- A radiologist uses AI as a second opinion.
- A radiologist is expected to approve a flood of scans after most colleagues have been removed.
The technology may be similar. The allocation of power is not.
Why would a company choose the worse workflow?
We tend to assume that a company will reject automation if it produces a worse product. Doctorow argues that this is often the wrong assumption.
A workflow can be worse for workers and customers while still helping management:
- It lowers the wage bill.
- It increases visible throughput.
- It makes work easier to measure.
- It transfers knowledge from workers into a system controlled by the employer.
- It weakens workers’ ability to decide how the job should be done.
- It pushes failure costs onto customers, contractors, or the public.
Self-checkout is a simple example. Removing cashiers can look efficient in a staffing spreadsheet. The wider system may include more theft, more locked merchandise, longer customer waits, extra security, and public spending on policing. The saving is easy to measure. The new costs are scattered elsewhere.
AI can work the same way. A code generator makes the number of produced lines go up. Review, testing, incident response, security analysis, and long-term maintenance become someone else’s problem.
An inferior workflow is not always a mistake. Sometimes it is a successful transfer of cost and control.
Code generation is not software engineering
Doctorow makes a distinction that gets lost in many AI productivity claims: writing code is only one part of software engineering.
Engineering also includes:
- Understanding the actual problem.
- Deciding what should not be built.
- Reasoning about the larger system.
- Finding ambiguous requirements.
- Reviewing changes.
- Testing failure modes.
- Maintaining old decisions.
- Communicating with everyone affected by the system.
An LLM may make code production faster without making any of those activities faster. If generation accelerates while review capacity stays fixed, the team does not necessarily ship more useful software. It may simply accumulate more code than anyone can properly inspect.
This creates automation blindness. People are bad at watching a mostly correct system for rare failures. High apparent accuracy can make oversight harder, not easier, because reviewers learn to expect the machine to be right.
A “human in the loop” is not a meaningful safeguard when that human has hundreds of outputs to review, little time, and responsibility for every missed error.
Benchmarks do not describe the whole job
Doctorow is skeptical of impressive AI claims that cannot be inspected. His point is not that every benchmark or demonstration is fake. It is that capability, economics, and workplace value are separate questions.
A system might perform a task that normally costs $20,000 while consuming $50,000 in compute. That would be a real technical achievement and a terrible business.
The same caution applies to workplace benchmarks. Before treating a result as proof of productivity, ask:
- What was the baseline?
- Was the whole workflow measured or only generation?
- How much human review was required?
- Were maintenance and technical debt included?
- What happened on unusual inputs?
- Who carried the cost of failures?
- Did the tool reduce work or merely move it?
- Could workers decide when not to use it?
- Was the system tested over enough time to reveal downstream costs?
A benchmark can show that a model completed a selected task. It cannot, by itself, show that the surrounding organization became safer, more productive, or better for workers.
Doctorow’s framing is useful here: “It needn’t be useless to not be true.” A product can do something impressive without supporting every claim made about it.
AI mandates are also management systems
When a company requires AI use, the goal may not be better software. It may be standardization, surveillance, or tighter managerial control.
Workers often hold knowledge that is hard to capture in a dashboard: which shortcuts are dangerous, which customer complaints signal a deeper problem, and when a technically valid answer is wrong for the situation.
A mandated workflow can override that judgment. It can also turn skilled work into exception handling:
- The system produces the normal output.
- The worker handles whatever the system cannot resolve.
- Management uses system metrics to set the pace.
- The worker remains accountable for both machine errors and missed targets.
That is reverse-centaur work. The most frustrating parts stay with the person, while much of their discretion disappears.
This also explains the flood of AI-generated pull requests hitting open-source projects. Generation is cheap, but evaluation is not. A contributor can produce a thousand patches faster than maintainers can carefully reject ten.
Doctorow’s tentative answer is sensible: make the contributor choose one patch, explain why it matters, and work through it. AI assistance can remain part of the process, but it cannot substitute for judgment or transfer unlimited review costs to volunteers.
Worker power is the missing layer
Advice about prompting and personal productivity does not address a workplace where employees cannot choose the workflow.
Doctorow’s answer is collective power. He points developers toward groups such as the Tech Workers Coalition, Tech Solidarity, and workplace unions. His argument is not that organizing is easy. It is that individual leverage disappears quickly when workers are interchangeable and jobs are scarce.
Teams can still establish useful protections before a larger organizing effort succeeds:
- Require worker participation in tool selection.
- Document where AI use is optional or prohibited.
- Measure defects, review time, and maintenance—not generated volume.
- Set limits on automated work entering human queues.
- Protect employees who report unsafe deployments.
- Keep responsibility with the managers who set staffing and throughput targets.
- Give workers a way to stop an automated process when quality falls.
- Negotiate over monitoring, data collection, and model-training use.
The important question is not whether AI belongs at work. It is whether workers have any say in what it does there.
A useful tool should expand human judgment. When it mainly increases pace, monitoring, and liability, the problem is not that the worker needs a better prompt. The problem is power.