I Analyzed Hundreds of AI Job Postings. The Same 7 Skills Showed Up Everywhere.

[0:00]So there are essentially infinite AI jobs right now, not growing demand, not a hot sector, none of that is true. It is functionally infinite. And that's true for businesses employing 10 to 20 people, as much as it's true for businesses employing hundreds of thousands. There is no functional upper limit to what employers would love to have as far as AI talent. And they cannot find them. After hundreds of interviews on particular roles. I am hearing from employers, we can't tell the role. And I hear you saying that must be a lie. I have applied for hundreds of AI positions, I am good at AI. It is not working. I get it. We have a K-shaped job market right now. And there is a split in what employers want that is confusing this issue. Because many employers who don't fully know AI are taking advantage of this situation by basically putting resumes out as learning tools. And then they use the interviews to learn from the talent what they need, which is really terrible, right? Like that's not the way you should be interacting with talent, it doesn't bring the best people to you, and it leaves a bad taste in everyone's mouth. There are also plenty of people who are looking for roles, who are either overstating their capabilities or who don't have the actual skill sets needed to thrive in AI. I'm not talking about being able to chat with an AI, right? I'm going to give you in this video seven specific skill sets that I have pulled from looking at hundreds of actual AI job postings. And then looking underneath at what the sub skills building those skills are, and I've gone farther than that, right? I'm not just going to talk about the skill sets, I'm going to talk about how you develop them. I'm going to put up a guide on the substack that helps you to actually get to those skills. And I'm going even farther than that. I'm putting together a hiring board because I think it's really, really confusing right now to have AI talent and AI hiring managers mixed in with everybody else. Because then you're like looking among all of these PM jobs, which are the AIPM jobs, which are the whitewashed AIPM jobs where it's just like we say AI, but we don't mean it. And I'm trying to fix that. Because I think it's time to bring some simplicity to this, hiring doesn't have to be as hard as it is. Okay. Before we get into all of that, let's dive in to what's actually going on in the job market. Fundamentally, the AI labor market is actually two markets moving in opposite directions. When I talk about K-shaped, I mean it. Market one is the traditional knowledge work roles, right? The things that we've all learned since the 2010s, generalist product managers, standard software engineers, conventional business analysts. And there's no other way to say it. I'm sure you're not surprised. That job opening count is flat or falling, it is not growing. Because most of the interest, most of the investment, where businesses are investing to grow, it's on the AI side, and that's the other side of the market. It's roles that design, build, operate, and manage AI systems. And that is growing fast. In fact, I've been kicking around tech for multiple decades and I have never seen it this hot for this kind of a job family. The ratio of AI jobs to AI talent right now is 3.2 to one. In other words, there are three plus AI jobs for every single qualified candidate right now. They can command their price and they do. If you want specific numbers, this is from a manpower group survey, which found 1.6 million jobs, which I think is low, and only about half a million qualified applicants, which I think is pretty fair. And that's leading to a very long time to fill the roll, 142 days to fill an AI role, which is almost half a year. And so the people who tell me I'm lying when I say that this market exists, I get it. If you're not in that half a million category, it does feel impossible because the entire rest of the job market is condensing into commodity. But if you're on the other side, you get it. This is a world where you can write your own ticket because people are desperate for these skills. So, without further ado, I don't want to belabor this. Let's get into what these skills are. I want this to be the most useful video on these skills because I went and I looked at all of these AI courses before I made this video. Because I was like, surely, someone out there has made a video that is based empirically on the AI job postings, backward analyzes them, decomposes them into sub-skills and gets very specific about what employers are hiring for that is a learnable skill. And by the way, this is easier than other information tech revolutions. If you think this is hard, when you were getting a personal computer in the 1980s to learn how to code, you had to fork over like 15 or 16,000 in today's dollars to do that. It was ridiculously expensive. It was heavily gated by your ability to afford stuff. Now, it's much, much easier. Almost anyone has access to an AI subscription if they want. AI can actually help you learn. We can do this. And we're going to start with the most fundamental shift of all. People sometimes call this prompting. I've talked a lot about prompting. I want to use the term that I am seeing more and more in job postings, and that is specification precision or clarity of intent. You have to learn to talk English to a machine in a way a machine takes literally. We are used to working with humans that read between the lines. We're used to working with humans that can infer from our intent pretty reliably. One of the reasons we know that general intelligence is not really here yet is that agents don't do a good job of that. Agents need us to be specific. An agent is going to take whatever specification you give it and go and build something. And if you're not clear about what that is, the agent is going to try its best to fill in the blanks, but that won't reliably reproduce your intent. Agents are bad at filling in the blanks. And yes, I'm going to give you a specific example. Let's say you're trying to improve customer support. But you're not giving something to a principal engineer where you say, hey, come up with a solution on customer support. You've read the tickets. We're not going to be that vague. Instead, we're going to be clear about what we care about in the prompt to the agent. This is the difference that job posters are looking for. You need to be able to say to the agent, I want you to build an agent that handles tier one tickets. I want you to be able to handle password resets. I want you to be able to handle order status inquiries. I want you to be able to handle return initiations. I want you to know when to escalate to a human based on customer sentiment. And I want to define customer sentiment in such a way for you here in these docks that you know how to measure it and score against it and escalate appropriately. I want you to log every escalation with a reason code. You have the same intent here, but you notice how specific that is? That is what the bar is for prompting in 2026. You have to be able to be that clear in your intent. Now, if you're a technical writer, if you're a lawyer, if you're a QA engineer, a lot of this is going to feel super familiar because you've done this kind of technical writing before. The gap is shorter than you think. For many of us who are not used to writing this specifically, it is a new skill, but it's absolutely learnable. All it takes is understanding in detail what you intend to put together. And I'm putting these in a specific order because this is actually the order you intuitively learn them in. I'm putting them in a sequence that makes sense for you. Once you specify what you want precisely, you immediately run into the next problem, which is did you get it right? Did you get what you wanted? We call that evaluation and quality judgment. And it's the single most frequently cited skill across all of the job postings I've come across. I'm not sure employers all get it, and I'm going to define it really clearly here. This is something, by the way, that is in engineering job postings, and ops job postings, and PM job postings. People talk about having an agentic evaluation mindset, whatever that means. And they want you to be able to do automated evals and simulation runs, et cetera, et cetera. Upwork has job postings that demand evaluation harnesses for functional task and longitudinal metrics, right? They're talking about building ways to test whether the AI does a good job. Every single posting will use slightly different versions of this, but really it comes down to being able to build systems that encode evaluation and quality judgment. And this is what all of that taste discourse is all about, it's just dressed up in skill language. And really, I get why people are pushing back on taste because when you talk about this is taste, it just feels vague and un-actionable and it just strokes the ego. But really what we're talking about is error detection with a degree of fluency. AI has really different failure modes from human failure modes. AI is often confidently wrong. It's fluently wrong, whereas humans when we're wrong, we tend to stumble. There's a lot of tells we have that we're used to hearing and seeing other people that don't show up with AI. And so if we're not used to working with AI, we may incorrectly see the confident response AI has and assume that that's true and right and correct. And I see this a lot, by the way. If you think this doesn't happen, I have seen it happen in real presentations where people will say, well, the AI presented it and it looked correct to me and look, it has all the right headers and this and that. And I'm like, yeah, but use some critical thinking here, this isn't actually correct. I don't care how confident the AI was. The skill here is resisting the temptation to read fluency by the AI as competence or correctness. It's just not. Another sub skill here is what I call edge case detection. You can show that you understand a subject deeply when you are able to look at the response from the AI and say, you know, this is correct at core, but the edge cases are wrong. I think Anthropic's engineering blog actually does a really good job of explaining how this taste is actually a learnable skill. What they say is a good eval task is written when more than one engineer looks at that eval task and would come to the same conclusion on a pass-fail basis. In other words, excellent evaluations are something we can all agree on and we can all learn to write. If you're an editor, if you're an auditor, these are the kinds of skills you're using all the time, you're just applying them in new ways. If you're not, this is the gold standard skill. Skill number two here, this is the one that's mentioned the most, and we all are going to have to get good at it, whether or not we have engineering on our title. And really the the best and simplest way to get good at this is to start reviewing AI output as if it has your name on it. Care about it, insist that it be correct, insist that it be right. And then as you start to build agentic systems, which is a learnable skill, we'll get into, you should be able to build them in such a way that you can sniff out the quality at the end. And speaking of multi-agent systems, let's talk about what skill is involved when we do these complicated multi-agent systems. Because people sometimes look at that like that's a chasm they can't cross. Like I've had people who say I can use chat GPT, I can even use cloud code, but when you say multi-agent, like go white at the roots, right? Like it's not easy. It is easier than you think. Fundamentally, the skill of working with multiple agents is the skill of decomposing tasks and delegating. It's a managerial skill, and you can learn it. You just need to be able to break apart work into manageable segments. That is part of how you understand what works. And then you compare that with some of these other skills you're learning, like specifying, like writing E-vals, to actually get what you want done. Now, if you think this sounds like regular project management, it's not. Agents work so differently from people. Agents need very defined guard rails and infrastructure to work correctly. You can give your team of six a set of assignments that are decomposed rather vaguely in human terms, and they will still figure it out. We're sort of generally flexible as workers. You cannot do that with agents. You have to very clearly specify the goal. Very clearly specify your initial intent. Very clearly define how you want a multi-agent system to run. And there's not that many ways to do it. The current best practice is to have a planner agent that keeps a record of tasks and that can work with a variety of sub-agents to get those tasks done. Now, if you've ever broken large projects into work streams, take comfort, that is a skill that transfers. Because you're really thinking through what are the logical delineations, what are the chunks in this work stream and how do we hand them off? That is something that you can learn to work with AI to do, and AI can help you on when you start to build bigger projects. One of the most interesting sub-sets of this skill right now is the ability to know, is a given project correctly scoped for the agentic harness I have? And I have videos up where I talk about this. The idea that you need to size your work for the agentic harness you have. If you have a single threaded agent harness that designs basically to be a little engineer in the computer that works for you, you have to size your task and decompose them to fit that engineer in a box. If you have a multi-agent system and you have a planner agent that operates over a long period of time and it has sub-agents, you have the flexibility to define a larger task. You still need to be clear enough about the sub-tasks and their logical relationship that the planner can make good choices. And so this is something where I say this out loud and you might think, oh, this isn't that hard. I promise you it's hard. I promise you it's technical. I promise you it's learnable, and people will pay for this. This is something that people are in desperate demand of all over the world. Now, you might think, well, this sounds really hard, and these agent systems probably fail. That brings me to the next skill. It's called failure pattern recognition and it's absolutely critical. It shows up in lots of these job postings because when employers put these skills together, you know what they recognize? Wow, it's not so easy as I thought, right? We have lots of ways that agents fail. I need someone who can diagnose this at root, fix it, and get me back to being productive. And yes, if you're wondering if I'm going to get into detail here, you got that right. Because to be honest with you, failure pattern recognition is not widely understood and people tend to say, well, oh, what's failure? I'm going to tell you. I dug into the research. I also have seen these failures. These are the six failure types that pop up. Context degradation is one, right? Quality is going to drop as your session gets long because you're polluting the context window. Another one is specification drift. Over a long task, the agent effectively forgets the specification unless you construct your agentic harness correctly, and the agent is forcibly reminded of the specification. A lot of what you see in the Ralph loop on Cloud that went viral is forcible reminder of specification. Sycophantic confirmation is another one. That's where the agent actually confirms incorrect data and then comes back and builds an entire incorrect system around that data. You have got to watch the data you put into these agents. They will take it seriously. They will confirm against it. They will sycophantically agree with it. And if you were feeding them bad company data, you're going to get bad systems. Tool selection errors are another one. Tool selection errors are painful. So this is one where the agent picks up the wrong tool and whether or not it gets the job done right, it's a tool it should never have picked up in the first place. This is especially common when you incorrectly frame tools in the system prompt, or you don't make them available in the harness in the correct way, or you have too many of them, or they're too long. Tools are something that probably deserve an entire deep dive on their own, but I will say here that the ability to diagnose tool problems is one of the markers of an AI fluent person. And part of how I know that is that the claud certified architect program, which recently launched, tests for this failure mode specifically because it's so important to building sustainable agentic systems. And if you think, oh, what's claud certified architect? It's nothing. Accenture is rolling this out to hundreds of thousands of people. It's going to be like an AWS certification shortly. Everyone's going to need it. Here's another failure, cascading failure, right? So one agent's failure propagates through the chain, you never had correction mechanisms and now you have a failure of the whole run. That's it is correctable if you put in loops and verification in the right places. The most dangerous failure of all, I kept for last. It's called silent failure. It's where the agent produces a plausible output and it looks right, but something went wrong and the actual result isn't acceptable in production. Those are very difficult to diagnose ahead of time, and once you find them, they're hard to root cause because they tend to look identical to correct output by most measures. I'll give you an example. Let's say you're trying to recommend a particular product to a customer, and it's brown leather boots. And the AI system comes back and says it's recommending brown leather boots, and the customer's unhappy and leaves a nasty review, and something went wrong. You go back and you see, okay, it said brown leather boots in the chat. That looks correct. The metadata on the product says brown leather boots. And you have to dig and dig and dig and dig to see that the issue is on the warehousing shelves, and someone actually shipped blue leather boots, and there are blue leather boots pictured in the last picture of the rotating carousel on that skew, and there was a mix-up. And in this case, it may be the agentic interaction with an incorrect initial data set that caused the problem, but it still shows up as a silent failure. That is the kind of hard work that you have to do to get these systems to work well. Now, if you're an SRE, if you're a risk manager, if you're an operations leader, you already think in these failure modes. This is not a big jump. If you're someone else and you're just not used to thinking in failure modes, I promise you once you get into it, it's a little bit addictive. Because it's like looking for through a puzzle and saying, where's the missing piece? There's got to be a missing piece in here. So it's absolutely something you can learn. Now, once you understand these systems pretty well, the higher level skill, again, something I'm rooting directly in job postings, is around trust and security design. Basically, how do you know where and when to implement these systems and where and when to put humans in? Where do you draw the line between human and agent? Where do you authorize an agent to take an appropriate action? And how do you know the authorized agent only took those appropriate actions? How do you keep an agent on guard rail so you know it does not say something inappropriate to a customer? So, this is a case where you basically have to build the containers or the guard rails around the agentic system in such a way that you are confident that it will predictably and reliably yield value in production systems. This is a very difficult skill because these systems are probabilistic, and just telling it in the system prompt, hey, be good, be nice is not going to be good enough. So digging in, if we look at sub-skills here, you have to understand cost of error, right? You have to understand what is the blast radius of particular problems. The art of building these systems in guard rails is the art of saying what is the worst thing that could happen? Let's get clear on that and then work backwards because you're never going to be perfect. Like a misspelled email draft, that's not great. A incorrect drug interaction recommendation is potentially catastrophic for the company. And so you have to understand where to put that valuation and how to make sure that you get the big things right. Another one is reversibility. Can you make this mistake go away by reversing it? Now, you can review a draft before sending it. You can't necessarily review a transaction that's a wire transfer that's already gone out. That's gone. Frequency is another way in which you understand the risks of the system. If it happens 10,000 times a day, it is potentially a much bigger risk profile that it happens twice a day. Then again, if it's twice a day going to 100,000 people, maybe you have to think about it. This requires a depth of understanding of the system that allows you to really map customer impact clearly and precisely. Last but not least is verifiability. Can you verify that this is correct? It's a big word in this discourse, and you have to look at all of the answers you're getting, and you can't just be tolerating semantic correctness. Semantic correctness is when the LLM says something to a customer and it sounds right. Functional correctness is when the LLM says something and it is right. Like an LM can say, hey, this is the right credit card for you, and that sounds correct. But if the credit card recommended is the wrong credit card, it's still a disaster. You have to be functionally correct, and you have to insist that you measure systems against that standard. And so a lot of what these job postings tend to look for is people who have that insanely high bar on quality and insist on building systems that uphold that. Now, let's say you've gone through this whole process, you could build agentic systems, you understand the boundaries they draw, you understand how to specify intent, all the skills I've just described. The crowning skill is context architecture. How do you build context systems that enable you to supply agents with the information they need on demand to successfully run at scale? This is the 2026 version of getting the right documents into the prompt, which is what we were doing in 2024. So you have to understand what is persistent context in your system, what is always there, what is per session or per run context that the agent needs. How do you make that available? How do you make sure that the data objects in your space are easy to find and easy to traverse by AI agents? How do you make sure that there isn't dirty and polluting data that confuses the AI agent in your context available to be searched? How do you differentiate between what is pulled into context and what isn't, and how do you start to troubleshoot when agents start finding the wrong context? Context architecture is one of the hardest things to do in 2026. And it's something that many companies are now willing to pay almost anything for. If they can get this right, it enables them to not just build one agentic system, but to build dozens. It's a massive unlock. And the people who can think through the data side of things logically, and put that in front of an agent in such a way that they can verifiably show that the agent can do the work, those people can write their ticket. And you know what? You don't have to be an engineer to do this. If you're a librarian, if you are a technical writer, you have a lot of the bones of this skill. You have the ability to understand technical information and where it's filed and where it goes. In the sense, context architecture is like building the Dewey decimal system for agents. You have to understand how to build a library that an agent can easily search through and find and say, ah, this is the right book. I have to pull this for this job. And that is a skill that you can test for, that you can hire for, and it is highly in demand right now. Okay. Last of the seven skills. This seventh skill is on almost every senior job posting. It's called cost and token economics. I'll simplify it for you. Is it worth it to build an agent for this job? You have to be able to go through and calculate the cost per token for a given task and reliably say, if I put an agent against this and it burns 100 million tokens, I can prove this is worth doing, or I can prove it's not worth doing, and I can do that ahead of time before I put a bunch of agents against this. If you don't know how to do this, and in particular, if you don't know how to do this in a world where you have model choice, where you can pick your tokens, where you have to pick the right model to pick the right tokens for the economics of the task. And you recognize that all of these models are changing their pricing all the time. That's the challenge. That is what you need to be able to do. Like, imagine a world where token cost as a whole is falling very rapidly, but you may need frontier model pricing for certain tasks. How do you ensure that if you're being tasked with getting a job done, you can get the right mix of models on the job? You can calculate out the blended cost of the task, and you can be confident that you're paying the right amount, and you're getting ROI on the task. That is a senior level qualification. You're not surprised, right? It's highly in demand. Being able to do that is basically just applied math. It's it's actually, you can actually build spreadsheets and calculators that help you to do this. Where you can just change variables and say, I think it'll be a hundred million token task, and you can see immediately across six different models how much it would actually cost assuming a given weight. And it's actually not as hard as you would think to figure out what those different components would cost, because you can put together a little prototype, and you can very easily cycle through tokens, see that it's plausible with this model and not with this model, see roughly how many tokens it takes across three or four runs, and you can start to build a plausible model. This is a situation where it's high school math, but you're getting paid like a senior architect or a senior engineer. Because you're fundamentally taking those mathematical skills and applying them in a very fluid and fast-moving world to help the organization be very cost-efficient with these agents, which are not cheap to run. Like if you're burning through a billion tokens with an agent, you'd better be sure it got it right. It'd better be worth it. If you're wondering what kind of job titles did I look through for this, is it only engineering? The answer is no, there are operations titles that have these skills. There are engineering titles that have these skills, yes, there are architecture titles that have these skills. There are product manager titles that have these skills. There are AI reliability roles that have these skills. People are calling them different things, and what I have done is dig underneath and map out seven common skills. And we are going to see in 2026 more and more new skills emerging and more and more new jobs emerging because fundamentally we're rebuilding job families around agents. And so you're going to find that someone is going to be very clear about wanting someone with high specification quality to be clear about intent with agents at initial parts of the run, or someone's going to be really good at evals and that's going to be a role that starts to emerge. But regardless, the underlying skill sets are the underlying skill sets, and part of why I'm confident they're not going anywhere is that they're tied tightly to how AI actually works. It's like, the agent may get 10 times better at doing complex long-running tasks, but you still got to have an eval at the end. You still got to specify your intent, make sure it's like, this is what we're going to do. You still have to be able to search your context appropriately. These skills are skills that you can bet on. These skills are skills that companies are betting careers on, and they're desperate for them, and no one can find them. And look, if you got to the end of this video and you're like, that's me, that's me, I'm raising my hand, head over to the job board that I'm putting up here. Go check it out, go put up your profile, and let's get you into the mix as part of a vetted pool of talent so that we can simplify this job finding and hiring process in the AI. If that's you, and you're like, I'm a hiring manager and I've got to get these kinds of people, same thing, head over there. If you're like, I want to get there, that's why I'm creating the guide to help you get there. That's why I'm working through a course with you on the substack where you can actually go through and teach yourself these skills. And you can self-diagnose and say, okay, which one do I need to work on and how do I get better at it? So, my goal here is to be practical. I want this to be something that is distinguished from other AI self-help guides by being specific enough to be useful by being grounded in actual job posts, by being grounded in the skills that I see employers looking me in the eye and begging me for after hundreds of interviews, they can't find them. I have seen people throw up their hands and tell me, you go out and interview people. I've interviewed hundreds of people, I cannot get this job filled. That is what it's like on the other side. And so if you want to be the person who is in demand in that world, this is for you. Bookmark this video, go back through it. I know it was dense. You can feed this transcript to an AI and ask it to explain it to you. People do that all the time. They tell me so in the comments. You can get help to get this done. I hope this has been helpful. Cheers.