Working With AI Turned Me Into a Manager, and Nobody Warned Me

There’s a confession going around developer circles right now. It starts with “I’ve been working with AI all week and I haven’t actually written any code.” Ask what they’ve been doing instead and the answers rhyme: breaking work into chunks, handing it off, reading what comes back, sending it back with notes. That’s not engineering. That’s being a team lead.

This isn’t a thread that blew up on Hacker News with 800 comments and a tidy conclusion. It’s more diffuse than that — the same observation leaking out of a dozen different places at once, usually as an aside. So the interesting question isn’t how many people feel this way. It’s what shape the change is taking.

The workday got replaced, not sped up

The old loop was simple. Pick up a ticket. Open the editor. Write code. Hit a wall, search, write more code. The thing in your hands was the code itself.

The new loop starts somewhere else entirely. First thought of the morning is now “how do I split this feature into three or four pieces?” Then you farm them out. One agent runs in the background while you watch another. Results trickle back and you make calls: merge this, redo that, patch this one yourself because explaining the fix takes longer than doing it.

Swap the agents for humans and you’ve described a lead’s Tuesday. Three juniors, three tickets, a queue of PRs to review. The only thing that changed is what’s on the other end of the handoff.

Delegation is a skill, and most engineers never trained it

“Just tell the AI what you want” sounds reasonable until you try it for a week.

Vague instructions produce confident wrong answers. Ask for a login feature and the model picks sessions or tokens on its own, invents its own take on your user table, and hands you something that compiles beautifully and matches nothing. Go too granular in the other direction and you’re dictating code out loud, which is slower than typing it.

Finding the right-sized chunk is the whole game. Anyone who has run a team knows this tension — how much rope to give the new hire, when to step in. But there’s one difference that breaks the analogy. People accumulate context. AI mostly doesn’t. The convention you explained yesterday is gone today unless you wrote it down somewhere the model can see.

Which is why everyone ends up with a rules file, a folder of prompt templates, a document explaining how the codebase actually works. That’s not a new practice. That’s maintaining a team wiki, with a colleague who has amnesia.

Review is the new bottleneck

Here’s where it gets uncomfortable. Code generation got several times faster. Reading and judging code did not.

Run three agents, get three times the diff. You still have one pair of eyes. The constraint just slid downstream, and now it sits on you.

AI-written code also fails differently than human code. The syntax is clean. The variable names are sensible. The structure looks like something a competent engineer wrote on a good day. And buried in it is a subtle miss on the actual requirement — the kind of thing that sails through a skim precisely because everything around it looks correct.

The failure mode from here is predictable. Review fatigue sets in and the bar quietly drops. You start thinking “tests pass, ship it.” Human teams rot the same way when review becomes ceremony. The difference is that a human team has natural throughput limits. The agent does not get tired, does not slow down, and will happily generate more code than you can meaningfully read, forever.

Trust has to be recalculated, not earned

Every manager eventually faces the same question: how much do I verify?

The same triage applies here. Test scaffolding, refactors, boilerplate — anything where a mistake announces itself loudly — you can hand off with a light touch. Auth, payments, data migrations, anything that fails silently and expensively — you read every line. That part transfers cleanly from managing people.

What doesn’t transfer is the arc. People get better. The junior you double-checked last year is the one you lean on now, and that trust compounts in one direction. AI has no such curve. A model update makes it suddenly sharper. A long context window makes it suddenly worse. Trust doesn’t accumulate — it gets recomputed per task, based on the shape of the problem rather than any track record. Your instincts from managing humans will actively mislead you here, because they’re built on the assumption that yesterday’s performance predicts today’s.

What you lose in the trade

Everything above is the optimistic read. The counterargument is not weak.

The most common worry is skill atrophy, and it’s more specific than it sounds. Certain knowledge only arrives through your hands. Why this function is slow, why this abstraction will become a liability in eight months, why this pattern feels wrong before you can articulate why — you learn that by writing code and living with the consequences. Review-only work dulls it. And a dull reviewer is a bad reviewer, because good review is downstream of good authorship. The role eats its own prerequisite.

Then there’s the pipeline problem. Nobody’s career starts in management. Leads can lead because they spent years doing the work first. But someone starting today learns delegation as their first skill, with no foundation underneath it. Where does the judgment to evaluate AI output come from, if evaluating AI output is the only job you’ve ever had? The honest answer is that nobody has solved this. Not the bootcamps, not the university programs, not the companies hiring juniors into agent-heavy teams.

The last one is softer, which might make it heavier. A lot of people are quietly admitting the work got less fun. The reason many of us got into this was the specific pleasure of grinding on a problem until it cracks. Delegate that and what remains is quality control. It’s the promoted engineer’s classic complaint: more scope, more impact, less of the thing you actually liked.

The job description is changing underneath you

AI agents aren’t replacing developers. They’re swapping out the contents of the job. Less time writing, more time decomposing, delegating, reading, and deciding. The catch is that almost nobody was trained for the second list. We hired for the first one.

That’s where the split will happen. The people who scope work well. The people who hold the review line at 6pm on a Friday when three diffs are waiting. The people who can articulate what they’ll verify and what they’ll trust, and who update that judgment when the model does. None of it correlates neatly with how well you write code.

So check your own last week. Time spent writing code versus time spent reading and correcting AI output — which was bigger? If it’s already flipped, you’ve been promoted whether you agreed to it or not. Which means the thing worth practicing this month probably isn’t coding.