Why Domain Expertise Beats Coding in the AI Era

The advice every junior engineer hears is some variation of the same thing: learn the fundamentals, ship side projects, get good at coding, and the career follows. For a long time, that advice worked. Coding was the bottleneck. The engineers who could write reliable systems were rare and valuable, and the path was clear — get better at the craft, get hired, get promoted.

Paul Iusztin, the author of LLM Engineer’s Handbook (~20,000 copies sold), thinks that path is closing. And the strange thing about the argument is who’s making it. Paul wrote a coding book. He runs a 40,000-subscriber newsletter about LLM engineering. He just launched a course called Agentic AI Engineering. He’s spent the last decade specializing harder in code than almost anyone you’ll meet.

When Angelina asked him at the end of our recording what advice he’d give younger engineers, his answer was direct and uncomfortable. “Be extremely good in a specific domain rather than know how to code.”

The bottleneck that’s moving

The premise underneath the advice is a bet about where engineering value will compound. For two decades, code was scarce — there weren’t enough people who could build systems, and the ones who could captured the value. AI is making code abundant. Not perfect code, not architectural code, but enough code that the bottleneck is shifting from “can someone build this?” to “should someone build this, and what should it do?”

Paul’s framing: “If you have the domain, that’s a thing that’s extremely valuable. Doctors — whatever happens. But how doctors will look like and how hospitals will look like with that, I don’t know.”

The valuable engineers in five years won’t be the ones who can write the cleanest React. They’ll be the ones who understand healthcare workflows well enough to know what AI should automate and what it shouldn’t. Or finance. Or supply chain. Or education. Or law. Domain expertise is becoming the input that determines whether AI produces something useful or something useless.

Why this is different from “be a generalist”

Paul isn’t arguing for generalism. The opposite — he’s arguing for deeper specialization, just in a different layer of the stack.

The shift looks like this:

Old specialization: Pick a tech stack, get extremely good at it, ride it for a decade. (Backend, frontend, infra, ML.)

New specialization: Pick a domain, get extremely good at it, use AI to build inside it. (Healthcare workflows, financial advisor automation, K-12 education software, legal contract review.)

The first kind of specialization is what Paul did before the AI era — he went deep on ML and AI engineering for ten years. The second kind is what he’s recommending now, because the leverage has changed. Code is becoming a tool every domain expert can wield. Domain expertise is becoming the constraint.

“For me, it’s education right now with AI. And if you go down, down the route, it will be very easy to adapt,” Paul says. The domain becomes the moat. The technical implementation becomes the commodity layer.

What this looks like in practice

Paul’s own startup is the proof of concept. He’s a founding AI engineer building vertical AI agents for financial advisors — not because finance is his lifelong passion, but because the domain has specific workflows (document-heavy, regulatory-bound, relationship-driven) that benefit from AI automation.

The advisors and operations people in that space know things he doesn’t. They know which steps in the advisory workflow are repetitive enough to automate and which require human judgment. They know what the compliance requirements are. They know what pricing the market will bear. Paul’s technical skill matters — but only in service of decisions made by people who understand the domain.

This is also what he means when he calls vertical AI agents “the new web apps” — frameworks and patterns will templatize. The differentiator won’t be the technical implementation. It will be the depth of domain understanding that informs what gets built.

For an engineer planning a career today, the implication is direct: pick a domain you can stay in for a decade. Spend time inside it before you spend time building for it. Talk to the people doing the work, not just the people buying software. Build the technical chops on top of the domain understanding, not the other way around.

The honest version

Paul is careful to acknowledge what he doesn’t know. “It’s hard to predict how things will look. But if you have the domain, that’s a thing that’s extremely valuable.”

The argument isn’t that coding skills won’t matter. They will. The argument is that the return on coding skills is plateauing while the return on domain expertise is climbing. An engineer who can code well and knows medicine deeply will out-earn an engineer who can code well and knows nothing else. An engineer who knows medicine deeply and can use AI tools will out-earn one who only does the medical knowledge work without the leverage.

The compounding has shifted. The engineers who notice the shift and pick a domain to go deep in will compound at a rate the pure-coder career path can’t match.

What this looks like for someone starting now

If you’re 22 and trying to decide between a generalist software path and a domain-specialist path, Paul’s advice tilts hard toward domain. The mistake to avoid is treating “AI engineer” as the destination — that’s still a tech-stack specialization. Treat it as a tool for building inside a domain.

Three practical implications:

Pick a domain you can spend a decade inside. Boring is fine — Paul says financial advisor workflows aren’t sexy, but the work is exciting because the technical patterns transfer to medicine, e-commerce, education, and any other vertical AI play. Boring + transferable beats exciting + niche.

Spend real time inside the domain before building for it. Talk to practitioners. Read trade publications. Understand what the people doing the work actually do all day. Most failed AI products fail because the engineers building them never understood the domain.

Use AI as a leverage tool. Vibe coding, frameworks, agentic systems — adopt them aggressively. They’re how you turn one engineer’s domain understanding into a product. The leverage isn’t optional anymore.

The career path Paul lays out is harder to follow than the standard advice. It requires patience inside a vertical, willingness to learn things that aren’t strictly technical, and discipline about not chasing every framework. But it compounds in a way the pure-tech path no longer does.

FAQ

Should young engineers learn to code or specialize in a domain?

Both, but in a specific order. Build coding fluency early, then pick a domain (medicine, finance, education, e-commerce, law) and go deep for years. AI is making coding skill abundant; domain expertise is becoming the rare input. Engineers who pair coding ability with deep domain knowledge will out-earn pure-tech specialists in the AI era.

Why does Paul Iusztin think coding is becoming abundant?

Tools like Cursor, Claude Code, and Lovable extend coding capability to engineers and non-engineers alike. The work that was scarce a decade ago — building reliable systems — is becoming a tool that domain experts can wield. The bottleneck shifts from “can this be built?” to “what should be built and how should it work?” Domain expertise answers the second question.

What domains are best for AI engineers to specialize in?

Domains with high regulatory complexity, document-heavy workflows, or relationship-driven processes are strong fits — financial advisory, healthcare administration, legal contracts, K-12 education, supply chain. The pattern: domains where the work is currently manual but the patterns are repeatable. Paul Iusztin’s startup builds vertical AI agents for financial advisors as one example.

Is it too late to start an AI engineering career?

No, but the entry path has changed. Specialize in a domain rather than chasing the latest framework. Learn coding fundamentals, then go deep on a vertical (finance, medicine, education) you can stay inside for a decade. The engineers entering the field now have an advantage if they pick the domain layer; those competing on framework knowledge alone face a tougher market.

How does vertical AI compare to horizontal AI as a career path?

Horizontal AI (foundation models, general-purpose tools) consolidates around a few large companies and demands deep ML research expertise. Vertical AI (domain-specific applications) is fragmented across hundreds of industries and rewards engineers who pair AI fluency with domain depth. Paul Iusztin calls vertical AI agents “the new web apps” — high volume, transferable patterns, broad opportunity.

What’s the difference between AI engineering and ML engineering?

ML engineering historically focused on training, fine-tuning, and deploying models. AI engineering focuses on building applications on top of existing models — RAG, agents, evaluation systems, prompt engineering, integration. The skills overlap but the bottlenecks are different. AI engineers spend less time on models and more time on system design, integration, and evaluation.

How long does it take to develop deep domain expertise?

Years, not months. Paul Iusztin spent ten years going deep on AI engineering before launching the bestselling LLM Engineer’s Handbook. Domain expertise compounds the same way — quick familiarity isn’t enough. Plan for two to five years of working inside a domain before claiming expertise. The compounding makes the long timeline worth it.

Can engineers transition into a domain specialization mid-career?

Yes, and the AI era makes it easier than ever. Mid-career engineers already have technical leverage. Adding domain expertise compounds quickly because they can ship working products inside the domain while learning. The biggest barrier is patience — accepting that the first year inside a new domain produces less output than the year before, while the foundation is being built.

What’s the risk of specializing in a domain?

The main risk is picking a domain that doesn’t grow or doesn’t transfer. Paul Iusztin’s hedge is choosing domains with workflows that translate across industries — document-heavy advisory work, regulatory-bound processes, relationship-driven services. The technical patterns transfer even if the specific industry contracts. Pure niche specialization (one micro-vertical only) carries more risk than broader workflow specialization.