Or: the machines don't get tired. That's the problem.

Press Play on Tape

Once upon a time a kid watched Star Wars and wanted a Chewbacca. Forget the lightsaber. He wanted the co-pilot. Huge, loyal, speaks a language nobody else understands, and fixes the hyperdrive while you take the credit.

A few years later he watched War Games. A teenager with a modem talks to a computer, the computer talks back, and together they almost end the world. The kid didn't care about the war. He wanted the computer that talks back.

The machines needed a while to catch up with the movies.

The first one loaded from a cassette. You typed LOAD, the screen politely asked you to press play on tape, and you waited. Five minutes of screeching and colored stripes dancing across the border. Someone walked past with the vacuum cleaner, you started again.

Then floppies. You took a hole punch to a single-sided disk so you could flip it and use the back. Double the storage, zero warranty.

Then the modem. 14,400 bits per second, a handshake that sounded like two fax machines getting divorced, and a BBS on the other end run by a guy who went to bed at midnight. So did his BBS. Your download was never killed by packet loss. It was killed by your mother picking up the phone to call your aunt.

Then DSL, and the internet stopped being a place you dialed into. You just lived there now.

Every machine was faster than the one before. And every one of them, however fast, still waited for you. You set the pace. Enjoy it. It's the last time in this story that's true.

From Stroustrup to Vibes

The engineers evolved together with the machines.

First there was the book. Stroustrup, a brick, and the chapter on pointers you read three times and finally got on the fourth, at 2 AM, after a segmentation fault explained it better than the book ever did. Then the thick books with animals on the cover, read front to back, because there was no other way to read them.

Then Google, and we found out that asking the right question was half the job.

Then Stack Overflow, and we found out the other half. Skip the accepted answer, copy the one below it with more upvotes, and nod like you know why it works.

Then autocomplete finished our variable names. Then Cursor finished our thoughts. Bad code, but code.

Then agents. Give them a solid plan and they map the codebase, write the code, run the tests and come back when they're done. Give them a vague prompt and they come back too. With something else.

And finally vibe coding. You describe a feeling, and a pull request shows up.

Every step, the machine typed a bit more and the engineer typed a bit less. Every step, we called it progress, and we weren't wrong. One thing never changed though: the engineer still had to understand what he shipped. Keep that in mind. It gets expensive later.

Now the chicken and the egg. For decades this one was easy: the engineer built the machine. Today the engineer built the LLM, and the LLM is building "an engineer." It plans, it ships, it never sleeps, and it reports to a human who still hasn't figured out which of the two is the co-pilot.

Ten at Once

What follows hasn't happened yet. It's a story about the future. If it looks like your current job, that's a coincidence you should probably discuss with someone.

A few months from now the tools got better again. The kid, all grown up, writes a solid plan in the morning, hands it to an agent, and by lunch there's a feature. Tested, documented, mostly right.

So he asks what every engineer asks when a machine sits idle. Why only one?

Five agents, five plans, five branches. He doesn't write code anymore. He's the man on top, and the first week feels like finally getting his Chewbacca.

Then the word travels. Somebody upstairs sees five features in a week and does the math. Parkinson said work expands to fill the time available. The AI edition is shorter and meaner: expectations expand to fill the capacity available. Five becomes the baseline. Next quarter, somebody says ten.

So he goes to ten. And ten is not twice the work of five. It's twice the switching. Every time he turns to an agent he has to load the whole thing back into his head. What's this one for, what did I tell it this morning, what did it decide on its own without asking. The machines don't pay that. He pays it, every time.

Operating systems have a word for this. Too many processes fighting over too little memory, and the machine spends its day swapping pages in and out instead of doing anything useful. CPU at a hundred percent, throughput close to zero. It's called thrashing. The engineer is a hundred percent busy from morning to night. Features ship. Ask him what's inside them and he'll need a minute.

The Queue

Let's be generous and pretend the machines deliver robust work every single time. They don't, but it's a fantasy story, so let them.

The feature is done. It's also useless, because features don't live alone. Each of his ten needs a change in someone else's product. Another team, their roadmap, their queue.

His request lands in their backlog behind their priorities, which always come first, because they're theirs.

Their cadence isn't his either. One team releases weekly, one monthly, one whenever the release manager is back from holiday.

And they don't move at his speed. Some teams run their own ten agents. Some are two humans and a shared calendar. His highway ends in their village road.

Give every dependency a decent 70% chance of being ready when he needs it. A feature with five of them has about a 17% chance that all five show up at once. The stars align more often. So the more he runs in parallel, the more finished work just sits there. And waiting code doesn't freeze. It rots, because main keeps moving under it.

In any system he ever designed he'd call this a producer outrunning its consumers with no backpressure. The queue grows until something falls over. In this story, the something is a person.

The Merge

Ten features in parallel means ten branches touching the same common files. The shared config, the router, that one model everybody imports and nobody owns.

So the streams cross. The Ghostbusters told us never to do it. We cross ten before lunch.

Nobody has time to fix forty conflicts by hand, so the machine fixes them. The LLM merges what the LLM wrote and explains, very confidently, why both sides were right. The engineer reviews a diff of a diff at seven in the evening. Tests go green.

What ships is a third thing. Code that no human designed and no agent remembers writing. It works, for now, and nobody can tell you why.

The Chase

Somewhere above all this, management is trying to keep up.

They can't read the pace, so they measure what they can see. More pull requests, more releases, more green. The numbers look great until the day they don't. To understand the speed they add meetings, and the meetings slow down the speed they were supposed to understand. They're chasing a dashboard that's always one sprint behind.

Meanwhile the real picture lives in exactly one place. Ten features, their dependencies, the conflicts the machine settled and the assumptions it made on the way. It doesn't fit in a ticket. You can't hand it to an agent, because agents forget everything between runs. You can't hire your way out of it either. Brooks told us a long time ago that adding people to a late project makes it later.

It lives in one head. That's the blind spot that doesn't scale. And when an organization finds a bottleneck, its first instinct is to push harder on it.

The machines, like the Terminator, absolutely will not stop. They don't have to. The glue that holds ten features, four queues and forty merges together isn't in the repository. It lives in his gray matter. More glue needed, more gray matter burned.

And gray matter doesn't autoscale.

Two Futures

This story has two possible endings.

In the first, the machines write the code and people oversee them. The engineer becomes an air traffic controller for agents, and the burn is just the price of the ticket, budgeted and accepted like the cloud bill. Some people will make peace with that. Some will be very good at it.

In the second, a few years in, something falls over that nobody can explain. A system written by agents, merged by agents, and understood by no one. And the industry does what it always does after a crash. Back to basics. Smaller scopes, fewer parallel bets, and people who know what a pointer is and why the queue keeps growing. Experience matters again, because the only defense against a system nobody understands is somebody who understands systems.

I don't know which one we get.

But the kid who watched War Games should have remembered how it ends. The machine plays every game there is, over and over, until it learns what none of the generals could: some games, the only winning move is not to play.

Ten at once might be one of them.