The AI skills gap is real (but it’s not what you think)

Estimated reading time: 8 minutes

Key takeaways:

• Coding is no longer the bottleneck. The real AI skills gap is in understanding architecture, slicing problems into testable chunks, and connecting code to business value.
• The ZIRP era masked deep engineering dysfunction.
• Don’t staff up with AI, skill up with it. The teams that win won’t be the ones who use AI to write more code faster. They’ll be the ones who use it as a reset to build better engineering habits.

---

Engineering teams are right to worry about AI skills gaps, but they’re often identifying the wrong ones.

AI reveals what we’ve always known: coding was never the bottleneck. Engineering value comes from understanding architecture, concepts, and business value, and then connecting these to problems that teams can solve in iterations. 

The biggest AI opportunity isn’t about AI at all. Instead, organizations return to the essence of engineering: breaking large problems into structural, testable questions with fast feedback loops. That’s the skills gap teams need to close. 

Coding as commodity

In The AI Measurement Crisis, our team at Uplevel found that 50% of engineering leaders expect code generation to require the least human effort, and 56% believe software development will be the most transformed by AI.

AI-coding tools turn code into a commodity and coding into a skill that can be accelerated or automated. Code fits into systems and markets like a widget, not an artisanal product. Code volume is now something we can turn up with a dial.

Amid these expectations, 88% of engineering leaders rate themselves as “prepared” or “very prepared” for AI implementation. Yet 98% say they lack sufficient in-house capabilities to support it. 

Nearly all leaders recognize an AI skills gap, yet most feel prepared to bridge it. What we can’t seem to agree on is what that means. As code becomes a commodity, coding differently is not the primary skill developers need to learn.

The new AI skills

It’s tempting to assume the AI skills we should emphasize are the ones that relate directly to AI. However, the questions we need to ask go beyond “should we use Claude or Copilot?” or “how can I get more boilerplate written?”

The new AI skills will resemble core, familiar engineering principles like identifying user needs, building testable slices, and operating abstraction layers that are refreshed and renewed. Without these skills, you can only use AI to optimize 20% of your development cycle.

1. Identifying user needs

The engineering role needs to expand beyond writing and shipping code. For decades, many companies have treated engineers like ticket-completers. Product writes a ticket, engineers write the code, and testers check for quality. That form of coding will suffer the most from Large Language Model (LLM) displacement. You can’t listen to instructions better than an LLM. 

That’s an opportunity! AI allows engineering teams to spend more time getting their hands dirty, understanding what to build and how to build it. That level of interaction with real users isn’t something AI can do as well. When you sit down to code, quantity will shrink and quality will rise. 

2. Building testable slices

Teams are doing more with less, and Quality Assurance (QA) resources are being squeezed. With LLMs increasing quality issues (our research found a 41% increase in bug rates), developers need to make testing and quality core skills. 

Of course, the edict here isn’t simply “do better.” Engineers need to learn how to slice projects into testable, deployable increments. The smaller you get while maintaining completeness, the faster you can iterate. 

Speed of iteration is a speed that matters. AI can speed up coding and testing, but engineers need to do the slicing. That’s an engineering skill, not a commodity skill.

3. Using developer abstractions effectively

A developer abstraction layer includes, but extends beyond, the CI/CD tooling. It simplifies a developer’s interactions with complex systems, allowing them to work without understanding every detail. 

Many teams recognize its importance but haven’t built a proper one. They’ve bolted together tools that could contribute to an abstraction layer but don’t yet function as one. Most teams still take tickets and make changes rather than operate a system optimized for deployment.

Teams need to find a balance. Offer approved patterns that speed up development while keeping things secure, and encourage experimentation. As the AI market booms and tools proliferate, this only becomes more important. 

ZIRP incentives have taken us to a breaking point

The skills mentioned above have always been core to engineering success. Why emphasize them now?

Zero Interest Rate Phenomenon (ZIRP) changed the game. From 2008 to 2022, money was cheap enough and lasted long enough that working within this environment is all many engineering leaders know.

However, as Gergely Orosz puts it: “A ZIRP is the exception and not the norm, over time.” This period wasn’t meant to last, but the industry came away from it with lasting bad practices.

ZIRP made it cheap to avoid core engineering skills. Instead of building those skills, companies could throw more engineers at problems, both technical and organizational, creating unseen organizational debt.

At the same time, companies could recognize systemic issues but overlook their nuances. Teams could build developer pipelines and consider the problem solved without evaluating whether bottlenecks limited effectiveness. They could run into issues, then simply hire up to cross the gaps.

We were heading for a breaking point long before ZIRP ended, and now it’s here. We created a lot of complexity, and the tech debt bill was always going to be due.

Build incentives to support new skill development

The industry’s approach to ZIRP was expensive, but money was cheap and hiring was easy. Figuring out systems-level problems is difficult. 

AI gives us the opportunity to reset and rediscover old knowledge, refreshed with new technology. These skills tend to be intangible, which makes them hard to sell in presentations, hard to see without quantitative metrics, and easy to believe they’re executed when they’re not. 

Until now, there hasn’t been enough incentive to get engineering teams to think and work outside of their boxes. Ironically, the rise of AI is making engineers realize they were working like robots – taking tickets, writing code, and passing tickets on. 

1. Embrace the pain and resist sunk cost

Change has a cost. So does sticking with the status quo. Face the fact that tradeoffs will be inevitable. Embrace the reality that those costs aren’t always financial. Sometimes, you resist walking away from investments to save face. 

During ZIRP, system problems didn’t feel painful enough because we could soften the blow by hiring up. The positive side of pain is that we can use it to force ourselves to face the failure of old incentives, and the necessity of building new ones. 

One of the biggest risks of AI is that we adopt it to avoid facing sunk costs. As principal engineer Bryan Finster writes: “without upstream clarity and downstream automation, faster coding leads to more defects, more rework, and more outages per delivery.” 

The pain of leaving upstream and downstream issues unfixed is coming regardless. You make a living studying the pain points of users. It’s time to feel yours.

2. Upskill your current engineers instead of hiring new ones

You don’t need to keep hiring. Period. Hiring is necessary, but it should not be the default solution to issues with productivity, velocity, and scale. AI will make this painfully obvious.

As Finster explains: “without AI, the pain is often like a low-grade ache. People live with it and become used to it. With AI, it’s like breaking your leg because AI amplifies everything.”

Fix your systems and upskill your engineers before amplifying them. Support engineers through the transition from ticket-taking to adopting more responsibilities. Create a Center of Excellence (or similar, if you don’t like the corporate jargon) to support people through the learning process. 

This isn’t just a switch you’re flipping. You’re building a long-term pipeline that will upskill engineers over time – new ones, when you do hire them, and on an ongoing basis as technologies change. 

3. Organize for outcomes and continuous learning

Teams know how to adopt new technologies. It’s easy to watch a few developers try a tool and then buy a team-wide license. That was never the hard part.

The hard part is that most of us don’t know how to use adoption to influence business outcomes. We take up new tools and move a little faster (we think), get a little bit more done (we assume), and call it a day. 

Our new goal is to teach behaviors, not technologies. Once you teach and reinforce the right behaviors, you can innovate forever. When you become a learning organization, you’re not brittle to future changes. New technologies emerge, and you can test them, adopt them, and fold them into a long-standing methodology for translating processes and tools into business value. 

Closing the AI skills gap

Many leaders think their job is singular: make money for the organization. A leader’s role can’t be narrow, even if you want it to be. 

Leaders are always building incentives, casting visions, encouraging certain behaviors, and teaching particular ways of thinking. Much of this is implicit. What do you reward? What do you prioritize? What do (and don’t) you talk about? 

Some organizations will be tempted to avoid this responsibility. They’ll try to recreate ZIRP-era strategies by “staffing up” with AI. This remains a short-term strategy at best. 

AI will make it harder to avoid the hard problems. Leadership includes education and change management. You’re doing it already, whether you want to or not, and if you don’t embrace it, then you’re likely doing it poorly. Why not do it well?

Get articles like this in your inbox

Choose your LeadDev newsletters to subscribe to.