Two-Hour Interns

For fifteen years I ran a company where the average tenure was over seven years. That mattered to me, in an industry where people usually change jobs every two or three. We had built something people wanted to stay inside of, and that felt like the real product, more than anything we ever shipped to clients.

I used to think about the math of turnover constantly back then. Six to twelve months for a new hire to build enough context to actually contribute, then maybe twelve to eighteen months of solid output, and then, often, they were gone, lured by a bigger title somewhere else. Good for the employee, who usually got a raise and more responsibility by leaving. Brutal for the employer, who had to absorb the cost of recruiting and onboarding and the slow drag of pulling the new person up the curve. Our culture made the math work in our favour most of the time, and I took that for granted.

Then I started building with AI, and the math broke entirely.

My agents quit every two hours. Sometimes faster. A context window expires mid-task and the agent I've spent ninety minutes briefing on the architecture of my codebase, the conventions, the three things we tried yesterday that didn't work, the file we are absolutely not supposed to touch, is simply gone, and the next one shows up with no memory of any of it. I have to start the onboarding from scratch. Re-explain the project, re-paste the relevant files, re-warn about the sharp edges we already discovered together the day before. It is the most extreme version of employee churn I have ever experienced.

The old math was six months to ramp, eighteen months of contribution, then attrition. The new math is six minutes to ramp, two hours of contribution, then attrition, and the intervals collapsed but the structure didn't, which means every agent still needs context and every agent still needs its work checked. The overhead just got compressed into the same day, over and over, and the cost is paid in cognitive load on me. I am the institutional memory now, the onboarding doc, the senior engineer who's been here long enough to know why we did it that way, and I have to perform that role thirty times before lunch.

There is an old rule I used to live by as a manager, which is that you wouldn't hire a twenty-year-old student for two days, even if you were paid to, because the price isn't the point, the overhead is. The math doesn't work.

I am doing it every single day now.

The Claude Code subscription divided across twenty working days is roughly twelve dollars, and Codex is similar, which means that for the price of a takeaway lunch I can summon an army of two-hour interns who are confident and fast and will tell me with absolute certainty that they have identified and resolved the issue, which is its own particular flavor of intern energy, the kind where the work has been done but not actually verified, and then their shift ends and a new one shows up, equally confident.

The thing that is slowly dawning on me, though, is that I have seen this problem before, and I just didn't recognize it.

For years while running my company, I poured enormous energy into giving my team context. Weekly town halls, a weekly email after every client trip with everything I had seen, quarterly offsites where we flew in our biggest clients to spend two days embedded with the team. None of it benefited me directly. All of it was an attempt to push context outward so that people could make better decisions without me in the room.

After about ten years, I quietly stopped doing most of it, not because it didn't matter but because I had realized something uncomfortable. Most people didn't want the context, and they couldn't reasonably be expected to hold the whole business in their head the way I did. They wanted clear instructions. When I switched from broadcasting context to giving very specific direction, output went up and I wasted less of my own energy on the things that weren't sticking anyway.

I think I am relearning that lesson now with agents, in a different shape but with the same underlying truth. We are pouring enormous engineering effort into harnesses and context engines and skill files and persistent memory, all of it aimed at turning agents into something closer to senior employees who carry the project around with them. But maybe the better move is to stop trying to make a two-hour intern think like a senior architect, and start designing tasks that a two-hour intern can actually finish.

Here is what I am starting to think about.

The skill that is becoming most valuable in this phase is one I undervalued for years as a CEO, which is the ability to decompose, to take something complicated and break it into pieces small enough that a fresh intern, with two hours of context and no institutional memory, can finish one of them. That is a real craft, part product manager and part senior engineer and part the kind of taste that knows what to leave out.

I am also thinking about the problem nobody seems to be solving yet, which is how agents interact with each other, because I can brief one agent, and I can brief two, but when I want the agent that wrote the backend to coordinate with the agent that is writing the frontend, the cognitive load is still on me. I end up being the bus between them, and I am a terrible bus, slow and distractible and prone to dropping things.

And I keep coming back to the asymmetry between assigning work and reviewing it. Assigning is intoxicating, because I can spin up five tasks in five minutes, but reviewing is excruciating, because it is the least fun part of the job and the most consequential, and my output is bottlenecked not by what I can ask for but by what I can actually verify. The bottleneck has moved from production to judgment, and I am underinvesting in judgment.

The technology will get better. Context windows will grow, memory will improve, and some of what I am describing here will sound quaint in twelve months. But I don't think the management problem goes away. I think it just changes shape, and the question of how a single human orchestrates dozens of fast, confident, forgetful two hour interns is going to be one of the defining management challenges of this decade, and almost nobody is talking about it as a management problem yet.

What I keep wondering is whether the people who will be best at this aren't the ones with the most technical skill, but the ones who already know what it feels like to manage a team that is always turning over. The agency owners. The restaurant managers. The construction foremen. The people who learned, the hard way, how to extract good work from someone who started yesterday and might quit next month.

Maybe they have been training for this their whole lives, and they don't know it yet.

And maybe the rest of us are about to find out that we were signing up to be managers without realizing it. The writer who just wanted to write a book, the founder who just wanted to ship a product, the analyst who just wanted to automate a workflow, all of them now running tiny organizations of forgetful collaborators, learning on the fly what it means to delegate and review and hold the thread when nobody else can. Building with AI was supposed to be the thing that freed us from management. It turns out it was the thing that made every one of us a manager.