Agentic Coding vs AI Engineering

Three roles get collapsed into one "AI" buzzword: traditional ML/AI (training models), AI engineering (building AI into products -- mostly integration), and agentic coding (doing software development with agents). The further you move from ML toward agentic coding, the less day-to-day ML depth the work needs -- embeddings, RAG, and prompt engineering become useful background, not the main focus.

The Pattern

Three roles get collapsed into one "AI" buzzword and constantly conflated. They sit on a spectrum from deep machine learning to plain software development:

• Traditional ML / AI -- researching and training models: the statistics, data, and math. Deep ML knowledge is the job.
• AI engineering -- building AI into a product: LLM features, RAG, evaluation, agents-as-product. Mostly integration -- wiring models, retrieval, tools, and evals together. This is the role Swyx named in 2023.
• Agentic coding -- doing ordinary software development with AI agents. You build any software; the agent is your tool, and you are still a software engineer whose toolchain changed.

The first two are domains of work; the third is a way of working. And they sit in that order for a reason: foundation models and APIs abstracted the hard ML parts, so the further right you move, the less ML depth the day-to-day needs. Work that once "took five years and a research team" now needs only "API docs and a spare afternoon" (Swyx); as Andrej Karpathy put it, "LLMs created a whole new layer of abstraction and profession... there's a lot of glue code/infra around it," with "significantly more AI Engineers than there are ML engineers" (Karpathy).

So the ML/AI fundamentals are good to have, not the main thing:

• For AI engineering, an understanding of ML helps -- but the job is integration, combining things rather than training them.
• For agentic coding, knowing how embeddings, RAG, and prompt engineering work helps you reason about why an agent misbehaves -- but it is not the focus. The focus is software and domain expertise, with the agent as the tool.

That last point has data behind it: across ~400,000 Claude Code sessions, people made about 70% of the planning decisions (what to build) and the agent about 80% of the execution decisions (how), and domain expertise -- not coding proficiency -- drove success: non-engineers reached verified success within a few points of software engineers (Anthropic).

Why It Matters

Conflating the three muddies hiring, learning, and team design -- a job ad for an "AI engineer" can mean any of them, and a developer "getting into AI" may be choosing between very different paths.

It matters most when you hire -- don't gate the work behind deep ML credentials:

• For AI engineering, hire integrators: API fluency, systems thinking, a feel for what "good output" looks like. By 2025 the field had shifted from vector databases to evals -- the question is no longer "can AI code?" but "how do we know the output is good?"
• For agentic coding, hire engineers and domain experts; treat ML depth as a bonus, not a prerequisite.

Most patterns on this site are about agentic coding -- working with agents to build software -- not AI engineering or ML, even though the skill sets increasingly overlap.

Last reviewed: 2026-06-26