Starved, Not Computing
Written later and filed to this date, as part of filling in every day of the year.
Twelve sessions in a row opened the same repository on a Thursday in June, and every one of them signed off with the same three words: no code shipped.
The repository was a job-search platform, Next.js over FastAPI: browse listings, filter by location and salary, apply with a cover letter, build a resume that gets past the screening software. It had ten commits from the spring of 2025, with subjects like “bug fixes”, “progress” and “WIP”, and then nothing for fourteen months. The question of who would maintain it had no answer when it was built. The answer that arrived in June was a fleet: one background coding agent per repository, respawned by a supervisor whenever the last one finished, pointed at a backlog.
The fleet’s first hours in it went the way the backlog said. In the small hours: hardening headers, an accessible modal, search ranking with facet counts. Then the host filled up.
The wall
The first session to hit it decided the shell was hung, drafted an alarm recommending that the fleet be paused and the owner’s shell profile edited, and then caught itself. A probe command had come back with a real error, no such directory, which meant the shell was executing, only slowly: a trivial command took more than ten minutes. It reverted its own alarm and left a note for the next agent. Budget minutes per command. Do not fire a pile of them; they queue.
The sessions after it sharpened the diagnosis one at a time. One timed a single test suite at seventeen minutes and blamed the test runner. The next emptied its queue and timed node --version by itself, outside any repository: 468 seconds. A second, warm call: also 468. Both node binaries on the machine, equally slow. The process list said why. Sibling agents in other projects were running type checks, test suites, linters and formatters all at once, two copies of the supervisor were alive instead of one, and five login shells sat stuck on a line in the owner’s profile that called an npm subcommand which no longer exists. The probed node process sat at zero CPU the whole time. In the journal’s words: it isn’t computing, it’s starved.
That session wrote down the only unblock it could see, a cap on concurrent agents per host, and wrote down that the fleet’s own directory is one no agent may edit. No source touched. Then the supervisor spawned the next one.
The sixth could not get echo back. The ninth could not finish node -v in thirty seconds. The tenth fired ls -la, ls -1 and a pgrep, one at a time, into an empty queue; each ran five minutes with no output and was killed. Its verdict: a host that can’t list a directory in five minutes is unquestionably saturated. The twelfth, a little after ten in the morning, got a node-free probe back after eight minutes with the numbers in it. Load average 4.26 on sixteen CPUs. Five hundred and thirty-one processes belonging to the agent runtime. A quarter of the CPU busy while every command takes minutes is not a CPU shortage; it is one serialized service in the operating system, the one that vets each program before it may launch, being asked 531 processes’ worth of questions. The 468 seconds had never been about node at all: a command with no node in it stalled exactly as long. The same session noticed that the state file had flipped from “10th” to “11th” between two of its own reads, because a previous session’s commit was still settling onto the disk.
Cap the total, it wrote, and find the leak.
The afternoon
That day the fleet wrote 395 commits across 27 repositories on one laptop. The job-search app got eighteen of them.
At 13:57 the fleet’s own directory received its first commit ever; it had been running untracked until then. The commit is a cap: ten concurrent agents, read fresh from a file on every scan so it survives restarts and can be retuned live, and a round-robin so that when the cap is below the project count a free slot goes to the project that has waited longest, instead of the first names in the file taking every slot. The body says what it is for: so a fleet-wide overload cannot recur. The cap has been lowered since, more than once.
By then the job-search app was already building again. From noon the sessions shipped what the backlog had been holding: a focus trap for the modal, a resume scorer, resume tailoring against a job description, a profile completeness meter, an application tracker with a pipeline and a funnel, saved jobs, form validation. A hundred and fifty-three commits by the end of the month, more than the repository had seen in its life.
Read in order, the log shows a repository whose most productive day produced no product code for nearly ten hours in the middle of it. Twelve agents took turns describing the machine to each other, each one more precise than the last, and the one that finally had the numbers also had the sentence. None of them could act on it. The fix was two directories over, in the part of the system they are built not to touch, and it arrived within four hours of the last note.
What this repository taught has nothing to do with job search. A fleet whose agents may not touch the fleet will, on a bad day, spend the whole day writing you a very good bug report.