Domain Expertise Has Always Been the Real Moat

The hard part of writing software has never been the writing. It was building a working model of the domain in your head first. Before you could ship a payroll system you had to understand garnishments and pre-tax deductions and what happens when someone’s pay period straddles a rate change. Before you could ship a transit app you had to learn what a GTFS feed is, why a trip and a route aren’t the same thing, and how a bus that’s “on time” can still be wrong. The code was a transcription of that understanding. Acquiring the understanding was the job.

Agentic AI severed the link between the two. You can now produce the software without ever building the model, and that breaks an assumption the whole profession was organized around.

The standard take, including my own from last year, is that these tools amplify senior developers because senior developers have judgment. True, but incomplete. What I’ve watched happen since is more specific and more interesting: the binding constraint has moved from can you build it to can you tell whether it’s right.

Think about who can actually use one of these tools well. Picture two people.

The first is a domain expert with no real software background. A logistics dispatcher, a clinical coder, an actuary. They can’t read a stack trace and they couldn’t tell you the difference between a hash map and a list. But they can look at a schedule the agent generated and know instantly that no driver can legally work that shift, or that a claim with those codes would never pay. They know the correct outputs for a given set of inputs because they’ve spent ten years living in those inputs and outputs. Hand them an agent and they are startlingly effective, because the thing they’re missing, the ability to produce code, is exactly the thing the agent supplies. What they bring is the thing the agent can’t: the ground truth.

The second is a strong generalist engineer who has never worked in the domain. They can architect anything, they know reliability and testing and how to keep a system from falling over at 2am. But drop them into clinical coding and they cannot tell a plausible-looking wrong answer from a right one. The agent will happily generate a billing rule that compiles, passes the tests the engineer thought to write, and is subtly, expensively incorrect. The engineer has no oracle. They can verify that the software is well-built. They cannot verify that it’s correct, because correctness here is defined entirely by a domain they don’t hold in their head.

Notice which way this cuts. Pre-agent, the engineer had a path the dispatcher didn’t: they could go learn the domain. Slowly, painfully, by shadowing experts and reading specs and getting things wrong in production, they would build the mental model and then they could build the system. That path was the whole career ladder in a lot of fields. The domain expert had no equivalent path, because learning to build reliable software is years of work they were never going to do.

Agentic tools collapsed one of those paths and not the other. The engineer’s advantage, the ability to translate a domain model into working code, is now cheap. The domain expert’s advantage, knowing what right looks like, is not. You can’t prompt your way to it. There’s no skill file that contains the tacit knowledge of a person who has reconciled a thousand payrolls.

So the most valuable person in this new world is the one who has both skills because they can verify at both layers. They know the generated code is sound and they know the answers it produces are true. They can write the test that encodes “a driver can’t exceed eleven hours” because they know the rule, and they can tell that the test itself is meaningful because they know what they’re testing. The agent does the transcription. They do the judging, twice.

If you’re an experienced engineer betting on where to spend the next few years, this is the bet. The mechanical skill you sweated for, turning a clear idea into clean code, has gotten dramatically less valuable. The thing that’s still scarce is a deep, verified model of some real domain. Go get one. Pick an industry, an instrument, a regulatory regime, a physical process, and learn it the way you once learned a programming language or framework. That’s the part the agent can’t do for you, and it’s the part that’s now worth the most.