Skills to Become an AI Engineer

>_You don't need a PhD

Let me kill the most expensive myth first: you do not need a machine learning PhD to become an AI engineer. You do not need to derive backpropagation or train a transformer from scratch. The labs already did that research and put the result behind an API. Your job starts where theirs ends.

Almost every strong AI engineer I have worked with came up through software engineering, not research. The ones who struggle are usually chasing the wrong syllabus, grinding linear algebra when the real work is prompts, retrieval, evaluation, and shipping. This is the roadmap I would hand my past self. I described the discipline itself in /resources/what-is-ai-engineering; this is the study plan.

>_Start with real software engineering

The best predictor of a good AI engineer is not curiosity about models but whether they can already ship a boring backend service without help. An LLM feature is a distributed system that happens to call a probabilistic API in the middle, so if you cannot debug a flaky HTTP call or model your data cleanly, adding a model only hides the problem behind something harder to inspect. Get fluent in Python or TypeScript, then make the fundamentals underneath solid.

• -APIs in depth: HTTP, JSON, auth, retries, timeouts, and streaming responses, which the model APIs lean on constantly.
• -Async and concurrency: model calls are slow and I/O-bound, so you will batch, fan out, and stream all the time.
• -Data modeling and a real database: context has to come from somewhere structured.
• -Git, tests, and deployment: the ordinary craft of shipping and rolling back code without drama.
• -Type-safe code and schema validation: your first guardrail against a model that returns garbage.

>_Prompting is your first control surface

Once you can ship, prompting is the first AI-specific skill to build: it is the cheapest, fastest lever over model behavior. Before you reach for a framework or a vector database, you can change what the system does by changing what you ask. Most 'the model is not good enough' complaints I investigate turn out to be a vague instruction, a missing constraint, or one prompt asking for four things at once.

Learn the moves that move quality: clear structure with delimiters, few-shot examples that cover the cases you fear, decomposing hard tasks into ordered steps, and pinning the output format so it is parseable. Then treat the prompt like code: version it, change one thing at a time, and never tune by vibes. The techniques are in /resources/what-is-prompt-engineering. Do not move on until you can reliably get structured output on inputs you did not hand-pick.

>_Evals separate shippers from demoers

If you learn one thing here deeply, make it evaluation. An eval is a dataset of representative inputs plus a way to score the outputs, the closest thing this field has to a test suite for a system that never returns the same answer twice.

You do not need a fancy harness to start. Twenty real inputs, an expected outcome or rubric, and a script that runs your prompt against them puts you ahead of most teams. Then learn the scoring ladder: exact match where you can, regex for the cheap wins, an LLM grading a rubric for open-ended quality, and a human in the loop for anything risky. Study LLM-as-judge and its biases, because a bad judge lies to you quietly. I go deep in /resources/what-are-ai-evals and /resources/how-to-test-llm-applications.

>_Retrieval, without the mystique

Retrieval-augmented generation sounds exotic and is mostly plumbing. You embed your documents into vectors, store them in an index, and at query time pull the relevant chunks into the prompt so the model answers from your data instead of its training. Learn it early: grounding in real data is what turns a chatbot demo into something a business will pay for.

The skill is not calling the embedding API, which takes an afternoon. It is everything around it: how you chunk documents, which embedding model you pick, whether you rerank results, and what you do when nothing relevant is found. Build one honest pipeline over your own documents with pgvector or a hosted vector store, and watch how often bad answers trace back to bad retrieval rather than a bad model.

>_Orchestration and agents

When a single call is not enough, you move into orchestration: chaining calls, routing between models, giving the model tools, and letting it loop until a task is done. This is where agents live, and where the most hype and wasted effort pile up. The trap is reaching for a heavyweight framework before you understand the primitives it hides. Learn the raw moves first.

• -Tool and function calling: letting the model invoke real code and act on the world, not just describe it.
• -The agent loop: plan, call a tool, observe the result, decide the next step, and know when to stop.
• -Routing and fallbacks: a cheap model for easy requests, a strong one for hard, and a path for failure.
• -State and memory: carrying context across steps without letting the window fill with noise.

>_Observability keeps you employed

Here is the skill no syllabus lists and every production team wishes it had learned sooner: observability. A deterministic service you can debug from a stack trace. An AI system fails quietly, returning a plausible, confident, wrong answer, and if you are not logging the full input, the retrieved context, the exact prompt, and the raw output, you cannot reconstruct what happened.

Learn to trace every step of a request end to end with Langfuse, LangSmith, or plain OpenTelemetry, so a bad answer becomes something you can open and inspect. Track cost and latency per call, because tokens are money and the model is the slow part of your stack. Watch for drift when a provider silently updates the model behind an endpoint, which is exactly what your evals are there to catch. The teams that sleep at night can answer one question: why did it say that.

>_Enough ML, and real product sense

You need some machine learning literacy, just far less than the gatekeepers imply. Know what a token is and why it caps context and cost. Know what temperature does, what embeddings represent, and roughly why a model hallucinates confident nonsense. That map is enough to make good decisions; skip the math that produces the weights, because you are never going to touch them.

The rarer, more valuable skill is product sense: knowing when not to use an LLM at all. A regex, a lookup table, or a plain function is often cheaper, faster, and more reliable; reach for the model only when the task truly needs open-ended language understanding. Half the craft is shaping the problem so the nondeterministic part stays small. The other half is caring whether the output is correct, which is really a quality discipline. I make that case in /resources/quality-assurance-in-the-ai-era.

>_Build these, skip that

Reading about this stack teaches you nothing. Building on it teaches you everything, because the failure modes only show up when real inputs hit your code. Skip the tempting detours: fine-tuning your own model before you have exhausted prompting and retrieval, collecting frameworks like trading cards, and treating every new model release as if last week's stack is obsolete. It is not; the primitives are stable even as the syntax churns.

None of this requires permission or a new title. The engineers who own this era are not the ones who memorized the most about models. They are the ones who can make a probabilistic system behave, prove that it does, and keep it honest in production. It is a learnable skill. If you want a path from zero, build these in order and start this week:

• -A structured extractor that pulls clean, validated JSON out of messy text, with a ten-case eval written before you tune the prompt.
• -A RAG app over your own documents, so you feel how often bad answers are really bad retrieval.
• -A small agent with two or three tools you wrote by hand, no framework, so you understand the loop from the inside.
• -An eval harness you rerun on every change, wired to a cost and latency view.