Twenty six of the thirty parts in this series carry runnable code. Four do not, and that ratio sits close to the honest split of the work: most of an AI engineering week is ordinary software engineering, and the part that is not ordinary is deciding whether the output was any good.
I open with that number because career advice for this role usually gets the ratio backwards. It sells the modelling and skips the plumbing, and then people arrive in the job surprised that their week looks like parsing malformed PDFs, arguing about chunk boundaries and staring at a spreadsheet of eighty failed answers trying to work out what they have in common.
Key takeaways
Job postings advertise fine tuning. Actual work is retrieval quality and evaluation. Optimise your learning for the second, and interview well on the first.
Backend developers convert into this role faster than data scientists do, because the hard part is systems work rather than modelling.
Another retrieval chatbot in your portfolio is noise. An eval harness with a number attached is signal, and almost nobody brings one.
Three things this series deliberately did not teach you: distributed inference, training economics, and the compliance conversation. Plan for those in year one.
Demand signal and what it pays
ManpowerGroup surveyed 39,063 employers across 41 countries for its 2026 Global Talent Shortage report, and 72 percent said they struggle to fill roles. That headline number has been drifting down slowly, from 75 percent in 2024 and 74 percent in 2025. What changed in 2026 is the composition. AI model and application development came in as the single hardest skill group to hire for at 20 percent, with general AI literacy right behind it at 19 percent. First time either has topped that list.
Compensation follows the scarcity, though less dramatically than social media suggests. Robert Half puts a 2026 national software engineer range at roughly 109,250 to 175,500 US dollars, against 134,000 to 193,250 for an AI or machine learning engineer. Call it a 15 to 20 percent premium at comparable seniority, not a doubling.
Two cautions on reading any of this. Aggregator averages skew high because they oversample frontier labs and large tech employers, and a 200,000 dollar average tells you nothing about a mid sized SaaS company in a secondary market. More usefully, the premium is paid for scarcity, and scarcity closes. Job security in this role comes from being the person who can tell whether the system works, which is a durable skill, rather than from being early, which is not.
Skills this series covered, mapped to the job
Our running project finished in a recognisable state. A documentation and support assistant that started as one prompt call in Part 2 now retrieves from a docs corpus with hybrid search and reranking, calls tools to check ticket status, routes cheap questions to a small model, runs a regression suite on every prompt change, and carries traces you can slice by tenant and provider. Roughly 4,000 lines of Python, of which the model calls are maybe 200.
Below is the competency map. Left column is what an employer is buying, middle column is where it lives in this series, right column is how a hiring loop probes it. Keep this one open while you prepare, because the third column is where most candidates lose the offer.
| Competency | Where it lives | How a loop tests it |
|---|---|---|
| Reliable model calls under load | Parts 2 to 6 | Asked what happens on a 429 at 3am, and whether your retry makes it worse |
| Retrieval design and ingestion | Parts 7 to 12 | Given a messy corpus and asked where you would chunk it and why |
| Measuring retrieval separately from answers | Part 13 | Asked how you know a bad answer was retrieval or generation. Very few can answer this |
| Tool calling and agent loops | Parts 14 to 19 | Asked to name a case where an agent is the wrong architecture |
| Evaluation and regression discipline | Parts 20 to 22 | Asked how you would ship a model upgrade without a silent quality drop |
| Security and guardrails | Parts 23 and 24 | Prompt injection scenario, usually with an untrusted document in the loop |
| Cost, latency and portability | Parts 25 to 29 | Given a monthly bill and asked where you would cut it first |
Notice what is absent. Nothing in that table requires you to train a model, derive a loss function or explain backpropagation. Conceptual grounding matters, and if attention or embeddings are still fuzzy then tokens and embeddings and how attention works in the GenAI Series will close that in an evening. Beyond that grounding, depth in transformer internals has a surprisingly poor return on interview time.
Routes into an AI engineering role
Four backgrounds feed this role, and they arrive with different halves of it already solved. Knowing which half you are missing is worth more than a generic study plan.
| Coming from | Transfers cleanly | Usually missing | Realistic ramp |
|---|---|---|---|
| Backend or platform engineering | Retries, timeouts, tracing, deploys, cost thinking | Comfort with a system that has no correct answer, only a distribution of them | 3 to 6 months. Fastest route by a clear margin |
| Data science or research | Evaluation instincts, metric design, scepticism about a good number | Production engineering. Services, queues, on call, packaging | 6 to 12 months, and the gap is engineering rigour, not AI |
| ML engineering or MLOps | Pipelines, registries, monitoring, drift, rollout discipline | Prompt and retrieval craft, which feels unrigorous at first and is not | 3 to 6 months. Second fastest |
| Analytics or support engineering | Domain knowledge, SQL, and a real sense of what users ask | Software engineering fundamentals, testing, version control at scale | 12 to 18 months. Longest route, and the domain knowledge is genuinely valuable |
Row two surprises people. Conventional wisdom says a data science background is the natural on ramp, and in hiring loops I have run it is consistently slower than backend, because the daily failures are systems failures. A malformed PDF, a rate limit cascade, a cache that silently stopped hitting. My advice to a data scientist making this move is to spend your first three months on engineering craft, not on prompting, and from notebook to Python package in the Data Science Series is the right starting point.
What a hiring loop actually tests
We ran a loop for two AI engineering positions across six weeks in 2024. Fourteen candidates reached the technical round, all of whom could describe retrieval accurately, most of whom had shipped something with it. Eleven were rejected on a single question, asked in different words by different interviewers: how would you know if this system got worse.
Answers we heard were user feedback, spot checking, and monitoring. None of those is an answer. One candidate said she would hold out fifty labelled questions, score retrieval recall and answer correctness separately, and refuse to ship a prompt change that moved either past a threshold she had written down in advance. She was a backend developer with no machine learning on her CV at all. We hired her, and she had our first real eval harness running in her third week, at which point we discovered our production answer accuracy was 74 percent rather than the roughly 90 percent everyone had assumed from demos.
Sixteen points of imaginary quality had been sitting in that gap for months, and every roadmap decision made in that period had been made against the wrong number. That is the cost of not being able to answer the question, and it is why the question gets asked.
Interview preparation rule
Prepare one story about a quality number you moved, with the before value, the after value, the change you made and how you knew it was the change. If you cannot tell that story yet, go build the eval harness described in Part 20 over a weekend and then you can. Nothing else you prepare will pay back as reliably.
Portfolio work that survives scrutiny
Standard advice says build a retrieval chatbot over your own documents and put it on your CV. That advice was good in 2023 and is now actively unhelpful, because everybody did it. I have reviewed CVs where four of five projects were the same tutorial with a different corpus, and none of them told me anything about the candidate except that they can follow instructions.
What separates a portfolio now is a number and a decision. Build the retrieval system if you like, but the artifact that gets you interviews is the write up next to it: here is my labelled eval set of 120 questions, here is recall at 5 for three chunking strategies, here is the one I chose, here is the case where it still fails and why I accepted that. Same project, entirely different signal. Comparison method is in Part 13 and the chunking options are in Part 9.
Second project worth having, and rarer still: something with a tool call that can cause a side effect, wrapped in an approval gate. Almost every portfolio agent is read only, which sidesteps the entire interesting problem. Show that you thought about what happens when the model decides to issue a refund, and you are discussing a different class of work than the person who built a chatbot. Part 19 covers the gate design, and the conceptual framing is in AI agents explained in the GenAI Series.
Gaps to close in your first year
Thirty parts covered application engineering against hosted models. Three areas were deliberately left out, and you will meet all of them. Self hosted and distributed inference, meaning quantisation, batching servers and GPU economics, becomes relevant the moment volume or data residency rules out an API. Training economics, meaning when a fine tune actually pays for itself, was argued in Part 7 but never run end to end. Compliance and model risk governance is the third, and it is the one that stalls launches.
Here is how I would sequence the next twelve months, whether you are job hunting or already in seat. Each quarter produces an artifact, because a quarter that produces only reading produces nothing.
| Quarter | Focus | Artifact you finish with | Done when |
|---|---|---|---|
| Q1 | Evaluation depth. Human labelling, agreement rates, judge calibration | An eval set of 100 plus labelled cases with a documented scoring rubric | You can reject a prompt change with a number rather than an opinion |
| Q2 | Security. Work the OWASP LLM Top 10 against your own system | A written threat model plus injection tests in CI | An untrusted document in your corpus cannot change agent behaviour |
| Q3 | Self hosted inference. Quantisation, batching, GPU sizing | A benchmark comparing hosted API cost against your own served model | You can state the crossover volume where self hosting wins |
| Q4 | Governance and fine tuning economics | One fine tune run end to end with a payback calculation, plus a model card | You can walk a risk reviewer through the system without an engineer present |
On structured learning, Anthropic publishes free courses covering the developer platform, the Claude API and Model Context Protocol server construction, and they are a reasonable spine for Q1 and Q2 if you prefer guided material. Treat any single vendor curriculum as one implementation of ideas that generalise, and cross read against the other provider docs, exactly as this series has done throughout.
Where to spend your next hundred hours
If you have a hundred hours and one goal, put seventy of them into evaluation and thirty into security. Not prompting, which you will pick up by doing, and not the newest framework, which will be different by the time you finish. Evaluation is what makes every other skill in this series compound, because without it you cannot tell whether any change you make is an improvement, and a system nobody can measure is a system nobody can safely change.
Skill I would avoid over investing in right now is framework fluency. Knowing one orchestration library deeply looks like expertise and ages like milk. Underlying concepts, retrieval quality, tool design, state management, evaluation, have been stable for three years while the libraries have churned repeatedly.
On Monday, do one thing: take whatever LLM feature you own or want to own, write down twenty questions it should answer, label the correct answers by hand, and run them. Two hours of work. Whatever number comes back will be lower than you expect, and that number is the beginning of every serious conversation you will have in this job.
That closes the series. Thirty parts, one project, from a single API call in Part 2 to a cost controlled, evaluated, portable service in Part 29. If you build something from it, or it saves you one of the three day debugging sessions described along the way, I would like to hear about it. Full index sits on the AI Engineering guide.
References
- 2026 Global Talent Shortage Survey, ManpowerGroup, 39,063 employers across 41 countries, with AI model and application development at 20 percent as the hardest skill group to fill.
- OWASP Top 10 for LLM Applications 2025, OWASP Gen AI Security Project, the Q2 reading list, with prompt injection at number one and sensitive information disclosure risen to number two.
- Anthropic courses, free structured material on the developer platform, the Claude API and building Model Context Protocol servers in Python.
- Model Context Protocol specification, the standard covered in Part 16 and worth tracking as tool access consolidates.
About The Author
DrJha