--- title: 'Becoming an AI engineer: the production-first path' excerpt: 'Most AI-engineer roadmaps list technologies. This one lists the six places production actually broke for us, because that is what the job defends against.' date: '2026-06-24' lastModified: '2026-07-04' author: 'Teo Deleanu' authorAvatar: '/team/teo.jpg' tags: ['AI Engineering', 'Production AI', 'Career', 'Learning'] keywords: ['becoming an AI engineer', 'AI engineer roadmap', 'AI engineering skills', 'learn production AI'] featured: false tldr: 'The AI engineer job is systems engineering around models, and the honest curriculum is the list of places production breaks: retrieval, agent loops, evals, observability, deployment, and multi-agent coordination. Each of those six areas maps to a documented failure from systems this blog operates, which is a better reason to learn it than any trend report. The way in is one narrow system built end to end and run in production, because a week of operating your own pipeline teaches what no tutorial covers. The model layer changes every quarter; the six failure surfaces have stayed stable.' keyTakeaways: - 'The job is not training models. It is building and operating the retrieval, tooling, gating, and observability around models someone else trains.' - 'Learn areas in order of what breaks: retrieval fails before generation, quality regresses without eval gates, and silent failures ship without purpose-built signals.' - 'Build one narrow system end to end and run it in production for a week; operating it is the half of the education tutorials cannot deliver.' - 'Skills compound when written down and versioned; process you cannot diff is process you cannot improve.' --- Roadmaps for becoming an AI engineer mostly list technologies: a vector database, a framework, a fine-tuning tutorial, an agent library. I have hired for this role and worked it, and the list I trust is different. It is the list of places production actually broke on systems I operate, because the job, reduced to one sentence, is defending a production system at the places where models meet reality. That defines the role better than any tooling inventory. An AI engineer in 2026 almost never trains a model. The models come from providers, arrive competent, and change quarterly. What does not arrive from the provider is everything around the model: retrieval that finds the right context, tools that act safely, gates that catch quality regressions, telemetry that sees silent failures, and the deployment substrate under all of it. That surrounding system is the job, and every part of this claim has a receipt in the posts this one links. ![The six failure surfaces an AI engineer defends: retrieval, agent loops, evals, observability, deployment and operations, and coordination at scale, each paired with the documented incident that earned it a place, plus a not-on-the-list row for transformer internals, fine-tuning, and prompt tricks](/blog/ai-engineer-surfaces.svg) ## The six failure surfaces Six areas cover most of what production demands, and each earned its place by breaking somewhere we run. This is also, not coincidentally, the shape of [what we teach](/diy); the curriculum was reverse-engineered from the incidents. **Retrieval.** When a RAG system answers badly, retrieval usually failed stages before the model ever ran, and the fix lives in chunking, hybrid search, and ranking rather than in a bigger model. Learn why recall is the ceiling on everything downstream: [how RAG works in production](/blog/how-rag-works-in-production). **Agent loops.** The expensive lesson is that orchestration should route rather than manage, and that most questions should never pay the multi-agent tax at all. The receipts, including a manager pattern that burned tokens negotiating with itself, are in [the anatomy of a multi-agent platform](/blog/anatomy-of-a-multi-agent-platform). **Evals.** Without a merge gate scoring model behavior, quality regressions ship exactly as easily as they would with no tests. A weekend of golden questions and CI wiring buys the gate: [evals as CI](/blog/evals-as-ci). **Observability.** The failures that kill AI products return HTTP 200, so the signals that matter are ones you build on purpose: scorers, probes, latency histograms, cost attribution. The full map: [silent failures](/blog/silent-failures-observability). **Deployment and operations.** Queues, timeouts, rate limits keyed to the right client, cold starts. Our demo needed five interventions in its first production week, every one an operations lesson rather than a model lesson: [the week-one incident log](/blog/it-runs-itself-first-week). **Coordination at scale.** Task queues, durable workflows, and knowing which your workload needs before it teaches you at 2 a.m.: [Airflow vs Celery vs Temporal](/compare/airflow-vs-celery-vs-temporal). Notice what the list omits. Transformer internals help interviews more than incidents. Fine-tuning is a specialist track most production work never touches. Prompt tricks decay with every model release, while the six surfaces above have stayed stable through every migration we have run. ## The way in is one narrow system Reading about the six surfaces is a start, and it is the smaller half. The half that makes you employable is operating something you built, because production is the only teacher for half this list. The path I recommend is the one documented in [the narrow-loop playbook](/blog/narrow-loop-playbook): pick one loop with a measurable output, write the spec and twenty golden questions before code, ship the thinnest complete pipeline to real infrastructure, gate merges on your eval delta, and then, the step everyone skips, run it for a week and read the logs daily. The [demo](/demo) on this site is that path executed: a document pipeline built in 29 days that then delivered a week of incidents worth more than any course module, from a model retired upstream to an answer rendered white on white. A week of operating your own system converts abstractions into instincts. "Retrieval fails before generation" is a sentence until your own recall number drops. "HTTP 200 is not a health signal" is a slogan until your own green dashboard hides a broken product. ## Tools change, write the process down One more habit separates engineers who compound from engineers who restart: writing the process down where it can be versioned. Our version of that is a library of roughly 85 SKILL.md files with semver and CI-checked pins, described in [how AI agents remember](/blog/how-ai-agents-remember), and the practice matters more than the format. A mistake corrected in writing stays corrected. Process you cannot diff is process you cannot improve, and in a field where the model layer changes quarterly, your written process is the asset that survives each change. That habit also happens to be the answer to the anxiety under most roadmap questions: whether the skills will still matter next year. The specific model names in this post will age. The failure surfaces will not, and neither will the discipline of receipts. If you want the guided version, [the DIY program](/diy) teaches these six modules on a system you build yourself, with the same skill library included. If you would rather assemble it from primary sources, every post linked above is free, and the sequence in the playbook is the syllabus. Either way, the credential that counts is a narrow system you operate, with numbers you can defend, which is exactly the standard [the operator brief](/about) holds itself to.