What does an AI engineer actually do in 2027?

Where the AI engineer role came from

A few years ago, the AI work in most companies was done by data scientists and machine learning engineers. Data science was mostly software development plus statistics, with a lot of research and experimentation, and machine learning engineers took models into production. If a company wanted a model, it collected data, trained a model and deployed it, and that took a specialised team.

That changed when large pretrained models became available through APIs. Suddenly a software developer could build a product on top of a model in days, without training anything, and a new kind of work appeared: adapting these models to a product, connecting them to company data and tools, and making them reliable enough for real users.

In 2023, Shawn Wang (swyx) wrote an essay called The Rise of the AI Engineer, describing this as a new role between software engineering and machine learning. In her book AI Engineering, Chip Huyen describes the difference this way: AI engineering is less about developing models and more about adapting and evaluating them, so evaluation and inference efficiency become much bigger problems, and machine learning knowledge helps but is no longer a must-have to build AI applications. By early 2025, LinkedIn's Jobs on the Rise report for the United States put AI engineer at number 1.

When I showed builders the search interest for AI engineering and ML engineering on Google Trends, the interest in AI engineering had been growing fast since 2023. Search trends show attention, not jobs, but together with the job reports they show the role is real and growing.

A simple definition

Here is how I define it for builders.

An AI engineer takes a business problem, decides whether and how AI should be part of the solution, and builds, deploys and maintains a system that uses AI models to solve it, with evidence that it works.

There are three things in that definition that people often miss. The work starts from a problem, not a model. The work includes deciding not to use AI when a simpler solution is enough. And the work isn't done at the demo, it is done when the system is deployed and you can show that it works.

What the work looks like, part by part

The best way to understand the role is to follow a request through the parts of the job.

Understanding the problem with the people who have it

Most AI projects start with someone in the business saying "we want AI for this." The first job is to understand what "this" actually is.

When a client comes to my team at Dextar, the first thing I ask is to show me how they do this today and tell me what exactly they want to improve. Who does the work now, what are the steps, how many times a day does it happen, where does it fail, and what would a better result look like? Without those answers, you can't decide what to build, and you can't check later whether it worked.

You also answer the business questions, because the people who pay for the system will ask them. How much will it cost to run each month? How long will it take to build? Will the model need to be retrained or updated, and how often? What happens when it gives a wrong answer?

Deciding whether AI is needed

Once you understand the problem, you decide whether it needs AI. A lot of requests that arrive as "build us an AI agent" can be solved with a Python script, a normal workflow or a product the company already pays for. If you solve the problem with less software and less maintenance, that is also good engineering.

When AI is needed, I follow a simple order. First check whether the problem can be solved with traditional software, then with classical machine learning, then with deep learning, and only then with generative AI. Each generation of AI solves certain problems better than others, and a fraud model trained on transaction data can be faster, cheaper and easier to test than an LLM for the same job.

Choosing and calling models

When an LLM is the right tool, you choose the model. That means comparing hosted APIs from different providers with open models you can run yourself, on quality for your task, cost per request, latency, context window, data privacy and whether the model can run where your data is allowed to go.

Then you call it properly. Real systems need retries when a provider has a bad day, timeouts, fallbacks to another model, rate limit handling, and a record of the tokens and cost of every call. That is why one of the first things we build in Build30 is a token tracker.

Getting the right data into the context

A model only knows what it was trained on and what you put in front of it. So a big part of the job is getting the right company data into the context at the right time.

This is usually retrieval-augmented generation (RAG): parsing documents, splitting them into chunks, turning them into embeddings, storing them in a vector database, retrieving the relevant chunks for each question and putting them into the prompt. It sounds simple in a tutorial, and it becomes the hardest part of the project with real data, because real documents have tables, scans, duplicates, outdated versions and access rules about who is allowed to see what.

This is also where data engineering matters. Data pipelines, cleaning and infrastructure are the base of every AI system, which is why data engineers are some of the most important people in any team that builds with AI.

Prompts, context and structured output

You write and test the instructions the model gets: the system prompt, examples, the format of the retrieved context, and the structure of the output. Most production systems need the model to return structured data, like JSON that matches a schema, so the rest of the software can use it. And you treat prompts like code, with versions and tests, because a small change in wording can fix one case and break three others.

Tools and agents

When the system has to do something and not only answer, you give the model tools: functions it can call, like searching a database, creating a ticket or sending an email. An agent is a loop where the model decides which tool to call, looks at the result and decides the next step.

The engineering work is in the details. Which tools does the agent need, and which should it never have? What happens when a tool fails or returns something unexpected? When does a person need to approve an action? How many steps can the agent take before it stops, and how much is it allowed to spend?

Evaluation

This is the part that separates a demo from a product. An AI system can give a confident, well-written answer that is wrong, and you won't know unless you check.

So you build evaluation into the system: a test set of real questions with known good answers, automatic checks for format and safety, sometimes another model acting as a judge (with its own limits), human review for the cases that matter, and monitoring in production. Every time you change a prompt, a model, the chunking or a tool, you run the evals again and compare.

Deployment and operations

You put the system behind an API, package it, deploy it, and make sure it keeps working. That includes tracing every request so you can see what the model saw and did, tracking latency and cost, setting alerts, and having a plan for when a model provider changes or retires the model you use.

Security, privacy and legal risk

AI systems create new risks. Users can try prompt injection to make the model ignore its instructions. Retrieval can leak documents to people who shouldn't see them. A chatbot can give a discriminatory or harmful answer to a real customer, and that becomes a legal and reputation problem for the company, not only a technical one.

Collections of public AI incidents, like the AIAAIC repository, are a useful reminder of what goes wrong when these risks are ignored. Part of the AI engineer's job is to design the system so these failures are less likely and are caught when they happen.

Documentation and communication

Finally, you explain what you built. That means documentation of how the system works, what it can't do, what to do when it fails and who owns it, and explanations for non-technical people who have to decide whether to trust it.

What an entry-level AI engineer actually does

If you join a team as a junior AI or ML engineer, you won't own the architecture on day one. In a team I lead, a new engineer gets a lot of reading and resources, and then we discuss them, so they understand what is happening in the field and in our project. They work with senior ML engineers and data engineers to understand how the whole pipeline works, from the data sources to the model to the production environment. They pull data from different sources and build parts of the pipeline. They talk to clients and product managers, because clients ask who is working on which part. They deploy services with a framework like Flask or FastAPI. And they write a lot of documentation about what works, what doesn't and why.

The most important skill at this level is finding solutions on your own. Nobody expects you to know everything, but they do expect you to search, read, try and come back with something. A company hires on many things beyond hard skills: your attitude, how you work with a team, whether you are willing to learn, and how you communicate when you are stuck.

The highest level of an AI or ML engineer, in my view, is being able to implement a research paper. Research papers describe new methods that usually have no ready-made code on the internet, so if you can read one and implement it, you can handle almost anything a team will give you.

How AI coding tools changed the job

AI is not coming for your job, it is coming for the boring parts of your job. It has become a very good junior developer: writing boilerplate, finding the missing comma, explaining a function you have never seen. That frees you to focus on system design, architecture, creative problem solving and leading the project. AI won't replace developers, but developers who use AI well may replace those who don't.

What this means in practice is that an AI engineer in 2026 is judged less on how fast they type code and more on whether they can design the system, split it into parts a tool can build, review what the tool produced, and explain every decision. If someone asks you in an interview how you built a project with a coding assistant, you should have the answer, because you can't call yourself an engineer if you don't understand the code. Engineering is making things better, and you can only make something better if you understand how it works.

Designing for agents as users

There is one more part of the job that is new. For years we designed user experience (UX): how a person experiences an app, its navigation, layout, colours and how fast it responds. Now there is also agentic experience (AX): how a person experiences a system where agents do part of the work for them.

For example, if a community has an agent that answers questions the moment someone asks, the experience depends on how good, how fast and how safe those answers are, and on which platforms allow the agent at all. More and more, AI engineers will design both how people use a system and how agents use it, which tools, data and permissions an agent sees, and what it is allowed to do.

What the role will look like in 2027

My prediction is that in 2027 the AI engineer will spend less time writing code by hand and more time on three things: designing systems, building evaluations, and reviewing and owning what agents and coding tools produce. I also expect companies to keep asking one person to cover what used to be several roles, data pipelines, model work, software and deployment, especially in startups. These are predictions, not statistics, and they will be wrong if coding agents become reliable enough to own production systems without review, or if regulation pushes companies back toward larger specialised teams.

Skills companies ask for

If you look at AI and ML job posts, the same skills show up again and again.

• Python, and SQL, because most company data lives in relational databases.
• Experience with model APIs, RAG and agents.
• A cloud platform like AWS, Azure or GCP, and deployment with Docker and an API framework.
• Evaluation and monitoring of AI systems.
• Production experience, which means you have deployed something that real people used.
• Communication: explaining technical decisions to people who are not engineers.

You can see this yourself by searching job posts for your target role in your country and noting which skills appear most often.

From the floor

When I explain the roles to builders, I draw a business leader in the middle, connected to users, business analysts, a tech lead, a system architect, ML engineers, data engineers, software engineers, DevOps and legal. Each of them has a separate job, because each job is complex. But when you look at job posts, many companies expect one ML or AI engineer to do the data engineering, the ML work, the software engineering and the deployment together. Part of that is because many teams are small, and part of it is a lack of understanding of how much work each part is. If you are a leader, plan separate people for these jobs once you can, and if you are an engineer, expect to learn a bit of each.

In one AI agents bootcamp session, I explained what recruiters look for in agent work. Knowing the topics is expected, but production experience matters most, because a business only cares about an agent that keeps working in production, and that is exactly where most agents fail. That is why every build in our bootcamps ends with a deployment.

Related

• AI engineer vs ML engineer vs data scientist vs software engineer
• AI engineer roadmap 2027
• Evals and reliability
• AI engineer portfolio

Sources

• The Rise of the AI Engineer, swyx, Latent Space (2023)
• The AI engineering stack, Chip Huyen in The Pragmatic Engineer
• AI engineers top LinkedIn's 2025 Jobs on the Rise list (United States)
• AIAAIC repository of AI incidents