The four things you will actually build

TL;DR: Almost everything built on language models is one of four shapes: turning messy input into structured data, answering from a body of documents, doing multi-step work with tools, or measuring whether any of it works. Learn to recognise which one a request is and you will know what you are building before you write anything.

Where you are. This is the first lesson of the course. It assumes you can program and assumes nothing about AI. If you want the role itself, the hiring landscape, and how it compares with other titles, that is the Applied AI Engineer guide and it is a different document. This course is about the craft: what you build and how.

The four shapes

Job postings and conference talks make this work sound like a hundred different things. In practice most of it collapses into four patterns, and every module later in this course is about one of them.

1. Structuring the unstructured. You have text a program cannot use: support tickets, contracts, CVs, transcripts, scraped pages. You need fields a database can hold. Classification, extraction, tagging, routing.

This is the least glamorous and the most common, and it is where most of the actual business value has landed. It is also the easiest to do well, because the output is checkable: either the extracted date is right or it is not.

2. Answering from a body of knowledge. You have documents and someone has a question. The model does not know your documents, so the system has to find the relevant part and answer from it, ideally citing what it used.

Every internal assistant and documentation search is this. Module 4 is about it, and it is where the embeddings lesson pays off.

3. Doing work, in steps, with tools. Not just producing text but taking actions: querying a database, calling an API, writing a file, then deciding what to do based on what came back.

This is the fashionable one and the one most often reached for too early. Module 5 covers it, including the more important question of when not to.

4. Knowing whether any of it works. Given a system that produces text, deciding if it is good enough to ship, catching it when it degrades, and comparing two versions.

This is the one beginners skip and the one that separates people who ship from people who demo. Module 6 is about it.

Notice where the fourth sits. It is not a phase at the end. It wraps the other three, and every serious system has a loop through it.

What you are not building

Worth being blunt, because a lot of course material aims elsewhere and you can waste months.

You are not training models. You will not derive backpropagation, choose a learning-rate schedule, or run a training cluster. That is a different and also excellent job. Applied AI engineering is building systems around models that already exist.

You are not doing classical data science either. Feature engineering, hypothesis testing, and gradient-boosted trees are a neighbouring discipline. They come up, but they are not what this work is.

The line that decides it: you need what it takes to build with models, not what it takes to build models. Everything in this course is on the near side of that line, and when something on the far side becomes genuinely useful, it appears in the form you need rather than in full.

The habit this should start

When someone describes a feature, ask which shape it is before asking anything else.

"We want AI to help with onboarding" is not actionable. But if onboarding means pulling fields out of submitted documents, that is shape one and you know roughly what it costs and how to check it. If it means answering new-joiner questions from an internal handbook, that is shape two and the hard part is retrieval quality, not the model. If it means filing tickets and provisioning accounts, that is shape three and you should be nervous.

Same sentence, three completely different projects. Naming the shape is the first useful thing you can do.

Do this before moving on

Take one AI feature you have seen, used, or been asked about, and write one sentence naming which of the four shapes it is. If it seems like two, split it into its parts and name each one, because that is what building it will require anyway.

Then write a second sentence: how would you tell whether it was working? If that sentence is hard to write, you have found the real difficulty in the project, and you found it before writing any code.

Go deeper

• The Applied AI Engineer guide covers the role rather than the craft: where it came from, how it compares with neighbouring titles, and what the market looks like. Read it if you want the career picture.
• RAG pipeline is shape two end to end, and the single most useful concept page to have read before module 4.
• Agents and tool use is shape three in one page, and worth skimming now so module 5 is not a surprise.
• Evaluation-driven development is shape four, and the mindset the fourth box in that diagram represents.
• Practice question: How is AI engineering different from ML engineering? is the "what you are not building" section as an interview question, and it comes up early in screens.

Key takeaways

• Nearly all applied AI work is one of four shapes: structure the unstructured, answer from documents, do multi-step work with tools, or measure whether it works.
• The fourth wraps the other three. It is a loop, not a final phase.
• Structuring messy input is the least glamorous shape and where most delivered value actually sits.
• You build with models, not models. Training and classical data science are neighbouring jobs.

LEARNING LAB1 of 4

Check yourself before an interviewer does. Answer from memory first.

A team asks for "AI to help with compliance reviews". What is the first useful question?

Which model should we use?Which of the four shapes is this: extraction, answering from documents, multi-step action, or measurement?What is the latency budget?