Domain expertise has always been the real moat

whatever1

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.

rayiner

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

dominicq

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.

threethirtytwo

“The hard part of writing software has never been the writing.” I’m tired of these endless articles on HN about software engineers trying to reinvent their identity while trying not to lose touch with reality. One way of dealing with LLMs is to deny the skill level of LLMs. Claim they can’t code as well as you. This excuse works to a certain extent but it also fails because not only are their multitudes of cases where the LLM IS intrinsically worse than me… but there are multitudes of cases where it is better. So this excuse cannot be universally true. The other way is to claim software engineering was never the hard part of engineering and that other things were harder and that was always where your primary skill was located. This excuse is also idiotic. First, Software engineering is hard. It is genuinely not something that anyone can pick up very quickly. Second, all those other “skills” like “domain expertise” are STILL targets for the LLM. It’s not like the LLM exclusively is only good at software. Just face the goddamn truth. AI is on a trajectory to dominate. That’s what all the trendlines say. It’s not currently dominating, but it’s close, and the trajectory points to an endgame where it is fundamentally better. The trendline could be wrong but the trendline is the best quantitative predictor we have and it’s been trumping all the half baked theories on HN where people were claiming self driving cars would never happen and AI could never code. HN was historically wrong… the trendlines and the VCs who made those bets have been right. So who’s the bigger idiot? Those VCs creating the AI bubble or HNers who have been continuously wrong about everything? (Minus crypto, HNers were right about crypto). If the trendline is true our skills as engineers not just the software part is on track to being dominated by an artificial intelligence. The tools trivialize your skills until all the moats are gone. Not only that… AI is becoming better at art. Poetry, writing, paintings, music… AI shows us how trivially reproduceable all of it is. That is the truth. We aren’t not unique and all the meaning behind being human is just an algorithm. It’s all reproducible. Even your self delusional attempt to deny and delude yourself away from these truths is predictable. I can see someone formulating a retort right now.

globalnode

This article is wrong. LLM's encode all the domain knowledge you could possibly want. As a software dev I can query an LLM, become a domain expert in a short amount of time, and then code up a solution. If people think their niche is safe from automation, think again. Even the people who think theyre the masterminds at the top. Edit: Yes "expert" was too strong a word. Proficient would be better. A lot of the barrier to entry in a field is just not understanding the domain.

ramshanker

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.

wg0

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.

yieldcrv

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.

bijowo1676

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

suncemoje

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.

znnajdla

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.

jeffnash

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.

girvo

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

wrs

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.

steve_adams_86

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.

burnto

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.

esikich

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?

azuanrb

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.

simianwords

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?

hyperpape

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.