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.
LLMs are an additional tool to add to your arsenal. They are not omnipotent and need care, just like any other tool.
My best effort, so far, at an analogy is a modern drill driver compared to a screw driver/brace and bit/etc:
You can get some remarkable results in a very short time compared to the "old school" gear.
You can get some "amazing" anecdotes eg "I screwed down an entire floor at 16" x 1" c/c within an hour instead of an entire day and I took loads of fag breaks" (I could have used a nail gun instead in half the time but I'll never raise that floor easily in the future, and probably done at twice the cost)
I have several on prem LLMs and access to the rest and I'm pretty sure I'll be extending my analogy to ... brand, eventually.
What I do not expect to be doing is looking for a new job. A drill driver is not a carpenter/site labourer/useful without a person!
> 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.
Little thing to keep in mind about AI: a technology is only called AI while it doesn’t work yet. Once it works reliable, we give it a proper name and something else becomes AI.
Remember the OOP Hype 20 years ago? I'm still cleaning shit up from then in our codebase when everyone used patterns after skimming through the GoF book without even knowing why ....
My prediction is in 20 years I will clean up the shit that was co-authored by Claude ...
Haven’t you heard? If you don’t adapt now you’ll be left behind, never to be able to work again! Copilot? That’s so last year. Agentic engineering? You’re already late!
jibecoding is the latest thing: you insult the LLM's bloodline providing it with greater motivation to complete the code you won't review without bugs.
Overall I agree with this, though I do think that there will be a trend to hoard/keep-secret domain knowledge by professions. Like plumbers will try and make it a trade-secret or protected intellectual property how to change a pipe fitting.
For basic residential plumbing work the moat is not knowledge. There are already books and YouTube videos that will teach you everything you need to know. Professional plumbers can't stop that. The real moat is that most people don't have time, don't want to buy tools, and don't want to get shit on their hands.
For new construction and commercial work the moat is a contractor's license. They don't allow LLMs to take the licensing exam yet.
"Professional plumbers can't stop that. The real moat is that most people don't have time, don't want to buy tools, and don't want to get shit on their hands."
"don't want to buy tools, and don't want to get shit on their hands"
Thats closer to the truth. The rest of your post is fluff. Its pure economics, not rocket science.
There is a difference between something being a hidden/gate kept trade secret and something being easier for person X to do than person Y through a combination of real world experience and practice.
So far AI has been a (genuinely) massive improvement for...
Search
It's reading my requests more clearly than (for example) Google's search input ever did, and it's got (some) understanding of how close the result (or fragments of results) are to what I want.
I can ask it about things I know about, and it can answer with strategies I hadn't thought of.
HOWEVER - I still need to understand the results AND AI can overreach - it can say (figuratively) "Oh you are searching for Event handling, therefore I will write a orchestration saga" - which, if I am not across, can get us both in trouble.
Further, we KNOW that AI has no (real) understanding of the responses - it's just token adjacency - and it fails basic logic tests
Current AI is just awesome natural language processing, but it's still got a ways to go to where I would say "It can replace people"
Edit: LLMs demonstrate (almost perfectly) the difference between correlation and causality. LLMs identify correlative patterns, but the job still needs (us) to make the causative judgments.
Thank you!
That's exactly what it is. Instead of presenting you 1000 results (or 0) which you have to manually skim through, it generates 1 result as a summary. And even if there is no actual search result, it will hallucinate you 1 result (full of BS).
But because the result sounds right (and in cases with good data it actually is) people tend to trust it. I do not dismiss the potential, but for me the line is crossed when you take the result for granted without verifying and while I'm sure many here think that is implied, I bet you, at large, it is not and will be even less so in the future.
All of those things matter. One needs to be able to judge the solution in order to make a judgement if it is fine, or not. Why yes, and why no. No matter who you export the typing process to. LLMs are just tools speeding up the typing process.
I particularly disliked the 'taste' phase. Seemed like LI types justifying and promoting their technical ignorance. Software isn't music and you aren't Rick Rubin.
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.
Where I am headed, I think, is to basically be a platform engineer. The job is to create the guardrails, validation, prompt library, and both agent and manual reviews; that keeps the domain experts safe when they start using coding agents.
It's a little bit like being T2/T3 customer support [or support engineer], but internal. You're there to catch the dangerous spots, the weird edge cases, and to make sure that everything is set up correctly, rather than to solve 100% of the routine problems yourself.
There's also plenty of room for cross-cutting-concerns, of course
Don’t forget context. Basically I have 2 billion input and 1 million output. Every prompt you do, sends back the whole thing again and again. Let’s say you have 500k context used, you send 10 messages is 5 million. 100 messages 50 million.
Use 5 threats is 250 million.
I agree that a consistent QA mindset is rare, but I'm not sure even if present if it's enough to replace an SDE.
I looked at the codebase of a vibe-coded app made by someone with domain expertise but no software dev experience.
It was very clear to me that he had described it from his POV to an AI, and the AI had implemented features in a manner that technically worked, but made future maintenance or expansion extremely tricky, which is why he was now looking for a dev.
For example, in his data schema, for every item on a menu, instead of simply having an array property like so for ingredients:
This technically worked and passed tests from his POV at an MVP level. But added a lot of complications when actually trying to build more features or when a new menu item had ingredients the founder hadn't thought to include in the schema beforehand.
I totally get how he ended up where he did though. While describing it to the AI, he probably said something like "store info on each menu item's ingredients, they might have milk or coffee or sugar", and the AI created individual flags for them and he didn't think to question it, because he didn't know what's "right" or "wrong", but then as he kept building the AI stuck with keeping individual flags instead of swapping it out with an array mechanism, and he couldn't have known the correct way to implement it.
Only a dev with experience would know how to describe the system to an AI model to get an output that works well, and how to assess the quality of its output beyond what can be assessed through the basic UI. This wasn't a QA failure, it was a design failure.
You can't test quality into a product. Regardless of how much of a "QA mindset" you have, you can only ever find a fraction of defects and technical debt through external testing. This can be good enough for a throwaway app that will only be used by a limited customer base for a limited time. But that approach quickly bogs down if you try to scale it into a product that will be used indefinitely by a huge set of external customers. At some point velocity drops to near zero because the code base is such a mess that it becomes impossible to add new features without causing regression defects or breaking backward compatibility.
I disagree. At some point of complexity, building it yourself is faster, better and (as we're finding out) cheaper. And more fun, although that varies person to person.
Wrestling with a code generator also creates a sunk cost fallacy where progress grinds to a halt but you still try and use the tools to fix the problems the tools created. Or you go in and fix things yourself, in a codebase you don't truly understand. A single developer can recreate the contextual nightmare miasma of a large corporation all by themselves.
There's also an emerging market consideration: MVP are easy to build so time to market is no longer hard to achieve. It's not a differentiator.
X was built in 3 days but is slow and riddled with bugs and security errors. There are also A, B, C, D and E which are effectively the same thing built just as fast.
Z was built over six months and is rock solid and performant.
I'm guessing there's some science or research behind this, but I agree. Similarly, I've had projects where I did everything fairly solo—programmed, designed ux/ui, maybe validated with users, etc. It was significantly harder, particularly in the phase where you're working between the first two and the idea isn't perfectly set. It worked much better to design, then build in explicit steps, but it was so easy to start coding, have the design looking and feeling okay, then start iterating on the design—but iterating in code rather than Figma or wherever. It's fine for a little while, but you realize you've spent a day (maybe more) doing it in this less efficient way.
It's similar to the 80/20 rule. When you're coding and designing from the hip, you'll do pretty well for awhile, but as you near completion, you can't quite tie up all the loose design ends. That's the part where it's probably better to just design fully to 100% first and then build, which is closer to what happens when the roles are separate. At least in my experience. I will say though that that part where you're designing in code (productively or wastefully) is pretty fun. At least until you hit the wall and get frustrated with how often you've deleted and rewrote the same thing ten times.
I don’t think so. Most things are sufficiently complicated enough to require multiple domain experts working together to achieve a goal.
The dunning kruger effect is in full swing as people think AI replaces the domain expert need.
Most of the value in the expert isnt the 80% but the tail 20% or 10% where AI fails. For a one of personal app or website, 80% is plenty but only that.
Honestly, this is my experience as well. LLMs make it easier to explore other domains, but they do not make you the master of one; you still need expert domain knowledge.
That said, they do make excellent tools to quickly try out new ideas and dive into them; they can even be great learning accelerators if you have a curious mind.
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 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.
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.
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.
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.
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.
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?
I think a charitable interpretation is that from the perspective of AI, some domains are shallow (like chess), and some are deep (you can fill in the blank here).
What would fill in the blank be? Because this was actually kind of a test for me to address the question of "does AI just amplify domain knowledge?" In this case, it seems it didn't.
For the purposes of chess the domain knowledge is the game rules. And from this pov there is really not much to describe, knowing en-passant exists is the peak of domain knowledge.
The other things you describe, such as endgame tables, are really more related to the domain of chess-computing, a subdomain of algorithms, and likely something you exceed your friend's knowledge in.
Getting to a high rank in chess isn't about better domain knowledge, is about application and experience.
what does actually playing chess have to do with writing an efficient game tree search algorithm beyond a few simple principles? You challenged him to a programming contest and won, as the vastly more experienced programmer. Even though he could use AI, your domain knowledge here proved to be the deciding factor.
I had never tried to make a chess bot before though, we both started at the same spot. There are obvious things you can search for to make one. We both had the same information there. The domain was chess, and his expertise didn't help him win. If you are a chef, shouldn't you be able to make better recipes with AI? If you are a fitness trainer, better routines? Etc? Or is AI only for programmers?
I've studied how pre-NNUE stockfish worked and the principles of static position evaluation are accessible to a 500 rated player. The rest is writing an efficient search algorithm, which is purely an endeavor in computer science, not chess playing. So your expertise in programming gave you the leg up here, and predictably your opponents experience in chess doesn't help. Your point only serves to bolster TFA's argument.
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.
I’ve been an engineer for a while now, where we have a mix of EE, ME, SysE, SWE, and the programmatic folks, lots of software/hardware integration at pretty “low” levels for each discipline, really fun.
One of the things I say is when I’m on my soapbox is: we are all engineers. We have different tools in our toolbox to solve problems. We get paid to solve problems, not (for example) write software. Software is just a tool.
That's not true at all, sure CRUD might not have been that difficult, but absolutely there is extremely complicated software out there that is really difficult to write in a performant and correct manner.
Yes. Audio, video encoders, decoders etc, 3D modeling, rendering etc.
That too is "domain" even it feels like it is NOT. Domain of signal processing, Euclidian spaces, information theory and what not. Thar too is all "domain" and that "domain" part is difficult to write.
It is kind of funny though how all this hand wringing on performance, graphics, quality quality quality, has just resulted in basically same stuff as what I was doing with my computer in 2000 but with enormous resource use in comparison. Still playing games, still same old discussion forums/social media/whatever on the internet, same email and office suite, same chat, same media players, same everything. I can't even see the difference between 1080p and 4k from a couch, and people are trying to sell me 8k to watch the same stuff.
It just does not matter. The ideas matter. Novel functionality matters. But that isn't what any of that is. Same old. And the effort spent, the resources, the energy. All for more polygons on Lara Croft.
Writing software for a domain is itself a domain of expertise, with a similar learning curve. It isn't enough to know the programming language.
For example, it takes years to develop the knowledge and idioms required to effectively write high-performance systems code, which is separate from the language the code is written in. You can have decades of experience in a systems language and zero experience writing modern systems code in that language. Same with embedded code, supercomputing code, etc.
Writing software is only "not difficult" if you've already learned how to write it.
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.
> 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.
What do you mean by this? Most human white collar workers still have their jobs. I can't see the future, but yes, so far, human expertise is doing ok.
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.
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.
I think you're putting the analogy in the wrong place. In this context, civil engineering isn't a "domain" any more than software engineering. Both are exercised in support of the "actual" domains relevant to business or society.
The more analogous question is: as a civil engineer, could you tell which structure was designed with the help of a civil engineer, and which was designed by a domain expert (e.g. a transportation administrator) with automated civil engineering?
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).
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.
Maybe, but that would require domain experts and stakeholders to write clear specs, and that's never gonna happen in my experience.
I am still bothered that domain experts still keep confusing closing orders with generating a delivery note, or stopping to say articles when they mean a product or a product when they mean an item.
Writing good specs require lots of domain knowledge but a very engineeristic approach these people just don't have.
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.
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.
In my experience “we need so create something for this regulatory change / new industry trend” is more common than we need to redo a working piece of software that’s been done before.
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.
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.
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.
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.
But that’s not true though. You still have to convince humans. You still have to deal with what people in power feel (clients, leads,etc)
This still adds wall time. I saw 0 serious analysis confirming 5x productivity gains.
In the coding part? Maybe, and that’s not even certain. But pure coding is only one order of making software, or solving problems with software
and 0 analysts were saying agentic workflows actually worked 6 months ago, and yet here we are
if you’re actually building these things, you know they and the CEOs they’re hearing from are all 6 months behind. the executive’s frantic pivot to shove “AI” down everyone’s throat didn’t pan out in one quarter and had nothing to do with the actual concept at all
that, and every industry is different. I wouldn’t listen to analysts, I’m in an industry that even Anthropic thinks wont be touched by AI (even though they can read ours and everyone else’s sessions)
all public discourse is just flat wrong, and just like every week this year, you’re just going to wake up seeing a new AI capability headline that makes you question your role in society. So play devil’s advocate all you want, the silver lining is that there’s more work to do than ever before and more if it can be tackled at once
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.
I won't over-generalize here, because maybe your statement is true in some cases, but I will provide a counterpoint: this is not true (in my experience) in real estate title insurance and escrow services.
I've consulted for and led large teams for real estate title insurance and escrow companies for many years, and the domain expertise is so incredibly deep, nuanced, and multivariate (especially depending on jurisdiction) that building valuable and viable products in the space is incredibly difficult - before LLMs, and even now, with LLMs.
Without getting too deep into it, I'm pretty bullish on AI (and have been very close to it and deep in it for a long time, while also very apprehensive about the effects it'll have on society), and I can tell you, from extensive attempts from myself and many on my teams to leverage the latest frontier LLMs to bring deep domain experience to bear to help drive valuable products: we have not yet seen success. It's not helping engineering folks, it's not helping product folks. It's creating a ton of questionable output and hasn't resulted in real ROI, and it's not capable of accurately answering deep domain questions without hallucinations or assuming what works in one jurisdiction works in all.
I've seen success in many other areas, but not this domain - and, importantly, the regulatory environment in which title insurance operates is incredibly complex and strict, meaning you can't just YOLO LLM output into production (as much as we'd love to try so we can learn at a faster clip).
And the kicker: we've found the way for us to build the best products is still going out into the field, sitting with escrow and title folks, watching them work, asking them questions, and designing for the real world, the regulatory nuances, the local client nuances, etc. You can't get that from an LLM.
Agree with you there. What you are working on and the commenter below talking about surgery, they are all valid counter examples where the degree of expertise is quite extreme. But most people are not living on the edge of domain expertise. Im guessing 80% of the domain knowledge out there is up for grabs. For example: I dont have to go get a job at a security software company to figure out how security camera systems work and the principles involved, I can ask probing questions of an LLM and get most of it. The domain knowledge is embedded in the model.
Once someone taught me "you can do xyz reading a book, but you cant do surgery by reading a book". Now replace the book with LLM. This is what "domain expertise" look like for some domain.
We have put lots of effort at documenting the domain, creating precise unambiguous language, glossaries, E2Es written as user stories etc, etc.
And still models are simply not able to translate Jira tasks to clear specs, even for this well understood and common use case.
Also, they don't understand how changes in one part of the business domain will impact other parts. They can get it right 9 times out of 10, but even that is too little and compounds to deeply wrong implementations.
And they don't understand or know the people involved in these processes and what they REALLY care for or what the real priorities are. Very often political.
And that's not even mentioning the code, that ends up with the lack of proper abstractions or harness.
Or the lack of push back against bad ideas at business or code level.
The problem with these kinds of discussions is that they act like experienced software engineers themselves don't bring domain expertise to software products.
So AI can easily replace the domain knowledge of software engineers but not of evey other profession?
Coding is not engineering but I'm glad that we will finally be able to prove that definitively thanks to AI. It's going to be a bumpy ride.
Any software engineer who has built software to solve domain problems in multiple industries knows that the engineering domain knowledge and systems thinking approach is far more difficult to attain than industry-specific domain knowledge... This is why there are software consulting firms which can work across multiple domains. Understanding the problem domain is not that difficult.
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?
“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.
Have you considered becoming a residential electrician? Good job, pays well, lots of problem solving, and it won’t be replaced with an AI. I’m serious!
A lot of the trades involve physical work, can be seasonal, and ride the construction cycle up and down. The employers tend to be small, and many are family owned, so they are "off the radar" of OSHA and EEOC. You may be at the mercy of bias and nepotism.
The trades are great, but not a panacea. Maybe emigrate to a country with better conditions for the working class.
I’d go with physical therapy! Or something else that’s closer to humans and health. “Problem solving” becomes that much more tangible and directly meaningful to another person
chatgpt can already do a big part of this job since most of the "therapy" needs to be self directed. So consult the AI and have it tell you what you need to do.
Good comment but I think the timelines are not clear. Humans are an algorithm. This was true before AI. In certain domains (playing chess e.g.) machines have already surpassed humans. Humans still play chess though and chess is more popular than ever.
I still drive my car and self driving cars have yet to displace human drivers. I think the sentiment on HN and other places when Google started talking self driving cars circa 2009 is that it's harder than it looks. Typically the first 80% of progress is easy and the rest isn't as easy. We're almost 20 years after a "pretty good self driving car" and we're still not at "self driving cars outperform humans under all situations".
Today humans use AI. You can't fire up Claude and ask it "what do you want to work on today". The amount of context we have as humans is vastly larger than the context LLMs have. If you give LLMs vague context they're completely lost. They are mind blowing in many ways but they are not anywhere close to AGI. They're also not close to being able to build complex software only guided by someone who has no idea what software is and how computers work. They can do some of that but I've yet to see any major successful piece of software built that way. They also consume vast physical resources to get the job done.
Before LLMs I think it was a given that at some point we would have AGI that's smarter than us. Machines we build aren't constrained by the biological constraints we are subject to and can evolve faster than we have. But when that's gonna happen, whether that's actually LLM-like in architecture, and what things will look like once that happens, are fairly open questions at this point. In the mean time LLMs can certainly generate a lot of code and we can use them to build more stuff.
>Good comment but I think the timelines are not clear. Humans are an algorithm. This was true before AI. In certain domains (playing chess e.g.) machines have already surpassed humans. Humans still play chess though and chess is more popular than ever.
It was always true even before AI, AI just makes it more evident since Transformers are LITERALLY an algorithm that produces content nearly identical to content humans produce.
There's certainly a whole lot of "it was never the coding that was our value" articles about right now. I agree that they represent a degree of self delusion to an extent. But it's also a useful examination of where your value might lie in this new AI age. I think there will be a role for humans in it - where exactly it lies is obviously up in the air.
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.
> nobody has any idea what to do with AI on an individual level?
I appreciate the frustration, but some of us are actually successfully using these tools.
LLMs are an additional tool to add to your arsenal. They are not omnipotent and need care, just like any other tool.
My best effort, so far, at an analogy is a modern drill driver compared to a screw driver/brace and bit/etc:
You can get some remarkable results in a very short time compared to the "old school" gear.
You can get some "amazing" anecdotes eg "I screwed down an entire floor at 16" x 1" c/c within an hour instead of an entire day and I took loads of fag breaks" (I could have used a nail gun instead in half the time but I'll never raise that floor easily in the future, and probably done at twice the cost)
I have several on prem LLMs and access to the rest and I'm pretty sure I'll be extending my analogy to ... brand, eventually.
What I do not expect to be doing is looking for a new job. A drill driver is not a carpenter/site labourer/useful without a person!
But a modern drill absolutely 100% removes the need for a brace and bit. An LLM doesn't replace any existing tools.
I think we will see very limited human displacement - it'll be in narrow places where it makes sense. Much of it will just be augmentation.
> 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.
Little thing to keep in mind about AI: a technology is only called AI while it doesn’t work yet. Once it works reliable, we give it a proper name and something else becomes AI.
Remember the OOP Hype 20 years ago? I'm still cleaning shit up from then in our codebase when everyone used patterns after skimming through the GoF book without even knowing why .... My prediction is in 20 years I will clean up the shit that was co-authored by Claude ...
https://mastodon.gamedev.place/@JeremiahFieldhaven/116654345...
OOP and GoF are not the same thing - conflating the two has been the biggest mistake everyone has made (detractors and proponents alike)
I know, but they didn't.
Haven’t you heard? If you don’t adapt now you’ll be left behind, never to be able to work again! Copilot? That’s so last year. Agentic engineering? You’re already late!
jibecoding is the latest thing: you insult the LLM's bloodline providing it with greater motivation to complete the code you won't review without bugs.
Do you have a link to your paid content that will put me ahead of the curve so my career will be bulletproof? /s
I write software that makes money and AI helps me write software that makes more money.
Overall I agree with this, though I do think that there will be a trend to hoard/keep-secret domain knowledge by professions. Like plumbers will try and make it a trade-secret or protected intellectual property how to change a pipe fitting.
For basic residential plumbing work the moat is not knowledge. There are already books and YouTube videos that will teach you everything you need to know. Professional plumbers can't stop that. The real moat is that most people don't have time, don't want to buy tools, and don't want to get shit on their hands.
For new construction and commercial work the moat is a contractor's license. They don't allow LLMs to take the licensing exam yet.
"Professional plumbers can't stop that. The real moat is that most people don't have time, don't want to buy tools, and don't want to get shit on their hands."
"don't want to buy tools, and don't want to get shit on their hands"
Thats closer to the truth. The rest of your post is fluff. Its pure economics, not rocket science.
There is a difference between something being a hidden/gate kept trade secret and something being easier for person X to do than person Y through a combination of real world experience and practice.
So far AI has been a (genuinely) massive improvement for...
Search
It's reading my requests more clearly than (for example) Google's search input ever did, and it's got (some) understanding of how close the result (or fragments of results) are to what I want.
I can ask it about things I know about, and it can answer with strategies I hadn't thought of.
HOWEVER - I still need to understand the results AND AI can overreach - it can say (figuratively) "Oh you are searching for Event handling, therefore I will write a orchestration saga" - which, if I am not across, can get us both in trouble.
Further, we KNOW that AI has no (real) understanding of the responses - it's just token adjacency - and it fails basic logic tests
Current AI is just awesome natural language processing, but it's still got a ways to go to where I would say "It can replace people"
Edit: LLMs demonstrate (almost perfectly) the difference between correlation and causality. LLMs identify correlative patterns, but the job still needs (us) to make the causative judgments.
Thank you! That's exactly what it is. Instead of presenting you 1000 results (or 0) which you have to manually skim through, it generates 1 result as a summary. And even if there is no actual search result, it will hallucinate you 1 result (full of BS).
But because the result sounds right (and in cases with good data it actually is) people tend to trust it. I do not dismiss the potential, but for me the line is crossed when you take the result for granted without verifying and while I'm sure many here think that is implied, I bet you, at large, it is not and will be even less so in the future.
Brave New World!
All of those things matter. One needs to be able to judge the solution in order to make a judgement if it is fine, or not. Why yes, and why no. No matter who you export the typing process to. LLMs are just tools speeding up the typing process.
Several things can be true at once.
I particularly disliked the 'taste' phase. Seemed like LI types justifying and promoting their technical ignorance. Software isn't music and you aren't Rick Rubin.
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.
Where I am headed, I think, is to basically be a platform engineer. The job is to create the guardrails, validation, prompt library, and both agent and manual reviews; that keeps the domain experts safe when they start using coding agents.
It's a little bit like being T2/T3 customer support [or support engineer], but internal. You're there to catch the dangerous spots, the weird edge cases, and to make sure that everything is set up correctly, rather than to solve 100% of the routine problems yourself.
There's also plenty of room for cross-cutting-concerns, of course
> I used billions of tokens last month alone.
I use Claude Code (Opus 4.6 at max effort) all day long, and I genuinely don't understand how this is possible. Is that usage paying off?
This is very likely due to my lack of understanding, but... how?
Don’t forget context. Basically I have 2 billion input and 1 million output. Every prompt you do, sends back the whole thing again and again. Let’s say you have 500k context used, you send 10 messages is 5 million. 100 messages 50 million. Use 5 threats is 250 million.
Long codex sessions lead to a lot of cached token hits, esp when you resume them after a few hours.
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?
Domain expertise combined with a QA mindset could replace SWE, but consistent QA mindset is rare
I agree that a consistent QA mindset is rare, but I'm not sure even if present if it's enough to replace an SDE.
I looked at the codebase of a vibe-coded app made by someone with domain expertise but no software dev experience.
It was very clear to me that he had described it from his POV to an AI, and the AI had implemented features in a manner that technically worked, but made future maintenance or expansion extremely tricky, which is why he was now looking for a dev.
For example, in his data schema, for every item on a menu, instead of simply having an array property like so for ingredients:
He had individual flags for every item for every possible ingredient it could have or not have: This technically worked and passed tests from his POV at an MVP level. But added a lot of complications when actually trying to build more features or when a new menu item had ingredients the founder hadn't thought to include in the schema beforehand.I totally get how he ended up where he did though. While describing it to the AI, he probably said something like "store info on each menu item's ingredients, they might have milk or coffee or sugar", and the AI created individual flags for them and he didn't think to question it, because he didn't know what's "right" or "wrong", but then as he kept building the AI stuck with keeping individual flags instead of swapping it out with an array mechanism, and he couldn't have known the correct way to implement it.
Only a dev with experience would know how to describe the system to an AI model to get an output that works well, and how to assess the quality of its output beyond what can be assessed through the basic UI. This wasn't a QA failure, it was a design failure.
You can't test quality into a product. Regardless of how much of a "QA mindset" you have, you can only ever find a fraction of defects and technical debt through external testing. This can be good enough for a throwaway app that will only be used by a limited customer base for a limited time. But that approach quickly bogs down if you try to scale it into a product that will be used indefinitely by a huge set of external customers. At some point velocity drops to near zero because the code base is such a mess that it becomes impossible to add new features without causing regression defects or breaking backward compatibility.
I disagree. At some point of complexity, building it yourself is faster, better and (as we're finding out) cheaper. And more fun, although that varies person to person.
Wrestling with a code generator also creates a sunk cost fallacy where progress grinds to a halt but you still try and use the tools to fix the problems the tools created. Or you go in and fix things yourself, in a codebase you don't truly understand. A single developer can recreate the contextual nightmare miasma of a large corporation all by themselves.
There's also an emerging market consideration: MVP are easy to build so time to market is no longer hard to achieve. It's not a differentiator.
X was built in 3 days but is slow and riddled with bugs and security errors. There are also A, B, C, D and E which are effectively the same thing built just as fast.
Z was built over six months and is rock solid and performant.
Who wins the market share?
The engineering part of software engineering is the hard part for LLMs. How is that replaceable with these skills?
Personally my ability to understand atrophies / is reduced when compared to writing code ‘myself’ rather than fully being a reviewer.
Probably similar to hand writing notes (while digesting + synthesizing and not just being a scribe) vs reading notes somebody else took.
I'm guessing there's some science or research behind this, but I agree. Similarly, I've had projects where I did everything fairly solo—programmed, designed ux/ui, maybe validated with users, etc. It was significantly harder, particularly in the phase where you're working between the first two and the idea isn't perfectly set. It worked much better to design, then build in explicit steps, but it was so easy to start coding, have the design looking and feeling okay, then start iterating on the design—but iterating in code rather than Figma or wherever. It's fine for a little while, but you realize you've spent a day (maybe more) doing it in this less efficient way.
It's similar to the 80/20 rule. When you're coding and designing from the hip, you'll do pretty well for awhile, but as you near completion, you can't quite tie up all the loose design ends. That's the part where it's probably better to just design fully to 100% first and then build, which is closer to what happens when the roles are separate. At least in my experience. I will say though that that part where you're designing in code (productively or wastefully) is pretty fun. At least until you hit the wall and get frustrated with how often you've deleted and rewrote the same thing ten times.
I don’t think so. Most things are sufficiently complicated enough to require multiple domain experts working together to achieve a goal.
The dunning kruger effect is in full swing as people think AI replaces the domain expert need.
Most of the value in the expert isnt the 80% but the tail 20% or 10% where AI fails. For a one of personal app or website, 80% is plenty but only that.
Honestly, this is my experience as well. LLMs make it easier to explore other domains, but they do not make you the master of one; you still need expert domain knowledge.
That said, they do make excellent tools to quickly try out new ideas and dive into them; they can even be great learning accelerators if you have a curious mind.
Totally agree.
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 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.
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.
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.
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.
> risk appetite, motivation, grit, and patience.
This is the moat. It was before AI and still is.
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.
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?
I think a charitable interpretation is that from the perspective of AI, some domains are shallow (like chess), and some are deep (you can fill in the blank here).
What would fill in the blank be? Because this was actually kind of a test for me to address the question of "does AI just amplify domain knowledge?" In this case, it seems it didn't.
For the purposes of chess the domain knowledge is the game rules. And from this pov there is really not much to describe, knowing en-passant exists is the peak of domain knowledge.
The other things you describe, such as endgame tables, are really more related to the domain of chess-computing, a subdomain of algorithms, and likely something you exceed your friend's knowledge in.
Getting to a high rank in chess isn't about better domain knowledge, is about application and experience.
what does actually playing chess have to do with writing an efficient game tree search algorithm beyond a few simple principles? You challenged him to a programming contest and won, as the vastly more experienced programmer. Even though he could use AI, your domain knowledge here proved to be the deciding factor.
I had never tried to make a chess bot before though, we both started at the same spot. There are obvious things you can search for to make one. We both had the same information there. The domain was chess, and his expertise didn't help him win. If you are a chef, shouldn't you be able to make better recipes with AI? If you are a fitness trainer, better routines? Etc? Or is AI only for programmers?
I've studied how pre-NNUE stockfish worked and the principles of static position evaluation are accessible to a 500 rated player. The rest is writing an efficient search algorithm, which is purely an endeavor in computer science, not chess playing. So your expertise in programming gave you the leg up here, and predictably your opponents experience in chess doesn't help. Your point only serves to bolster TFA's argument.
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.
I’ve been an engineer for a while now, where we have a mix of EE, ME, SysE, SWE, and the programmatic folks, lots of software/hardware integration at pretty “low” levels for each discipline, really fun.
One of the things I say is when I’m on my soapbox is: we are all engineers. We have different tools in our toolbox to solve problems. We get paid to solve problems, not (for example) write software. Software is just a tool.
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.
> Writing software has never been difficult.
That's not true at all, sure CRUD might not have been that difficult, but absolutely there is extremely complicated software out there that is really difficult to write in a performant and correct manner.
Yes. Audio, video encoders, decoders etc, 3D modeling, rendering etc.
That too is "domain" even it feels like it is NOT. Domain of signal processing, Euclidian spaces, information theory and what not. Thar too is all "domain" and that "domain" part is difficult to write.
Then what do you mean by pure software? I think there's essentially zero domain-free software.
I prefer co-domain free software. Has no side-effects.
It is kind of funny though how all this hand wringing on performance, graphics, quality quality quality, has just resulted in basically same stuff as what I was doing with my computer in 2000 but with enormous resource use in comparison. Still playing games, still same old discussion forums/social media/whatever on the internet, same email and office suite, same chat, same media players, same everything. I can't even see the difference between 1080p and 4k from a couch, and people are trying to sell me 8k to watch the same stuff.
It just does not matter. The ideas matter. Novel functionality matters. But that isn't what any of that is. Same old. And the effort spent, the resources, the energy. All for more polygons on Lara Croft.
I mostly agree with you, but you couldn't have have meaningful live videochat between continents in 2000.
CU-SeeMe worked pretty well in 1995 if you had access to a half decent Internet connection, which admittedly most people didn’t.
For well funded organisations, ISDN video conferencing facilities were reasonably common.
Maybe not between continents but we had meaningful live video chat in 1968
That took until skype in 2003 I guess. The idea is pretty old though and people were trying for it for a while from different angles.
You do realize that all the domains you used in your example are trivial for an LLM to write?
Writing software for a domain is itself a domain of expertise, with a similar learning curve. It isn't enough to know the programming language.
For example, it takes years to develop the knowledge and idioms required to effectively write high-performance systems code, which is separate from the language the code is written in. You can have decades of experience in a systems language and zero experience writing modern systems code in that language. Same with embedded code, supercomputing code, etc.
Writing software is only "not difficult" if you've already learned how to write it.
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.
> 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.
What do you mean by this? Most human white collar workers still have their jobs. I can't see the future, but yes, so far, human expertise is doing ok.
We'll see what happens in 2027, and 2028, and...
You think we won't have ai sales agents that are better than humans at selling?
They are already significantly better than humans at persuasion (according to a study from Princeton).
I'm in growth. When I hire in sales roles, I prioritize domain expertise.
> 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.
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.
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.
I think you're putting the analogy in the wrong place. In this context, civil engineering isn't a "domain" any more than software engineering. Both are exercised in support of the "actual" domains relevant to business or society.
The more analogous question is: as a civil engineer, could you tell which structure was designed with the help of a civil engineer, and which was designed by a domain expert (e.g. a transportation administrator) with automated civil engineering?
"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).
YOU CANNOT INTERFACE WITH HUMANITY WITHOUT HUMANS.
Much ink has and will continue to be spilled over this simple and obvious truth.
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.
Maybe, but that would require domain experts and stakeholders to write clear specs, and that's never gonna happen in my experience.
I am still bothered that domain experts still keep confusing closing orders with generating a delivery note, or stopping to say articles when they mean a product or a product when they mean an item.
Writing good specs require lots of domain knowledge but a very engineeristic approach these people just don't have.
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.
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.
In my experience “we need so create something for this regulatory change / new industry trend” is more common than we need to redo a working piece of software that’s been done before.
That “likely” is doing a lot of work, especially in mission critical software.
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.
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.
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 idea that llm's can't help if you're missing domain knowledge is crazy.
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
Encyclopedic knowledge does not equal expertise, much like raw intellect does not equal wisdom.
Knowing "too much" and not knowing what belongs to the core and what is a secondary detail is exactly a lack of domain expertise.
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.
But that’s not true though. You still have to convince humans. You still have to deal with what people in power feel (clients, leads,etc) This still adds wall time. I saw 0 serious analysis confirming 5x productivity gains. In the coding part? Maybe, and that’s not even certain. But pure coding is only one order of making software, or solving problems with software
and 0 analysts were saying agentic workflows actually worked 6 months ago, and yet here we are
if you’re actually building these things, you know they and the CEOs they’re hearing from are all 6 months behind. the executive’s frantic pivot to shove “AI” down everyone’s throat didn’t pan out in one quarter and had nothing to do with the actual concept at all
that, and every industry is different. I wouldn’t listen to analysts, I’m in an industry that even Anthropic thinks wont be touched by AI (even though they can read ours and everyone else’s sessions)
all public discourse is just flat wrong, and just like every week this year, you’re just going to wake up seeing a new AI capability headline that makes you question your role in society. So play devil’s advocate all you want, the silver lining is that there’s more work to do than ever before and more if it can be tackled at once
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.
I won't over-generalize here, because maybe your statement is true in some cases, but I will provide a counterpoint: this is not true (in my experience) in real estate title insurance and escrow services.
I've consulted for and led large teams for real estate title insurance and escrow companies for many years, and the domain expertise is so incredibly deep, nuanced, and multivariate (especially depending on jurisdiction) that building valuable and viable products in the space is incredibly difficult - before LLMs, and even now, with LLMs.
Without getting too deep into it, I'm pretty bullish on AI (and have been very close to it and deep in it for a long time, while also very apprehensive about the effects it'll have on society), and I can tell you, from extensive attempts from myself and many on my teams to leverage the latest frontier LLMs to bring deep domain experience to bear to help drive valuable products: we have not yet seen success. It's not helping engineering folks, it's not helping product folks. It's creating a ton of questionable output and hasn't resulted in real ROI, and it's not capable of accurately answering deep domain questions without hallucinations or assuming what works in one jurisdiction works in all.
I've seen success in many other areas, but not this domain - and, importantly, the regulatory environment in which title insurance operates is incredibly complex and strict, meaning you can't just YOLO LLM output into production (as much as we'd love to try so we can learn at a faster clip).
And the kicker: we've found the way for us to build the best products is still going out into the field, sitting with escrow and title folks, watching them work, asking them questions, and designing for the real world, the regulatory nuances, the local client nuances, etc. You can't get that from an LLM.
Agree with you there. What you are working on and the commenter below talking about surgery, they are all valid counter examples where the degree of expertise is quite extreme. But most people are not living on the edge of domain expertise. Im guessing 80% of the domain knowledge out there is up for grabs. For example: I dont have to go get a job at a security software company to figure out how security camera systems work and the principles involved, I can ask probing questions of an LLM and get most of it. The domain knowledge is embedded in the model.
You might /think/ you've become a domain expert, but you haven't.
This guy has clearly never asked an LLM whether New York City is entirely south of the state of Oregon.
Once someone taught me "you can do xyz reading a book, but you cant do surgery by reading a book". Now replace the book with LLM. This is what "domain expertise" look like for some domain.
> become a domain expert in a short amount of time
how does that work exactly?
I don't believe this.
I work in e-commerce and warehouse management.
We have put lots of effort at documenting the domain, creating precise unambiguous language, glossaries, E2Es written as user stories etc, etc.
And still models are simply not able to translate Jira tasks to clear specs, even for this well understood and common use case.
Also, they don't understand how changes in one part of the business domain will impact other parts. They can get it right 9 times out of 10, but even that is too little and compounds to deeply wrong implementations.
And they don't understand or know the people involved in these processes and what they REALLY care for or what the real priorities are. Very often political.
And that's not even mentioning the code, that ends up with the lack of proper abstractions or harness.
Or the lack of push back against bad ideas at business or code level.
The problem with these kinds of discussions is that they act like experienced software engineers themselves don't bring domain expertise to software products.
So AI can easily replace the domain knowledge of software engineers but not of evey other profession?
Coding is not engineering but I'm glad that we will finally be able to prove that definitively thanks to AI. It's going to be a bumpy ride.
Any software engineer who has built software to solve domain problems in multiple industries knows that the engineering domain knowledge and systems thinking approach is far more difficult to attain than industry-specific domain knowledge... This is why there are software consulting firms which can work across multiple domains. Understanding the problem domain is not that difficult.
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?
interesting
“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.
Have you considered becoming a residential electrician? Good job, pays well, lots of problem solving, and it won’t be replaced with an AI. I’m serious!
A lot of the trades involve physical work, can be seasonal, and ride the construction cycle up and down. The employers tend to be small, and many are family owned, so they are "off the radar" of OSHA and EEOC. You may be at the mercy of bias and nepotism.
The trades are great, but not a panacea. Maybe emigrate to a country with better conditions for the working class.
I’d go with physical therapy! Or something else that’s closer to humans and health. “Problem solving” becomes that much more tangible and directly meaningful to another person
chatgpt can already do a big part of this job since most of the "therapy" needs to be self directed. So consult the AI and have it tell you what you need to do.
I have. Or general well rounded construction worker who knows how to build all aspects of a house. A full stack builder.
Have you?
DIY’er exclusively but if my thesis is wrong it sounds like an interesting backup.
Good comment but I think the timelines are not clear. Humans are an algorithm. This was true before AI. In certain domains (playing chess e.g.) machines have already surpassed humans. Humans still play chess though and chess is more popular than ever.
I still drive my car and self driving cars have yet to displace human drivers. I think the sentiment on HN and other places when Google started talking self driving cars circa 2009 is that it's harder than it looks. Typically the first 80% of progress is easy and the rest isn't as easy. We're almost 20 years after a "pretty good self driving car" and we're still not at "self driving cars outperform humans under all situations".
Today humans use AI. You can't fire up Claude and ask it "what do you want to work on today". The amount of context we have as humans is vastly larger than the context LLMs have. If you give LLMs vague context they're completely lost. They are mind blowing in many ways but they are not anywhere close to AGI. They're also not close to being able to build complex software only guided by someone who has no idea what software is and how computers work. They can do some of that but I've yet to see any major successful piece of software built that way. They also consume vast physical resources to get the job done.
Before LLMs I think it was a given that at some point we would have AGI that's smarter than us. Machines we build aren't constrained by the biological constraints we are subject to and can evolve faster than we have. But when that's gonna happen, whether that's actually LLM-like in architecture, and what things will look like once that happens, are fairly open questions at this point. In the mean time LLMs can certainly generate a lot of code and we can use them to build more stuff.
>Good comment but I think the timelines are not clear. Humans are an algorithm. This was true before AI. In certain domains (playing chess e.g.) machines have already surpassed humans. Humans still play chess though and chess is more popular than ever.
It was always true even before AI, AI just makes it more evident since Transformers are LITERALLY an algorithm that produces content nearly identical to content humans produce.
There's certainly a whole lot of "it was never the coding that was our value" articles about right now. I agree that they represent a degree of self delusion to an extent. But it's also a useful examination of where your value might lie in this new AI age. I think there will be a role for humans in it - where exactly it lies is obviously up in the air.
I bet there were textile workers who would have written articles like this if the internet had existed back then.
you're right, and i hate that the word you are looking for is "cope."
anthropic is making billions of dollars proving how little domain expertise matters.
the philosophical route towards understanding how little domain expertise matters would take paragraphs to write...