There’s been plenty of chatter about AI’s effect on jobs. Will everyone get laid off to train AI? Will every developer become a super generalist? Are there new roles rising from the ashes? But Corey Hymel, head of research at Andela, wanted numbers behind that chatter. He and his team looked at nearly 50,000 job postings to find the skills and roles that are emerging before the industry has properly given them titles. I spoke with him to find out what that research says about the new developer skillsets that land permanent roles.

Q: You did this research on how skills shift and change in job titles. Could you give an intro to the project?

A: At Andela, our general approach and methodology to the market is that job titles and resumes are the best worst thing that we have out in the world right now. We’re obsessed with understanding very fine-grained skills of what people are able to do.

That’s premise number one. Premise number two was that we hear very commonly “Oh, AI is changing jobs. Oh, AI’s gonna get rid of jobs,” or, “AI is gonna create new jobs.” But it’s all very anecdotal and not very data-driven. We looked at it and said, “Is there a way that we can actually go in and put some numbers and some rigor to actually understand what’s going on behind the curtains with all of these jobs?” We’ve got an internal skill taxonomy and ontology that we use that grounds all of this and is the base of the research and data structure that goes in.

But for us, it’s really important because the other big side of our business is around learning and upskilling. So how can we provide our customers information around where the industry is heading? Here are some skills that people should be learning that we’re seeing become more common. These are the roles. Some of these might fall in between two. While you might say “Front-end engineers need to go learn this,” actually you probably should pull in product managers as well. I think job titles have always lagged the work, but especially now it’s getting worse and worse.

Q: So it’s not necessarily about job titles changing, but more about new skills being applied to existing job titles and mid-range roles appearing. I think you talked about DevSecOps as an example of a bleed role.

A: Exactly. What I’m seeing in the news pretty frequently is this pervasive narrative that AI’s gonna make everyone a generalist, and it’s just turning these jobs into gray jobs where skills can bleed all over.

And what the data shows is that isn’t true. There are very niche skill bundles that are either forming as net new roles that no one’s talked about yet, or the underlying skills within historical roles are starting to change.

From the labor market or the hiring side, it’s either happening so quickly that people can’t keep up with it, or enterprises don’t really know what skills people should be learning, so they just default to a generalist title like “AI engineer.” What does that mean? There are 100 different flavors of what that could be. But for them it’s just easier to say “Oh, we need someone that does AI.”

Q: At re:Invent last year, Amazon’s CTO Werner Vogels talked about the T-shaped developer, where you have a deep focus but a broad base of understanding. Does your data reflect that? Or are you seeing a more specific concentration of these skill bundles?

A: I’ve gotten that question a few times, and transparently, I’ve not followed up with it as much as I probably should have. You have the T shape and you have the I shape, and I think there’s a star shape. From what we’re seeing, the T shape does typically follow the pattern in the data. But I don’t have a definitive answer on that yet.

Q: That’s something I’d love to know because, anecdotally, I hear a lot of people talking about this broadening of what a full-stack developer is — covering everything from product design to SRE. I wonder if people are actually hiring roles for that or if that’s just something that happens within organizations.

A: We didn’t see in the data this idea of a net generalist. But what we are seeing is that if you look at the typical flow of the software development life cycle — if you put roles down in some linear fashion of product manager, then front-end engineer, back-end engineer, DevOps, and then QA — the bleed between those roles is where we’re starting to see the most common mix of skills.

For instance: the front-end product engineer. This might be like an F-shaped engineer, meaning they lean to one side — they might have a background in front-end engineering, but now they’re being asked to stretch into a product role to talk to customers, get feedback, prioritize a backlog of features, and so on.

We’re seeing the same thing on the back-end and the DevOps side — back-end engineers now needing to know about deploying models into production and thinking about scalability. That F goes in the other direction.

Q: That F shape is interesting. With AI, now that you’re able to touch the things that are closest to you, you can branch out — back-end engineers can start touching the database and things like that.

A: Even to some degree merging over into production, and even into the front-end side too.

Emerging Skill Bundles

Q: What are some of the skill bundles that you saw in the research?

A: One of the ones our customers often describe but never label was this idea of an LLM application engineer. This is someone that’s very versed in building products on top of LLMs, whether it’s OpenAI APIs, open weight models, or Claude. They know how to plug into the APIs, but they can also take the step beyond that — meaning they know how to construct the harnesses.

They’re familiar with things like evals, which when we talk to customers, they tend to think of as just a back-end engineering concern. But that’s a very specific skill set. Your classical back-end engineer will not necessarily know about building agent eval harnesses or governance and guardrails. That role showed up as quite prevalent in the data.

Another one I’ve heard a few times is that 2026 and 2027 is going to be the year of the CFO — specifically around how to deal with consumption spending. New products are all on consumption models, and your developers are generating new kinds of OpEx spend. A FinOps reliability engineer is someone able to think about project development while factoring in cost — not just typical end-user cloud consumption, but also developer tooling. When we’re building AI-native SDLCs, people talk about financially responsible ways to do this. We hear a lot about how to optimize and reduce token spend, and when to use cheaper or faster models for simpler processes versus more capable models for highly complex tasks.

The last one was a docs-as-code engineer.

We hear a lot about spec-driven development, and it’s often treated like something that should be pushed directly down onto developers. In reality, there is a new role emerging where people who were doing classical technical writing or classical documentation are proving to be some of the best spec-driven engineers. They construct context better than developers can to feed into new models, and they set the context for long-term agentic development on larger codebases.

Q: The LLM application engineer is an interesting one — I hear a lot from people that everybody should be building their own software factory. It seems like this is something you’re expected to do as an individual engineer no matter what, because everybody’s going through an agent and doing evals on their own code. It’s interesting to see that these skills appear as specialized clusters in the data.

A: I think that’s the big insight with all of this. It challenges the narrative that either everyone’s just going to be an expanded full-stack developer, or everyone’s just a generalist who can do everything now. In reality, we are seeing statistically significant trends of specific skill groupings emerging in hiring and job data.

Why Job Titles Still Matter

Q: Did you notice anything about job titles? Do they matter for these skill groupings?

A: In my opinion, job titles are important, especially in this context, because they give enterprises a way to better describe the work that needs to get done. When you look at how a job gets created inside an enterprise — specifically the job title — you’ve got the individual closest to the work, often someone within the team. But there are layers on top of it: HR, then finance, then procurement, then eventually a recruiter. You get this chain of custody, and the work gets more ambiguous as it passes through that chain, not only in the description but in the understanding of what the role should be. That’s where the fallback to a generalist title becomes easier.

I hope that with more specific job titles, everyone from the person closest to the work all the way to the recruiter is able to accurately describe exactly what needs to get done. A better title reduces time-to-hire, surfaces better candidates, and sets everyone up to succeed.

From the candidate side, imagine you’ve been a back-end engineer for 20 years and you see a back-end engineering role. You just hit apply because you need a job. The odds of ending up in a position where you won’t be successful is relatively high because the underlying skills, requirements, and expectations could be vastly different from what you know. That’s why these new, more precise titles matter.

Talent Debt

Q: In the research post you talked about talent debt. What is talent debt?

A: Talent debt accrues the same way that technical debt does. But the difference is that the skill half-life is shrinking substantially. Back in the day, you could get a job as a Java engineer and work for 20 years doing Java programming and be fine. But now the pace of change is so fast that the half-life of how long those skills stay relevant is shrinking substantially.

What you get is skill compression, which then forms into talent debt. A lot of companies are experiencing it now — this race into AI has led them to look at what they have on the bench and realize the gap between existing skills and what the work now demands is wider than expected. Closing that gap proactively, through upskilling and clearer role definitions, is how organizations avoid letting that debt compound.