Anil Dash wrote something recently that stuck with me.

He was writing about what happens to engineers in the age of LLMs, and he made a distinction most AI discourse glosses over. There are engineers who code because it pays well. And there are engineers who code because something about the work itself — the precision, the craft, the quiet satisfaction of getting a system to do exactly what it should — is part of who they are.

For the second group, he said, the LLM transition isn't just a career disruption. It's a grief event. The part that mattered — writing the code — is getting abstracted away.

He's right about the grief. But he's also pointing, maybe without meaning to, at a door opening.

What Gets Abstracted, and What Doesn't

LLMs changed the economics of writing code. They didn't change what it takes to deploy AI that actually changes how a business runs.

They don't take away the judgment about what to build. They don't take away the ability to walk into a manufacturing plant, spend three days understanding how bids actually move through a pipeline, and come out knowing exactly where a model would change the outcome — and whether it would be trusted enough to get used. They don't take away the domain depth that turns a technically correct RAG implementation into one that retrieves something useful to a real person making a real decision.

What's getting automated is the assembly. What's getting amplified is the engineering judgment that was always the scarce ingredient.

The engineers who figure this out early — who lean into the deployment problem rather than away from it — are about to have the most interesting careers in the field.

Forward-Deployed: Where Engineers Ship Outcomes, Not Just Code

a16z called it one of their biggest ideas for 2026: forward-deployed AI. The thesis is simple and the implications are enormous. Most AI benefits have accrued to companies in or adjacent to Silicon Valley. The rest of the economy — manufacturers, logistics operators, specialty distributors, regional healthcare companies — is largely untouched. Not because the technology doesn't apply. Because no one has done the work of actually deploying it there. Joe Schmidt put it plainly: new founders and engineers need to use forward-deployed motions to discover the opportunities hiding inside big, legacy verticals. The opportunity, he argues, is massive.

That gap is an engineering problem. And it's not the kind that gets solved remotely, with a clean spec, against a well-structured dataset.

Getting AI into a real operation is a discovery process. The data is messier than anyone described. The ERP was customized in 2009 by someone who no longer works there. The "historical bid data" turns out to be a combination of three spreadsheets, a CRM that wasn't used consistently until 2022, and institutional memory in the head of a VP of Sales who is retiring in 18 months. The CAD files are in a proprietary binary format with essentially no accessible metadata.

None of this is in the requirements document. It's what you find when you actually go.

And when you go — when you're the engineer embedded in the operation, running discovery sprints, doing the data profiling, building solutions that fit the actual workflow rather than an idealized version of it — you're doing something no amount of LLM tooling replaces. You're the one closing the gap between what AI can theoretically do and what it actually does, for real people, in a real business, with consequences that matter.

That's what forward-deployed engineering looks like. And that's what shipping outcomes means.

What the Work Actually Looks Like

It looks like being embedded with a fleet cost optimization company and realizing their invoices arrive in 47 vendor-specific formats with OCR variations no rule-based matcher can handle — and building a ten-stage AI pipeline with a structured rules engine that knows "WESCO DIST INC" and "Wesco Distribution" are the same entity. Then watching the operation run faster because of something you built.

It looks like working with a customs brokerage and discovering that ISF filing deadlines carry direct financial penalties — which means the CBP status polling interval isn't an architecture preference. It's 60 seconds, because anything slower is operationally wrong. And building the 12-state lifecycle machine that makes that reliable.

It looks like spending the first week of an engagement not writing code at all, but profiling data, running workshops with domain experts, understanding what the 15-year veteran knows that the system doesn't — and using that to design a scoring model the sales team will trust enough to actually change how they work.

This isn't CRUD apps. It isn't the AI feature tacked onto a SaaS product. It's engineering in the service of operations built over decades, where what you build either works in the field or it doesn't.

The Engineers This Work Is Built For

Dash writes about coders with soul — people who got into this because building things with code is intrinsically satisfying, not just financially rewarding. He worries about what happens to them as the act of writing code gets abstracted away.

We're less worried. Because the thing that made those engineers interesting was never the syntax. It was the judgment. The curiosity. The drive to understand a system well enough to make it better. The desire to see something they built actually used, actually trusted, actually changing how someone does their job.

Those qualities have a home. It's just not where most AI engineering roles are being posted right now.

It's inside a manufacturing operation in the Midwest, where someone has spent 20 years accumulating domain knowledge no LLM was trained on. It's inside a fleet management company that guarantees its clients measurable savings — and needs engineers who understand that the AI has to earn that guarantee, not just generate output. It's anywhere the work is real, the stakes are real, and shipping outcomes means more than merging a PR.

Any engineer can ship code. Not every engineer can ship outcomes.

If you're the second kind, we'd like to talk to you.