We are all AI agent managers now
The work is no longer writing the code. The work is designing and scaling agent systems.
One of the hardest transitions in my career was moving from IC to manager.
Like a lot of developers, I got promoted because I was good at getting work done. I had good technical judgment. I cared about the team. I would figure out what work needed doing and then do it - without needing to be told what to do (“every manager’s dream!”).
Then I got the title, and it hit me in the face.
My whole identity was tied to writing code. There is still nothing I love more than coding. So when the job changed, I kept reaching for the old version of useful.
I stayed too hands on. Because my sense of self worth and identity came from how much output I could produce myself.
I gave too much input on technical decisions. I opened PR’s because it made me feel helpful (but secretly annoyed the team). I jumped into details that were no longer my job.
At the time, I told myself this was being helpful.
I knew the system. I knew the code. I knew what good looked like. So of course I should stay close to the details.
But if I am honest, it was fear of letting go.
I wanted to feel needed. I wanted to prove I still had the technical edge. I wanted to be useful in the way I already knew how to be useful.
Eventually you learn that this is not your job anymore.
A manager is not there to write code or be the smartest engineer the room. A manager gives clarity, direction, support, and care. They grow the people on the team. They build the systems and environment that let other people do their best work and enjoy their job.
I have felt the same shift with AI agents.
My first instinct is still to be hands on. Tell the agent every step. Watch every move. Pull the work back toward me because I think it will be faster if I make the decision myself.
But I am starting to realise that this is often the same ego again.
It’s the part of me that thinks I know best. The part that assumes the agent needs me in every detail. The part that wants to stay close enough to the work that I can still feel like the person doing it.
And that is the old model.
Do not get me wrong. Agents need human direction. Engineers are as necessary as ever. Agents do not have human intelligence or creativity and make stupid mistakes “ALL THE TIME”. But the shape of the work is changing.
The work is no longer only writing the code. The work is deciding what should exist, what good looks like, what constraints matter, and how the system should produce the result.
That is still engineering.
It is systems design. It is architecture. It is product judgment. It is taste. It is knowing when a solution is too clever, when the code is fighting the product, when the abstraction is wrong, and when the whole task should be reframed.
The engineer managing agents is still an engineer.
They have not stopped doing technical work. The work has moved up a level.
They are not the junior engineer writing every line of code. They are closer to the senior engineer designing the system, setting direction, making tradeoffs, and deciding what good looks like.
That is a strange shift if you love writing code.
It can feel like letting go of the part of the work that made you useful.
But I think the opposite is true.
The job now is to think bigger.
Not bigger in a vague motivational sense. Bigger in a practical sense. You can do work now that was impossible even a few months ago. What are you doing with that new power?
What would I build if I was not limited to the work I can personally type?
What quality bar would I set if I could run more experiments, review more options, test more paths, and throw away more bad versions?
What system would I design if I had agents that could research, draft, code, test, refactor, document, and review in parallel?
This is where the rules start to change.
A lot of us still use agents the old way. We ask for one task, wait, correct it, ask for another task, wait again.
That works. But it keeps us inside the old shape of work.
The better version is to build systems.
That means giving agents clear jobs. It means writing down the context they need. It means defining the quality bar before the work starts. It means asking for evidence, tests, screenshots, diffs, tradeoffs, and failure modes (”trust but verify”).
It means reviewing output like a technical lead, not hovering over every keystroke.
Practically, I think this changes things.
First, start with the outcome.
What needs to be done, why, and how do you know when the job is done well? Planning and requirements are a real job. I use AI agents for planning but guide them at every step. Agents write better task descriptions than humans.
PS: steal my planning skill here.
Second, set the quality bar.
Tell the agent what must be true when the work is done. Functional and non functional requirements. Tests should pass. The UI should work on mobile and desktop.
Example: Acceptance criteria on tasks.
Third, improve the system after every failure.
If the agent misses context, add the context. If it repeats a bad pattern, write the rule down. If the review takes too long, make the expected output clearer next time.
That is the part that feels most like management.
A good manager does not just correct the work. They improve the conditions that produced the work.
A good agent manager does the same thing.
They turn repeated corrections into instructions. They turn taste into examples. They turn quality into checklists. They turn hard-won context into reusable operating rules.
This is already how senior technical people work.
The most senior engineers often write less code than people expect. Architects do not create value by typing faster. They create value by making better decisions, setting direction, and helping other people avoid expensive mistakes.
As an IC, this can look like doing nothing.
They are in meetings. They are writing plans. They are asking annoying questions before anyone gets to build.
But directional work matters.
A team can work incredibly hard on the wrong thing and still fail. I have seen teams pull all-nighters on projects that did not need to exist. The work was real. The effort was real. The value was not.
That is the lesson I keep coming back to with agents.
The goal is not to micromanage the machine.
The goal is to build a system where the right work gets done, with enough context, enough constraints, and enough review that you can trust the output.
We are not just writing prompts anymore.
We are managing workers that do not get tired, do not need motivation, and can run in parallel.
That means the bottleneck moves.
It moves from typing code to choosing direction.
It moves from doing every task yourself to designing the system that gets tasks done well.
That shift is uncomfortable if your identity is tied to being hands on.
I know because mine is.
I still want to jump in. I still want to fix the detail. I still want to prove I can do it myself.
But the better I get at working with agents, the more I think the real work is learning to let go of those old rules.
Think bigger.
Raise the quality bar.
Ask what becomes possible when your job is not to do every task, but to design the system that gets great work done.
I think this is what real engineering has always been.