The team that split in half without anyone noticing
What happens when AI adoption creates two tiers of engineer and nobody names it
A principal engineer I know told me something last month that I haven’t stopped thinking about.
She leads a platform team of eight. Four of her engineers adopted Claude Code early, built fluency over a few months, and are now operating at a pace she described as “genuinely disorienting.” The other four haven’t. Not because they were told not to. Not because they’re resistant to new tools. They just didn’t make the jump, for reasons ranging from skepticism to workload to the simple inertia of established habits.
“The problem isn’t the speed difference,” she said. “The problem is that my team is becoming two different teams. The ones using AI are making architectural decisions at a pace the others can’t follow. Code reviews have become adversarial because the reviewer can’t hold the context of what was generated. My best non-AI engineer told me last week that he feels like he’s falling behind in his own codebase. He’s been here four years. He built half of it.”
She paused and said: “I didn’t create a capability gap. But I’m the one who has to manage it, and I have no playbook for this.”
Intent Solved recently published a piece calling this the “Shadow Dev Problem”: the phenomenon of AI-augmented developers operating at a fundamentally different level of output from their peers, creating a quiet fracture inside engineering teams. They frame it as a tooling and governance challenge. They’re right that it is. But it’s also something deeper, something the governance frame doesn’t reach.
It’s an identity crisis. And it’s happening inside every engineering team that’s adopted AI unevenly, which is nearly all of them.
The capability gap is an identity gap
When half your team can produce in a day what used to take a week, and the other half is still working at the old pace, the gap isn’t just operational. It’s existential.
The engineers who haven’t adopted AI are watching their peers ship at a rate that makes their own output look insufficient by comparison. They haven’t gotten worse. The baseline moved. And because nobody formally acknowledged the shift, they’re left to interpret it on their own.
The interpretations I’ve heard from engineers in this position: “I’m falling behind.” “My skills don’t matter anymore.” “I’m going to get managed out.” “The thing I was good at has been automated and I don’t know what I’m good at now.”
These are not productivity problems. These are identity problems. I wrote about this mechanism in the context of promotions: when the role changes faster than the person’s self-concept can adapt, the result is impostor feelings, not because they’re incompetent, but because their proof system stopped compiling. The metric they used to evaluate themselves, quality of hand-written code, lines shipped, depth of implementation knowledge, just got devalued by a tool that wasn’t part of the equation six months ago.
The AI-adopting engineers have a different identity problem, one that’s less visible but equally real. They’re producing more than ever, but the nature of what they’re producing has changed. I wrote about this in the AI coding piece: the job shifted from building to evaluating, and the people doing the evaluating are burning cognitive resources on a different kind of work without recognizing that the recovery mechanism, the craft of writing code, got automated along with everything else.
So both halves of the team are experiencing identity disruption. The non-adopters feel left behind. The adopters feel productive but depleted. And the team as a whole is fracturing along a line that nobody drew.
Code review becomes the fault line
The Intent Solved piece mentions that code review gets harder when the reviewer is operating at a different level than the person who wrote the code. That’s understating it. Code review is where the fracture becomes visible and where the relational damage compounds.
In a healthy team, code review is a peer activity. It assumes rough parity of understanding. Reviewer and author are operating in the same conceptual space, and the review is a conversation between equals about tradeoffs, edge cases, and design choices.
When one engineer generated a 2,000-line change with AI assistance in a day and the reviewer is expected to evaluate it with the same care they’d apply to a hand-written 200-line PR, the relationship changes. The reviewer isn’t a peer anymore. They’re an auditor of work they didn’t participate in, can’t fully contextualize, and can’t produce at the same rate. That shift in dynamic does something corrosive to the reviewer’s sense of professional standing.
I watched this happen on the platform team I mentioned. The non-AI engineers started rubber-stamping reviews because the alternative was spending their entire day evaluating someone else’s AI-generated output, which felt like grading homework. The AI-adopting engineers interpreted the quick approvals as validation. The non-adopters experienced them as surrender. Nobody talked about it. The code quality data didn’t surface it. But the team’s relational health degraded in a way that showed up three months later when two of the non-adopters quietly started interviewing.
The two responses that don’t work
The Intent Solved piece describes two common reactions: blocking the tools, or allowing a free-for-all. Both fail, and the psychology explains why.
Blocking fails because it punishes initiative and creates shadow behavior. Your most capable engineers, the ones with the highest agency and the strongest drive to improve, are the ones who adopted AI first. Blocking the tools tells them their initiative was wrong. That’s a trust violation. They’ll find workarounds, and now you’ve lost visibility into what they’re doing without gaining any control over how they do it. You’ve also sent a signal that the organization punishes early adoption, which is exactly the behavior you need to reward if you want to survive the next two years.
The free-for-all fails because it creates the capability gap without any infrastructure to manage it. If some engineers adopt and others don’t, and the organization provides no shared standards, no training pathway, and no adjustment to how work gets evaluated, you’ve created a two-tier team by neglect. The adopters pull ahead. The non-adopters fall behind. And because nobody named the gap, nobody has permission to address it. The manager is stuck observing a divergence she can’t formally acknowledge because the organization hasn’t given her the language or the tools to manage it.
This is the pattern I described in the adaptation budget piece: change that happens without infrastructure creates exhaustion and withdrawal. The non-adopters aren’t resistant. They’re unequipped. They were given no onboarding, no training, no adjusted expectations, and no acknowledgment that the job just changed underneath them. Calling that resistance is like calling someone who wasn’t given a parachute resistant to jumping.
The psychological contract that broke
There’s a concept in organizational psychology called the psychological contract: the unspoken agreement between an employee and their organization about what each side owes the other. You invest your skills and time. The organization provides stability, development, and a fair evaluation of your contribution.
AI adoption broke the psychological contract for the non-adopting half of every team, and nobody renegotiated it.
The implicit promise was: if you build deep expertise in this codebase, that expertise will be valued. If you write careful, well-tested code, that craft will be recognized. If you invest in understanding the system at a level that lets you make sound architectural decisions, that investment will compound.
Then a tool arrived that lets someone with six months of context produce output that looks comparable to what took four years of accumulated knowledge to produce by hand. The output isn’t identical. The AI-generated code may have different quality characteristics, different failure modes, different maintenance costs. But from the outside, from the perspective of a sprint review or a velocity chart or a promotion panel, it looks the same.
The four-year engineer’s investment didn’t become worthless. But its legibility changed. The thing that made their contribution visible, the pace and volume of carefully crafted code, is no longer the distinguishing signal. What distinguishes them now is judgment, context, pattern recognition, the ability to catch what the AI gets wrong. Those are real and valuable. But they’re invisible on a Jira board, and organizations that run on vibes rather than explicit evaluation will miss them entirely.
The control surface
The fix is not tooling governance, though governance matters. The fix is naming the transition and managing it as the identity-level disruption it actually is.
Name the gap out loud. The single most important thing a manager can do is acknowledge that AI adoption has created a capability divergence on the team, that neither side is at fault, and that the organization has a responsibility to close the gap rather than letting it compound. The conversation nobody is having, “this tool changed what the job is, and we need to talk about what that means for each of you,” is the conversation that prevents the fracture from becoming permanent.
Redefine what “good” looks like. If your evaluation system still rewards volume of code shipped as the primary signal of engineering contribution, you are structurally punishing the engineers whose value is now judgment, review quality, and architectural stewardship. Update the rubric. Make the invisible work visible. I keep returning to this across several pieces because it matters structurally: if you changed the job but didn’t change the evaluation, you’re measuring the old job and wondering why people feel lost.
Invest in the non-adopters as aggressively as you invested in the tool. Pair them with adopters. Give them dedicated time to build fluency. Treat the learning curve as a staffing cost, not an individual performance issue. If someone needs three weeks of reduced output to become proficient with AI tooling, that’s a capital investment, not a performance gap. Budget it accordingly.
Protect the expertise that AI can’t replace. The four-year engineer who knows why the system was built the way it was, who can spot the architectural decision that will cause problems in 18 months, who understands the failure modes that aren’t in any documentation, that person’s value just increased, not decreased. But only if your organization can see it. Make that expertise a formal part of the evaluation framework: institutional knowledge, risk identification, system stewardship. If you can name it, you can reward it. If you can’t, you’ll lose it.
Signals
You’ll know the fracture is healing when code reviews become conversations again instead of rubber stamps. When the non-adopters start experimenting with AI tools without feeling like they’re admitting defeat. When the adopters start seeking out the deep-context engineers for review because they recognize what the AI misses. When nobody on the team feels like they’re on the wrong side of a line that was never supposed to exist.
The Shadow Dev Problem isn’t a tooling problem. It’s what happens when a technology changes the nature of work faster than the organization changes its definition of value. The tool arrived. The identity disruption followed. The team fractured along a line that nobody drew and nobody is managing. The engineers on both sides of that line are doing the best they can with no playbook and no acknowledgment that the job just changed underneath them.
Your team didn’t split because someone made a bad decision. It split because no one made a decision at all. The gap is growing every day you don’t name it.