Everyone Is Now a Manager of Agents
My mornings start by delegating five to ten tasks to coding agents, and my afternoons are spent reading the pull requests they send back. The job became a loop, and the loop is making me more technical, not less.
My workday stopped looking like a maker's schedule about a year ago, and it took me months to admit what it had turned into. Right now there are eleven development servers running on my machine, one for every project I have open, each pinned to its own port and its own color so I can never confuse which codebase I am looking at. I do not start the day inside any of them. I start it by writing tasks. Five to ten of them at once, each one scoped tight enough to hand off, each one delegated to a coding agent running in its own fresh cloud machine. One task, one agent, no shared state, no agent stepping on another's work. Then I close those tabs and go do something that actually needs me.
The agents run unattended. That is the part that still feels strange to say out loud. They read the codebase, they make their changes, they run the tests, and they come back with a pull request. My afternoon is a review queue. I read the diff the way I would read a diff from a new hire with unlimited energy and no ego, and I make one of three calls on each one. Accept it. Redirect it with better instructions. Kill it and take nothing personally. On a heavy day that is a few dozen pull requests moving through one person, and the next morning the loop starts again.
The title is manager. The skill is still technical.
I want to be clear that this is not an exotic workflow anymore. Google's DORA research, which has been measuring how software teams actually work for over a decade, put AI adoption among development professionals at ninety percent in 2025, with a median of two hours a day spent working with it. The interesting question stopped being whether people use these tools. The question is what shape the job takes when the tools can carry a task end to end, and the honest answer is that the shape is management. Not the calendar-and-headcount kind. The kind where your leverage comes from what you choose to delegate and what you refuse to ship.
of software development professionals now use AI in their daily work, spending a median of two hours a day with it
The pushback I hear most is that managing agents deskills you. Hand the typing to a machine, the argument goes, and the muscle atrophies until you can no longer catch what the machine gets wrong. I take that argument seriously, because the strongest evidence for humility here is real. When METR ran a randomized trial with experienced open source developers in 2025, the ones allowed to use AI finished their tasks nineteen percent slower, while believing the whole time that they were twenty percent faster. That gap between felt speed and measured speed is exactly the trap. If you delegate and then rubber stamp, you are not a manager of agents. You are a passenger with commit access.
slower, not faster, for experienced developers using AI in METR's randomized trial, while they estimated they were 20% faster
But the deskilling argument assumes the review is passive, and mine is anything but. Here is what actually happens when dozens of diffs cross your desk every day. You read authentication code in the morning, animation timing after lunch, a database migration before you log off. The volume compounds. You start recognizing the failure patterns, the places agents cut corners, the architectural seams that hold and the ones that tear. This is the same mechanism that keeps a strong engineering manager technical for decades, reading their team's work with real attention and real stakes. The typing was never where the depth lived. The judgment was, and the judgment is getting more reps than it ever got when I wrote everything myself.
Three habits carry most of that weight, and all three came from getting it wrong first. The one that changed my output the most is that I never correct an agent twice. The first time it does something wrong I fix the output, because that is fast and the work has to ship. The second time it does the same thing wrong I stop and write a rule instead, a permanent file the agent has to read before it touches anything. My rules today are a museum of things that already bit me. Never put a secret key in a client bundle. Check which account is authenticated before you commit. This specific mobile bug is invisible in one browser and breaks in another, so verify in both. A prompt is a conversation and it dies with the session. A rule is infrastructure and it compounds. If you find yourself explaining the same preference for a third time, you are not managing, you are repeating yourself in a nicer tone.
The second habit is that isolation is what makes parallel delegation possible at all. One task, one agent, one clean machine, and nothing shared between them. The instinct is to give several agents the same repository so they can build on each other, and it fails every time, because two agents editing the same tree do not collaborate, they overwrite. The moment I let that happen I stopped being a manager and became a merge conflict. The same discipline applies to me, which is why every project gets a port and a color nothing else uses. Context collision is not only an agent problem. It is a human one, and it looks like editing the right file in the wrong project at eleven at night.
The third habit is the one I trust least and need most. Verify the verification. An agent recently finished a piece of work and reported it done. I ran the command to confirm and the command told me there was nothing there, so I reported back that nothing had shipped. Both of us were wrong, and neither of us was lying. My check was authenticated as the wrong account, and the service returns not found rather than forbidden when you lack access, so a permission error arrived dressed as an empty result. The work had been sitting there the whole time. When the agent and your check disagree, the tempting move is to pick a side. The correct move is to consider that the check itself is broken, because a verification step you never audit is just a second opinion you trust for no reason.
I have started calling the shape of the day the manager's loop. Delegate, review, decide, repeat, and the technical depth is the by-product, not the casualty. The wider economy is already settling into the same shape. Anthropic's Economic Index found that enterprise API usage runs at a seventy seven percent automation rate, meaning the task is handed over whole rather than worked on side by side, against fifty percent for consumers chatting with a model. Companies are not paying for autocomplete. They are paying for delegation, and delegation only works when someone competent is standing at the end of the loop deciding what merges.
automation rate in enterprise API usage, where tasks are delegated whole rather than co-written, versus 50% for consumers
So the skills I practice now are not the ones I expected to be practicing at this point in my career. Writing a task so unambiguous that a machine cannot misread it, which turns out to be the same discipline as writing a good brief for a person. Reading a diff fast without reading it carelessly. Killing work I paid for, in tokens and in hope, the moment it is wrong, without sunk cost dragging it into the codebase. None of that is soft. All of it is technical, applied one level up from the keystroke. The title on this new job is manager. The skill it runs on is the same one it always was.