Why domain expertise is becoming the scarce skill in agentic coding

The model before the code

The hard part of writing software has never been the writing, argues a post on the blog brethorsting.com: it was building a working model of the domain in your head first. Before shipping a payroll system you had to understand garnishments, pre-tax deductions and what happens when someone's pay period straddles a rate change. Before shipping a transit app you had to learn what a GTFS feed is, why a trip and a route are not the same thing, and how a bus marked as on time can still be wrong. The code was a transcription of that understanding; acquiring the understanding was the job.

What agentic AI changed

Agentic AI severed the link between the two, the post argues: software can now be produced without ever building the model, which breaks an assumption the profession was organised around. The standard take — including the author's own from a year earlier — is that these tools amplify senior developers because senior developers have judgement. That is true but incomplete. The binding constraint, he writes, has moved from can you build it to can you tell whether it is right.

Two people, two failure modes

Take a domain expert with no software background: a logistics dispatcher, a clinical coder, an actuary. They cannot read a stack trace, but they can look at a generated schedule 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 have spent ten years living in them. The ability they lack is exactly the one the agent supplies, and what they bring — ground truth — is what the agent cannot. Now take a strong generalist engineer new to the domain. They can architect anything, but in clinical coding they cannot tell a plausible-looking wrong answer from a right one. The agent will generate a billing rule that compiles, passes the tests the engineer thought to write, and is subtly, expensively incorrect. The engineer has no oracle.

Which path collapsed, and what to bet on

Before agents, the engineer had a path the dispatcher did not: they could learn the domain slowly, by shadowing experts and getting things wrong in production, and then build the system. The domain expert had no equivalent path, because learning to build reliable software was years of work they were never going to do. Agentic tools collapsed one of those paths and not the other. The engineer's advantage — translating a domain model into working code — is now cheap; the expert's advantage, knowing what right looks like, is not, and cannot be prompted into existence. The most valuable person in this new world, the post concludes, is the one who holds both skills, because they can verify at both layers. They can write the test that encodes the rule that a driver cannot exceed eleven hours because they know the rule. The agent does the transcription; they do the judging, twice. For engineers deciding where to spend the next few years, the advice is to pick an industry, an instrument or a regulatory regime and learn it the way they once learned a programming language.