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.
Domain expertise has always been the real moat
431–440 of 592 posts
Re: Domain expertise has always been the real moat
#432While 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. H…
I think the answer is in the second sentence of the article. The most valuable person in this new world (using the author's own phrasing from the penultimate paragraph) is the one who is good at "building a working model of the domain in [their] head".
Depending on the domain, this may either be the domain expert themselves, or someone else trained in formal logic, data structures and organizing information into coherent hierarchies. If this is neither the domain expert nor the programmer, then it must be someone in between. In the old world, this role was called "business analyst".
Re: Domain expertise has always been the real moat
#433While 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. H…
Anybody who has ever done programming professionally in the small scale knows this. Refining the requirements is the job. In fact, I've never known an industry so keen on levelling its own moats as the software industry. We regularly invent things like 4GL, graphical programming and frameworks and engines such as Unity just to enable more people to do programming. People will happily teach programming for free in out…
the 1 dimensional thinking that's perverse in the industry will be catastrophic.
we don't like doing the hard things e.g training juniors so they can be skilled seniors via good apprenticeship programs i.e on the job. now we r delegating to stochastic parrots.
in terms of systems thinking which is one skill you need to be a domain expertise - very few people are ever curious & are not willing or able to ask critical questions. hence the groupthink that's prevalent in the industry.
no wonder the quality of software never goes up - while the building blocks have gone up in quality. an analogy is like having super strong bricks but making brittle structures
Re: Domain expertise has always been the real moat
#434Earlier quoted context omitted.
It only takes two or three unreviewed prompts like "the page loads slow, plz fix" for you to end up with a tangled mess that even the agents can't productively work with. Take a look at the Reddit forums for vibe-coders - now that a bunch of them have been hacking on things for 3+ months there's a growing awareness there that you hit a wall. Here's the first post I found from just searching "reddit vibe coding wall",…
Offtopic, but how do you monitor all of this stuff, Simon? Do you have a routine where you recheck Reddit, Twitter, HN, other resources, or do you use LLMs to find material for you?
I spend way too much time on Hacker News, Bluesky and Twitter and occasionally check in on Reddit (I'm more of a lurker than a poster there.)
I don't have any automated LLM scanners, but I do frequently have ChatGPT run searches for me with questions like "Find the most credible accounts of the recent Oracle layoffs, how they went, rationale, problems caused".
Re: Domain expertise has always been the real moat
#435It 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…
“Teaching and engineer to understand the minutia of fund accounting well enough to build software for these firms is tough.” Sounds like you need a senior familiar with finance/accounting and a family to feed. Email me!
Hah very clever :)
Re: Domain expertise has always been the real moat
#436Earlier quoted context omitted.
> If you're worried about non-technical vibe coders taking your job, the correct response is to be much better at building software than those vibe coders. That means you need more skill, more ambition, and more experience. It's hard! This is a false fear. The real risk isn't that some 19 year-old vibe coder is going to replace you, it's that there's simply less need for more experienced engineers. The market is shri…
> The real risk isn't that some 19 year-old vibe coder is going to replace you, it's that there's simply less need for more experienced engineers. The market is shrinking. That last sentence is verifiably false if you look at SWE job postings and their recovery since 2022. It’s also a poor take in general, buying very much into the narrative propagated primarily by OpenAI and, especially, Anthropic, who nonetheless c…
> That last sentence is verifiably false if you look at SWE job postings and their recovery since 2022.
Source?
https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE
And it's probably worse than it looks because phantom job postings are a real thing.
> ...who nonetheless continue to hire large numbers of SWEs while paying double the market rate.
Tech companies have laid off over 200,000 people since the beginning of 2025. Even putting aside the fact that (from what I understand) over half of Anthropic and OpenAI's employees are in non-engineering roles, if you assumed every employee was an engineer, Anthropic and OpenAI could triple their staffing levels and it still wouldn't even fill a quarter of the void.
Re: Domain expertise has always been the real moat
#437While 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. H…
WRT the native grammar, consider adjective order. Few native english speakers (me included) can off the cuff name the proper order, but everyone knows the "right" order. https://dictionary.cambridge.org/us/grammar/british-grammar/...
Great example
Re: Domain expertise has always been the real moat
#438[flagged]
Re: Domain expertise has always been the real moat
#439While 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. H…
Yes. The author stumbled on the p vs np problem but with humans. Verification is easy. Solving is the millennium prize question.
Agreed. But there is a new dynamic coming to place. Who can execute faster now that we have AIs? I think the combination of (Good SWE using AIs) collaborating with (Domain Expert using AIs) is the winning team. Things are accelerating on all fronts, the frontier may be jagged but AIs is making progress on all capabilites.
Re: Domain expertise has always been the real moat
#440While 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. H…
> 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. Right, so the spec is derived from examples, an interactive process that doesn’t require a programmer.
The programmer skill is how to abstract the specs from all the examples. And then to formalize it. Actual coding is merely translation. And only beginners tend to focus on that.