Home → Leadership
AI or Leadership?
The newest developer on the team finished a three-day estimate in two hours. The code works, the tests are green. Then I asked: "Why did you open a transaction here?" The answer: "That is what it suggested."
- Writing got cheap, verifying got expensive. The bottleneck moved from coding to reviewing.
- Consistency erodes on its own. Three developers can solve the same problem with three different libraries and all three are "right".
- The most insidious risk is with juniors. Ready answers speed them up now and can cut off the path to seniority later.
- The question is wrong: AI can decide but cannot take responsibility. That is why it does not replace leadership.
What got cheap, what got expensive
Most of the AI debate runs along "will it take our jobs". What I see in the field is less dramatic and more interesting: some work became almost free, and some became more expensive than before.
- First drafts, boilerplate, converters
- Known solutions to known problems
- First steps in an unfamiliar language or framework
- Test data, sample input, draft documentation
- Verifying what comes back
- Consistency across the codebase
- The "why did we do it this way" knowledge
- Juniors actually learning
The whole right-hand column is, not coincidentally, work that lands on the leader's desk. AI did not reduce a leader's job; it changed its content.
Three things that happened
1. The migration that ran fine in staging
A generated database change ran in seconds in staging. In production it locked the table for several minutes. The reason is simple: staging had a thousand rows in that table, production had millions.
The generated code was not "wrong"; it simply did not know our data. That is a context problem, and carrying context to the team is your job, not the model's. From that day our rule became: every data-changing migration has a mandatory field in the PR template — "how many rows in production?"
2. Three developers, three libraries
Within one sprint, three people used three different approaches for date handling. All three were reasonable, all three worked, all three came from a different suggestion.
Six months later that means "three separate timezone bugs". Consistency used to emerge on its own, because people wrote code by looking at each other's. Now everyone writes by looking at their own conversation, and the shared memory weakens.
The fix was not a ban but a written decision: a short "in this project we use these" file, given to the tool as context too.
3. PRs doubled, delivery speed did not change
This one surprised me most. Output really did go up: the number of PRs opened doubled. But the time for features to reach production stayed roughly the same.
Measuring it made the reason obvious: review capacity was unchanged. Writing got faster, reading did not. PRs started waiting in the queue, reviews got shallower — and bugs that passed shallow reviews reached production.
The real issue: the junior learning path
Everything above is solvable. This is the heading that actually worries me.
How does seniority form? By getting something wrong and seeing the consequence. A system falling over at 2am, a three-hour bug hunt, an event that makes you say "never again". What teaches is not the answer itself but the road to the answer.
A ready answer shortens that road. Short term it is great: the junior produces faster, feels good, the team is happy. Long term it is risky: a year later you can have someone who shipped a lot of work but does not know why any of it is the way it is. And that person freezes in the first real crisis, because the question in a crisis is not "how do I write this" but "what is happening here".
- The defence rule. If you cannot explain your code, do not open the PR. The review question is fixed: "why this approach, what was the alternative, what could go wrong here?" If they cannot answer, the code is not ready.
- Try with your own head first. On a new topic, the first 30 minutes are tool-free. Then use whatever you like. The point is not to block, but to arrive with your own hypothesis.
- Share the bug hunt. When a senior solves a problem they do not solve it alone; they share the screen and narrate their reasoning. That turned out to be the single most effective teaching tool we have.
None of this is anti-tool. I use them, the team uses them. But a tool is an accelerator; if the direction is wrong, you get to the wrong place faster.
How a leader's job changed
| Before | Now |
|---|---|
| Solving the hard problem yourself | Building the system that verifies solutions |
| Waiting for standards to emerge | Writing the standard and feeding it to the tool |
| Treating review as routine | Planning review capacity as a resource |
| Giving juniors work | Giving juniors difficulty |
| Leaving confidentiality to IT | Making a clear call on what data never leaves |
That last row matters especially. Customer data, private repos, contract text — sending these to an external service is a commercial decision, not a technical one. If the rule is not written down, the team invents its own, usually in good faith. A written boundary protects people without making them feel guilty.
Why "AI or leadership" is the wrong question
Because they are not in the same category. A tool produces suggestions, writes code, even does good analysis. But it cannot do this:
When the system falls over on Friday night, a human calls the customer. A human stands behind the decision and says "that was my call". A human notices that someone on the team is thinking about leaving.
The core of leadership is not producing knowledge; it is owning the outcome. That is the part that cannot be delegated.
What AI threatens is not leadership; it is information brokerage disguised as leadership. Managers whose job is only to move "who is doing what" from one place to another. That role was already fading; this just accelerated it.
Three numbers I started tracking
- Time from PR open to merge. If output rises while this gets longer, the bottleneck has moved to review.
- Bugs opened in the first 48 hours after release. Is the speedup real, or just deferred cost?
- Share of work a junior closes alone. If it is falling, we are producing dependence rather than learning.
Checklist
- Did review capacity grow along with output?
- Is there a written "in this project we use these" document?
- Is it written down which data must never leave?
- Can the junior defend their code? Did you ask on the last PR?
- Did a senior narrate their reasoning to the team in the past month?
- Did delivery time actually shorten, or did only the PR count rise?
Conclusion
Back to the start: that two-hour job really was good work. The problem was not in the code; the problem was that "that is what it suggested" counted as a reason.
AI will make your team faster. Someone still has to say which direction they are speeding in — and that person has to be the same one who answers the phone when it goes wrong.