Domain expertise has always been the real moat

How much pontificating needs to be done before people acknowledge nobody has any idea what to do with AI on an individual level?

First being good developer and learning how to use AI was sufficient, next it was being able to design architecture, then it was “taste” that made all the difference and now being an expert in the domain is the only thing that matters really.

Until AI is basically in a stable, predictable, state of improvement or stagnation, these takes will continue to be pointless and most likely completely wrong.

I recently reviewed an app built mostly with vibe coding. The owner said it was almost ready to launch and just needed a quick check.

After looking through it, the database design was a mess. Some features worked, some didn’t. I explained the missing pieces and why things were breaking. Like OP said, he’s the domain expert.

I used billions of tokens last month alone. The tools are getting better fast. But giving AI to a domain expert doesn’t mean you no longer need software engineers.

A domain expert can use AI to build software. And a software engineer can use AI to learn about the domain. Both bring different expertise to the table.

Such a good example of this I encountered recently:

I was on a fishing trip. I asked the charter if he’d want to check out a free app I work on (https://oceanconnect.ca) in case it might be useful for his work.

I don’t know how people on the ocean use ocean data. I don’t really know what they want to know, or why. I wasn’t totally prepared for the incredible onslaught of questions and information pertaining to how people use the data or what we can do with the data, and it was so cool and exciting to get that perspective.

It was a good reminder that models are not the same as the systems they abstract, and knowledge to develop them has almost nothing to do with using them. This guy was a wealth of knowledge about how they use weather data on the water. In a sense, he knows more about the data than I do (even if he doesn’t realize it, or doesn’t understand it in its digital representation), and would be far better equipped to make a useful application for people like him if he could program.

I found myself thinking people like him could actually do amazing stuff with LLMs if they sat down and got their ideas out on a screen. I’d really like to interview people on the water daily some day to refine the product if we ever have the funding. That domain knowledge is highly, highly specialized and people know things you’d never guess after living in a complex domain for decades.

The software generalist described in this post has domain expertise as well. In software.

If you’re a great generalist software engineer today, you aren’t jumping to some random domain to escape AI. Software is your domain. You’re sticking with it as it expands and transforms.

It was never about the code.

After spending the last 5 years building software for venture capital and private equity, this blog post really resonates with me. Writing code is by and far the _easiest_ part of my job; understanding the financial engineering and nuance behind what my company's customers need from us the tough part.

We always joke that we'd rather hire a senior fund accountants and teach them to program if we could, only problem is there just aren't any of these folks around. Teaching an engineer to understand the minutia of fund accounting well enough to build software for these firms is tough.

Maximal Point of View that is harder and harder to disagree with: Sharing your domain expertise is asking to get yourself automated away. Already, if any company hasn't begun trying to maximally collect data on every aspect of their employee's work, they are asking to get wiped by future automated competition from companies that learned everything they could from their employees, then replaced them. Open Science? Open Source Code? Shared your art online? We were all suckers, and might be the first to go.

I work as an analyst, and our group has roughly 20% analysts with strong technical (software engineering) skills, and the rest are more traditional analysts / domain experts.

In the past year we've seen these non-technical analysts become more productive when it comes to developing internal tools, by leveraging AI models for the dev part.

Prior to this, pretty much everything was developed in Tableau. It was the most accessible way for non-devs to build working tools.

Just the other day one analyst in our group presented a tool he had been working on, which was basically a port of a tableau report, made into a more flexible app.

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.

My friend is an electrical engineer and just passed a FIDE chess rating of 2000. Has played for 30 years, started the chess club in high school. Knows a little programming from the stuff he had to do with microcontrollers in college.

I'm an infra/admin jack of all trades with a comp sci degree and have been a hobby programmer for 30 years. I have a Lichess rating of 1000 on a good day.

We tried doing a chess bot competition (open book, use AI to program it, pull in opening books, end game tables, whatever, free for all) and I absolutely stomped him, but I've only beat him in real life over the board twice in 20 years.

He will beat 99% of random players in real life, and I will beat maybe 20%.

I'm not sure what I'm trying to say, but it seems to me that maybe domain knowledge isn't everything anymore? Or the domain itself has shifted?

In my own experience this is 180 degrees from reality. As a generalist, feeling out the depths of a single domain (something I've been forced to do at least 50 times in my career, to the point that I'm probably a global expert in at least 2-3 things I don't actually care about, but are poorly documented and not especially lucrative on their own) is something that's basically a bunch of Google searches, reading source code, and writing/running tests manually, none of which I really care about short of getting to "the right solution."

Meanwhile, as a generalist who has a basic understanding of general things, everything from how to design efficient network protocols, to how cache lines affect the performance of sorting algorithms, without being a real expert in any of those things, I act as a constant course correction for AI agents doing work on my behalf, in a way that LLM context windows simply cannot replicate.

To give a concrete example, I recently used agents to build a specialized sync protocol that broadly resembles Dropbox. It's nowhere near as efficient in terms of how blocks are synced (because it entirely happens on a LAN and the cost difference is minimal), but I constantly had to make objectively more valuable course corrections on how the sync actually traversed the participating nodes. If I'd just let the LLM drive, it would have come up with a reasonably efficient algorithm (better than I probably would have done on my first try in the same timeframe) that would have had an obvious (to me) single bottleneck.

Not just domain expertise. The hard part has always been marketing, distribution, risk appetite, motivation, grit, and patience.

There are plenty of things which are "trivial" to produce with no moat and yet are still million dollar businesses. Kebab stands. Water bottles. Barber shops. Movers.

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

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.

Good post! Also, in my opinion, domain expertise is actually more interesting than pure coding ability. Coding, for me, has always been a means to an end. I'm equally happy with a spreadsheet if it solves my problem, and in fact I hate most apps.

This is such a sane take. It is THE reality we have been always ignoring.

Writing software has never been difficult. It is the domain that has been the issue. Always.

Nice idea, but engineers are engineers for a reason.

I’d suggest that the domain expert partner with a GenAI senior engineer to build together. In fact I believe this is the new dev team model. Domain Expert + Senior Engineer + QA. Not sure we still need a project manager anymore and we certainly don’t need scrum masters.

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.

> The engineer’s advantage, the ability to translate a domain model into working code, is now cheap.

I say this as someone who uses AI a lot. Its still a far cry from cheap, especially with that pesky “working” word in there.

This sort of thing has Microsoft Access vibes about it. All AI is enabling is domain experts to spin up their own software systems with no understanding of how the systems should be put together.

Sure it lowers the bar, and some people will design decent things, but mostly these things will become mission critical and broken at the same time.

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

revelations never stop coming do they

I feel like this aspect has been discussed on HN many times. The thing that resonates with me strongly is that there’s rarely a clear or fixed set of requirements to begin with - at least from my work experiences. Then, domain expertise helps with being able to proactively call out when they are missing and support in defining them. Still I am of the view that with enough context AI could also replace the best engineers with the best domain expertise.

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

> inputs and outputs

If the inputs and outputs are only and exactly those of the domain, sure. But software is more than that. And your logistics operator (or my actual work example: our extremely talented designers with deep understanding of our product) can validate parts of the agents output, but the rest of it they can’t and it makes a mess.

I’m sure this will change, but it hasn’t yet.

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

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

Agree on this one. As a Civil engineer, I can smell which software ( or some part of) was developed by computer engineers without much understating of the "domain". The worst offenders are software needing multi-domain expertise in the first place. Crude Ex. Payroll (Finance) and Leaves (HR) are 2 seperate domain, and they need to account for each other.

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

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.

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.

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)

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

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.

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.

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

Like so many posts that end up on HN, I just want to say "you've got a decent idea, but tone it the fuck down."

It's absolutely true that domain knowledge is incredibly useful, and developers aren't always great at gaining it. But there's also something about decomposing systems into their component parts, understanding algorithms, and knowing how code works that's also incredibly useful, even with agents in the picture. A really good developer needs both of those skills.

Take that example, of the generated shift that's illegal (by coincidence, I do freight optimization and work with examples like that in my day job). A domain expert will know the specific example is illegal. So they'll tell the agent to fix it. The agent will probably fix it for that case.

How does the domain expert then know that the agent has produced a thorough fix, as opposed to just that scenario? Not because the agent says so. So it is because they test it manually (but which cases)? Or because they review the strategy of the agent's tests, and know how the algorithms work, and know the edge cases that the tests need to cover? But they can't do that, by stipulation, because they're not experienced with code, they're just using the agent.

So yes, if the agent gets to the point where it can design robust software that avoids edge cases in a complex domain, doing complex operations and is thoroughly tested, and so on, then half of my skills are going to be irrelevant.

Out of the box, agents don't do that today. Perhaps they'll get to that point, but until then, your knowledge of where to put a semicolon has become less useful, but your ability to specify and test processes precisely has not.

But yeah, knowing your domain well is a damn good idea.

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.

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

YOU CANNOT INTERFACE WITH HUMANITY WITHOUT HUMANS.

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

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

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.

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.

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 idea that llm's can't help if you're missing domain knowledge is crazy.

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.

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.

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

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.