Live data from Hacker News

Domain expertise has always been the real moat

brethorsting.com

461–470 of 592 posts

Re: Domain expertise has always been the real moat

#461
post #340

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

This is the exasperating part about learning to speak Spanish using a textbook; you must guess the grammar rules because the textbook won't tell you. So, you use the English rule and hope and pray that it is the same in Spanish, and you'll be right the majority of the time but often wrong. Spanish textbooks written 100 years ago tell you the grammar rules and are more useful than recent textbooks.

While interesting, I rarely found knowing grammar rules beyond some very basic ones to help all that much for learning to speak a language, compared to language exposure and speaking practice.

Re: Domain expertise has always been the real moat

#462

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

I think this neatly captures the gap in the article; it’s thinking of domain expertise as static, rather than something that needs to be built/extracted.

It also goes the other way; A a good engineer can build experiments and discover the domain even without an oracle on the team; reading protocols or manuals or specs, for example. In other words, learn to be a domain expert themselves.

Personally I find the most efficient way to learn a concept to be building it; you are immediately faced with your blind spots. AI for sure helps improve cycle time on these discoveries if you use it that way; time writing boilerplate goes to ~zero and you can spend your time figuring out how to answer the real questions.

I do think that we as a profession need to learn new architectural and craftsmanship patterns to make it easier to learn from our code; concepts like Literate Programming which were too fussy for fast-moving teams may end up accelerating in the agentic world; I need to read a lot more code than I write now. But also things like Acceptance Test Driven Design; not new concepts, just newly increased in value.

Re: Domain expertise has always been the real moat

#463

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

Yes. The author stumbled on the p vs np problem but with humans. Verification is easy. Solving is the millennium prize question.

I agree that it has some resemblance, but the striking thing about NP-complete problems is that an efficient solution to any of them is an efficient solution to all of them, which makes it worth trying exceptionally hard to find one.

It could be that whatever lackluster expertise you can squeeze out of an LLM is good enough to discourage investment in the real thing since unlike NP-complete problems, expertise isn't generalizable.

Re: Domain expertise has always been the real moat

#464

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

Interpolating between the examples still requires understanding of the domain for the interpolation to be a sensible one. And it’s an iterative feedback process: thinking about possible interpolations leads you to cases that need clarifications from the domain experts. The domain experts won’t come up with all relevant examples by themselves, and they typically aren’t as good at thinking about interpolations like a developer who is trained to always consider all possible cases; they don’t think in terms of models the way a developer does.

Re: Domain expertise has always been the real moat

#465

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

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

This combination of requirements is the business in most domains. Software or otherwise. Codefying different rules and executing them.

Re: Domain expertise has always been the real moat

#466
post #91

Earlier quoted context omitted.

Vibe coded a simple game (10,000 tokens of source code) with two popular coding agents. (Once each, to compare.) One spent 200,000 tokens, to produce 10,000. The other spent 1.9 million. It could have been a single LLM call (10k tokens). lmao (I note that the latter was designed by a company whose main source of revenue is token spend...)

What about the other 998 million tokens?

Ya got me there. Maybe he's running OpenClaw?

Re: Domain expertise has always been the real moat

#467

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

> 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. This is the part I disagree with. In a non-agentic world, the expert and the programmer are two different people. If the expert finds a bug in the software,…

> realizes that the fix is incorrect because of sloppy thinking

If the domain expert doesn’t understand the generated code, they can only discover incorrect logic by specific examples (specific inputs), which is usually impossible to do exhaustively. The programmer, on the other hand, can see incorrect logic directly, generalized over all possible inputs and states. It’s the difference between testing and proving correctness.

Re: Domain expertise has always been the real moat

#468

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

I have found this with (mechanical) engineers. They know what they want to see but don’t understand the underlying details which are more mathematical than the average engineer is able to work with. So the people working on engineering software are often physicists or applied mathematicians.

Re: Domain expertise has always been the real moat

#469

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

I guess the flip side to that is the iterative conversation to develop these specifications is exactly what AI chatbots are good at. It's also the main reason why very structured AI agent orchestration for software engineering modelled on rigid processes fails to really provide much value.

I suspect that the reason AI chatbots are not very good at developing such specifications is that they don’t build a domain model in their “head” — the only models they have are already hardcoded in their weights. A human learning a domain, on the other hand, forms new neural connections representing the model of the domain that they build in their head.

Re: Domain expertise has always been the real moat

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

Post reply on HN