There are developers who make a team faster. There are developers who make a team better. And there are developers who slowly make a team dependent on them, without anyone noticing.
The three I want to talk about are usually rewarded for it. They look experienced, productive, sometimes indispensable. AI is making all three of them easier to scale.
1. The Senior Cynic
You have met this one. Years of experience and a long list of things that do not work. Every new approach reminds them of something they tried five years ago. A simpler architecture will not scale. A different testing strategy was already tried. Another tool is not going to solve anything.
Experience is valuable. It becomes a problem when it turns into a filter that rejects anything unfamiliar. The Senior Cynic is usually not protecting the architecture, they are protecting the mental model they have built over their career. Knowing why something failed in the past is useful. Assuming it cannot work in a different context is not.
AI makes this cheaper. Ask for arguments and you get arguments: comparisons, trade-off tables, a full technical rationale for the position you already held. You no longer just have a strong opinion, you have twenty pages backing it up in ten seconds.
The antidote is not optimism, it is evidence. Try the thing. Measure it. Let the current context weigh more than the muscle memory.
2. The Guess Coder
This one is easier to spot, because it shows up in the code. They build for a future that does not exist yet. A simple requirement becomes an abstraction. The abstraction becomes a framework. The framework needs configuration, the configuration needs an extension system, and now you maintain infrastructure for a problem you have never actually had.
The intentions are usually good. They want to avoid technical debt. They want something that scales. They have read about SOLID, clean architecture, hexagonal architecture, event-driven systems, distributed everything. The catch is that principles without context turn into cargo cult engineering, and often the best architecture for the future is the simplest one you can change today.
AI makes this effortless. Ask an agent to "make this extensible" and you get hundreds of lines of perfectly reasonable looking code. It compiles. The structure looks sophisticated. And you have just spent an afternoon solving a problem you do not have.
The fix is not to stop thinking about the future, it is to separate known future requirements from imagined ones. Build for what you know, keep the code easy to change, and validate an assumption before you turn it into architecture.
3. The Superhero
This is the one I worry about most.
The Superhero knows everything. The weird legacy service, how the deploy actually works, why that obscure config exists. When production breaks, everybody knows who to call. They are genuinely valuable, and that is exactly the problem.
The team learns that the fastest route to a solution is to ask them. So people stop investigating. They stop learning the system. They stop taking ownership. The Superhero rarely pushes back on that, and sometimes reinforces it: "I'll just do it", "it's faster if I handle it", "I'll explain it later". Because they are good at solving problems, it works. In the short term.
Then the organization starts rewarding the behavior. They become the person who saves releases and fixes incidents, and being indispensable starts to look like career progress. But there is a difference between being valuable and being a dependency. A healthy team should not need one specific person to keep operating.
The goal is not to stop the Superhero from solving incidents. It is to make sure the next incident does not need the same person. Fix the problem, share what you learned, improve the system, hand the responsibility over, reduce the odds of it happening again. Otherwise you are not removing the fire, you are building a very efficient fire department around one person.
What the three have in common
They look nothing alike, and they optimize for the same thing: themselves, instead of the team's ability to operate without them. The Cynic protects their experience. The Guess Coder protects their imagined future. The Superhero protects their indispensability.
AI amplifies all three. More arguments, more complexity, more changes landing faster than the rest of the team can follow them.
Which is why I do not think AI adoption is mostly a tooling problem. It is a team problem. A team with a strong engineering culture gets amplified. A team with weak delegation, thin tests, knowledge silos and a taste for over-engineering gets amplified too, and much faster.
What to optimize for instead
Not developers who know everything, but developers who make knowledge accessible. Not developers who build for every possible future, but developers who keep today's system easy to change. Not developers who are indispensable, but developers who make the team less dependent on them.
The strongest developer on a team is probably not the one who can solve every problem. It is the one who makes sure the team does not have to solve the same problem twice.
With AI in the loop, that distinction matters more, not less.
