Upskilling Developers in the AI Era: What Actually Works

Nobody knows how to build software anymore. I don’t mean that as a doom line. I mean the roles changed, the boundaries between them changed, and the industry hasn’t settled on how we build software now that AI writes a big chunk of the code. Everyone is figuring it out at the same time, including us.

So when a CTO asks me how to upskill their developers for the AI era, I tell them the honest version first: it’s harder than the LinkedIn posts make it sound, and most of the advice out there is aimed at the wrong thing. The advice says “learn these five AI tools.” The real problem isn’t tools. It’s that the job itself got bigger, and you can’t lecture someone into being ready for the bigger job.

I’ve hired and managed developers for more than 20 years, at Full Scale, Stackify, and VinSolutions. Full Scale has more than 350 engineers across 80-plus active clients, and we’ve spent the last two years on the slow work of upskilling software engineers into broader, AI-ready developers. We’ve gotten some of it right and a lot of it wrong. This is what I’d tell another engineering leader who’s trying to do the same thing.

What upskilling developers actually means now

Start with the definition. It’s narrower than the word makes it sound.

Upskilling a developer for AI is not teaching them to prompt an LLM. The mechanical part of writing code is the slice AI got good at, so that slice got cheap. The value moved to everything around it.

The developer who’s worth keeping owns the whole loop:

• Understanding the actual problem
• Defining the requirements
• Designing the solution architecture
• Building it
• Testing it
• Deploying it
• Getting feedback and seeing if it actually helped the customer

The narrow specialist who only does one station on that loop is the role AI is quietly eroding. A front-end developer who only writes components, a back-end developer who only takes a ticket and closes it, is doing the part a model can now do most of. The durable developer runs the entire arc and uses AI to move faster through each stage.

That’s the goal of upskilling: turn specialists into developers who own outcomes, not tasks. If you’re just a coder, the AI era is going to be uncomfortable. If you can take a fuzzy problem and carry it all the way to a shipped, working feature, you’re more valuable than you’ve ever been. The market is already paying for it: PwC’s 2025 Global AI Jobs Barometer found jobs that ask for AI skills carry a 56% wage premium, up from 25% the year before.

Why training doesn’t scale

Here’s the thing that surprised me most, and it’s the reason most upskilling programs fail.

You cannot upskill anyone without hands-on experience. Courses don’t do it, videos don’t do it, and neither does the best internal curriculum you can build. People learn this work the way they’ve always learned it, by doing it on real projects and getting their work reviewed, over and over. It’s an apprenticeship. It takes a thousand code reviews, not a slide deck.

And experience is the one thing a leader can’t distribute evenly. That’s where it gets hard.

We see this every day because of how Full Scale works. We have engineers embedded with more than 80 different clients, and every one of those environments teaches a different lesson:

• Some clients are big enterprises that are never cutting edge. The developer there is doing solid work in a mature, careful environment. They could be brilliant and still get almost zero exposure to AI, because the client moves slowly and isn’t pushing it.
• Some clients are small and innovative and jumped straight on AI. The developer there is learning at the frontier every single day, because the work demands it.
• Some clients have a single developer working alone. There’s nobody on the client side to learn from, and often nobody with the authority to push an initiative like adopting AI tooling through. That developer is on an island.

So you take two equally talented engineers, give them the same training, and a year later one is far ahead of the other, not because of ability but because of where they happened to be placed. The reps weren’t equal.

This is the real reason “just send them to a course” fails. The course was never what taught anyone. The work did, and the work isn’t uniform.

It’s also a quiet warning for the buyer. If you run an engineering org that isn’t aggressively using AI, your own developers are falling behind right now, and you probably can’t see it. They’re doing fine work in your environment. They’re just not building the muscle the market is about to demand.

You have to hire learners

If experience is what builds the skill, then the most important thing you can do for upskilling happens before anyone is hired.

You have to hire people who are wired to learn.

My whole message to our engineers about surviving this shift comes down to one word: curiosity. Stay curious about how AI is changing the job and curious about how you can use it, and you’ll adapt. If you’re not curious, you’re in trouble, because this career never stops changing and never has. That’s the same argument I make at length in Product Driven, my book on building engineering teams that own outcomes.

So we screen for how someone thinks, whether they go learn the thing they don’t know, whether they can reason about a problem they’ve never seen. It’s why our skills assessment for developers is a real conversation, not a timed coding test. Our acceptance rate runs under 3%, but I want to be careful about how I say that, because the screen isn’t the magic. A tough screen tells you how someone did on a test one afternoon. What actually compounds is whether that person keeps learning for the next five years. The hiring decision is really a learning-rate decision.

The opposite of this is what I call cheapshoring: hiring the cheapest hands you can find and treating developers as interchangeable labor. That model was always shortsighted. In the AI era it’s a disaster, because the cheap-hands developer is exactly the one whose job AI is absorbing.

Junior developers are the hardest case

Upskilling junior developers is its own problem, and AI made it sharper.

Juniors reach for AI before they have the judgment to check it. A senior developer uses an AI tool the way a manager uses a fast employee: they delegate the typing and then review the output, because they know what good looks like. A junior doesn’t have that internal sense yet, so they accept whatever the model gives them. The code looks right. They can’t tell that it isn’t. This is why I think of AI pair programming as a skills test, not a speed boost: it’s a speed boost only for the developer who already knows what good looks like, and it exposes the one who doesn’t.

None of that means keeping AI away from juniors. It means being deliberate about how they use it. The old apprenticeship was a senior reviewing a junior’s code. The new apprenticeship is a senior reviewing a junior’s code and the AI’s code together, and teaching the junior how to tell the difference. The teaching surface is still code review. AI just put more on the table to review.

What we actually built

Once we accepted that experience is the teacher and that our client environments don’t hand it out evenly, the answer became obvious: we had to manufacture the reps ourselves.

We built an internal program called the Spartan Training Academy for all 350-plus of our engineers. The flagship is a Claude Masterclass series, with live sessions several times a month that run from beginner AI workflows up to advanced agentic programming, things like wiring an AI agent into GitHub, databases, and Slack and running review-and-approve flows in CI/CD. On top of that we put out short training videos every week and longer ones every couple of weeks, and most of those are recorded by our own engineers teaching each other. It’s peer to peer, not handed down.

My reasoning is blunt:

I don’t want to get a year down the road and have clients give back half our developers because they never learned AI and now they’re behind the times. We refuse to be in that position.

I’ll be honest about the messy part too. Inside any group of 350 engineers, you’ve got people on the leading edge, a big middle pack, and some laggards who just don’t believe the hype or don’t want to change. That spread isn’t unique to us. Stack Overflow’s 2025 developer survey found 80% of developers now use AI tools, even as their trust in the accuracy of those tools fell to 29%. People are using AI and still unsure of it, all at once. You don’t get all of them onside with one program. We use both carrots and sticks, and at this point I think the team has had more AI training than they want. That’s roughly the right amount.

The program itself isn’t really the point. The training just gives everyone a baseline of reps their specific client wasn’t going to hand them. The real learning still happens on the work. The Academy makes sure nobody is starting from zero when the work shows up.

What an engineering leader should do Monday

If you’re a CTO or VP of Engineering and you can’t stand up an internal academy this week, here’s the honest short list. It’s part of how the CTO job itself has changed in the AI era: less about the code, more about the people and the judgment around it.

1. Hire for learning rate, not framework checklists. Screen your next candidates on how they think and whether they teach themselves. That’s the biggest upskilling decision you’ll make, and it happens at the door.
2. Make AI mandatory on real work, and use code review to teach. Reps beat courses. Put the tools in front of people on actual projects, then review the output together. Don’t let it be optional, and don’t let it be unsupervised.
3. Widen scope on purpose. Take a specialist and hand them the next station in the loop. Give the back-end developer the deployment. Give the front-end developer the requirements conversation. Discomfort is where the growth is.

Be honest with yourself about the cost. Widening scope and pushing AI onto real work slows a team down for a while. A specialist who picks up deployment will be slower at it than whoever owned it before, and the first few sprints feel worse, not better. Upskilling employees is never free in the short run. So contain the cost instead of pretending it isn’t there: start people on lower-stakes work, pair them with someone who’s already strong, and keep the review tight until the judgment shows up.

Or you can partner with someone who already built the muscle. That’s a real part of why companies use staff augmentation with us instead of hiring direct. They get developers who’ve already been trained on AI workflows and who keep getting trained, instead of inheriting a team that quietly fell a year behind. AI is already standard practice in this kind of work: Deloitte’s 2024 Global Outsourcing Survey found 83% of executives already use AI inside their outsourced services. Our retention runs above 93%, which matters here more than it looks, because the judgment a developer builds only compounds if they stay long enough to build it.

The companies that win the next few years won’t be the ones with the fanciest AI tools. Everyone will have the same tools. They’ll be the ones whose developers learned to own the whole problem, and who hired for that on the way in.

If you’d rather not wait two years to build that muscle in-house, book a call with Full Scale and we’ll talk through what your team needs.