The skills you need to work in AI in 2026

Before choosing another AI course, choose the work you want to be able to do.

That sounds straightforward until you read the job descriptions. Bell's AI adoption role says you don't need to write code. An engineering role at 1001 asks for full-stack development and customer deployments. ServiceNow's principal research position asks for an established publication record. All three involve AI, but preparing for one won't necessarily prepare you for the others.

The useful question is where you want to contribute: building applications, improving models, operating infrastructure, or helping people apply the technology to their work. Each requires a different investment. Recent hiring posts and employer descriptions offer concrete examples of those differences, although they don't tell us how common each role is across the whole market.

For someone deciding what to learn next, they offer something more actionable than a universal list of tools: responsibilities you can prepare for, and work you can show to demonstrate that preparation.

Follow the problem through to deployment

Consider a forward deployed engineer: an engineer who works closely with customers to build and deploy software in their environment.

At 1001, the job includes understanding customer operations, helping decide what to build, and working through unclear requirements, legacy systems and messy data. The technical requirements include TypeScript and React, plus Python or Node. The company asks for two to four years of full-stack engineering experience and substantial travel to customer sites. This is an experienced engineering role with customer responsibility. 1001's job description

To understand why those skills appear together, imagine a hypothetical operations team asking for an assistant that explains delayed shipments. Before building it, you need to discover what “delayed” means: late leaving the warehouse, late reaching the customer, or late against a promise that somebody has since revised?

That answer determines which records to retrieve and which dates to compare. You might need SQL to investigate the data, an API integration to fetch updates, and a user interface that lets an operator check the explanation. If the system lacks a delivery timestamp, somebody must decide whether it can answer at all.

The model is one component in that work. For this assistant, a precise prompt won't compensate for missing delivery records. If you're targeting applied engineering, practice that whole sequence: investigate an unclear request, inspect the data, build the integration, then put the result in front of someone who can challenge it.

You can learn a framework while doing this. You also need to understand the operations it performs well enough to debug them when the framework's defaults don't fit your problem.

Learn how to tell whether it works

Once an application produces convincing answers, the next skill is finding the answers it gets wrong.

In a hiring post for mid-level and senior data scientists, Roche's Anna Surdacka names Python, LLMs and retrieval alongside golden datasets, prompt regression and hallucination tracking. Those last three describe work needed to assess a system and notice when changes make it worse. Roche hiring post

A golden dataset is a set of examples with reviewed expected answers or assessment criteria. Prompt regression testing checks whether a prompt change breaks behavior that previously worked. Hallucination tracking records unsupported output so the team can investigate it.

For the shipment assistant, a test set could contain ordinary deliveries, missing scans, revised delivery promises and conflicting records. Decide how each should be handled before inspecting the model's answer. Otherwise, it's easy to accept a plausible explanation after the fact.

Keep some examples separate from the ones you use to adjust the application. If you repeatedly tune against every question in your test set, a better score may reflect adaptation to those examples; the untouched cases provide another check.

Then inspect failures at the right level. Did retrieval find the wrong shipment? Did the model ignore a relevant record? Did the answer use the correct dates but apply the wrong definition of “late”? Each failure calls for a different fix. Rewriting the prompt for all three could leave the underlying defect untouched.

This is work you can demonstrate even in a small project. Show the initial baseline, the cases that failed, what you changed and the results on the separate test cases. Record response time and cost under stated conditions, too. An improvement that makes the application too slow to use is a tradeoff worth explaining.

Operating the system is another specialty

Building a feature also creates work for the people maintaining the environment around it.

TD's AI/ML platform hiring post asks for Azure, Python, Terraform, CI/CD, automation, security and governance. Terraform defines infrastructure in code; CI/CD automates steps in testing and releasing software. That combination offers a recognizable route for someone with cloud or platform engineering experience. TD hiring post

Here, a useful learning project might focus on reproducible deployment, access controls and diagnosis when something fails. For the shipment assistant, that could mean keeping credentials outside model inputs, enforcing which records a user may access, and recording enough information to investigate an incorrect response without unnecessarily retaining sensitive data.

Answer quality and access control need separate tests. An accurate explanation of a shipment is still a problem if the requester wasn't entitled to see it. Likewise, a dashboard showing few service crashes won't tell you whether the answers are supported by the source records.

If you already operate production services, you have relevant experience to build on. The additional learning is how model behavior, evaluation and changing inputs affect the service you're responsible for.

Help people change how they work

Software can be available and still go unused. Someone has to understand the work it is meant to improve, help people use it, and establish whether the change helped.

Bell's AI Adoption & Engagement Lead makes that responsibility explicit. The role includes workflow discovery, workshops, guidance on secure no-code agents, documentation and measures of adoption and process improvement. Although coding isn't required, the specification asks for a computer science or technology degree, technical fluency and experience with technology adoption. It is a hybrid role in Toronto or Mississauga. Bell's job description

For someone coming from operations, consulting or training, that gives a concrete direction for development. Learn enough about the technology to recognize its limits, then practice finding a useful application and helping colleagues work with it.

Take the same hypothetical shipment assistant. An adoption specialist might discover that operators don't need a chat window; they need an explanation beside the existing exception queue. They could document which questions the system handles, teach users how to check its sources, and record cases that still need investigation.

Measuring the change takes care. More questions submitted to the assistant could mean successful adoption, or it could mean users need several attempts to get an answer. Pair usage with a relevant outcome, such as time to resolve a case, and check whether faster handling has increased mistakes or shifted work to another team.

Domain expertise helps you ask those questions. It also needs to be combined with hands-on familiarity: enough experience using and testing the system to give guidance that survives contact with an actual user's problem.

Some customer-facing roles demand deeper engineering and commercial experience. Anthropic's London Applied AI Architect position combines deployed LLM applications, evaluations and architecture with technical sales; it asks for five-plus years in technical customer-facing work. Check the responsibilities behind the title before deciding which path fits you. Anthropic's job description

Match the depth to the role

For model development and research, the preparation changes substantially.

1001's separate machine learning engineer role asks for statistics and deep learning fundamentals, model training and adaptation, rigorous experiments, and production pipelines. It requires at least four years of relevant experience. These responsibilities extend beyond connecting an application to a model API. 1001's ML engineer description

ServiceNow's principal research role in Montreal goes further: it asks for a PhD or equivalent research experience, eight or more years of post-PhD research experience, an established publication record and the ability to set a research agenda. Its subjects include agent memory, continual learning, safety and privacy. A portfolio assistant cannot substitute for that record. ServiceNow's job description

There are also roles where statistical modeling remains central. Tamara's product data science hiring post requests Python, SQL, statistical fundamentals, experimentation and ownership of models in production, with pricing or recommendation experience desirable. It asks for three-plus years of relevant experience and is based in Riyadh. Tamara hiring post

For a reader with a quantitative background, those requirements suggest building on existing depth. Practice formulating a modelable problem, choosing an appropriate baseline and explaining uncertainty. If you want research work, learn to read and reproduce relevant papers, then investigate a question whose answer isn't already supplied by the tutorial.

These examples concentrate on software, data and enterprise applications. Hardware, robotics and other AI specialties bring additional requirements. Even within this narrower scope, you can make a more useful learning decision by separating the work:

The suggested projects are ways to practice and demonstrate relevant skills. They don't replace a vacancy's experience requirements.

Make your contribution inspectable

Fini's Deepak Singla gives applicants a useful prompt in his AI Solutions Engineer hiring post: explain something you built, whom it served, what you personally owned and the hardest product decision you made. Fini hiring post

You can use those questions to assess your next project before you start it.

For an independent engineering project, you could build an assistant that answers questions from public product documentation, avoiding the need for access to a company's shipment records. Keep it read-only and identify a specific intended user. Compare its answers with a simple search baseline. Test questions the documents cannot answer, outdated pages and failed retrieval. Include the source passages so someone else can inspect whether the answer follows from them.

Write down a decision you had to make: perhaps the assistant refuses to combine conflicting instructions until a document owner resolves them. Explain what that restriction costs the user and why you kept it. If nobody has used your project yet, say so; test results don't become customer outcomes because they look good in a presentation.

For adoption work, the equivalent evidence might be a workflow assessment, a small pilot and training materials. For model research, it will require an appropriate experiment and the research depth the role demands. In each case, distinguish your own decisions from the work done by collaborators and AI tools.

Choose a responsibility from a real job description and use it to set the scope of your learning. Then give someone enough detail to examine your work: what you attempted, how you checked it, where it failed and what you decided to do next. That gives both you and a prospective employer something concrete to discuss.

Related reading: AI jobs worth a look. Browse the AI jobs feed for more hiring posts.