The Gap

For any sizable software development team, you will find a spectrum. On one end, there are developers who light up at the mention of a new AI coding tool — they've already been using it for a month before you raise it in a meeting. On the other end are engineers who are skeptical, protective of their craft, and frankly unconvinced. Both positions are understandable. Both are sincere.

This isn't really about AI. It's a pattern that plays out with every significant shift in how software gets built — cloud migrations, agile transformations, DevOps, containerization. The technology changes. The human dynamic doesn't.

Consider the developers who resist. In many cases, they're your most experienced engineers. They've seen hype cycles come and go. They have hard-won instincts about quality, about risk, about what "good" actually looks like. Asking them to hand part of that process to a tool that sometimes confidently produces nonsense isn't an easy sell — and it shouldn't be. Their skepticism is often a feature, not a bug.

Then there are the early adopters. They're already faster. They're experimenting, sharing prompts, pushing the edges of what's possible. Left alone, they pull ahead. The gap between these two groups widens quietly, until it becomes a team culture problem.

The instinct for many leaders is to close that gap by force — mandating tools, measuring adoption, making it a performance expectation. It can work, but the cost is real: attrition, resentment, and people who comply without buying in. You get the behavior without the mindset, and that rarely holds.

Most engineering leaders are genuinely proud of their teams. They want to bring people along — to close the gap without burning bridges. That instinct is right. But it requires a different kind of strategy, and knowing where to focus that strategy makes all the difference.

The question worth sitting with isn't how do we force adoption — it's how do we make the value undeniable? That's a harder problem. It's also the one we help teams solve.

Who Actually Lives in the Gap

The trust-based approach is harder at the start — it demands more patience, more conversation, more leadership attention. But the outcomes compound in ways that forced adoption rarely replicates. Across the teams we've worked with, the ones that get there together tend to stay together.

To spend that energy wisely, leaders need to understand where the gap actually lives. Junior developers are natural early adopters — the career upside is obvious, and they have less to unlearn. Senior engineers, once they engage seriously with the tools, tend to find their own footing. Their judgment about when to trust AI output and when to override it is exactly what makes them valuable in an AI-assisted workflow.

Mid-level developers are the heart of most engineering teams. They've put in years of real work to get good at what they do. They've ground through hard problems, built instincts, earned their seat. And now, from where they're standing, it looks like the industry is asking them to hand the keyboard to a machine. That's not an abstraction for them — it feels personal.

This group is often quietly watching for the agent to fail. Not out of malice, but because failure would confirm what they already believe: that real programming requires a human, that the tools are overhyped, that their investment in craft still matters. They are simultaneously worried that AI will take their job and reluctant to engage with it on their own terms. That tension — fear and resistance living side by side — is what makes them so difficult to reach through conventional change management.

These are the developers who need the most from their leaders. Not pressure, not mandates, not dashboards measuring their tool usage. They need someone to help them reframe what's actually happening — to show them that their experience and judgment isn't being made obsolete, it's becoming more valuable. An AI that writes code still needs someone who can tell whether the code is right.

That reframe — widely quoted now, and increasingly hard to argue with — is the one worth internalizing. The developers in the middle of the gap aren't at risk because of AI. They're at risk if they become the last ones on the team who haven't figured out how to work alongside it. That's a distinction leaders need to make explicit, clearly and generously, over and over again.

There Is a Path — But It Takes Work to Find It

The teams that navigate this well don't stumble onto the right approach by accident. What we've seen at Lever10, working with engineering leaders across industries, is that success comes down to two things: leadership that understands the technology well enough to speak to it credibly, and a clear-eyed read of their own team's culture and fears. When both are present, adoption accelerates. When either is missing, the gap widens — quietly, and then all at once.

Every team has its own version of this problem. The middle-tier developers on your team aren't a monolith — they have specific fears, specific histories, and specific things that would actually move them. A generic change management program won't reach them. A leader who understands what's really going on might.

The gap doesn't close on its own. The longer it stays open, the more it costs — in productivity, in culture, and in the talent you'll lose to organizations that figured this out faster. If you're reading this and recognizing your team, that recognition is worth acting on.