Domain expertise has always been the real moat

As someone who has jumped from one industry to another: I'm sorry, but domain expertise isn't much of a moat. Yes, it takes a while to learn a particular industry/business, but it doesn't take that long, and worse still: one advantage that LLMs have over us humans is they have such a broader inventory of human knowledge at their disposal. I've literally used LLMs as product managers for new domains, and while I see the rough edges that LLMs have, they always have significant domain expertise.

I don't think that's the moat.

Domain knowledge is not the moat it might appear to be, especially in industries that heavily document

Using AI to more rapidly learn a domain will help in the short term

But in the long term, all moats will evaporate

> 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.

Not yet.

We won't be there until AI is more like a virtual person, where the domain expert trains the AI in a similar manner to training a real person.

At this point, agentic coding only eliminates the engineer when creating very simple applications. Once the application gets complex, either the domain expert needs to become an engineer, or an engineer is needed.

Knowing the correct answer to one million instances of a+b, and validating this, does not guarantee that an oracle will use the + operation that's correct over a domain billions of times larger, which you can't exhaustively check.

In the past few months, I've used agents to brute force and reverse engineer solutions to problems I would never have economically have figured out on my own. I did it by putting agents in loops, connected to hardware and the internet, reading technical documentation, and relentlessly trying.

The code was shit. But it's much better to start with working shit and make it correct than spend weeks frustrated that nothing works.

I get that being a domain expert and instantly knowing the output is shit is important, but even if the output looks great, the code can be shit, and it takes looking at the code and knowing something about it to figure that out.

The solution to shit output is not (always, sometimes it is) just another if statement.

Even in a very well specified OSS effort, where I have some expertise, and I carefully reviewed the AI's output every goddamn step of the way, bugs slip through that the agents confidently tell me can't happen, and when shown proof they… add just another if, instead of really questioning assumptions.

You either know what you're doing, or you don't.

One little detail. The models are already pre trained on similar system implementations. Likely whatever you are building has been built in some form or shape in the past and the ambiguity is resolved by someone in the training set.

> Domain Expertise Has Always Been the Real Moat

Yes, and the Big AI companies are currently hoarding data about all domains out there.

> There’s no skill file that contains the tacit knowledge of a person who has reconciled a thousand payrolls.

That person has zero skill in actually making tight automation that doesn't just fall over. And I have yet to see an AI agent that tells them "look, your requirements are contradictory, given this and that, these two cannot coexist".

Those little sycophants will just go and try to please the domain expert and placate him in all ways possible. Bend backwards rather then forcing them to reassess their assumptions.

This is why we have product managers!

More generally, I think it’s more specialized knowledge.

If you have particularly specific knowledge in pretty much any domain, combining that with AI can lead to huge gains.

"to build software you need someone who can make requirements and someone who can build systems"

revelations never stop coming do they

This is exactly my experience vibe coding as a security architect of 20 years https://open.substack.com/pub/rakkhi/p/vibe-coding-as-securi...

Domain expertise has always been the path to advancement in most SWE jobs. You’ve always had to understand the domain and have judgment to not be stuck as a “code monkey” in almost every company barring the big tech outliers where you can be on a generic framework or library team.

"Go get one."

Yes, and its price law all the way down to the metal, hasn't it always been?

I think this article is stating the obvious. In software, it has always been a requirement to learn the domain, and then capitalize on that in any way the software can be written (by hand, as a tech lead, or managing others, or lately, using ai).

To me, the bottleneck feels like it's shifted. It's no longer 'can we build this?' but 'should we build this, and why?' Strategy might be the last thing AI can't do for us at least for now

Brilliant framing. If you understand a domain and understand software architecture then you are in an extremely strong position right now.

I bet there were textile workers who would have written articles like this if the internet had existed back then.

> the binding constraint has moved from can you build it to can you tell whether it’s right.

My suspicion is we are still moving up along a continuum of capability.

Models didn’t used to produce coherent sentences (GPT-2 era) and now they can. Past models (GPT-3 era) made syntax errors and now models can write well structured code. Past models didn’t reliably emit correct syntax to request a tool call, or track context across multiple tool calls - and now they can.

Frontier models can’t write code without glaring security flaws, even as they already follow other best practices. So on those two criteria of code quality we are still in need of models improvements.

All these forms of correctness lie along a continuum. Today’s models can’t assess what’s needed in a domain for work to be “good” - but if current trends hold it’s just a matter of time.

There's a lot of people agreeing and disagreeing with the article, but on what grounds? How do you know "domain expertise" is a "moat"? Vibes? Has there been ongoing, persistent attacks by AI on domain expertise where we can say the moat holds, economically speaking? So far it seems quite the opposite.

So far the evidence seems to be pointing to a different adage, Sutton's Bitter Lesson, which (generalized) says to not bring human expertise to a problem that can be "solved" with unfathomable volumes of data. Because the latter has historically slaughtered the former for decades. But somehow people believe this time it's different?

I will counter there is one thing that is a persistent moat, and it's not domain expertise; it's sales. Convincing other humans to part with their money. Humans have shown they will trust a person/human touch to part with their money more than an AI.

But I'm not convinced today's AI or tomorrow's won't be able to replicate domain expertise in domain X for any X.

I started an agentic experience app in domaining , people don’t seem to take it that well , they are afraid of letting AI run on its own.

So "the real moat" are BIs and PMs equipped with LLMs? Man will I enjoy seeing this tower of babel crashing down on some heads. Unfortunately, software has tendency to survive for a long time even the shittiest conditions. Taking into account average turnover of 2 years, we're at least 3-5 generations before it collapses, so the people who started this madness will most likely be elsewhere and won't see the reckoning.

Domain expertise is neccessary but not sufficient.

It takes a LOT of time to validate every path, possibly an infinite amount of time, depending on the complexity of the domain.

It's not just domain expertise. Sustainbly great work is done by people with expertise _and_ ownership/accountability.

there is a big difference between seeing that pairs of input and output are correct, and knowing that the system is correct. there are invinitely many in and output pairs and only checking some while you vibe code your tool is never going to be a reliable method

This is not entirely wrong, but oddly describes the major flaw in its own argument: software engineering has tacit knowledge just like every other domain of expertise! And just as you can't become a doctor by just reading textbooks, or an architect by just looking at plans, you can't become a software engineer by just reading a bunch of code.

Successful software results from the intersection of expertise in two domains: the application domain, and software engineering.

Wouldn't the model have as much domain expertise as pretty much any human? I'm assuming the average project manager isn't reading the entire internet

This is a nice theory, but is it true in practice? (At scale; I’m sure at least 10% of domain experts will find they enjoy writing software too)

> 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.

I'm not sure that even that will remain as valuable or work as a viable moat.

We live in an era of corporate consolidation and absolutely, positively having to meet the revenue target. We also have invested literal trillions of dollars into the AI technologies that made the first skill the author mentions less valuable. However, the result just isn't there. Like the author says, there's a need for domain expertise.

However, you had a bunch of investors plow that trillions of dollars into the current AI boom with the understanding that they could, at the very least, take anyone and have them create what used to take an experienced software engineer, and in far less time and cost, and they invested thinking that the corporate oligopoly would deliver this. They'll now do anything to get that money back. Anything.

If that means telling the corporate oligopoly to tell customers that they need to expect less in the way of domain expertise from the models, well, they'll do that. And since there are relatively few players (the literal meaning of oligopoly) and they all have incestuous financial relationships with each other, they have incentive to hold that line as an entire industry. Development of better tools to create better domain expertise models would take even more money, which the investors don't want to provide, and, short of soaking the public investment markets, can't even find the cash for. Thus, the customer has to lower their expectations if the investors are to not lose their asses on the AI bet.

Something has to break.

Sure, producing code has become cheap. Yet again the taste matters and LLMs do not have taste - they will apply patterns that are unnecessary or not extendible, producing unmaintainable systems that nobody understands. Capturing domain knowledge was the crux of development process, but so was verifying, documenting, ensuring that multiple systems work together, maintaining uniformity. I don't know where the assumptions, done by developers, that they only need to produce code that just works or goes brrr fast comes from.

Domain expert can develop working code, but they will not be able to ensure above.

YOU CANNOT INTERFACE WITH HUMANITY WITHOUT HUMANS.

Much ink has and will continue to be spilled over this simple and obvious truth.

These kind of posts always miss the point that in a team of 10 not everyone needs to be a domain expert, and that now the same work can be delivered with a team of five or less.

Bad luck for the remaining ones.

These guys live in their heads, so when the world changes, they invent reasons why they’re still relevant.

What’s the truth, though? Are we still relevant?

My experience is that three years ago, when this kind of AI work first started becoming usable, I had to talk to the AI a lot. I had to review a lot. I had to change a lot.

These days, I talk to the AI less and fix less, while the amount and quality of the output we make together has gone up and the time required has gone down.

That suggests to me that AI is like a coworker coming up through the ranks. At first, it was like a capable, hard-working junior: useful, maybe even like a small team, but still making lots of mistakes and needing a lot of communication. Now it’s mostly on board. It almost always knows what I’m talking about, but not always. I have to fix less, but taste, architectural judgment, and domain knowledge still matter.

I’m aware of the value of my domain knowledge in browser instrumentation, and the nuances of CDP commands that may never have been documented anywhere. The commands are documented, but their quirks, behaviors, and the way you can combine them to create a working system are not. I can still suggest things to agents that help them.

I don’t know if that gap is closing. I do know that I’m learning less new domain knowledge because I don’t have to be in the code as much. But I also know my hard-won technical nuance and architectural lessons still matter. Maybe agents will eventually be able to hit iteration repeatedly until they figure all of that out. That seems more likely as they get more capable. But that’s still a hypothesis. I haven’t seen it directly yet, just a vague sense of where the capability is going.

With advances in memory and the models themselves, I don’t see why they don’t end up with something like that. And I agree with the top comments: the goalposts are always moving for the people trying to redefine their own relevance in a changing world.

The main pattern I’ve noticed in myself is that I spent years, really a decade, chasing down random bugs in the web platform, JavaScript frameworks, and browser instrumentation. I was very deep in that for a long time. That helped me build the products I built.

But over the last three years, I’ve started growing in a new direction: big-picture business, go-to-market, sales, and marketing. I guess that’s adaptation. You spend a decade building technical IP assets, and then you can build more of the same because you have the domain knowledge, while working with agents to massively increase the speed of production.

The situation feels analogous to having hired a small team of capable juniors three years ago who have now grown into A-players. If that had happened, we’d have the capability we’re operating at today. It’s just that we’re using AI and paying a lot less for it.

That’s my experience building a set of large, highly nuanced technical tools around the web platform.

AI changed the shape of my company. I migrated into a role where I’m not just doing the taxes every year or writing all the code myself, but thinking seriously about marketing, GTM strategy, and sales. For me personally, my evolution is in that direction now.

That doesn’t mean I’m not still growing in product sense or technical judgment, but it’s very different from the deep technical stuff I was in before. Now I’m freed up to focus on other parts of the business.

A fun benefit is that I get more time to rapidly build things that interest me: little side bets that may just be fun, or may actually become cool products.

The transition into sales and marketing is new to me, but I welcome it in 2026.

I think AI may be easier to deal with if you have your own small company than if you’re watching it affect your job inside a workplace. I’m not sure. I’ve heard people say good things about that too.

I’m not making an argument. I’m not trying to convince anyone. I’m just sharing my experience.

I have the opposite take. Because Claude is also a domain expert at most things, and you can unit test your way to making things "just work".

If you ask me and a logistics dispatcher the task of building logistics dispatching software (whatever that is), I will get there first.

Highly agree with much of the article. IMO, this is why many engineers who learned to code in the post-2010 'new hot framework every week' era but before LLM coding took hold are able to get much better results from AI assisted coding than those on either end of that sweet spot. The domain expertise in this case is constantly having to adapt to learning the latest flavor of the week DB or JS framework and adapt existing patterns and paradigms to new ones. Agentic coding itself is, in this case, one of those new paradigms.

Knowing the caveats and pitfalls of this through years of (often-painful) experience is what, at least for me, allows me to preempt a lot of the sloppy assumptions or omissions that even the frontier models make when working on systems at scale. This means I can leverage my domain expertise on these high-level areas while delegating the grunt work that is harder to screw up to the agents. I find this enables me to work faster while avoiding the slop making its way into critical engineering decisions.

Network effect is the moat not domain expertise. Domain expertise build on network effect (for instance the knowledge of the network) yes, but just simple domain expertise is only a training round way.

LLMs are the best domain experts, but the curse is that they know too much.

so it takes a domain expert to remove unnecessary things, similar to how stone carvers create by removing material, not adding

> The mechanical skill you sweated for, turning a clear idea into clean code, has gotten dramatically less valuable.

But that was never the hard part!

Come now.

After twenty plus years as a professional software developer I can name two hard problems, not more. One is related to the article, the other is not:

1. Getting that clear idea out of a stakeholder's brain. Traditionally this would be a specification but doesn't need to be that formal. Remember, remember the first panel of https://i.redd.it/i2aeyrivmjoz.jpg An LLM doesn't help here because it doesn't push back. It'll do whatever you tell it to do even if it's not what you really wanted. The software developer here operates very similarly as a translator and it always has been true a translator who speaks both sides well will be able to do the highest quality work. This is not at all new. It always has been the advice that if you know things like, say, logistics and software or any such pair then you'll be well off financially either because you can do this translation well or because you realize what's missing and can do a product for it.

2. The other problem, of course, is debugging. Since LLMs fundamentally work from a training set any debugging problem not blatantly obvious to a sr developer is hopeless for them.

This is why Google is pushing SEOs to get their clients to codify and publish their domain expertise: while it gives them a way to filter signal from noise/slop right now (supposedly helping to "improve search experiences"), it also simultaneously extracts that experience into a consumable form for later training.

They really do want to know the ins-and-outs of the HVAC service business, for example, because they hope their agents will be handling it in a few years.

Perhaps the good news is that even the best spreadsheet-slinging accountant in the west would still going to need some programming experience to do their verification.

I mean, they could ask an LLM "what does this code do, and will it always X when Y", but that's just nesting the verification problem inside another verification problem.

the idea that llm's can't help if you're missing domain knowledge is crazy.

There are two different type of domains to be aware of here;

1) Problem Domain Knowledge: This is what people generally mean when they say "domain expertise". This has always been and always will be the moat with/without AI. Simply because this is what understanding and modeling a problem is all about. It abstracts the key concepts/ideas and their relationships in the problem domain and builds a coherent model. This model embodies a set of functionalities with bounded scope and clear assumptions.

2) Solution Domain Knowledge: This is the implementation domain for the above problem. The model arrived at above gives the requirements which must be mapped to concepts/ideas and their relationships in the solution domain. When our implementation domain is a computer system, this takes the form of architecture, algorithms and data structures. The probability of a good solution here is directly proportional to how good a model we were able to construct in the problem domain above.

Albert Einstein;

"The mere formulation of a problem is far more essential than its solution, which may be merely a matter of mathematical or experimental skills."

"If I had an hour to solve a problem, I'd spend fifty-five minutes thinking about the problem and five minutes thinking about solutions."

> A logistics dispatcher, a clinical coder, an actuary. [...] 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.

With my sincere apologies to the author if I'm wrong, I'm pretty darn sure this was written by AI.

Guys, c'mon. I don't get it. It's one thing to have an AI write code for you, because code is ultimately functional. At least in the general case, the primary purpose isn't to express an idea.

Prose is different. Your writing represents what you think. You are your writing. Why would you outsource that?

I don't get it! Unless you're a (cheating) student, or you're writing marketing drivel.... what is the point? Just don't write the blog post. It's okay. Telling the robot to write the blog post doesn't accomplish anything. I don't care what a robot thinks!

I'm sorry, I'm just getting really tired of AI generated articles on Hacker News. Please, please don't outsource your own speech.

The standard take, including my own from last year, is that these tools amplify senior developers because senior developers have judgment.

My take is much less charitable. I think a lot of senior devs are lonely and enjoy talking to chatbots all day. Saying it amplifies their productivity is a justification.

A domain expert might know if a system produces correct results.

But they know nothing about the scaling, performance or maintenance of a system that will inevitably come up in production.

They also can't tell if the code created is maintainable, or unmaintainable sphagetti code.

What happens if there is a race condition, or a memory leak?

Just say you do not know.

The problem with these kinds of discussions is that they act like experienced software engineers themselves don't bring domain expertise to software products.

So AI can easily replace the domain knowledge of software engineers but not of evey other profession?

Coding is not engineering but I'm glad that we will finally be able to prove that definitively thanks to AI. It's going to be a bumpy ride.

Any software engineer who has built software to solve domain problems in multiple industries knows that the engineering domain knowledge and systems thinking approach is far more difficult to attain than industry-specific domain knowledge... This is why there are software consulting firms which can work across multiple domains. Understanding the problem domain is not that difficult.

blablabla AI usage has to be regulated. end of story

What some people here are missing, is that domain experts or hobbyists are mostly vibe coding tools for themselves -- not as a SAAS product. They tend to work good enough to do the thing they want it to do. It runs locally or on some VPS, and is held together by string and duct tape.

The work product probably offends real software engineers in the way that a normal home cooked meal would offend a Michelin star chef. Yet, before last summer, these people never contemplated the ability to cook their own meals before. The fact that they can do this now is a very big deal.

In the past, an engineer who deeply understood the internals of a DB and how memory management worked in Java would be indispensable.

Now these skills don't matter as much because LLM's/Cloud/Java abstract out these problems.

What makes domain expertise a different category itself that lends it to be not automated out by LLM? Example: Why can't I go to into an agri-startup and become better than anyone else by querying an LLM even when I have no domain expertise? Much the same way I beat the dev who was good at DB internals?

I disagree because we're buying up companies and training models, creating skills and agentic workflows on individual domain expert's 30 years of notes and prior projects

The only moat is that there is so much more work for domain experts since they and many of the bureaucratic processes in between aren't the bottleneck anymore

I think it's important to be clear on what's really happening. Companies were accomplishing 5% of their annual plans, and now they're taking a realistic swing at all 100% to likely reach 20-25%. It's a crazy amount of work, for the same specialists and more human workers.