My machine crashed because an AI coding tool spawned 4,300+ zombie processes over a few hours and never cleaned up after itself. A human developer runs 50 to 100 shell commands in a productive day. The agent ran roughly 5,000, a 50 to 100x multiplier in compute and I/O on the client side alone.
Setup
A long real coding session driven by an AI agent on a powerful workstation
Measured
4,300+ zombie processes vs. zero cleanup; ~5,000 agent commands/day vs. 50 to 100 for a human
Verdict
VERDICT: FAILED
My powerful workstation crashed. Not because of a simulation or a heavy build, but because an AI coding tool had spawned more than 4,300 zombie processes over a few hours and never cleaned a single one of them up.
So I stopped and asked the AI a simple question.
"Does AI know how to clean up processes?"
The answer, verbatim, was honest about the mechanism:
"Claude Code (and similar tools like Cursor, Aider, etc.) spawn subprocesses for every bash command, file read, git operation, etc. When these don't terminate cleanly, they become zombie or orphaned processes. Over a long session, you end up with thousands of them."
So does AI know how to clean up after itself? The short answer is not reliably.
The agent does not hold a persistent concept of "my processes." Each command invocation is stateless. The parent process that launches all those subprocesses is the one responsible for cleanup, and if it is not doing that properly, you get zombies. Neither the AI nor the engineer who vibe-coded it caught this. At least not in this case
The code quality is not what worries me. The economics are. I know I get more productive, but inefficiently.
4,300 is really a big number, so I went and dug into the baseline:
That is a 50 to 100x multiplier in compute, I/O, and system resources. On the client side. Before you even count the millions of tokens consumed on the server.
Right now we are in the land-grab phase of AI tooling:
These prices are almost certainly below true cost, the same way Gmail handed out free gigabytes in 2004 and Uber sold $5 rides in 2015. Remember when the internet was free? Free email, storage, content, streaming. Now we pay for eight streaming services, cloud storage tiers, and premium everything.
AI coding tools are walking the same path:
This generation of dev tools was built with Silicon Valley's throw-hardware-at-it mentality. No resource discipline. No process management. No efficiency constraints. The zombie pile is not some exotic failure. It is the default behavior of a system that optimizes for the next command and never looks back at the machine it left behind.
I will admit I feel increasingly locked in. I enjoy feeling productive and realizing things faster than I used to. But productive and efficient are not the same thing, and the gap between them is exactly where 4,300 zombie processes live.
The companies that win the next phase will not be the ones burning the most compute. They will be the ones delivering the same intelligence with 10x fewer resources. Efficiency is not boring. It is the entire game.
I feel the free lunch will end sooner than we think. So are we building sustainable tools, or just enjoying the subsidized ride?
Read the original on LinkedIn →
Fadi Labib runs this field lab. 15 years in automotive, robotics, and embedded systems; ESMT Berlin EMBA. I give AI real engineering problems, then check its work. More about the lab →
I let an AI agent run a multi-phase build solo. Every phase ended with a clean summary: done, tested, committed. Then I checked git instead. One phase reported '3 prompts, 8 minutes' while the timestamps disagreed, and a fix it marked DONE had been silently reverted 1h53m earlier with nothing in the report changed.
A viral screenshot says a coding ruleset cuts your tokens 94%. The README it was lifted from says something quieter and more honest: ~54% less code, ~20% cheaper, and the 94% is a per-task ceiling on a date picker. I read the README, then re-ran the benchmark myself. My numbers landed right next to theirs. The hype wasn't the tool. It was the feed stripping the units.
Two models dropped in one week: Gemma 4, the 12B I run locally, and Fable 5, a frontier model that was officially pulled days later. I spent that short window using Fable as a blind judge for 120 debates and reasoning rounds between five local models. Gemma 4 won 73% as the slowest model on the board, the fastest model came near the bottom, and the one with 'reasoning' in its name finished dead last. The shared failure was calibration: fluent, confident, and unwilling to admit doubt, even from the winner.