AI Vampires: The Hidden Price of Twenty Agents

A while back I was still redirecting agents at two in the morning. Not because one thing had to be finished — I simply could not stop redirecting. One came back with a result, the next was ready for a new assignment, and every time there was something else waiting for me to have an opinion about.

That is not an anecdote about discipline. It turns out there is a name for it.

Marc Andreessen co-founded Netscape and is now a venture capitalist at Andreessen Horowitz (a16z), the firm half-named after him and one of the most influential investors in all of Silicon Valley. A big deal, in other words.

He described a term on the Joe Rogan Experience that he says is going round the Valley: the AI vampire. His definition: "it's when AI turns you into a vampire. You're up all night doing AI coding because you are so productive. You're getting so much done that you can't turn off."

He tells it as a success story. He starts from a genuine puzzle: if agents make you four or twenty times more productive, you would expect programmers either to leave the profession, or to work a quarter of the hours and have a pleasanter life. "What's actually happened is virtually to a person, they're all working more hours than ever."

Then comes the passage that stayed with me. About his friends in the industry, some of them quite famous: "when you talk to them now as opposed to six months ago, they look terrible. They're sleep deprived. They've got bags under their eyes… clearly not taking care of themselves — and they're absolutely ecstatic."

Visibly falling apart, and delighted about it. That combination is the entire phenomenon. From the inside it does not feel like burnout. Rogan's response is the sharpest line in the whole conversation: how much Adderall has been sold by now?

The mechanism Andreessen describes is not addiction in the usual sense. It is latency.

You give an agent an assignment. It works for about ten minutes and comes back "like a puppy" with a result. You evaluate it, redirect, hand over the next one. Except those ten minutes are dead. So you open a second pane. And a third. "The state-of-the-art today in the valley is 20 bots at a time… the only thing you have to do is be there every 10 minutes to give them feedback."

Your job has become a polling loop with a ten-minute interval. And there is the trap, in Andreessen's own words: "The opportunity cost of going to sleep is too high because if you go to sleep, you won't be with your 20 AI coding agents." Sleep is no longer rest. It is downtime for a crew you are responsible for.

What disappeared along the way, he names himself — without drawing the conclusion. On the old model: "you have to spend like two hours refamiliarizing your brain with all the code, then you work for 10 hours, then you spend two hours trying to unplug and get back to normal life."

Two hours to ramp up, and two hours to ramp down. That ramp-down was not waste; it was the way back. The agent loop deleted it. There is nothing left to unplug from, so you never do. You are not stuck because the work is hard. You are stuck because there is no longer a moment at which it is finished.

To be fair: Andreessen is not hiding the damage. He points at the bags under their eyes himself. My objection is not that he missed it — it is that he files it under upside.

That is precisely the wrong column. In any other trade, "he looks awful, he doesn't sleep, and he thinks it's wonderful" is not a productivity figure but a reason for a conversation. We have written before that constant AI assistance wears you down. This is the next stage of that: not exhausting despite the enjoyment, but exhausting through it. Euphoria that keeps you awake is not an antidote to exhaustion. It is the reason you see it coming too late.

There is a second layer underneath, and Andreessen supplies the evidence for it himself. Why does twenty times the output not produce less work? Because demand moves with it: "every company has a thousand things they've wanted to have code for that they've never been able to get to."

He presents that as good news — no unemployment, elastic demand. And he is right; we argued ourselves that code is getting cheap and engineering isn't, and that a bigger backlog is the logical result. But read the same fact from the other side: the backlog is now infinite by construction. There will never again be an evening on which the list is empty.

And that list is what used to make people stop. Not willpower — the finish line. Remove it and put nothing in its place, and all you are left with is the vampire. DHH now runs sixteen agents at once across four machines, and the reason that works for him is not stamina but judgement about what does not need building. It is also why your organisation is still expensive: drawing boundaries is organisational work, not a tooling choice.

I am not an outsider here. I was the one still redirecting at two in the morning. So no sermon — just what I have agreed with myself, and what belongs in a team agreement as far as I am concerned:

• A cap on parallel agents. Not because twenty is technically impossible, but because the number decides how finely your day is shredded into ten-minute blocks. At three you can still think. At twenty you are a dispatcher.
• A hard stop time, and no agent starts work after it. A running agent is a reason to come back. That has to end before you do.
• Overnight output gets reviewed in the morning. Reviewing at two in the morning is not reviewing. It is approving.
• "Done" is a decision, not an empty queue. If the backlog is infinite, someone has to say out loud that this was enough. If you don't, the tool never will.

None of that is a technical problem. Which is also Andreessen's own escape hatch, at the end of the same conversation: "the fundamental moral and ethical issues are still the ones we have to answer." Fine. Then this is one of them, and this is my answer.

At ZEN Software this now sits in how we work rather than in a good intention. Agents run inside agreed limits, review happens rested, and the question "should this be built at all" comes before "can an agent build this" — because the answer to the second one is always yes these days.

That is the heart of what our AI-native software engineering and AI consultancy is about: not the maximum amount of code per night, but a pace you can still sustain next quarter. If you want to know what that looks like for your team — get in touch.