The Invisible Divide: AI Is Creating Two Classes of Developers

Something quiet is happening inside development teams, and most technology leaders don’t see it until the friction becomes impossible to ignore.

On one side, you have developers who adopted AI early, retooled their workflows, and now operate at a different speed and altitude. On the other, you have skilled, experienced engineers who haven’t made the jump. Not because they can’t; because they won’t, or because nobody showed them what was possible.

The result is two classes of developers forming within the same organization, with different instincts, priorities, and definitions of what ‘doing the work’ even means.

For CIOs managing modern development organizations, understanding this divide is the first step toward closing it.

It’s Not a Skills Gap. It’s a Willingness Gap.

The instinct is to call this a skills problem. Train the team on AI, close the gap, move on. But the real barrier runs deeper.

“I’d say it’s about 70% willingness, 20% skill, and 10% just not knowing what’s possible,” said Doug Compton, Principal AI Developer at Slingshot. “Some developers don’t go out and research on their own, so they just think AI is a coding assistant. They don’t realize it can do more.”

That breakdown matters because each piece demands a different response. A skills gap responds to training. An awareness gap responds to exposure. But a willingness gap? That requires something harder to deliver: trust, proof, and a reason to care.

Nathan Thomas, Senior Developer at Slingshot, sees this firsthand with other teams: “The biggest barrier is willingness. I’ve seen developers who have all the tools at their disposal. Some use them, but a lot just don’t.”

Most organizations already have the licenses, the subscriptions, and the infrastructure in place. The tools are sitting right there. The divide isn’t about access. It’s about adoption, and the tangled reasons behind why capable professionals choose to sit this one out.

When AI Removes the Part Developers Love Most

There’s a dimension to this divide that rarely gets airtime in leadership conversations: identity.

Development attracts a specific type of thinker. People who love solving deep logical puzzles, who get energy from wrestling with complex problems line by line. AI changes that equation in ways that feel personal.

“A lot of developers are people who likes to think deeply, dig into puzzles and problems,” Doug explained. “Some of the parts they enjoyed about development, now the AI handles. They’re stuck with the stuff they don’t really care for: managing AIs, massaging business requirements, coming up with prompts and plans. That’s just not as enticing for some developers.”

This reaction isn’t stubbornness or technophobia. For some developers, AI doesn’t feel like an upgrade; it feels like the job they signed up for is disappearing, and what’s replacing it doesn’t light up the same part of their brain. The role is shifting from writing code to orchestrating systems, and that shift doesn’t appeal to everyone equally.

Tech leaders who dismiss this as resistance miss the real signal. Developers who push back might be telling you something important about how the role needs to evolve, and about the kind of support, reframing, or redirection they need to make that transition successfully.

The Amplifier Effect: Fast Gets Faster, Slow Gets Slower

One of the most counterintuitive observations about AI adoption is that it doesn’t level the playing field; it tilts it.

“The developers who were fast before are still fast,” Nathan said. “If people who were fast before pick up AI, they’re even faster. And the people who were a little slower? Even with AI, they still end up slower. Everyone is faster than they were, but the gap between the two groups hasn’t closed. If anything, it’s grown.”

AI functions as an amplifier, not an equalizer. The developers who already brought strong instincts, architectural thinking, and velocity to their work now multiply those strengths through AI. Meanwhile, AI doesn’t suddenly transform developers who already struggled with throughput.

This shift changes how CIOs should think about team composition and capacity planning. If AI amplifies existing strengths rather than compensating for weaknesses, the real investment isn’t just to hand everyone the same tools. It’s to invest in the foundational skills and habits that AI amplifies best: systems thinking, architectural instincts, clear communication, and the ability to manage multiple workstreams at once.

Doug reinforced this point from the AI side of the equation: “AI is probably one-and-a-half times slower than a senior developer at getting something small done. But you can have four of them all doing it simultaneously. That’s where you get your efficiency gains. And that multitasking? That’s a skill developers need to learn how to build.”

Code Reviews Have Become the Frontline of the Divide

If you want to see where the invisible divide becomes visible, look at your code review process.

“The people who don’t want to utilize AI end up being a lot more picky when they review AI-generated code,” Nathan observed. “They ask questions they probably wouldn’t ask during code reviews of someone they trust to do the work.”

It’s not intentional obstruction. It’s what happens when one group of developers holds AI-generated code to a higher standard than human-generated code, not because it’s lower quality, but because it came from a source they don’t trust. The friction plays out in pull requests that stall, review cycles that double, and a general slowdown that cancels out the speed gains AI was supposed to deliver.

Nathan captured the tension clearly: “Someone asks why the developer wrote the code a certain way, and the honest answer is that’s how the AI did it. But what the AI wrote is valid and works; there’s no better or worse alternative. So does it make sense to sit there and pick it apart?”

Beyond the interpersonal friction, the code review process itself needs to evolve. The traditional model of line-by-line human review simply cannot scale in a world where AI generates pull requests at a pace no team can manually absorb.

Doug advocates for a two-phase approach: “Have AI do code reviews first. Use a separate model, a separate process, something that doesn’t carry bias from the code itself. Have it check for adversarial patterns, code quality, and business requirements. Only after it passes that review do the humans look at it, and at that point, I’m looking from an architectural perspective, not line by line.”

Results Speak Louder Than Mandates

So how do you close a gap built on willingness, identity, and trust? Not by mandating AI adoption from the top, but by proving its value from the middle.

“The best thing to do is just show what you’re doing and what the results are,” Nathan said. “It’s kind of a slow burn. You’re doing it this way, and eventually it’s hard to ignore.”

Nathan described this as a results-driven approach and stressed that it works precisely because it doesn’t require buy-in upfront. Developers who see a colleague shipping faster, solving problems more efficiently, and earning recognition for their output will start asking themselves the obvious question: ‘Why wouldn’t I do the same?’

“You go high enough up in an organization, you’re going to find someone who’s results-driven. That’s how it works,” Nathan added. “You prove it in the trenches, and it makes its way up. People start seeing the success and naturally want to replicate it.”

Doug agreed and took it a step further: “Identify a champion: somebody who’s already interested and using it. Have them share tips and tricks. Start with the small things that make their work easier, so they get used to it before you get into the harder stuff. Dip their toes in first. Don’t mandate it.”

This champion-first model sidesteps the resistance that top-down mandates create. It gives skeptics space to observe, ask questions, and opt in at their own pace. And for developers who resist AI for personal or philosophical reasons, Doug recommends something even simpler: address their concerns directly. If they worry about job security, reassure them. If they worry about environmental impact, share what the company is already doing. Meet the human concern before pushing the technical solution.

Training That Meets Developers Where They Are

Slingshot’s internal approach to closing the divide offers a practical blueprint. Doug runs weekly AI training sessions for the development team, and the structure is as important as the content.

“It started simple,” Doug said. “I had one session that was about onboarding your AI like it’s a new employee. How do you bring AI into your project so it knows the information it needs to be useful, rather than a nuisance you have to correct? Then you slowly expand from there into efficiencies and business improvements, once the foundation is in place.”

The key insight: don’t overwhelm. Developers already face a massive cognitive load managing complex systems. Dumping an entirely new way of working on top of that is how people check out; little by little wins.

Nathan confirmed this approach: “The training builds on itself, so it’s not all at once. AI tends to be a lot, especially when you start reading what it’s outputting and trying to understand it. They introduced it to us piecemeal over time so that we could digest it.”

But the best measure of success isn’t attendance. It’s what happens after the sessions end.

“One of the things I’ve enjoyed most is the people who direct message me afterward,” Doug said. “I can tell they’re excited about it. They reach out, ask questions, and say thank you. That always makes me feel good, thinking I’m actually helping people.”

Slingshot also invested something rarely discussed but essential: time. Leadership allocated two hours per week of non-billable time specifically for developers to learn, play, and experiment with AI tools. That investment sent a signal that this wasn’t a side project or a personal curiosity; it was a company priority backed by real resources.

The Divide Won’t Close Itself

The invisible divide forming within development teams isn’t temporary, and it won’t resolve on its own. Left unaddressed, it creates friction in code reviews, tension in team dynamics, and a widening performance gap, turning capacity planning into guesswork.

But the answer isn’t a mandate. It’s a combination of visibility, empathy, and structure. Identify the real barrier (willingness, not skill). Acknowledge the identity shift AI creates for developers who love the craft of writing code. Put champions in place who lead through results, not authority. Build training programs that respect your team’s cognitive load. And invest real time and resources to signal that this matters.

The organizations that close this divide won’t just have faster teams. They’ll have more unified ones, operating with shared language, shared tools, and a common view of where the work is heading.

The question isn’t whether your team has two classes of developers; it almost certainly does. The question is how long you’re willing to let that stay invisible.

Slingshot