Lesson 1.1: What an AI engineer actually builds
An AI engineer builds products on top of existing language models rather than training them. Learn what the job covers and how it differs from data science.
When people hear "AI engineer" they often picture someone training giant neural networks from scratch, in a lab, with thousands of processors. In practice, most AI engineers do something different and much closer to everyday software work: they take a model that already exists, usually through an API, and build a useful product around it. By the end of this lesson you will be able to say what that work involves, name the five areas it covers, tell the role apart from data scientist, machine learning engineer and software engineer, and estimate the running cost of an AI feature with a simple model. You need no machine learning background. If you have used a chatbot and you can read a small amount of code or a spreadsheet, you are ready.
This is the first lesson of the AI Engineering track. The whole track is built on one idea that this lesson introduces: the model is a component, and the engineering is everything around it.
Using a model versus making one
Think of a language model the way you think of a database or a payment gateway: a powerful component that someone else builds and maintains, which you reach over the network and pay for by use. A small group of research teams train the models. A much larger group of engineers turn those models into features people use: a support assistant that answers questions from policy documents, a search tool for contracts, a tool that drafts a report from raw numbers, a system that reads invoices and fills in a form.
This changes what the daily work looks like. It looks far more like software engineering than like research. You design how information flows into a request, how answers flow out, how the result is checked and what happens when the model is wrong. You are not adjusting the model's internal numbers. You are building the system the model sits in.
There are good reasons most teams work this way.
Cost. Training a general model from scratch costs far more than almost any company can justify. Using one costs a small amount per request.
Speed. A working prototype can exist in days, because the hard part, the model, already works.
Focus. The valuable part for a business is rarely the model. It is the specific problem solved, the company's own data and the way the feature fits the workflow.
None of this means a model is trivial. It means the engineer's skill is applied elsewhere: in giving it the right information, controlling what comes back, and proving that the whole thing works well enough to trust.
The five areas of the job
Almost everything an AI engineer does falls into one of five areas. Learn these now, because the rest of the track takes them one by one.
Giving the model the right context. A model only knows what it learned in training plus what you put in the request. If you want it to answer from your company's policy, you have to put the policy in. Deciding what to include, in what form and how much, is often the hardest part. This is where retrieval comes in, which you will study in modules four and five.
Controlling the output. A model's natural output is free-form text. A program needs something structured: a field in a form, a category, a number in a known format. Getting reliable, parseable output is a skill in its own right and is covered in module three.
Connecting tools and data. Letting the model look up an order, search company documents or call an internal service turns a text generator into something that can act. Module seven is about this.
Measuring quality. The question "is this answer good?" has no built-in answer. You need examples, ways of grading them and a habit of checking that a change made things better and not worse. Module six covers evaluation, and it is the area beginners most often skip.
Running it reliably. Cost, speed, errors, rate limits, privacy and monitoring. A feature that works in a demo and falls over under real traffic is not finished. Module eight is about this.
Here is a picture of how a team's effort might divide across these areas on a typical first project. Treat it as an illustration of the shape and not as survey data.
The most striking thing about this picture is how little of it is "choosing the model" or "writing the prompt". Those matter, but they are a small part of the work. Most of the effort goes into supplying good information and checking that the results are right. A newcomer who thinks the job is mainly about clever prompts is in for a surprise.
Predict first: a company wants a chatbot that answers customer questions using its own policy documents. Which of the five areas will take the most effort: choosing a model, or something else? Decide before reading on.
For most teams it is not the choice of model. Getting the right policy text in front of the model, and then checking that the answers are correct, take far more time. Switching to a slightly better model changes little if the model is given the wrong paragraph. This is why the first areas on the list, context and measurement, are where experienced engineers spend their attention.
How this differs from the neighbouring roles
The titles in this field overlap and companies use them loosely. It is more useful to compare what each role is for than to memorise names.
Role · Starts from · Main output · Typical questionData scientist · A body of data · Analyses and trained models that predict something · What does this data tell us, and can we predict it?
Machine learning engineer · A trained model · A model made fast, reliable and deployed at scale · How do we train, serve and monitor this model?
Software engineer · A product need · Product features and services · How do we build this feature reliably?
AI engineer · A product need and a general model · A working feature built on an existing model · How do we make this model do something useful and trustworthy?
A data scientist usually starts with data and builds a model that predicts something, such as whether a loan will default. An AI engineer usually starts with a product need and uses a general model to meet it. The two overlap, and good AI engineers still think in data and measurement terms, but the main output is a working feature rather than a trained model. A machine learning engineer spends more time on the model itself: training it, making it faster, serving it to many users. An AI engineer is more likely to treat the model as a given and build around it.
In a small company one person may do all of these. The labels matter less than the questions. If you find yourself asking "how do I make this existing model useful and trustworthy for this task?", you are doing AI engineering.
A worked example: summarising calls
Suppose a lender wants to summarise long customer call transcripts so that agents do not have to read them. The team receives about 2,000 calls a day. An AI engineer would split each transcript into pieces if it is long, ask the model for a short summary in a fixed format, store the result and track how often a human reviewer has to correct it.
Look at that last step. If reviewers correct 15 summaries out of every 100, that is a 15 per cent error rate, and it becomes the number the team works to reduce. It is also a cost. Every summary has to be checked, and every wrong one has to be fixed by a person. The more calls, the more wrong summaries, and the more reviewer hours. The simulator below turns that into rupees. Change the number of calls, the share that need correcting and the time each check takes, and watch the reviewer hours move.
At the starting numbers, reviewing takes about 92 hours a day and costs around ₹37,000 a day, or roughly ₹9.5 lakh a month. Notice two things. First, the line on the chart does not reach zero when the error rate does: even a perfect model has to be checked, so the check time sets a floor. Second, moving the error rate from 15 down to 5 per cent saves a meaningful amount, but moving the check time from two minutes to one saves even more. An engineer who only works on the model's accuracy can miss that the cheapest improvement is in how reviewers are asked to check.
This is a small example of a habit that marks good AI engineers: they measure the whole system's cost and quality, and not only the model's accuracy.
The error rate is the lever. The chart below takes the call-summary example, with a two-minute check and a five-minute fix, and shows the reviewer hours a day at three error rates.
A second example: the policy chatbot
Take the policy chatbot from the earlier question. A bank wants customers to ask "can I repay my loan early?" and get a correct answer from the bank's own terms. The model has never seen those terms, so the engineer's first job is to get the right text in front of it.
The rough steps are these. Break the policy documents into sections. When a customer asks a question, find the sections most likely to contain the answer. Put those sections into the request, along with the question and an instruction to answer only from them. Return the answer along with a pointer to the section it used.
Each step can fail in its own way. The right section might not be found, so the model answers from general knowledge and gets the bank's rule wrong. The section might be found but split across a page break, so the answer is half there. The model might ignore the instruction and invent a rule. None of these is a problem with the model's intelligence. Each is a problem of context, output control or measurement, which is why the five areas are the right way to think about the work.
How would the team know the chatbot is good? Not by trying a few questions and liking the answers. They would build a list of, say, 200 real questions with the correct answers checked by someone in the bank, run the chatbot on all of them and count how many are right. When they change something, they run the list again. A change that fixes three questions and breaks five is not an improvement, and only a list will tell you so.
A list of 200 questions sounds like a lot, and it is worth checking what it can tell you. The more questions you test, the narrower the range around the score. Set the size of the list and the share the chatbot got right.
At the defaults, 180 of 200 correct is 90 per cent, with a margin of about 4 points, so the true figure could plausibly lie between about 86 and 94 per cent. A list of 50 questions would leave a margin of about 8 points.
A third example: reading invoices
A finance team receives invoices as PDFs in dozens of layouts and has someone type the key fields into a system: supplier, invoice number, date, amount and tax. An AI engineer sees a task about output control: take messy text and produce a small, reliable record.
The engineer would extract the text, ask the model to return exactly those five fields in a fixed format and then validate what comes back. Is the date a real date? Is the amount a number? Does the tax plus the pre-tax amount equal the total? These checks, written as ordinary code, catch many wrong answers before they reach the finance system. When a check fails, the invoice goes to a person.
Look at the design. The model does the hard part, reading varied layouts, which would be tedious to code by hand. Ordinary code does the part that must be exactly right, which is arithmetic and format checks. Good AI systems combine both, and they are designed on the assumption that the model will sometimes be wrong. That assumption, handled well, is what separates a demo from a product.
What an AI engineer needs to know
You do not need to be an expert in every area, but a few skills carry most of the weight.
Ordinary software skills. Calling an API, handling errors, writing tests, reading logs. Most of the code is plain software.
Comfort with data and text. Understanding formats, cleaning messy input, spotting when something has gone wrong in a table or a document.
A feel for how models behave. Knowing that they can sound confident and be wrong, that the same request can give different answers, and that wording and context change results.
Measurement habits. Building a test set, defining what "good" means and checking changes against it.
Product sense. Understanding what the user needs, how much error is acceptable and when a human should step in.
This track builds each of these in order. You will first learn how a language model works at the level an engineer needs, then how to call one reliably, then how to give it your own information, test it, let it use tools and run it in production.
The map of this track
The eight modules follow the order in which the work usually unfolds.
1. The AI engineering map, this module: what the job is, the parts of an application and the choice between building, buying and fine-tuning.
2. LLM foundations: tokens, how a model predicts the next word, temperature, and how models are trained and adjusted.
3. Working with model APIs: prompts, structured outputs, streaming, cost, errors and retries.
4. Embeddings and retrieval: how to find the right text for a question.
5. Retrieval-augmented generation: putting retrieval and generation together, and how it fails.
6. Evaluation: how to know whether your system is good.
7. Agents and tools: letting the model take actions, and keeping it reliable.
8. Shipping and operating: cost, speed, caching, safety, privacy and monitoring.
Each lesson uses plain language, small examples and numbers you can change. By the end you will have the vocabulary and habits to build and judge an AI feature yourself.
Common mistakes
These are the errors most often made by people starting out in this work.
Thinking the job is prompt writing. Prompts matter, but they are one small part of a larger system. Context, evaluation and reliability take far more time.
Judging quality by a few examples. Three good answers prove nothing. Build a test set and measure.
Trusting a confident answer. Models write fluent, plausible text whether or not it is right. Plan for wrong answers and build checks.
Choosing the model first. Start with the problem, the data and the way you will measure success. The model is a later and often reversible decision.
Ignoring cost until it arrives. A feature that costs a few rupees per request is a very different business at ten thousand requests a day. Estimate early.
Skipping the human. For anything that affects money, health or rights, decide when a person reviews the output, and design that step on purpose.
Treating the first demo as the product. A demo that works on five examples says little about a thousand real ones.
Key takeaways
AI engineers mostly build products on top of existing models rather than training new ones, so the work looks like software engineering more than research.
The job covers five areas: context, output control, tools and data, quality measurement and reliable operation.
Choosing the model is usually a smaller task than giving it the right information and checking the results.
The roles near it differ by starting point: a data scientist starts with data, a machine learning engineer with a trained model, an AI engineer with a product need and a general model.
Models are sometimes wrong, so good designs pair the model with ordinary code that checks the result and with humans where it matters.
Always measure the whole system's cost and quality, not only the model's accuracy.
Check yourself
1. What is the main difference between how a data scientist and an AI engineer usually start a project?
A data scientist starts with data and trains a model to predict something. An AI engineer starts with a product need and uses an existing model to meet it.
2. Name the five areas an AI engineer's work covers.
Context, output control, tools and data, quality measurement, and running it reliably.
3. In the call summary example, why does the reviewer time never reach zero even if the model is perfect?
Every summary still has to be read and checked, so the check time sets a floor.
4. A team has 2,000 calls a day, a 2-minute check, a 5-minute fix and a 15 per cent error rate. Roughly how many reviewer hours is that per day?
About 92: 2,000 times (2 + 0.15 times 5) minutes, divided by 60.
5. Why is "ask the model to return five fields, then check them with ordinary code" better than trusting the model alone?
The checks catch wrong answers, such as invalid dates or totals that do not add up, before they reach a system that people rely on.
Try this
Set aside about forty minutes and pick a task in your own work or life that involves reading a lot of text, such as emails, reports, messages or forms.
1. Write down the task in one sentence and who would use the result.
2. List what information a model would need to do it well, and where that information lives today.
3. Describe the output you would want, as a short record with named fields, and not as free text.
4. Write down three ways a wrong answer could look, and how you would notice each one.
5. Estimate how many items there would be per day, how long a person would take to check one, and how often you expect a wrong answer. Put your numbers into the review-cost simulator above to see the daily hours and the monthly cost.
6. Decide where a person should review the output, and where it would be safe to let the system act alone.
A good result is a one-page note a colleague could read and understand: the task, the information needed, the output format, the likely mistakes and an estimate of the cost of checking. That note is the beginning of the design for a real AI feature.
Tags: AI Engineering LLM applications Careers Software engineering Beginner