📊 Visual Summary: Want a quick overview? Check out our Leading AI infographic that maps the five leadership lessons — context, roster, ambition, planning, and ownership — onto the models and tools I use every day.
Nowadays we all use AI for development. And if you don’t, someone will eventually tell you that you are lagging behind — for good reasons.
But let me be clear about what this article is not.
This is not another piece arguing whether vibe coding beats assisted coding, or how far you should let the AI go before you take the keyboard back. It is not about AI dooming software development. It is not about whether humans get replaced. Those articles already exist in enormous quantity, shouted from both directions, and I have already written my own take on the honest middle of that argument.
This article just wants to tell you about one experience of mine. A strange one, honestly — strange enough that it took me a while to trust it.
Because after a couple of years of building real software alongside AI agents, day after day, I noticed something I did not expect at all:
Doing software development with AI agents is not that different from leading a department of software developers.
Not as a cute metaphor. Not as a motivational analogy for a conference talk. I mean that the actual daily mechanics — how you brief, how you assign, how you plan, how you handle a bad result — turned out to be the same mechanics I had already spent years learning on human beings. I keep reaching for old instincts, and they keep working.
So here is our story for the day.
Some Context First
I have been in tech since 2017.
That means I got a good long run in the era before this one. In early 2024, coding with AI was either non-existent or a running joke among tech people like us. You would see a demo, you would laugh, and you would go back to writing the thing yourself. The coding part fell to human hands — almost all of it, almost all the time. Whatever shipped, a person typed it.
And luckily for me, before the AI era arrived, I was already — and still am — in a leadership position.
At the peak I had the privilege of leading around 20 people: developers, business analysts, testers, and even a project manager. That number matters less than the shape of it. Twenty people is past the point where you can hold everything in your head, past the point where you can personally check every piece of work, and well past the point where you can get away with vague instructions. Twenty people is where you either learn to delegate properly or you drown.
So before AI hit us, I had already accumulated a fair amount of experience: running parallel projects, running different teams, running different kinds of teams, across different companies and different clients. Different personalities, different levels of seniority, different appetites for ambiguity. The kind of experience you do not particularly enjoy earning, because you earn most of it by getting it wrong first.
Now it is 2026. And most of the people I know rarely write code by hand anymore. That is the AI’s job now.
So what exactly do they do all day?
They lead the AI agents.
That is the actual work. Briefing, directing, reviewing, correcting, deciding. And the surprising part — the part that made me want to sit down and write this — is that everything I learned leading human teams translated over almost perfectly. Not loosely. Not poetically. Practically. I use the same moves. They land the same way. The failures rhyme.
I did not expect that. I assumed the new era would ask me for a new skill set, and instead it handed me a bill for the one I already had.
Let me show you what I mean, one lesson at a time.
1. Give Enough Information to Solve the Problem
Let me start with my first real lesson as a lead.
When I was the front-end team lead, the structure looked like this: the tech lead worked directly with me, along with the business analyst and the other team leads. They could not work directly with each of my team members — there were not enough of them to go around, and that is exactly why the lead role exists in the first place. So it fell to me to take what I received in those rooms and hand it down as tasks and details to my own members. My team size moved around over the years, somewhere between four and eight people.
And in all that time, through all those team compositions, one thing never changed:
If I assigned a task without saying enough, or without giving enough context, that task was going to blow up. One way or another.
Sometimes it came back built on an assumption I never made and never wanted. Sometimes it came back solving a slightly different problem than the one the client had. And sometimes — on a lucky day — the member came back and told me they could not start at all.
That was the lucky day. I want to be very clear about that, because it took me a while to appreciate it. The task that stalls costs you a day. The task that proceeds confidently in the wrong direction costs you a week, plus the review, plus the rework, plus the awkward conversation with whoever was waiting on it. Silence is cheap. Confident wrongness is expensive. That is true of people, and as you will see, it is even more true of AI.
So I over-corrected. Naturally. I started giving my members far more context than they needed — the full background, the client history, the adjacent systems, the reasoning behind decisions made months earlier. I figured more information could not possibly hurt. If under-briefing was the problem, over-briefing was the cure.
It was not.
Too much context, and people start overthinking. I watched it happen repeatedly. They begin solving problems that were never in their scope. They start weighing trade-offs that did not matter for this ticket. They hesitate on decisions that should have taken thirty seconds, because now they can see six considerations pulling in different directions and no clear signal about which one I actually cared about. Things stopped going as I planned — not because anyone was careless, but because I had handed them a map of the entire continent when all they needed was the street.
The sweet spot, the one I eventually settled on and still use, is just enough context — or a little more than needed. Not less. Not a flood. Enough to make the right call, plus a small margin for the surprises I did not anticipate.
Now here is the part that genuinely surprised me: it works exactly the same way with AI.
When you tell an AI to do something, you have to give it enough context — not too much, not too little, and the window is narrower than people assume.
Give it too much, and the AI starts overthinking in a way that is almost uncomfortably human. It wanders. It over-engineers. It “improves” three things you never asked about, because somewhere in that pile of context it found a thread worth pulling and no signal telling it not to. You asked for a button and you get an architecture.
Give it too little, and it starts hallucinating its way through the gaps just to complete the task. And it will complete it. That is the trap. It will hand you something that looks finished and confident and entirely reasonable, built on invented assumptions about the parts you never explained.
Either way, you are not going to like the result.
We use different vocabulary for these two failures. When a person does it we say they misunderstood the ticket. When an AI does it we say it hallucinated. Different words, different industries arguing about them, entirely different research literatures.
But from the lead’s chair, it is the same failure. It has the same root cause — an unclear brief — and it has the same fix. You did not give them what they needed to succeed.
And I will say the uncomfortable part out loud, because it applies to both: when the brief is bad, the failure belongs to the person who wrote the brief. That was true when I was assigning tickets to a human team, and nothing about the AI era has made it less true.
2. Every Member Has Their Own Strengths and Weaknesses
Back in my day, dealing with humans made this lesson impossible to miss.
There are people who are fast, but who leave a lot behind to be cleaned up. There are people who are slow, but whose work is always deeply satisfying the moment it lands in your hands — you open it and you know you will not be revisiting it. There are unique people who can work with their mouth wide open, talking the entire time, somehow producing perfectly good output while narrating. And there are people who flatly refuse to come into the office in the morning and are reliably, cheerfully there at midnight.
A weaker version of me would have tried to standardise all of that. Push the fast one to slow down, push the slow one to speed up, get everybody on the same hours, and end up with a team of mediocre averages who all resent me a little.
What I actually did was simpler:
- I paired the fast guy with the slow guy. The fast one covered ground; the careful one caught what got dropped along the way. Neither had to become the other. Together they were better than two copies of either.
- I gave the midnight guy the tasks that did not need much communication. At midnight there is nobody to talk to anyway — so I stopped fighting the schedule and started using it. The deep, isolated, uninterrupted work went to the person who was awake in the most uninterrupted hours of the day.
- And the person with the big mouth? I gave them the talking tasks. The chasing, the reminding, the follow-ups, the “has anyone actually confirmed this with the client” work. Because that is a real task by itself. It is not overhead, it is not something you squeeze in between the real work — it is the thing that keeps twenty people pointed in the same direction, and it deserved someone who was genuinely good at it and did not find it draining.
None of this was clever. It is close to the first thing any decent lead figures out. You do not get to choose a team of identical ideal workers, so you learn who is good at what, and you route the work accordingly.
Now bring that instinct into 2026.
A lot of people today swear by one single AI. Claude, for example. And at the time of this post, Claude is still the most intelligent AI on earth by most benchmarks — I am not going to argue with the scoreboard.
But here is what strikes me every time that argument comes up:
Our human teams were never made up of the most intelligent people on earth, and they still performed.
Not one team I ever led was staffed with the top-ranked person in every discipline. That is not how teams work, that is not how hiring works, and it is certainly not how budgets work. What made those teams effective was never raw individual brilliance. It was fit — the right person on the right problem, with someone paying attention to which was which.
So when I look at the models now, I do not look for a winner. I look at a roster.
I find Claude intelligent, absolutely. But in daily use it behaves remarkably like that fast guy I always dealt with: a little arrogant, a little too quick, not checking things thoroughly enough before declaring victory. And lazy in its own particular way — I mean that partly in terms of token price, because those tokens run out very quickly. One of the most intelligent people I ever worked with only ever worked six hours a day, no more, no negotiation. Claude is the same. Brilliant, and then done. Its ability to crawl the internet is also something I think Anthropic can still work on.
I also use ChatGPT, which at the time of this post is one of the most balanced models on the board. Sufficiently intelligent — not quite the best Claude on the hardest reasoning — but its web crawling is good enough for real work and the token price is not that high. Every team needs a dependable middle. The person who is not the star, is never the bottleneck, and quietly carries a third of the sprint.
Gemini’s ability to crawl the web is the best I have used, most likely thanks to its Google origins. Some of its other abilities can fall short of the others, and that is fine — that is not what I bring it in for. You do not hire a specialist and then complain that they are a specialist.
And all of that is only the models. On top of that sits another layer: each tool — Claude Code, Codex, the Antigravity IDE — has its own strengths and weaknesses that are distinct from the model underneath it. Same worker, different working conditions, genuinely different output.
I will not go into the full detail here — that comparison deserves a post of its own. But I do pair each AI to the work it is best at. In practice, my rotation looks something like this:
- Claude Code writes the software spec and helps with the design. Fast, sharp, good at the shape of a thing. Exactly where a little arrogance costs you nothing.
- Codex does the implementation — the long, patient, unglamorous stretch of actually building it.
- Antigravity IDE comes in last for testing and for tightening up whatever got left behind.
Look at that list again. That is not an AI trick. That is staffing.
It is the exact same instinct as pairing the fast guy with the slow guy — put the quick thinker where speed is worth more than caution, put the careful one where a missed detail is expensive, and have someone come through at the end to catch what everyone else walked past. You learn each worker’s grain, and you cut along it instead of against it.
The mistake I see most often is not picking the “wrong” AI. It is picking one AI and then being disappointed that it is not equally good at everything — which is a complaint no experienced lead would ever make about a human being.
3. Never Settle for a Good-Enough Roster
Knowing your roster is one thing. Being satisfied with it is another — and that is the habit from those years I have never been able to put down, nor do I think I should.
Throughout my time leading teams, there were always people that other teams rejected — and that I found golden.
Remember the midnight guy?
He was almost fired. Not for his work — for his eccentric behaviour. He did not fit the shape of what people expected an employee to look like, he kept hours nobody had approved of, and by the time I heard about him the conversation had already moved to letting him go.
So I scouted him. I took him onto my team, and then I did the only genuinely clever thing in this story: I left him where he deserved to be. I did not try to sand him down into a normal employee. I did not fix his hours or his manner. I gave him the work that suited exactly the person he already was, and then I got out of the way.
He shone. Within a fairly short stretch he became one of the best employees that company had. The same behaviour that had nearly cost him his job was, in the right seat, the reason he outperformed everyone around him.
That is the habit. Never accept a good-enough roster. Not when you are leading people, and not now.
Which brings me to what I am doing at the time of writing this. I have been trying to experiment with Kimi, because I keep hearing very good results from people I trust — and the token price is much cheaper than what I currently pay. On paper, that is precisely the profile I have learned to chase: the one everybody is overlooking, that quietly does the work, at a fraction of the cost.
Sadly, I cannot. Kimi is currently not taking on more subscribers, so the door is closed for now.
And I will admit that annoys me more than it probably should — which is itself the point. I have already run the roster I have, I know its grain, and the work is getting done. It would be very easy to call that good enough and stop looking.
But I have seen what happens when you keep looking. He almost got fired, and he became one of the best people in the building.
So no. I am not settling. The moment that door opens, I am going to find out what Kimi is actually good at.
4. Never Go Without a Plan
When I led 20 people, there was one thing we could never skip before doing anything: planning.
We planned everything in detail. Who does what. What “done” actually means for each piece. What risks might be involved and who is watching them. Not because anybody loved writing documents — nobody loves writing documents — but because twenty people moving without a shared plan is not a team. It is twenty separate projects that happen to share a repository, and you will only discover how separate they were at integration time, which is the worst possible moment to find out.
The plan was never really the point. The alignment was the point. The document was just the cheapest way to make alignment visible and checkable before it cost anybody a week.
Now, working with AI, I want to be honest about a real hazard here: planning too far ahead can bite you. These tools move fast. A meticulously detailed plan written against last month’s capabilities can age badly — you can find yourself carefully routing around a limitation that quietly stopped existing two weeks ago, or building scaffolding for a step the model now handles on its own. That risk is genuine and I am not going to pretend otherwise.
But going in with no plan at all is still, by a wide margin, the worst option.
Without a plan, you spend your entire day chasing the AI. And I mean chasing, literally — reacting to whatever it decided to build, discovering its interpretation after the fact, correcting course once the work already exists, re-explaining the same constraint for the fourth time because there is nowhere for that constraint to live except in your last message.
You are not leading at that point. You are following. Fast, busy, and following.
That is the same trap as the unplanned human project, just accelerated. The AI closes the loop so quickly that you get to experience the consequences of poor planning several times before lunch. In a sense that is a gift — the feedback is brutally fast — but only if you actually learn the lesson it is teaching.
These days this reflects itself in writing requirements and specs with the AI, exactly the way you would plan the work with a human team, just faster and with a much more patient collaborator. You talk through the goal, you argue about the edges, you write down what done looks like, you name the risks. Same conversation I have had a hundred times in a meeting room.
The only real difference is the format: it usually ends up as a .md file, because both humans and AI can read it.
And that is my favourite small detail in this whole era. The artifact of good leadership did not change. The plan is still the plan. It just changed file extension.
5. Accept the Responsibility
I have always admired great leaders. And across every good one I have worked under or watched from a distance, they share one thing:
They accept responsibility for the whole team or unit.
Great leaders do not blame bad results on their subordinates. They take responsibility for whatever the result turns out to be — publicly, without hedging — and then they go learn from it privately. It is not a performance of humility. It is a recognition that they were the one who assigned the work, set the context, chose the person, and approved the plan. If it went wrong, their fingerprints are already on it.
This is especially true in the AI era. Maybe more true than it has ever been.
I have been teaching and mentoring for a while now, and in that role I see people make mistakes constantly — which is fine, that is what learning looks like. But when I ask what happened, the most common phrase I hear, by a distance, is:
“It was my AI.”
And here is what stuns me about it. That phrase is not untrue.
It really was the AI that made the mistake. Factually, they are correct. I have checked plenty of these cases, and yes — the model wrote the broken thing, invented the wrong assumption, produced the confident nonsense. The accusation is accurate.
But follow the logic all the way down and see where it lands.
If I get the result from your AI, and you take no responsibility for what that result turned out to be — then why should I hire you at all?
Why not talk to the AI directly? At least the token price is much cheaper than your salary. At least then, when it goes wrong, the mistake is mine to own and mine to fix, rather than something handed to me with a shrug and an explanation of who is really to blame. The moment your answer to a bad outcome is “the AI did it,” you have described yourself as a pass-through — and nobody needs to employ a pass-through.
That is the whole thing, right there. That is the part I wish more people sat with.
The AI still makes mistakes. If it were perfect, there genuinely would be no need for humans in the loop — that is not a scary hypothetical, it is just the honest implication. But it is not perfect, and so what the moment actually requires is exactly what we needed from a good team lead back then: someone who owns the outcome. Someone who checks. Someone who catches it before the client does. Someone for whom “it came out wrong” is a problem to solve rather than a fact to report.
That ownership is not a nice-to-have on top of the technical skill. It is the job. It is the specific, concrete thing a human is still being paid for.
And yes — you will still mess up with the AI. Let me be the first to say it about myself: even as I write this, I still make plenty of mistakes with it. Bad briefs. Wrong model for the task. Plans I skipped because I was in a hurry and thought I could get away with it. I am not writing this from the far side of having solved it.
But that is not the failure. Making the mistake was never the failure.
The failure is handing the mistake to somebody else with the AI’s name stapled to it.
The lesson is the same one leadership has always taught, and it has not softened at all in the transition: you learn, and you own your mistakes, and that is precisely how you grow.
An Honest Interlude: Where the Comparison Does Break
I should be fair before I go any further, because I do not want to sell you a comparison that is cleaner than reality.
Leading AI is not identical to leading people, and the places where it differs matter.
An AI has no career you are responsible for growing. It has no Monday-morning mood, no bad week, no personal life quietly pulling at its attention. It will not be discouraged by blunt feedback and it will not be motivated by praise. It does not remember yesterday unless you deliberately arrange for it to. And it will never come to you unprompted to say I think we are building the wrong thing — which, honestly, is one of the most valuable things a good human team member ever does.
Those differences are real, and some of them cut in the AI’s favour while others cut sharply against it.
But notice that every single item on that list is about the relationship, not about the work. The parts that changed are the human parts: motivation, growth, morale, initiative, memory. The parts that stayed the same are the operating parts: brief clearly, assign to strengths, plan before you start, own the result.
And it is the operating parts that fill your calendar. That is why the transfer feels so complete in daily practice even though the comparison is imperfect on paper.
6. And There Is Still Plenty More
Being a great leader does not stop at five lessons and a caveat.
It requires a great deal of learning, and it is no coincidence that there are so many leadership and management books, classes, and courses in the world. That entire industry exists because the subject is genuinely deep, genuinely hard, and mostly resistant to being learned any way other than slowly.
So everything above is just the very basic. The first few things you figure out. There is far more still — how you give feedback that actually changes the next result, how you calibrate trust so you are not re-checking work that has earned the benefit of the doubt, how you decide when a piece of work is good enough to stop, how you keep quality steady across parallel streams that are all moving at once. Every one of those has a direct equivalent in agent work, and I have opinions about all of them.
But maybe that will make the story for another day. Today’s is already quite long.
What I find genuinely stunning, though — and this is the thing I actually want you to take away — is this:
None of those lessons in leadership and management turned out to be a waste. Not one of them.
We spent the last couple of years being told that human skills were about to be devalued. That the safe ground was technical, and everything else was decoration. From where I sit, having watched my own working life get reorganised around these tools, close to the opposite happened. The skills I built managing people are the exact skills keeping me effective now that most of my “team” runs on tokens. Context. Delegation. Planning. Ownership. All of it still load-bearing, all of it still the difference between a good week and a wasted one.
The tools changed completely. The job of directing them barely changed at all.
So in a sense, human skill is not wasted.
It is more important now than it has ever been.
That is the story for the day.
Ready to Join the Journey?
If our mission to provide honest, accessible, and free education resonates with you, here’s how you can be part of it:
- 🌐 Visit our platform: skill-wanderer.com
- 📚 Start learning: dojo.skill-wanderer.com
- 📝 Read more: wanderings.skill-wanderer.com
Lead well — whoever, or whatever, is on your team. See you next time.
