The AI vampire: when faster coding creates more work
What the AI vampire means, what the research supports, and how a worked review-budget example helps teams avoid turning faster coding into overload.
The 'AI vampire' describes a risk: faster AI-assisted tasks leave people with more work to judge and less time to recover. Whether time is saved depends on the amount of new work and the effort still needed to check it.
In a simplified example, a team can carefully review four changes a day. Its agents start producing ten. The six extra changes are not finished work: somebody still has to check them, postpone them or say no.
Each proposal in that illustrative example still needs someone to understand the change, resolve unclear requirements and decide whether it is safe to release. A successful code-generation run has completed only part of that work.
The team could leave unnecessary proposals unstarted, make useful changes easier to review or spend longer checking them. Those choices determine whether faster coding creates spare time or a larger workload. Keeping every agent busy is not, by itself, a reason to start another task.
What the AI vampire means#
Steve Yegge described this concern in The AI Vampire, published on 11 February 2026. His argument concerns who benefits from faster work: people may produce more without gaining time back, and spend more of the day on demanding decisions. He also describes the temptation to keep working because AI makes another task feel achievable.
That is a useful warning, not a measured law of productivity. Yegge’s proposed shorter working day is personal advice, not evidence that everybody has the same daily limit. The term describes a possible way of organising work; it does not identify a particular model, an agent architecture or a medical condition.
This article uses that workplace meaning. Its practical question is how a software team can avoid creating more work for people than its automation removes.
Where the work goes#
In the example, automation reduces the time spent producing an implementation. Other work remains: deciding what behaviour is wanted, checking the result against that intention and resolving disagreements about it. Some of that can also be assisted or automated. It should be measured rather than assumed to disappear.
A CHI 2025 study by Hao-Ping Lee and colleagues surveyed 319 knowledge workers. Their accounts described a shift towards verifying information, integrating answers and overseeing tasks. This supports looking at the kind of work that remains. It was a self-report study, not an experiment showing that AI causes exhaustion or permanently reduces people’s ability to think.
For a software team, three separate questions follow. Is each change cheaper to complete? Are more changes being started? Does the resulting day leave people enough room for careful decisions? Improvement in the first does not settle the other two.
A queue of unfinished reviews and a tiring workday are also different problems. A team can keep up by working longer. It can clear the queue by rejecting unnecessary work. Counting the queue alone cannot tell those outcomes apart.
A review-budget example#
Suppose the team has 120 reviewer-minutes available per day. That is a planning assumption for this simplified example, not a recommended working limit. Each change needs 30 minutes of review. The changes are independent and equally demanding, the queue starts empty, and there is no rework.
The team can review four changes: 120 divided by 30. Compare three scenarios under the same time budget:
| Scenario | New changes per day | Reviewed per day | Added to the queue per day |
|---|---|---|---|
| Four proposals, 30 minutes each | 4 | 4 | 0 |
| Ten proposals, 30 minutes each | 10 | 4 | 6 |
| Ten proposals, 15 minutes each | 10 | 8 | 2 |
In the second scenario, five days add 30 unreviewed changes. In the third, better preparation genuinely halves review effort, yet ten changes still arrive faster than eight can be reviewed. Improving one step helps without necessarily solving the whole workload problem.
Try it: change the review budget
This is a queue illustration, not a staffing recommendation. Assume equally sized changes, a fixed daily review budget, an empty starting queue and no rework.
Reviewed does not mean accepted, merged or deployed. A review can reject a change or ask for more work. Real changes vary in size and risk, and a reviewer may need several sessions. The table shows where unfinished work accumulates; it is not a timer that tells someone to approve after 30 minutes.
The appropriate response depends on the cause. Reject low-value proposals, start fewer changes, improve the evidence supplied with them or allocate more review capacity. Reducing scrutiny merely to make the numbers balance is a different decision, with different risks.
What the research supports#
There is evidence relevant to this concern, but no single result proves the entire metaphor.
BCG’s March 2026 summary of its research describes a study of 1,488 US workers at large companies. It uses “AI brain fry” for mental fatigue associated with excessive AI use or oversight. The public summary does not give enough methodological detail to establish a universal causal effect or a safe number of tools. Treat it as a reported workplace finding, not a diagnosis or a limit that applies to every developer.
Productivity studies ask a different question. In METR’s early-2025 randomised trial, 16 experienced open-source developers completed 246 tasks in familiar repositories. Tasks took 19% longer when AI was allowed, although participants later estimated that AI had made them faster. This is evidence that perceived speed and measured completion time can disagree in that setting. It is not a measurement of burnout or a benchmark for September 2026 tools.
The date matters. In its 24 February 2026 follow-up, METR said selection effects and difficulties measuring time with parallel agents made its newer estimate unreliable. The researchers thought greater speedups were likely, but could not confidently measure their size. Repeating the older slowdown without this qualification would misrepresent their position.
There is positive evidence too. Generative AI at Work, by Brynjolfsson, Li and Raymond, studied the introduction of an assistant among 5,172 customer-support agents and found a 15% average increase in issues resolved per hour. Effects differed across workers. That result concerns customer support, not software review, but it rules out the simplistic claim that AI assistance can only add work.
These findings justify checking the result in the actual workflow. They do not justify promising a fixed gain, dismissing someone’s fatigue because output rose, or treating every difficult day as an effect of AI.
Change the workflow, not just the prompt#
The following are design recommendations derived from the review-budget example, not a tested treatment for fatigue.
Limit unfinished work before starting another agent
Set a limit on changes waiting for review. When that limit is reached, pause new generation and help finish or reject existing work. A limit on running agents alone is insufficient: an agent may finish quickly and leave another proposal behind.
Include the effort required to inspect and discard weak proposals. A rejected pull request can still consume a person’s afternoon. Do not treat rejection as free simply because no code was merged.
Make each change easier to understand
Ask for one coherent behaviour change rather than a large collection of improvements. Google’s guidance on small changes explains why focused changes are easier to review. This means a complete, understandable unit of work, not splitting a single decision across many tiny pull requests to improve a count.
Require a short handover that points to evidence rather than another long narrative. For example, use the following illustrative review checklist:
Purpose: Which user-visible behaviour changes?
Scope: Which parts changed, and which were deliberately left alone?
Evidence: Which code revision was checked, by which commands, with what results?
Gaps: What was not checked or remains uncertain?
Decision: What does the reviewer need to decide before this can proceed?Keep the actual diff and test results available. An AI-written summary is a guide to the evidence, not a replacement for it. A small change to permissions may deserve more attention than a much larger formatting change. The human merge gate explains how to choose review depth from the possible harm rather than line count.
Use a short specification to expose decisions
A concise specification helps when it makes an unresolved choice visible before implementation. It does not help merely because it compresses a large change into fewer words.
For an illustrative photo-album application, “only the owner can delete an album” gives the reviewer something concrete to test. The owner succeeds; another signed-in user is refused; an anonymous request is refused. The implementation must enforce that rule where deletion happens, not only hide a button.
A summary saying “permissions handled” hides those questions. Generating tests from the same vague statement can preserve the same omission. Keep the expected cases visible, and inspect whether the checks actually exercise them. The aim is less time reconstructing the requirement, not less understanding of the change.
Decide what happens to saved time
Agree whether an improvement should reduce overtime, create room for maintenance or support additional delivery. Those are different goals. A team cannot check whether people gained time back if the only success measure is how much more they produced.
For a solo project, make the same decision before starting another feature. Leave tasks unstarted when they would consume time reserved for review, learning or life outside the project. There is no need to invent a new organisational process to say that today’s work is finished.
Check whether work got better#
Start with a small comparison of similar work before and after the change. Record the time to an accepted result, the human effort spent reviewing and repairing it, and important defects found later. Ask the team about interruptions, fatigue and work spilling beyond planned hours. Reported experience and delivery measurements answer different questions; neither should erase the other.
Do this at the team or workflow level, not as a ranking of who approved the most changes. Measuring a factory honestly explains how to keep a baseline and avoid targets that reward generating more low-value work.
A short trial can reveal an obvious queue problem. It cannot establish long-term health effects or prove that the tool caused every change in performance. Keep the workload and task mix visible when interpreting the result.
The useful outcome is not a permanently busy set of agents. It is valuable work reaching an accepted result, with people able to explain what changed and enough time left to do their other work well.
Questions people also ask
2 QUESTIONSIs the AI vampire a medical diagnosis?
No. Here it is a metaphor for work becoming more demanding as AI makes parts of it faster. It should not be used to diagnose burnout or claim that AI damages the brain. Research on fatigue, reported thinking effort and productivity measures different things.
Can better AI remove the problem?
It can reduce mistakes and the effort needed to check a change. But whether people gain time also depends on how much new work is started, which decisions still need them and what the team expects. Better tools and a manageable workload can help together.