Domain Expertise Has Always Been the Real Moat | Aaron Brethorst

Brethorsting

Home
Blog
Categories
Archive

Links

My Photography

Threads

Instagram

GitHub

LinkedIn

Email Me

Menu

Home
Blog
Categories
Archive
RSS Feed

Links

My Photography

Threads

Instagram

GitHub

LinkedIn

Email Me

May 30, 2026

Software Engineering

AI

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.

© Aaron Brethorst

The process of writing software has historically been less about the mechanics of coding and more about establishing a foundational understanding of the underlying domain. Before actual coding could begin, one had to build a mental model of the domain; for instance, one needed to understand the complexities of garnishments and pre-tax deductions before building a payroll system, or grasp concepts like the structure of a GTFS feed and the nuances of scheduling before developing a transit application. The code itself was merely a transcription of this pre-existing understanding, implying that the acquisition of domain knowledge was the primary professional hurdle.

The advent of agentic artificial intelligence has fundamentally altered this dynamic by severing the direct link between developing domain understanding and producing functional software, thereby challenging established professional assumptions. While some views suggest that these tools primarily amplify senior developers due to their inherent judgment, the more precise observation is that the binding constraint has shifted from the ability to build something to the ability to verify its correctness.

This shift highlights a crucial differentiation between two types of professionals. The first group consists of domain experts, such as logistics dispatchers, clinical coders, or actuaries, who possess deep, practical knowledge of a field. These experts do not necessarily have a background in software engineering, yet they possess the necessary "ground truth." They can instantly recognize whether an agent-generated schedule is legally viable or if a claim code is accurate, because they have internalized the necessary inputs and outputs through years of real-world experience. When provided with an agent, these experts are highly effective because they supply the domain context—the knowledge the agent lacks—which allows the system to produce meaningful results.

The second group comprises strong generalist engineers who excel at system architecture, reliability, and testing. However, when placed in a specialized domain, these engineers lack the necessary specialized knowledge required to assess the true correctness of the output. An agent can generate code that is syntactically correct and passes predefined tests, but if the domain context is absent, the resulting software may be technically sound yet fundamentally incorrect or, more dangerously, expensively flawed. The generalist engineer cannot verify the true correctness of the answers because the definition of correctness is embedded within the specific domain knowledge that they do not possess.

Historically, the professional trajectory involved a path where engineers could acquire domain expertise by shadowing experts, reading specifications, and iteratively making errors in a production setting to build a mental model before coding the solution. This path was unavailable to domain experts, as learning the rigorous process of building reliable software was an extensive, time-consuming endeavor for them. Agentic tools have collapsed this historical divergence by making the mechanical skill of translating a domain model into working code significantly less valued.

Consequently, the most valuable asset in this evolving environment is the individual who possesses both skill sets: the ability to verify the code’s technical soundness and the ability to verify the results’ factual accuracy. This dual capability allows the professional to act as a crucial layer of verification. The agent handles the transcription and mechanical execution, while the human provides the necessary judgment, double-checking that the generated outputs align with established domain truths.

For an experienced engineer planning their career, this necessitates a strategic pivot. The mechanical capability of translating an idea into clean code has diminished in relative importance. The scarcity now lies in developing a deep, verified model of a specific domain. This involves choosing an industry, a regulatory framework, or a complex physical process, and dedicating oneself to learning it in the same rigorous manner once applied to mastering programming languages or frameworks. This domain expertise is precisely the element that agents cannot replicate, making it the most valuable skill in the modern landscape.