Domain expertise has always been the real moat

I find the article interesting and (largely) correct in its analysis of how an individual can use AI. What I think is missing is that organizations (like enterprises, research labs, etc), have multiple people and multiple experts in different fields. So you can have BOTH the AI engineer and the domain expert in the field. Not only can you have this but this is actually common in most large companies. The difficulty lies in making the collaboration work and the information flow correctly so that the domain expertise of the expert can flow into the software product built by the engineer.

A mental model I use for this is that we have users, builders and experts when creating AI products. For most individual use cases a person is the user, builder and expert: I make a prompt about how to write code in a way that I like that I will later use. Coding agents moved into the direction of builders that were also experts in the field iterating on a product for third-party users. The next frontier will be finding the right patters for teams to capture expert knowledge handle the collaboration between engineer/builders and experts. Just having PMs handle that interaction will be a super bottleneck.

My cofounder and I are actually working on a project in that direction (https://www.getvalmar.com) --> we'd love any input on how engineers prefer performing feedback loops and getting input from subject matter experts :)

While I agree that domain expertise has always been a moat, I believe the author is missing something critical: there is a big difference between being able to verify the output of a system is correct, and being able to tell a system how to generate the correct output to begin with.

Personal example: I had a software engineering colleague who was the best coder of financial management systems I've ever encountered. He gained these skills through years of in-the-trenches development. One of the things he told me, and that I also observed, was that the vast majority of financial experts (basically, the people in the accounting department of companies) had an extremely difficult time just telling him what the rules of any particular transaction should be. But what they could do was tell him whether the handling of any particular transaction was right or wrong. So often times he would sit down with these accounting folks and go through lots of example transactions he came up with, and from there he essentially built up the requirements spec.

In my experience, that is the primary difference between people I've known who are good software engineers and those who aren't: people who can specify the detailed rules of any system, vs. folks who take a "well, I know it when I see it" approach.

I have a strong suspicion that folks who have a high degree of domain expertise in a particular area will fail as software builders even in an agentic world because they will struggle to elucidate clearly the rules in their head that they've learned over years. As an analogy, it's kind of like asking a native speaker for the grammar rules of their language. Often times they can't, but they'll just say "well, that sounds wrong." They may be "domain experts" in their language, but they'd have a hell of a time prompting an AI system on how to grade a test for grammar correctness.

It's funny how out of touch AI is with seeing the big picture of problems.

Here's an example I encountered last week:

Someone in my neighborhood is a 75 year old chemical engineer who likes computers and got into Linux a few months ago. I see him from time to time when walking around, he's a nice guy and overall has a scientist's mindset. He doesn't make a lot of assumptions and tries to think things through but sometimes he has big blind spots in unfamiliar fields.

I helped him install Linux and also hook up an SSD to one of his older machines and now it flies.

On his own he had an old sound card that he wanted to use on that machine. He asked me if the card is compatible. I told him it almost certainly is because the Linux kernel has drivers for a ton of devices. His motherboard's built-in sound card was fine but he likes tinkering with audio in general.

He managed to physically install the card correctly but called me and said there's no sound playing. Then he says he spent 12 hours troubleshooting the issue, using ChatGPT and Googling for assistance.

Over the phone he told me he tried many different things. Installing, tweaking and configuration ALSA, PulseAudio and PipeWire related tools and tweaking everything you can imagine. Nothing worked, no matter what happened, it never played sound through his speakers.

He asked me if I could come over to help so I did.

In 30 seconds I solved the problem.

I went to his sound settings in his desktop environment and saw that his sound card was being picked up. I looked at the back of his machine and noticed this card had 2 black ports with the bigger style jack for headphones. There was no usual green port which is usually used for output. I shined a flashlight to look closer. One of the black ports was labeled headphones and the other was unlabeled. His was connected to the unlabeled one. I swapped it to the other port and everything worked right away.

All of that to say, as a software engineer I have second hand embarrassment that a trillion dollars invested into AI didn't think to respond with "did you double check to see which port you connected the speakers to?". I asked him if AI ever suggested that and he said no, it immediately went into polluting his system with a bunch of unnecessary tools and chasing incorrect rabbit hole after rabbit hole. AI understands nothing.

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.

I find this take off. In general, LLMs collapse a bit of all knowledge work, including many domain experts. I work with domain experts often and it’s usually the most difficult part of the process. Now, I can ask an LLM the questions I need to design the system and have an agentic system help me build parts. And it works, quite well.

The places it falls flat is domain expertise that isn’t well documented, like specific business processes. Knowing something will fail because X in dept A won’t like it and will undermine it (politics) or some silly process I didn’t know about forbids it.

So it’s not domain expertise, it’s idiosyncratic expertise that shines these days. Knowing where things deviate from a domain or the standard and being able to adapt around that. Years ago there’s a group I worked with and I was at the mercy of about 3 people I could ask questions to in order to make sure I was doing things correctly because digging into that domain was time prohibitive. Now, I can sit down one evening and dig fairly deep into a domain. I can understand common practice, approach, acronyms, nomenclature, so on. I can find other popular competing systems. I can rapidly figure out what I need.

The same is true for software, agents don’t collapse software they help people build fairly usable systems but they don’t find the expertise a senior level engineer has where designs or implementations may fail in practice. The idiosyncrasies of software and software systems, especially in your very specific set of constraints you need to operate in that may deviate from the rest of the world.

Things the domain expert on the author's example cant tell (from the top of my head):

- is the app is properly deployed - how will the release cycle be - is it secure? - can we run two instances of it without messing up the orders/routes/whatever? - will we spend 5k/month in vercel if people start using it - how will we notice service degradation - if we change the data do we have downtime? how do we schedule that downtime window. - where is the code stored? can the team access it? - how are new contributors onboarded? - does the app use credentials and where to store them? - does the app manipulate or store PII? - if the user refreshes the app does it generate a duplicate order/route/whatever? - if there's an upstream service are we making sure our timeouts are properly configured? - if there's an upstream service are we making sure our connection pool is properly configured? - do we have a max connection lifetime so that middleware like AWS NAT or ALB don't leave us with dead connections in our pool?

I think that makes the point clearly. Also it may explain why software developer jobs are currently on the rise despite SWE-Bench-Pro-Ultra-Magic has been maxxed for months now.

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

This has always been true since the dawn of programming.

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.

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

Okay, but I've always gravitated towards working on tools and libraries and back-end stuff; as much as possible, the domain for me is software.

Whenever I read articles like this one that appear to be very generic and give advice about dealing with AI, I remind myself that he software industry is like the construction industry.

It will never be organized, never fully optimized, and it will always be custom — because it has to cater to the reality of wildly different tastes, contexts, and localities. There may be some good tools, raw materials that show up once in a while.

> So the most valuable person in this new world is the one who has both skills

This has always been the most valuable person. A skilled software developer who is also deeply experienced in their target domain is untouchable. They can always move the ball forward at some rate, assuming they're making any attempt at all.

It takes a really long time to absorb some domains. The most painful one I've experienced is the banking industry. It took me a solid decade in the trenches before I felt comfortable running a status call with a bank's operations staff without a babysitter.

I like to think of this as a sort of cube of capability. The X axis is technical expertise, the Y axis is domain expertise and the Z is physics (ai/tools/computers). The volume of this space is what we are interested in. Scaling up to a wild amount of AI capability with the best developers on earth (infinite x-z plane) is still going to perform like shit (zero volume) if you have no practical domain expertise available.

Specificity, availability and recency are perhaps the most important parts of domain expertise. None of these tend to be in ample supply with frontier language models. You can get a general sense of how a bank operates from chatgpt, but the FDIC would take over your bank in the middle of the first night of operations because you didn't learn the secret handshake (how to interact with your customers, competitors, regulators, etc).

As a doctor who learned how to program, I started by writing useless Chrome extensions. One thing I learned early was that programmers generally do not like learning the nuances of medicine, and many are quite open about how little they want to learn it. I have tried convincing my fellow residents to learn a simple language like Lua or even just Python, but the resistance is even greater, despite the fact that they constantly express how they have always wanted to learn programming like I did.

I even went as far as setting up their IDEs, configuring their environments, and encouraging them to just vibe-code. It seems that the mental friction involved in switching domains is too high for most people to justify the reward. Perhaps the reward itself is not compelling enough, or perhaps this is simply the limit of adult motivation.

I started programming with Python around the time GPT-3 arrived, when Cursor had generous free tiers and excellent starter plans. A few Raspberry Pis, laptops, desktops, and countless hours of tinkering later, I discovered how much I enjoyed solving problems with software. There is so much to learn from the programming world: the concept of open-source software, the idea that people from anywhere in the world can collaborate on the same codebase, and the fact that many do so with little or no expectation of reward.

As this post points out, in the project I am currently working on—a comprehensive Clinical Decision Support System—it feels almost second nature to translate the rules, hidden rules, social dynamics of hospitals, and the common mistakes that we and our juniors make every day into software. Taking those observations and turning them into systems that work is surprisingly intuitive.

Perhaps the most valuable thing I gained from medical school, combined with my own personality, is the desire to keep learning. I naturally gravitated toward systems thinking, and the path forward seems clear to me: become a true expert in whichever specialties I ultimately practice, while simultaneously becoming highly skilled at systems thinking.

As for systems thinking itself, I find it useful to create rules not only for the codebase but also for the testing harnesses and development processes around it. The goal is to build systems that can enforce quality automatically as the codebase grows, ensuring that standards scale without requiring constant manual oversight.

'course, software development itself is a 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?

Very well articulated for sure. But, I do think the word _'expert'_ always tends to do a lot of heavy lifting.

What looks like _'expertise'_ may actually be pattern recognition built through repeated practice. I do believe that is what a model can already do faster than humans.

So, to me, we've got to be cautious here in that what this post implies is humanity must strive to be in the 99.99th percentile of domain knowledge to 'beat' the model. This is perhaps problematic.

I do think focusing on judgement is the only tact discourse here, and I do think that is fine. Once we have invariance well-defined and covered in suites of various types of testing strategies, and are focused on regulation, wouldn't that be a more doable objective?

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

The company I work for is currently trying to accelerate internal AI adoption, and recently laid off people to help force it. As I've written here before, this merely pools accountability (not removing it) and things will break in unexpected ways as people are not domain experts in these new areas added to their jobs.

I wonder if we will see a large reversal in a few years, or if AI will somehow be able to fix this too

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.

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.

A non technical domain expert might usually lack thought clarity. They might know what is right once they see it but they seldom know how to reach there, even with AI. They will write themselves into slop in 3 days.

The real moat I believe is the ability to hold the the problem in the head, isolate it and mentally design a way to structurally solve it iteratively.

Very few people have it. Much less common with domain experts.

I would rather bet on educating domain to the engineer than teaching a domain expert to architect software.

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.

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.

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.

But there's nothing stopping AI from developing domain expertise. If you fine tune a model based on the records of all previous work (effectively "shadowing" the existing workers) then it can easily learn this domain knowledge. The only difference is that AI companies have gone after programming domain knowledge first. Others will come later.

Kernel developer is not the job same as a game developer or an ERP integrator...

But Generalizations aside I think people greatly under estimate how rare is the ability to reduce complex subjects into concrete steps that someone else can follow, human or machine.

Go ask your grandma for a recipe you will find that it never turns out the same, giving her Claude Code is not going to change that.

Agentic coding favors senior generalists with a broad experience in many things rather than narrow experience in one or two things. I no longer think of myself as a backed engineer. That's what I was. I can do it all now. I've been building products and doing CTO jobs for a few decades now. I'm not a specialist in all layers of the software but I know enough about all layers of the stack to be able to do things with an agentic coding tool.

It helps if you can think at the system level and understand how everything is fitting together, why certain things are better than others, etc. Domain knowledge in multiple domains helps for that. That's what it means to be a generalist. And that includes having the prior experience with having built different types of software. Understanding architectural patterns. Being aware of pros/cons of different solutions. Etc. You don't have to be a specialist in any of this. But you do need to understand things at a high level.

Being a generalist equips you to enter new domains quickly. I've done lots of consulting on search projects in the past two decades. Every project is different. But the technology stays the same. I've built search engines for dating websites, maps, addresses, material scientists, art work, etc. Every project, most of the work is figuring out what the product is about. What good search looks like in that domain. And what they are doing that is sub-optimal that needs fixing. You can't work on search ranking unless you understand that. And you only have a few days to figure it out.

I disagree.

Having worked across many disjunctive domains the value of "expert in domain" is greatly exaggerated. It's not like search engine doesn't exist nor that it cannot be easily absorbed. Quite often becoming expert is as simple as careful reading API documentation for existing, same domain system.

The piece is heavily one sided and don't recognize the problem of low reliability software: e.g. imagine a software designed in a way that it keeps critical piece of data as a global static variable. This will always work for a single user but will leak with two. Make it semi-critical and e.g. a part of profile loading.

Just as non-expert cannot verify if result is correct from a domain perspective, expert in domain cannot verify the output based on the basic principles (data security, safety, isolation, persistence, etc.) or even know that monetary values shouldn't be kept in floats.

Nothing like article claim had changed outside of a false promise of being productive.

Software engineers without domain expertise can fake it with unreliable results and experts without swe skills can fake it with unreliable results.

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.

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.

From my experience what domain experts are often missing - and at least currently this is also an area where LLMs fail - is the ability to model data and interfaces in a sustainable way and factor in team and domain boundaries.

This is a failure mode that senior engineers have seen a few times throughout their career: They know how certain choices will play out over time... and the kind of problems and roadblocks these choices might cause.

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

Nah, we’ve always produced software without much understanding of the domain. It’s the premise behind lean: we don’t know much, so get something in front of customers and refine it.

So I don’t believe there’s been a strong decoupling here akin to the degree that understanding the code and writing the code has been.

I'm such a generalist. During all my career, from support to decades of C-level, I was equally challenged by domain and IT people for not being deep in everything. But whenever they couldn't come up with a compromise, I was the person who always offered it. Doing purely consulting work now, mostly implementation. And this "little bit of everything" can be strongly multiplied by AI tools, since I already know what exactly I want to achieve, I just need speed and a cross-check.

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.

The article says that domain expertise is more valuable now because agents can code well, but not understand the domain well.

I believe there are domains that are very well encoded. The model very often can know that a shift can't be longer than 11h and if you ask an agent for scheduling software it can surprise the developer by encoding that rule.

Both domain knowledge and coding skills became cheaper.

It might depend on the domain. Highly regulated domains like finance have entire books around how they should work.

However, I agree that verification skills became more important in both areas. A domain expert needs to catch 12h work shifts and experienced programmer needs to catch when the LLM accidentally put a route in a section that doesn't require authentication.

Both require some kind of harness and automatic verifications methods.

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.

There is a separate aspect of having domain expertise in that it open paths for a software engineer to make a lateral switch to a Business Analyst role. That in turn opens paths to management track on the business side as one gains deeper knowledge. If you have business expertise AND direct SDLC experience, that is a different kind of value you bring to the table.

Obviously it is a very different kind of track, take a long time to develop and means you are no longer programming but then with LLMs, hand rolled programming has been massively reduced anyway.

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.

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

Although the idea of the main promise of the article is correct - that teaching domain expert to use AI seems to be faster than teaching senior developer the domain, there is and will be a learning curve to learn AI. It still sounds like this article is trying to sell vibe coding in a fancy wording. However, domain expert working in team with senior developer that utilizes AI will be the ultimate combo.

I think this misses something.

AI is going to struggle at building a consistent internal model of the domain into the software unless you’re able to give a structured explanation of the domain.

If you’re just giving it a set of inputs and expected outputs, it’s not going to generalise well and fail at out of sample input, unless the AI already understands the domain from its training set.

Being able to give a structured explanation of a domain (and being able to judge if the internal model of the software makes sense) is not the same as having experience in a domain.

Lots of ppl with domain experience can tell a right output from a false one, but can’t tell you why.

While agents are able to take over a large part of code writing, software development skills themselves are still a moat. How to design systems for the future, for team collaboration, for cost efficiency, hosting strategies, security… these are decisions that will still have to be made by a software expert.

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.

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

Sure, I think the article is basically correct, as things stand right now ... but the problem is that that wipes out software development as a career: software becomes just a tool that domain experts can spin up to make their jobs easier.

I thought real moat of software is requiring virtually no extensive knowledge/experience of both system and domain. Copying taste and network effect is significantly difficult. The fact is venture backed startups with plenty of talents and resources has been rarely making their positions in the market before vibe coding. That's why people at 20s can compete with experts in various areas. Current backlash is due to creation of guys with just x years experiences in the industry we often see in other mature enterprises.

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

While the article is interesting, it makes assumptions that are not explicitly stated. And the one strong assumption that makes no sense to me is that they discuss team size = 1. Sure, a domain expert now can use an agent. But he might as well work with a development team, or a developer that uses an agent. That's pretty standard I would say.

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.

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