Domain expertise has always been the real moat
brethorsting.com759 points by aaronbrethorst 20 hours ago
759 points by aaronbrethorst 20 hours ago
While I agree that domain expertise has always been a moat, I believe the author is missing something critical: there is a big difference between being able to verify the output of a system is correct, and being able to tell a system how to generate the correct output to begin with.
Personal example: I had a software engineering colleague who was the best coder of financial management systems I've ever encountered. He gained these skills through years of in-the-trenches development. One of the things he told me, and that I also observed, was that the vast majority of financial experts (basically, the people in the accounting department of companies) had an extremely difficult time just telling him what the rules of any particular transaction should be. But what they could do was tell him whether the handling of any particular transaction was right or wrong. So often times he would sit down with these accounting folks and go through lots of example transactions he came up with, and from there he essentially built up the requirements spec.
In my experience, that is the primary difference between people I've known who are good software engineers and those who aren't: people who can specify the detailed rules of any system, vs. folks who take a "well, I know it when I see it" approach.
I have a strong suspicion that folks who have a high degree of domain expertise in a particular area will fail as software builders even in an agentic world because they will struggle to elucidate clearly the rules in their head that they've learned over years. As an analogy, it's kind of like asking a native speaker for the grammar rules of their language. Often times they can't, but they'll just say "well, that sounds wrong." They may be "domain experts" in their language, but they'd have a hell of a time prompting an AI system on how to grade a test for grammar correctness.
Anybody who has ever done programming professionally in the small scale knows this. Refining the requirements is the job.
In fact, I've never known an industry so keen on levelling its own moats as the software industry. We regularly invent things like 4GL, graphical programming and frameworks and engines such as Unity just to enable more people to do programming. People will happily teach programming for free in outreach programs (I am just one example). No other profession does this. Perhaps with the exception of mathematicians and other fields that are very close to programming.
I could teach an economist enough programming in a weeks that they could write an ERP module, but I could not learn enough economics in a week to write one. If the language was the barrier, we could invent a more effective one. We invent new languages weekly anyway. Having seen how quickly beginners can make things with Unity or Godot, I seriously doubt an LLM agent could improve much on this. Of course, if the job is writing yet another CRUD React app with a Java or Python backend, then sure, the LLM will be very effective. But compared to doing same app in something like Excel or MS Access? Not that much.
Everything everywhere does this. All human progress has been making common and accessible the rare and expensive. Universities, online courses, textbooks, etc all exist to make economics as accessible as possible, there’s just a really tight reward loop with programming so your rate of learning it is more tangible
I think you are underestimating how hard it is for average joe to learn programming basics. I remember a fellow in high school that just could not accept that = in programming is assignment not an equation (like in high school math)
I'd like to believe I have an inkling, having done a fair bit of teaching.
Still, imagine how hard other skills are to acquire. How much civil engineering can you learn in two weeks? How much violin playing? But you could absolutely get basic grasps on a general purpose programming language. With something specialized like Unity or Excel you would get tons of useful output.
The hurdle around assignment operator is as old as symbolic languages. That's why legends such as Niklaus Wirth wanted to use another operator, ":=", a notation that is still being used.
Anyway, it can be a hurdle, but one I find that most people get over pretty quickly.
> The hurdle around assignment operator is as old as symbolic languages. That's why legends such as Niklaus Wirth wanted to use another operator, ":=", a notation that is still being used.
Well, sure; but more generally, the ability to accept other meanings for symbols (and keep subtly different symbols straight in one's head) is a mental skill, and individuals vary in their aptitude for it. (Presumably, this one is also relevant to natural language learning, since one must reckon e.g. with false cognates.)
>We regularly invent things like 4GL, graphical programming and frameworks and engines such as Unity just to enable more people to do programming.
You're right on the money on this.
Earlier this month I went to visit a company for a complete demo prototype of a full one-to-one train simulator trainer mostly designed and programmed by a former civil engineer using Unity engine. According to the company, they could not do it if Unity engine (or similar) is not around because it will be prohibitively expensive to develop.
In a related news, Unity recently released AI eco-system namely Unity AI Suite [1].
[1] Unity AI Suite:
the 1 dimensional thinking that's perverse in the industry will be catastrophic.
we don't like doing the hard things e.g training juniors so they can be skilled seniors via good apprenticeship programs i.e on the job. now we r delegating to stochastic parrots.
in terms of systems thinking which is one skill you need to be a domain expertise - very few people are ever curious & are not willing or able to ask critical questions. hence the groupthink that's prevalent in the industry.
no wonder the quality of software never goes up - while the building blocks have gone up in quality. an analogy is like having super strong bricks but making brittle structures
I use LLMs daily for coding. That said, I agree with your sentiment. Super strong bricks, poorly put together, makes a bad building.
Another analogy I like is a beginner playing a $100k Stratavarius probably can't produce anything near a professional violinist playing a $50 violin.
Personally I use LLMs to level up my systems thinking. I describe the domain, I have it brainstorm some scalable solutions, I look them up, I bring them up to the team, and we discuss, and I implement. It's a great workflow imo.
>One of the things he told me, and that I also observed, was that the vast majority of financial experts (basically, the people in the accounting department of companies) had an extremely difficult time just telling him what the rules of any particular transaction should be
We have internalized more knowledge than we can explain sounds like the textbook definition of Polanyi's paradox:"Polanyi's paradox, named in honour of the British-Hungarian philosopher Michael Polanyi, is the theory that human knowledge of how the world functions and of our own capability are, to a large extent, beyond our explicit understanding" [0]
Thanks so much! I hadn't heard of Polanyi's paradox before but it is exactly what I was talking about. The Wikipedia entry even highlights the problem for AI-driven development:
> Polanyi's paradox has been widely considered to identify a major obstacle in the fields of AI and automation, since programming an automated task or system is difficult unless a complete and fully specific description of the procedure is available.
having worked on automation of accounting process, it has been a combination of ever evolving ruleset/edge scenarios for 10% cases plus standardised rules for 90% of the cases. i think the problem is that it is an evolving field. alot of times it borders law, which makes it murky and vague too.
cf https://en.wikipedia.org/wiki/Dual_process_theory as a causative agent behind the paradox.
I think this neatly captures the gap in the article; it’s thinking of domain expertise as static, rather than something that needs to be built/extracted.
It also goes the other way; A a good engineer can build experiments and discover the domain even without an oracle on the team; reading protocols or manuals or specs, for example. In other words, learn to be a domain expert themselves.
Personally I find the most efficient way to learn a concept to be building it; you are immediately faced with your blind spots. AI for sure helps improve cycle time on these discoveries if you use it that way; time writing boilerplate goes to ~zero and you can spend your time figuring out how to answer the real questions.
I do think that we as a profession need to learn new architectural and craftsmanship patterns to make it easier to learn from our code; concepts like Literate Programming which were too fussy for fast-moving teams may end up accelerating in the agentic world; I need to read a lot more code than I write now. But also things like Acceptance Test Driven Design; not new concepts, just newly increased in value.
That is why coders who learn problem domains are where the money is at.
Works for me.
Already learned two or three problem domains well enough and now it is starting to compound.
WRT the native grammar, consider adjective order. Few native english speakers (me included) can off the cuff name the proper order, but everyone knows the "right" order.
https://dictionary.cambridge.org/us/grammar/british-grammar/...
Another one: tekamolo, for German and adverbs this time.
Temporal, kausal, Modal, Lokal
https://www.olesentuition.co.uk/single-post/tekamolo-how-to-...
I think the answer is in the second sentence of the article. The most valuable person in this new world (using the author's own phrasing from the penultimate paragraph) is the one who is good at "building a working model of the domain in [their] head".
Depending on the domain, this may either be the domain expert themselves, or someone else trained in formal logic, data structures and organizing information into coherent hierarchies. If this is neither the domain expert nor the programmer, then it must be someone in between. In the old world, this role was called "business analyst".
I'm this person, and I do find AI to be quite helpful, though I'm mostly just playing around at this point.
I'm the daughter and granddaughter of programmers, and I learned the basics of how to code as a kid. I'm good at it and have a knack for it, but I didn't want to do it for 8+ hours a day and then spend my nights on it as well, so I didn't pursue it as a career. I did an undergraduate degree in Linguistics, which has been really helpful for having an intuitive sense for what 'language as data' can accomplish and for a strong understanding of the difference between language as data and language as meaning. I studied formal logic systems. Then I did a graduate degree in Library Science and worked in libraries for a decade and a half.
I can organize and define systems very well, and I'm trained in how to wheedle information people don't consciously know out of them without them knowing I'm doing it. I've spent enough time around actual devs to understand where my limitations are and when to loop in someone who knows more to check my work, and when it's important for the work to be super accurate versus when I can learn by fucking around. (Front end and design? Fuck around! Database structure? Fuck around but with an exceptionally robust backup system kept outside of the AI tools' purview + don't fuck around in prod. Storing credentials and people's information? Ask someone.)
The problem companies are going to have is I'm very disinclined to work for them doing this, particularly if they want us because they think we're going to be cheaper. Most people who are in this category a.) could be devs and opted not to, and there's a reason for that and/or b.) are the children, cousins, etc. of programmers. We're not stupid: we know we're just as disposable as they're trying to make devs.
Having descended from a humanities social background and blundered into professional programming rather incidentally, a lot of this resonates with me.
I've frequently been credited as a person who can really string all the disparate elements of tacit knowledge together into a unified fabric in our particular subdomain, and helped a lot of people plug Swiss cheese gaps in their knowledge that way and come away with the feeling that it's all been tied together theoretically.
However, it's not immediately obvious to me how, in our LLM psychosis cultural moment, this facility shoots to the top of the value chain.
Having worked with domain experts I concur on the difficult time they have expressing the rules of their domains.
Once I built a little domain-specific language for them, that was tested against old jobs to see if they contradicted the past; it was a nifty project and since then I am convinced that DSLs are underrated as a way to encode expertise.
Can you give an example (even if contrived) of how that would have looked ? I’m very curious !
I had the experts write markdown files that contained the rules looked somewhat like:
## 1A Rule name
Some prose explaining the rules liking to official documentation.
``` if municipality and inhabitants > 10000 then functionA else functionB ```
Then a trivial parser would extract the rules, the DSL was then handled by Lark[1]. So pretty simple, but it made collaborating with experts easier as simulated results would also output some markdown they could read.
Sounds like "Literate Programming", where the code and comments are reversed: instead of everything being code except what's marked as a comment, everything is a comment except what's marked as code.
I think that you raise some excellent points here. I want to dive deeper into what is meant by domain knowledge -- as a I see it. This phrase comes to mind: "Those who know, do. Those that understand, teach." (Google search tells me that it is frequently misattributed to Aristotle.) People who cannot clearly articulate rules for their domain only "do". However, those that can clearly articulate will "teach". Thus, I would say true domain knowledge is the ability to teach that domain to others.
I largely agree, but want to note that there’s the counterpoint “Those who can, do; those who can’t, teach” (from George Bernard Shaw’s 1903 play Man and Superman), which also has some nugget of truth in it.
I agree with your point that people “from” the domain aren’t automatically equipped to start AI-building software in the domain, exactly because they often lack one of the most crucial software development skills — being able to (and having the desire to) describe a complex system with a finite set of deterministic rules.
But I don’t think we should be calling these people “domain experts”. I think we should reserve that name for the other group, for the people who truly and deeply understand the domain, the whys and whats and why nots.
> But I don’t think we should be calling these people “domain experts”. I think we should reserve that name for the other group, for the people who truly and deeply understand the domain, the whys and whats and why nots.
I've spent a lot of time in my career extracting info from the business and I think most do understand the whys/why nots but aren't practiced at organizing all of those decades of experience into a higher level abstract model that can easily be communicated.
It's typically layers and layers of information with dependencies in many directions littered with exceptions. Just like our software design+dev experience, it takes a lot of practice to try to organize all of that info into a coherent presentable model.
That ship has sailed. Anyone who works in a field is now considered a domain expert (or "SME") even if they're nothing of the sort. There should ideally be another term that's a superset, but I doubt it would ever catch on.
You're doing a bit of a "true Scotsman fallacy" here.
It feels like without a bit of true Scotsmanship, the term “domain expert” doesn’t really mean anything.
Sure it does, it’s just a highly contested meaning that depends on a proper contemporary interpretation if to be received as intended in this context. Context that varies domain to domain. For the domain name buyer it’s quite different than the metacognitive scholar.
Agree. If you can't explain it to someone else, you don't really understand it yourself. These people are practitioners not experts.
People you say are not experts are fully capable to explain whys and whats and why nots. In more details that you can absorb.
They will do that on examples tho. They will recognize and explain every single exception they see - but they are not able to list all exceptions up front. Because, that is highly unusual task
> So often times he would sit down with these accounting folks and go through lots of example transactions he came up with, and from there he essentially built up the requirements spec.
Right, so the spec is derived from examples, an interactive process that doesn’t require a programmer.
Talking to CPAs never gets you to Pacioli groups.
Talking to engineers and mathematicians gets you there.
Interpolating between the examples still requires understanding of the domain for the interpolation to be a sensible one. And it’s an iterative feedback process: thinking about possible interpolations leads you to cases that need clarifications from the domain experts. The domain experts won’t come up with all relevant examples by themselves, and they typically aren’t as good at thinking about interpolations like a developer who is trained to always consider all possible cases; they don’t think in terms of models the way a developer does.
LLMs already have interactive discussions with me on the topics I engage with, including asking expansive questions, so I do not think this is beyond the realm of the technology.
The programmer skill is how to abstract the specs from all the examples. And then to formalize it. Actual coding is merely translation. And only beginners tend to focus on that.
Sounds very similar to what AI is good at.
I've yet to see AI be good at extracting good abstractions. More often than not it jumps to creating a battery of special case checks.
May work for simple cases, but how would you come up with something like typst, or thunderbird?
> But what they could do was tell him whether the handling of any particular transaction was right or wrong. So often times he would sit down with these accounting folks and go through lots of example transactions he came up with, and from there he essentially built up the requirements spec.
This combination of requirements is the business in most domains. Software or otherwise. Codefying different rules and executing them.
Yes. The author stumbled on the p vs np problem but with humans. Verification is easy. Solving is the millennium prize question.
I agree that it has some resemblance, but the striking thing about NP-complete problems is that an efficient solution to any of them is an efficient solution to all of them, which makes it worth trying exceptionally hard to find one.
It could be that whatever lackluster expertise you can squeeze out of an LLM is good enough to discourage investment in the real thing since unlike NP-complete problems, expertise isn't generalizable.
Agreed. But there is a new dynamic coming to place. Who can execute faster now that we have AIs? I think the combination of (Good SWE using AIs) collaborating with (Domain Expert using AIs) is the winning team. Things are accelerating on all fronts, the frontier may be jagged but AIs is making progress on all capabilites.
I have found this with (mechanical) engineers. They know what they want to see but don’t understand the underlying details which are more mathematical than the average engineer is able to work with. So the people working on engineering software are often physicists or applied mathematicians.
This is the exasperating part about learning to speak Spanish using a textbook; you must guess the grammar rules because the textbook won't tell you. So, you use the English rule and hope and pray that it is the same in Spanish, and you'll be right the majority of the time but often wrong. Spanish textbooks written 100 years ago tell you the grammar rules and are more useful than recent textbooks.
While interesting, I rarely found knowing grammar rules beyond some very basic ones to help all that much for learning to speak a language, compared to language exposure and speaking practice.
> I have a strong suspicion that folks who have a high degree of domain expertise in a particular area will fail as software builders even in an agentic world because they will struggle to elucidate clearly the rules in their head that they've learned over years.
This is the part I disagree with.
In a non-agentic world, the expert and the programmer are two different people. If the expert finds a bug in the software, they have to describe that bug, send it over to a programmer to fix, wait for a new release and until that scenario occurs again, realize that their description was actually wrong, send a corrected description, rinse and repeat for a few iterations until the bug is finally fixed for good.
In a world of agents, the expert finds the bug, asks the agent to fix it, realizes that the fix is incorrect because of sloppy thinking, does a few iterations until the feature works correctly, and that's it. Bug fixed; with 10 minutes of work instead of a few weeks.
> realizes that the fix is incorrect because of sloppy thinking
If the domain expert doesn’t understand the generated code, they can only discover incorrect logic by specific examples (specific inputs), which is usually impossible to do exhaustively. The programmer, on the other hand, can see incorrect logic directly, generalized over all possible inputs and states. It’s the difference between testing and proving correctness.
> In a world of agents, the expert finds the bug, asks the agent to fix it, realizes that the fix is incorrect because of sloppy thinking, does a few iterations until the feature works correctly
That would require clearly (a) knowing what you want, and (b) expressing it unambiguously and in detail, including all edge cases. Essentially producing a spec.
Most people are not able to do either. Talking to an LLM does not change that.
but.. they can iterate real quick!
As long as the expert don't run of patience, he may be able to do that.
Consider finance sector -- the industry is powered by excel spreadsheets made by non-programmer having no clue how programming works.
Spreadsheet is a DSL for finance and a lot of other sectors. But the lack of formal logic capabilities shows when you seen the spreadsheet organization. Most only stand with ducktape all over the place.
I had the same problem in air travel industry. Our ticketing officers were never able to communicate how the ticket commission rules from our partners should be interpreted. I ended up adding a test framework, that allowed to add examples and counterexamples of existing flights to each rule, to verify that they are applied the way they'd assign commission by hand.
Domain expertise matters more than most bootcamp grads want to hear. Knowing how to phrase a query for a specific domain is half the battle.
You described reasoning by analogy, which two thirds of the population does.
Please explain explicitly what you are implying, because I don't get it
Who are the 1/3 of the population that does not reason by analogy?
This is basically the gap BDD tries to close I guess. It assumes that domain experts can't fully articulate the rules upfront.
I fully agree here. It's also not uncommon to have the reply for specific items be "Ahh, well that is a bit of an edge case see because of X and Y" and then you learn there are many many "special cases" to the point that they aren't that special anymore.
Some companies use product managers for this purpose. They translate the implicit domain knowledge of those experts into explicit requirements, mostly through interviewing.
> I have a strong suspicion that folks who have a high degree of domain expertise in a particular area will fail as software builders even in an agentic world because they will struggle to elucidate clearly the rules in their head that they've learned over years.
Maybe they need a build a hybrid expertise of "domain" and "software engineering". For example, robotic surgery requires expert surgeons to build sufficient expertise in robotics
Also, noticed a pretty high karma for a throwaway account.
Are we thinking about the wrong side here? Wouldn't the LLM be a super-intelligent financial expert as well as a super-intelligent coder?
I guess the flip side to that is the iterative conversation to develop these specifications is exactly what AI chatbots are good at.
It's also the main reason why very structured AI agent orchestration for software engineering modelled on rigid processes fails to really provide much value.
I suspect that the reason AI chatbots are not very good at developing such specifications is that they don’t build a domain model in their “head” — the only models they have are already hardcoded in their weights. A human learning a domain, on the other hand, forms new neural connections representing the model of the domain that they build in their head.
'course, software development itself is a domain.
It's funny how out of touch AI is with seeing the big picture of problems.
Here's an example I encountered last week:
Someone in my neighborhood is a 75 year old chemical engineer who likes computers and got into Linux a few months ago. I see him from time to time when walking around, he's a nice guy and overall has a scientist's mindset. He doesn't make a lot of assumptions and tries to think things through but sometimes he has big blind spots in unfamiliar fields.
I helped him install Linux and also hook up an SSD to one of his older machines and now it flies.
On his own he had an old sound card that he wanted to use on that machine. He asked me if the card is compatible. I told him it almost certainly is because the Linux kernel has drivers for a ton of devices. His motherboard's built-in sound card was fine but he likes tinkering with audio in general.
He managed to physically install the card correctly but called me and said there's no sound playing. Then he says he spent 12 hours troubleshooting the issue, using ChatGPT and Googling for assistance.
Over the phone he told me he tried many different things. Installing, tweaking and configuration ALSA, PulseAudio and PipeWire related tools and tweaking everything you can imagine. Nothing worked, no matter what happened, it never played sound through his speakers.
He asked me if I could come over to help so I did.
In 30 seconds I solved the problem.
I went to his sound settings in his desktop environment and saw that his sound card was being picked up. I looked at the back of his machine and noticed this card had 2 black ports with the bigger style jack for headphones. There was no usual green port which is usually used for output. I shined a flashlight to look closer. One of the black ports was labeled headphones and the other was unlabeled. His was connected to the unlabeled one. I swapped it to the other port and everything worked right away.
All of that to say, as a software engineer I have second hand embarrassment that a trillion dollars invested into AI didn't think to respond with "did you double check to see which port you connected the speakers to?". I asked him if AI ever suggested that and he said no, it immediately went into polluting his system with a bunch of unnecessary tools and chasing incorrect rabbit hole after rabbit hole. AI understands nothing.
Such a good example of this I encountered recently:
I was on a fishing trip. I asked the charter if he’d want to check out a free app I work on (https://oceanconnect.ca) in case it might be useful for his work.
I don’t know how people on the ocean use ocean data. I don’t really know what they want to know, or why. I wasn’t totally prepared for the incredible onslaught of questions and information pertaining to how people use the data or what we can do with the data, and it was so cool and exciting to get that perspective.
It was a good reminder that models are not the same as the systems they abstract, and knowledge to develop them has almost nothing to do with using them. This guy was a wealth of knowledge about how they use weather data on the water. In a sense, he knows more about the data than I do (even if he doesn’t realize it, or doesn’t understand it in its digital representation), and would be far better equipped to make a useful application for people like him if he could program.
I found myself thinking people like him could actually do amazing stuff with LLMs if they sat down and got their ideas out on a screen. I’d really like to interview people on the water daily some day to refine the product if we ever have the funding. That domain knowledge is highly, highly specialized and people know things you’d never guess after living in a complex domain for decades.
Product management is its own skill, and few true domain expects have it. Without some form of PM, the resulting software will end up a mess due to poor UX, too much bloat, etc.
I think AI is going to force most software engineers to pick up this skill in some form. Building is easy; knowing what to build is the hard part.
>> 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.
They can, and they are. You just don’t hear about it on places like HN because those people are not on this website. Which is why some people here make smug statements like “if LLMs are so good at programming how come we haven’t seen any useful apps made with LLMs???”
Things the domain expert on the author's example cant tell (from the top of my head):
- is the app is properly deployed - how will the release cycle be - is it secure? - can we run two instances of it without messing up the orders/routes/whatever? - will we spend 5k/month in vercel if people start using it - how will we notice service degradation - if we change the data do we have downtime? how do we schedule that downtime window. - where is the code stored? can the team access it? - how are new contributors onboarded? - does the app use credentials and where to store them? - does the app manipulate or store PII? - if the user refreshes the app does it generate a duplicate order/route/whatever? - if there's an upstream service are we making sure our timeouts are properly configured? - if there's an upstream service are we making sure our connection pool is properly configured? - do we have a max connection lifetime so that middleware like AWS NAT or ALB don't leave us with dead connections in our pool?
I think that makes the point clearly. Also it may explain why software developer jobs are currently on the rise despite SWE-Bench-Pro-Ultra-Magic has been maxxed for months now.
I find this take off. In general, LLMs collapse a bit of all knowledge work, including many domain experts. I work with domain experts often and it’s usually the most difficult part of the process. Now, I can ask an LLM the questions I need to design the system and have an agentic system help me build parts. And it works, quite well.
The places it falls flat is domain expertise that isn’t well documented, like specific business processes. Knowing something will fail because X in dept A won’t like it and will undermine it (politics) or some silly process I didn’t know about forbids it.
So it’s not domain expertise, it’s idiosyncratic expertise that shines these days. Knowing where things deviate from a domain or the standard and being able to adapt around that. Years ago there’s a group I worked with and I was at the mercy of about 3 people I could ask questions to in order to make sure I was doing things correctly because digging into that domain was time prohibitive. Now, I can sit down one evening and dig fairly deep into a domain. I can understand common practice, approach, acronyms, nomenclature, so on. I can find other popular competing systems. I can rapidly figure out what I need.
The same is true for software, agents don’t collapse software they help people build fairly usable systems but they don’t find the expertise a senior level engineer has where designs or implementations may fail in practice. The idiosyncrasies of software and software systems, especially in your very specific set of constraints you need to operate in that may deviate from the rest of the world.
> I work with domain experts often and it’s usually the most difficult part of the process. Now, I can ask an LLM the questions
And you will not notice the obvious errors in its answers to even basic questions, because you are no expert and should have really consulted with one.
When talking about their own area of expertise, almost everybody immediately notices the glaring faults. But then they are very impressed and take LLMs as gospel when talking about anything else. I do not get it.
How would you know the agent is correct in domain expertise if you’re not possessing domain expertise yourself?
Shallow generic domain knowledge is not really a helpful domain expertise, is it.
Lets take banks - knowing how banks work in general means little for that one specific bank who is paying you, which has different portfolio than most, different processes because everything is homebrew over decades of doing business and they differentiate from rest of the market in many ways and thats their key proposition, different data infra, set of internal apps, protocols and so on. There is no general llm knowledge you can distill in few minutes that would help you much.
You need to know your specific company, no way around it. In fact, to be proficient in those deliveries, you need to know those internal politics, processes, their quirks and so on, 100x more than some code fast delivery since this is majority of any bigger project. You need some reputation to get things done effectively.
This, for some time, won't be something llm can massively improve, unless those companies change themselves.
>> You need to know your specific company, no way around it
Of course there are ways around it. For example you can build the foundation yourself (which will cover the 80% that is shared across every company in that industry) and give users the ability to build the rest themselves inside the software. This type of abstraction-based architecture is how platforms like Salesforce took off and became ubiquitous.
"So the most valuable person in this new world is the one who has both skills because they can verify at both layers. They know the generated code is sound and they know the answers it produces are true."
This has always been true since the dawn of programming.
Cannot agree.
Whole TFA doesn’t take into account reason why software development was actually so valuable.
Single specialist in any domain is not that valuable. You may charge $200 for hour of his time sure. But to grow company you now need N specialists.
What software was doing was not making specialist obsolete replacing a specialist by encoding his knowledge - well many tried to do so but failed even in 80’s “expert systems”.
What software was doing was making it possible to structure specialist work, make it possible for a single specialist to serve more customers at the same time, make it possible to hand over work in a structured way to junior specialists, making it easier for senior to take over edge cases and spot check work of those junior specialists.
This setup allows company to not being tied to number of specialists to grow, this setup allows company to charge less per customer but take over more of the market share.
Whole premise that now each specialist will waste time dabbling in AI software development is ludicrous, especially if each specialist would be building his own tooling somehow.
That sounds more like the extractive setup of corporations like IBM, where return/specialist must be maximized against the number of clients that can be juggled simultaneously.
Whereas in larger technology firms, yes that happens to some degree, but only with the highest level specialists such as PEs, fellows, etc.
They are already so wildly profitable and valuable by the simple nature of computing itself: it scales second only to money with regards to compounding effects. Once you have software someone can use, it scales near infinitely to more users, thus value is extracted from the work of a single specialist for all time. No need to complicate it with trying to abstract work juniors can do (and fail) and then have seniors correct. What would they be doing in non-extractive firms?
Yes, but most people (especially a large portion on HN and Reddit) do not internalize it.
A SWE who has always worked in DevTooling companies will always be preferred by DevTooling companies over a generalist. A SWE who has always worked in AdTech will always be preferred by AdTech companies over a generalist. etc etc.
Software fundamentals - though useful - are table stakes skills at this point. No business wants to deal with the headache of on-ramping employees who have never worked in a specific domain or industry because it takes too long for a generalist employee to build the intuition needed to understand that segment of the industry.
> Software fundamentals - though useful - are table stakes skills at this point.
I'm having a difficult time even seeing what we're talking about here. I see "seniors" in our industry that don't know what I would call the fundamentals of programming or software development; apparently not all fundamentals are created equal.
And therefore there will be a huge knowledge gap as companies refuse to hire anyone who hasn't worked in the field for 5+ years and people who want to work in that field but haven't don't get hired.
Not really. Most people continue to remain in a specific domain from their internship days, and professional networks develop.
Historically, startups were the traditional path for a generalist to build domain expertise because most startups couldn't be picky with talent, but the market has changed.
In all honesty, too much fat did develop in the tech industry over the last 6 years. Traditional hiring pipelines (eg. Limiting early career recruiting to grads from top 10-20 CS/ECE/EECS programs nationally along with Vets and some grads from decent regional programs) still net good calibre talent worth their weight in gold, but others just aren't working out.
I'm afraid you appear to be contradicting yourself by saying internship in one comment and stating that companies don't bother with onboarding employees with no knowledge in a previous comment.
An internship is fine for onboarding becuase you aren't paying a FT employee level salary or benefits, and expectations are your hire is still learning but has some aptitude or interest in becoming a domain expert.
On the other hand, hiring a mid-career SWE who spent much of their career in one domain who is transitioning to another is a significant risk without additional social proof such as referrals where someone actually vouches for their skills.
> No business wants to deal with the headache of on-ramping employees who have never worked in a specific domain or industry…
The usual sickness. If you don’t train people to become specialists and just expect them to fall from the sky, it’s only a question of time until you run out of specialists.
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.
Exactly, plus you now have a new superpower with AI — the ability to dig into and ramp up expertise in mostly any domain. I’d say the article gets it backwards.
True that AI lets you get information fast an efficiently. But it might just make you feel like you understand, even if you don't have the kind of hard won domain intuition that this article is talking about. I certainly often get delusions of grandeur when I learn a lot of something and haven't yet suffered with it in practice.
Expertise is largely tacit knowledge, reading AI slop isn't expertise.
You can quickly get the "lay of the land" and discover primary sources which you can study. Learning from the AI, I agree, is rife with landmines.
Exactly. The software engineering domain is huge. I could code just about anything when I was 16 years old after 2 years of intensive learning... It took me an additional 10 years to learn to design software that is secure, maintainable, efficient and scalable.
> Notice which way this cuts. Pre-agent, the engineer had a path the dispatcher didn’t: they could go learn the domain. Slowly, painfully, by shadowing experts and reading specs and getting things wrong in production, they would build the mental model and then they could build the system. That path was the whole career ladder in a lot of fields. The domain expert had no equivalent path, because learning to build reliable software is years of work they were never going to do.
Okay, but I've always gravitated towards working on tools and libraries and back-end stuff; as much as possible, the domain for me is software.
A non technical domain expert might usually lack thought clarity. They might know what is right once they see it but they seldom know how to reach there, even with AI. They will write themselves into slop in 3 days.
The real moat I believe is the ability to hold the the problem in the head, isolate it and mentally design a way to structurally solve it iteratively.
Very few people have it. Much less common with domain experts.
I would rather bet on educating domain to the engineer than teaching a domain expert to architect software.
> So the most valuable person in this new world is the one who has both skills
This has always been the most valuable person. A skilled software developer who is also deeply experienced in their target domain is untouchable. They can always move the ball forward at some rate, assuming they're making any attempt at all.
It takes a really long time to absorb some domains. The most painful one I've experienced is the banking industry. It took me a solid decade in the trenches before I felt comfortable running a status call with a bank's operations staff without a babysitter.
I like to think of this as a sort of cube of capability. The X axis is technical expertise, the Y axis is domain expertise and the Z is physics (ai/tools/computers). The volume of this space is what we are interested in. Scaling up to a wild amount of AI capability with the best developers on earth (infinite x-z plane) is still going to perform like shit (zero volume) if you have no practical domain expertise available.
Specificity, availability and recency are perhaps the most important parts of domain expertise. None of these tend to be in ample supply with frontier language models. You can get a general sense of how a bank operates from chatgpt, but the FDIC would take over your bank in the middle of the first night of operations because you didn't learn the secret handshake (how to interact with your customers, competitors, regulators, etc).
Whenever I read articles like this one that appear to be very generic and give advice about dealing with AI, I remind myself that he software industry is like the construction industry.
It will never be organized, never fully optimized, and it will always be custom — because it has to cater to the reality of wildly different tastes, contexts, and localities. There may be some good tools, raw materials that show up once in a while.
As a doctor who learned how to program, I started by writing useless Chrome extensions. One thing I learned early was that programmers generally do not like learning the nuances of medicine, and many are quite open about how little they want to learn it. I have tried convincing my fellow residents to learn a simple language like Lua or even just Python, but the resistance is even greater, despite the fact that they constantly express how they have always wanted to learn programming like I did.
I even went as far as setting up their IDEs, configuring their environments, and encouraging them to just vibe-code. It seems that the mental friction involved in switching domains is too high for most people to justify the reward. Perhaps the reward itself is not compelling enough, or perhaps this is simply the limit of adult motivation.
I started programming with Python around the time GPT-3 arrived, when Cursor had generous free tiers and excellent starter plans. A few Raspberry Pis, laptops, desktops, and countless hours of tinkering later, I discovered how much I enjoyed solving problems with software. There is so much to learn from the programming world: the concept of open-source software, the idea that people from anywhere in the world can collaborate on the same codebase, and the fact that many do so with little or no expectation of reward.
As this post points out, in the project I am currently working on—a comprehensive Clinical Decision Support System—it feels almost second nature to translate the rules, hidden rules, social dynamics of hospitals, and the common mistakes that we and our juniors make every day into software. Taking those observations and turning them into systems that work is surprisingly intuitive.
Perhaps the most valuable thing I gained from medical school, combined with my own personality, is the desire to keep learning. I naturally gravitated toward systems thinking, and the path forward seems clear to me: become a true expert in whichever specialties I ultimately practice, while simultaneously becoming highly skilled at systems thinking.
As for systems thinking itself, I find it useful to create rules not only for the codebase but also for the testing harnesses and development processes around it. The goal is to build systems that can enforce quality automatically as the codebase grows, ensuring that standards scale without requiring constant manual oversight.
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.
Stuff where all the info isn't available online.
For example, I used to do integrations for sports betting sites. AI is going to help with the basics, like understanding the default puck line is 1.5 in hockey. AI is not going to realize that Bet365 changes their API endpoints for each season, so you need to be ready to fetch the updated ones before the new season starts, whereas most other sportbooks have consistent endpoints that you don't need to keep updating.
How much domain knowledge is actually unavailable to AI is going to vary by domain, as will the value of that. Chess is probably one extreme, where all knowledge is public, whereas something like military R&D might be the other extreme where domain knowledge is tightly guarded.
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.
I don't know how you can say application and experience isn't domain knowledge. If it isn't, I have no idea wtf we are talking about and I'll have to accuse you of moving goalposts.
You use websites a lot.
Should AI make you really good at frontend development?
Chess is a precisely defined mathematical problem in a fairly simple artificial world. Most domains aren’t like that.
I think this might be one of the worse examples of the dynamic, for the reasons already mentioned by others (programming a chess bot is really more of a programming exercise than a chess exercise), but it’s food for thought, so thanks for posting it. Some IRL domains are definitely more chess-y than others.
Everything is a programming exercise. Can a person with domain knowledge and NOT programming logic succeed. I thought that's what this was about. Ok, sure, AI is good at programming.
Writing software for which a full spec is available before you begin — in this case the rules of chess — was an easy problem even before AI.
There's no chess spec, it's not "solved" like it's just a matter of implementation. Chess bot programming wouldn't be a thing otherwise. I think it's really quite funny that you think this super complicated game is just some trivial programming problem. Try it.
It's easy to make a chessbot that only makes valid moves. Making a chessbot that plays optimally is hard.
But OP wasn't talking about solving optimalization problems, but understanding the rules of a business domain.
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.
You can say that about any domain. I'm done with this. What I'm hearing from people is that AI is only for programmers and is useless for everyone else. And it honestly seems to be that way.
>AI is only for programmers
As we now know it, AI pretty much means a language model and the product of programming so many times is thought to be completely represented by the output of a language alone.
On top of that programming languages are more structured and logical than average, so impact on other less-logical efforts (having more scarce clear-cut examples in the same huge training set) can be expected to be less drastic even if they are language-centric also.
It really is working so well for some programmers so far that that's got to be a big one, and possible to push closer to the finish line than lots of other things. And it really is huge "software" companies that are putting up all the big bucks, dwarfing anybody else who's focusing on non-programming languages, or even more rare, non-language AI.
Almost all the money is being put into their own domain, how else would they have the decades of domain experience to best gauge progress which is still needed, plus get the most positive reinforcement from the underlying math & logic.
There's plenty of momentum and critical mass of people already where if AI does turn out to only be for programmers, they'll be just fine with that if they can just make it more true than it is already. That's enough work to keep them busy for the foreseeable future right there.
Doesn't look like any comparable momentum otherwise, it's like a snowball vs an avalanche.
A terrible example, because chess is very, very simple - deterministic, rules fully specified in a few pages. We're talking about how you operate in a "games" which, among other complexities, involve the economy and human social dynamics. Billions of other agents. Find a plumber and try to beat them when someone calls you with a clogged toilet. Find a teacher and try to beat them when a student is repeatedly acting out.
Very well articulated for sure. But, I do think the word _'expert'_ always tends to do a lot of heavy lifting.
What looks like _'expertise'_ may actually be pattern recognition built through repeated practice. I do believe that is what a model can already do faster than humans.
So, to me, we've got to be cautious here in that what this post implies is humanity must strive to be in the 99.99th percentile of domain knowledge to 'beat' the model. This is perhaps problematic.
I do think focusing on judgement is the only tact discourse here, and I do think that is fine. Once we have invariance well-defined and covered in suites of various types of testing strategies, and are focused on regulation, wouldn't that be a more doable objective?
"the binding constraint has moved from can you build it to can you tell whether it’s right."
The company I work for is currently trying to accelerate internal AI adoption, and recently laid off people to help force it. As I've written here before, this merely pools accountability (not removing it) and things will break in unexpected ways as people are not domain experts in these new areas added to their jobs.
I wonder if we will see a large reversal in a few years, or if AI will somehow be able to fix this too
Until AI can take responsibility I don't see the accountability issue being solved, hopefully this doesn't just mean humans become responsibility machines.
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.
Markets, not individual businesses. Many Kebab stands are tiny businesses. The fan-out for retail is necessary.
The market is big.
> risk appetite, motivation, grit, and patience.
This is the moat. It was before AI and still is.
It was never about the code.
After spending the last 5 years building software for venture capital and private equity, this blog post really resonates with me. Writing code is by and far the _easiest_ part of my job; understanding the financial engineering and nuance behind what my company's customers need from us the tough part.
We always joke that we'd rather hire a senior fund accountants and teach them to program if we could, only problem is there just aren't any of these folks around. Teaching an engineer to understand the minutia of fund accounting well enough to build software for these firms is tough.
You are wrong. Writing programs (atleast efficiently) is not the easiest part. It just appears to be once you get accustomed.
Domain expertise is hard but not that hard compared to the insane mental discipline required to write efficient scalable code.
Domain expertise is valuable and hard but I don't get this "domain expertise is harder than disciplined coding" mentality.
Domain expertise is hard but not that hard compared to the insane mental discipline required to write efficient scalable code.
Not all code has to be efficient scalable code. I know some domain experts that were not programmers. They picked up enough Python or Swift + UIKit (this was pre-LLMs) and their applications are now widely used in their domain. In some cases, they contracted some software companies in the past to do the work. However, they did not understand the problem domain well, requiring the domain expert to iterate with them over and over. In the end it was more efficient to let the domain expert to learn enough programming do it with some guidance from experienced programmers.
Also remember that a lot of domain-specific apps do not need to be huge. E.g. I was once at a factory in the 90ies and they needed to do time-consuming calculations for a particular expensive machine. So, someone who worked at the factory wrote a small program in Excel + I think VBA. This accelerated their work extremely and probably saved them 10,000s or 100,000s in manual labor. It was easy for a non-programmer to write, because they knew all the details of the machine and the calculations, since they had done it over and over again. But it's not a enterprise web app or anything and it does not matter if the program runs in 1 or 4 seconds.
By the way, I also consider efficiency to be a specific knowledge domain, or architecting a very large project. So in the end it really depends on how narrow or wide your definition of 'programming' or 'coding' is.
A implies B doesn't mean B implies A. Not all programs have to be efficient and scalable.
But mental discipline required to write efficient and scalable code is insane that most domain expertise is feeble by comparison.
Seriously doubt you ever did serious financial math.
Coding is way easier.
> Writing programs (atleast efficiently) is not the easiest part. It just appears to be once you get accustomed.
Programming is the easiest part! (c) decade+ experienced senior developers
Right. If you're spending your time among developers to whom the code part is second nature, the differentiating thing becomes domain knowledge. If you spend your time among people of that domain who have no coding skill, to them it will appear to be the opposite.
I think there is some prestige factor in the background too. Being seen like some kind of code monkey is to be avoided like the plague. Business people really don't value the math savant engineer nerd archetype who just codes and codes.
Highest prestige is always taste and judgment, not correctness and skill. This is why people will also talk about how business soft skills, communication etc are more important than hard skills like programming, math, etc. I think one should be careful with this. On the one hand it's true that career progression is quite dependent on soft social skills, but there are also really hard kinds of software jobs where cognitive horsepower and technical experience are absolutely crucial and soft skills won't save you.
> Domain expertise is hard but not that hard compared to the insane mental discipline required to write efficient scalable code
"efficient scalable code" is just as vague as good code. How are you going to know your code is scalable if you don't understand your domain? Scalability is not something you sprinkle onto code.
Scalability stems from domain knowledge.
Sometimes you need two orders of magnitude. Sometimes you need five. Sometimes you need less than one.
Are you kidding me. What has domain got to do with efficiency and scalability.
Efficiency is about using minimum cpu cycles or minimum memory or minimum network round trip or more generically using minimum/optimum resources to get something done.
Scalability is about minimizing bottlenecks and linear scaling so one can just copy and execute by adding more nodes/resources and expect correctness and increased throughput.
Both of these have nothing to do with domain expertise.
To be fair, I'd consider hard-core scalability/reliability software engineering skills to be their very own speciality domain.
But I'd also claim that these things fall on a spectrum. At the extreme end we have exchanges and HFT-like trading systems, where absolute accuracy and latency are not even constraints but industry fundamentals. At the other end we have "toy" applications that handle tens of requests per second, tops.
Scalability problems are definitely near the extreme end. Only instead of raw latency, you get to deal with complex failure modes, throughput, capacity problems, read amplification and thundering herds... all the while being constrained by available CPU cycles and bounded memory.
> Scalability is about minimizing bottlenecks and linear scaling so one can just copy and execute by adding more nodes/resources and expect correctness and increased throughput.
Yes, technically, but note that this entire thing can be anything from crucial to completely worthless depending on the domain.
You need insane scalability for a social network or a streaming service, you don’t need any real scalability for (completely made up) managing a fleet of airplanes or the internal logistics of a zoo.
Writing scalable and efficient programs are extremely hard. This matters for serious projects but for small projects, honestly who cares.
> Efficiency is about using minimum cpu cycles or minimum memory or minimum network round trip or more generically using minimum/optimum resources to get something done.
No profitable business wants to pay you for writing code that uses "a minimum" of a resource. It wants to pay you to find the right balance between resource usage, time-to-market, operating cost, code complexity and probably several other factors.
I run a small profitable business. I avoid those who doesn't care about efficiency or scalability like the plague. Laziness shouldn't be promoted.
“Teaching and engineer to understand the minutia of fund accounting well enough to build software for these firms is tough.”
Sounds like you need a senior familiar with finance/accounting and a family to feed. Email me!
IDK, there's a tipping point where at best domain expertise without skill leads to a LOT of tech debt.
In fact about half of my career has been dealing with 'domain knowledge at least present enough to get the ticket/epic closed but leads to a lot of tech debt'.
i.e. a good portion of my jobs have involved a lot of a good amount of:
- Review PRs with a fine tooth comb because despite domain knowledge, people are human and can either don't know any better, make mistakes, or willingly refuse to integrate feedback, or worst refuse to double check what the coding agent wrote for them.
- 'refactor this thing because it was technically correct but written so poorly that it leads to timeouts and/or a Manager/DBA is screaming' [0]
> We always joke that we'd rather hire a senior fund accountants and teach them to program if we could, only problem is there just aren't any of these folks around. Teaching an engineer to understand the minutia of fund accounting well enough to build software for these firms is tough.
A truly good software engineer is able and willing to learn the domain, but there has to be a way for them to learn. I say that because I've been at shops where various levels did that (i.e. sometimes the company itself, sometimes the team, sometimes colleagues) and I've been at shops where everything is lip service and at best you can only glean from what's in the JIRAs and what you can glean from what people outside of IT say in meetings you are in.
> After spending the last 5 years building software for venture capital and private equity, this blog post really resonates with me. Writing code is by and far the _easiest_ part of my job; understanding the financial engineering and nuance behind what my company's customers need from us the tough part.
I think a big paradigm shift especially in the past 5 years has been that most companies are expecting folks to work to the bone, and it winds up being counterproductive because it prevents anyone from being able to have the important conversations.
Culture is a huge factor in this, I've worked at shops where at the very least you could easily have a side conversation or a meeting, and shops where you might as well sign a change.org petition to request time to talk about it properly.
Still, you are right at the crux; Requirements matter more than code at the end of the day. I've been at shops where a person's definition of 'Correct' meant a feature got delayed despite all requirements being met, because they didn't like they way it was written after they were gone the whole time it got implemented and the rest of the team approved all design decisions.
[0] - Next thing you know you learn about a 'batch process' has %numberOfRecord%*10 inserts, possibly with additional fetches given a poorly designed data model to where it is doing SQL upserts in the most wrong way (i.e. doing a get from the DB and then adding a record to be inserted if not present.) and they keep doing more and more questionable things to 'improve performance' rather than rethinking the data layer's query pattern. Seen it more than once in my career.
Tech debt is what most orgs/managers ask for. If nobody is complaining, there's no problem. Nobody but you knows what's behind the scenes until they ask for something new that the tech debt makes take longer than you think it should. But they don't perceive it that way, because they're probably not software people. They just see it as a new ask that will take a bit longer than expected.
Nobody cares about quality, if they can't perceive it. They want practical results. AI will give that to them, to some degree. Most people don't see software as deterministic anyways, so sometimes not working doesn't register as the monumental, show stopping, failure that it would me or you.
This sort of thing has Microsoft Access vibes about it. All AI is enabling is domain experts to spin up their own software systems with no understanding of how the systems should be put together.
Sure it lowers the bar, and some people will design decent things, but mostly these things will become mission critical and broken at the same time.
I work as an analyst, and our group has roughly 20% analysts with strong technical (software engineering) skills, and the rest are more traditional analysts / domain experts.
In the past year we've seen these non-technical analysts become more productive when it comes to developing internal tools, by leveraging AI models for the dev part.
Prior to this, pretty much everything was developed in Tableau. It was the most accessible way for non-devs to build working tools.
Just the other day one analyst in our group presented a tool he had been working on, which was basically a port of a tableau report, made into a more flexible app.
Our group is slowly replacing tableau with self built tools, with HUGE performance gains. I think these BI companies are in deep trouble, especially ones like tableau that make drawing something simple, like a histogram, near impossible.
But there's nothing stopping AI from developing domain expertise. If you fine tune a model based on the records of all previous work (effectively "shadowing" the existing workers) then it can easily learn this domain knowledge. The only difference is that AI companies have gone after programming domain knowledge first. Others will come later.
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
Eventually infrastructure will be more simple to orchestrate too without faults I suspect from well developed devops harnesses. The risk and scale companies are willing to accept will still fall on humans for some time even then. I don't see most people vibe coding a million user app that has deeper needs than the basics we see now.
> 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?
Long codex sessions lead to a lot of cached token hits, esp when you resume them after a few hours.
I personally don't count cached hits as $used... Neither in my harnesses, nor in the LLM-enabled apps I create. A cached token cannot be counted 1:1 as to a non-cached token, that would be silly.
Wait... when some Claude 5x/20x users say they are getting "$2000 of tokens for $100," does the 2k value include cached tokens, counted at the same $/token either way?
We cannot be this dumb as a community, can we? I must be wrong/misunderstanding..
I'm a fairly moderate user, never hit any kind of usage limits, but I used 44 million cache create tokens and 1.5 billion cache read tokens, which ccusage estimates would have cost $990, and calculates the different categories separately.
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...)
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.
But how is it even possible (bad harness?), or wise, to send 500k or 1M tokens per call? Regarding cache, how are you not hitting the 1hr cache? Also, start new chats early and often!
I have been "agentic coding" since Sonnet 3.5 and after this paper came out, it became my bible:
https://github.com/adobe-research/NoLiMa
Last I checked, all models suck as you fill the context window. "Context engineering" is how you do this whole thing.
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.
Domain expertise combined with a QA mindset could replace SWE, but consistent QA mindset is rare
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?
Who's got better marketing? Is it even a product that customers care about rock solid and performant? Which ones cheaper and has the least friction to getting started? Which one's CEO golfs with your company's CEO?
Time and time again, the market proves worse is better, from the format wars of the 80's and 90's, to Microsoft Windows still being dominant (and oh yeah, Teams). Sometimes quality does win, but if being built in 3 days means they can make a profit charging 1/100th the price of Z, I wouldn't count the cheap ones out of the game just because Z is better.
My comment was more "all things being equal."
Though the market so far has had a lower limit on "worse". We're finding out how low we can go before consumers start valuing quality again.
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 very recently 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:
items["latte"]["ingredients"] = ["water", "milk", "sugar", ...]
items["latte"]["has_milk"] = true
items["latte"]["has_nutmeg"] = false
items["latte"]["has_cinnamon"] = false
items["latte"]["has_sugar"] = true
...
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.
I have found this to be the case as well. As developers we are just really good stewards of the code because we obviously have knowledge to make sure that the code is engineered in a way that it can scale and grow without tech debt becoming unwieldy.
I found AI to be pretty bad with like a bare bones code base without solid patterns in place already. It works but it's just monolithic files galore. use effects hooks everywhere. Nasty state situations with poor data practices. Security vulnerabilities up the wazoo.
It's weird to have this conversion with them. Like yeah your code works but it's so tangled up it's hard to reason about where to start to begin to unwind it all sometimes.
It can be done but cleaning up someone else's slop is the exact reason why I hate AI. It was hard enough to review great code and be critical, honest, and fair but we knew it was an essential part of the process, helped build shared understanding, and was a way to learn from one another.
Whereas throwing in jumbled garbage to review just feels like a waste of our brain cells we spent decades earning by embracing the craft.
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.
> Domain expertise combined with a QA mindset could replace SWE, but consistent QA mindset is rare
I've heard this story at least 3 times already:
- Domain expertise combined with outsource could replace expensive US SWE
- Domain expertise combined with SWE could replace QA
- Domain expertise combined with SWE could replace infra engineers
Why is everyone so preoccupied with replacing someone with someone instead of doing their fucking job?
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.
The engineering part of software engineering is the hard part for LLMs. How is that replaceable with these skills?
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.
Kernel developer is not the job same as a game developer or an ERP integrator...
But Generalizations aside I think people greatly under estimate how rare is the ability to reduce complex subjects into concrete steps that someone else can follow, human or machine.
Go ask your grandma for a recipe you will find that it never turns out the same, giving her Claude Code is not going to change that.
Agentic coding favors senior generalists with a broad experience in many things rather than narrow experience in one or two things. I no longer think of myself as a backed engineer. That's what I was. I can do it all now. I've been building products and doing CTO jobs for a few decades now. I'm not a specialist in all layers of the software but I know enough about all layers of the stack to be able to do things with an agentic coding tool.
It helps if you can think at the system level and understand how everything is fitting together, why certain things are better than others, etc. Domain knowledge in multiple domains helps for that. That's what it means to be a generalist. And that includes having the prior experience with having built different types of software. Understanding architectural patterns. Being aware of pros/cons of different solutions. Etc. You don't have to be a specialist in any of this. But you do need to understand things at a high level.
Being a generalist equips you to enter new domains quickly. I've done lots of consulting on search projects in the past two decades. Every project is different. But the technology stays the same. I've built search engines for dating websites, maps, addresses, material scientists, art work, etc. Every project, most of the work is figuring out what the product is about. What good search looks like in that domain. And what they are doing that is sub-optimal that needs fixing. You can't work on search ranking unless you understand that. And you only have a few days to figure it out.
> Agentic coding favors senior generalists with a broad experience in many things rather than narrow experience in one or two things.
Is it? Agents are coming for generalists first.
I disagree.
Having worked across many disjunctive domains the value of "expert in domain" is greatly exaggerated. It's not like search engine doesn't exist nor that it cannot be easily absorbed. Quite often becoming expert is as simple as careful reading API documentation for existing, same domain system.
The piece is heavily one sided and don't recognize the problem of low reliability software: e.g. imagine a software designed in a way that it keeps critical piece of data as a global static variable. This will always work for a single user but will leak with two. Make it semi-critical and e.g. a part of profile loading.
Just as non-expert cannot verify if result is correct from a domain perspective, expert in domain cannot verify the output based on the basic principles (data security, safety, isolation, persistence, etc.) or even know that monetary values shouldn't be kept in floats.
Nothing like article claim had changed outside of a false promise of being productive.
Software engineers without domain expertise can fake it with unreliable results and experts without swe skills can fake it with unreliable results.
Nice idea, but engineers are engineers for a reason.
I’d suggest that the domain expert partner with a GenAI senior engineer to build together. In fact I believe this is the new dev team model. Domain Expert + Senior Engineer + QA. Not sure we still need a project manager anymore and we certainly don’t need scrum masters.
> Agentic AI severed the link between the two. You can now produce the software without ever building the model, and that breaks an assumption the whole profession was organized around.
Nah, we’ve always produced software without much understanding of the domain. It’s the premise behind lean: we don’t know much, so get something in front of customers and refine it.
So I don’t believe there’s been a strong decoupling here akin to the degree that understanding the code and writing the code has been.
From my experience what domain experts are often missing - and at least currently this is also an area where LLMs fail - is the ability to model data and interfaces in a sustainable way and factor in team and domain boundaries.
This is a failure mode that senior engineers have seen a few times throughout their career: They know how certain choices will play out over time... and the kind of problems and roadblocks these choices might cause.
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.
An idea that's beginning to solidify for me is that AI tools make software development harder.
It's harder because they dramatically raise the bar for what's possible to do. An individual developer can take on significantly more challenging projects now, because the ultimate constraint has always been time and AI can help you get more done in the time available.
But the stuff you can get done with that time is a whole lot harder. You have to understand lots more things, and get radically outside your pre-AI comfort zone.
It used to be acceptable to spend several days refactoring a codebase, or figuring out how to ship a small feature because it's in a part of the system you hadn't worked in before or involved learning a new library in order to build it.
Coding agents mean you can climb those curves a whole lot faster, but you still need to climb them - and the volume of information coming your way is much higher.
If you're worried about non-technical vibe coders taking your job, the correct response is to be much better at building software than those vibe coders. That means you need more skill, more ambition, and more experience. It's hard!
From that perspective, development has always been harder since I started. I left college with a copy of K&R and remembering courses that applied to real life immediately, because data structures and such were just what we had. In my first job, I ended up writing a code generator to help serialize a large number of data structures, straight from a compiler design class.. which right now you don't need to know a thing about, because serialization and languages with introspection are everywhere. The knowledge you need to be a professional engineer just kept going up through the last 30 years, while most of the basics became far less relevant, because the libraries just did it.
AI raises the bar again, as its probably at least as good as me, if not better, at anything I learned in college. I've spent years living off of random trivia from the last 30 years, as I saw computing grow with me. How do you know this?! Because everything built on top of it didn't exist when I was your age, so I had to learn it! But well, nowadays the AI is better at that trivia too.
The world moves, we do what we can with what we kno. It's not just programming, but what innovation and automation has done to the vast majority of things humans have done to be productive for each other since humans are people. We'll have to cope, like the guy that bred oxes to pull the plows.
> If you're worried about non-technical vibe coders taking your job, the correct response is to be much better at building software than those vibe coders. That means you need more skill, more ambition, and more experience. It's hard!
This is a false fear. The real risk isn't that some 19 year-old vibe coder is going to replace you, it's that there's simply less need for more experienced engineers. The market is shrinking.
Also, even if the premise behind the SaaSpocalypse is naive and oversimplified (companies aren't going to replace all their SaaSes with internally vibe-coded replacements), it looks reasonable that net-net AI will have a negative impact on the value of software.
> The real risk isn't that some 19 year-old vibe coder is going to replace you, it's that there's simply less need for more experienced engineers. The market is shrinking.
That last sentence is verifiably false if you look at SWE job postings and their recovery since 2022.
It’s also a poor take in general, buying very much into the narrative propagated primarily by OpenAI and, especially, Anthropic, who nonetheless continue to hire large numbers of SWEs while paying double the market rate.
> That last sentence is verifiably false if you look at SWE job postings and their recovery since 2022.
Source?
https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE
And it's probably worse than it looks because phantom job postings are a real thing.
> ...who nonetheless continue to hire large numbers of SWEs while paying double the market rate.
Tech companies have laid off over 200,000 people since the beginning of 2025. Even putting aside the fact that (from what I understand) over half of Anthropic and OpenAI's employees are in non-engineering roles, if you assumed every employee was an engineer, Anthropic and OpenAI could triple their staffing levels and it still wouldn't even fill a quarter of the void.
> That last sentence is verifiably false if you look at SWE job postings and their recovery since 2022.
Do you take into account recent layoffs of Meta (8k people), Block (4k people) and others?
I worry this is looking at where the ball is now instead of where it's going. The recent disproof of an Erdos conjecture should put to rest the idea that LLMs will reach a skill ceiling before they reach superintelligence.
I believe we are headed for a world of superintelligent AI where LLMs are much better at logical thinking than humans, the same way that chess engines are much better at chess than humans.
In that world there's really nothing humans can offer in terms of logical thinking other than their humanity itself. An 8 year old with Stockfish can beat Magnus Carlsen, and an 8 year old with Codex (and daddy's credit card) will be able to beat me at software engineering.
I don't buy that at all.
It doesn't matter how great the LLMs get, the act of creating software using them will still require a great deal of skill.
Most people just don't think in terms of software.
Try asking a non-developer in your life what their dream software would be for their work, or their hobby. If they don't have what Nilay Patel calls "software brain" I'd be surprised if they came up with something actionable.
(For more on software brain see "THE PEOPLE DO NOT YEARN FOR AUTOMATION", which makes the point I"m making here but much, much better: https://www.theverge.com/podcast/917029/software-brain-ai-ba...)
You could give a non-developer the smartest LLM in the world and they wouldn't be able to create GitHub with it, because creating GitHub requires an enormous amount of understanding of what software developers need from a cloud source control tool.
Sure, you can argue that the LLM "knows" what GitHub needs already and can guide their human-user to that, but why would a human-user who doesn't understand the domain ask an LLM to do that in the first place?
> Try asking a non-developer in your life what their dream software would be for their work, or their hobby. If they don't have what Nilay Patel calls "software brain" I'd be surprised if they came up with something actionable.
I've posted this in numerous comments because I think it bears repeating: there are tech-savvy non-developers who are actually building and shipping stuff with AI. I personally know a few who have been successful in acquiring initial customers.
You can say "but their apps won't scale", "their apps aren't secure", etc. and you might be right but these criticisms ignore the fact that most human-built software suffers from issues around scalability, security, etc. What AI in the hands of a relatively tech-savvy person is capable of is building functional, usable applications that are pretty decent compared to what you might get if you paid an experienced contractor tens of thousands of dollars to build.
A whole generation of young people has grown up with the internet, smartphones, etc. They might not be trained software engineers or have a "software brain" but in many cases they probably have a better intuitive sense for digital product design than a 30 or 40-something engineer who has been staring at an IDE for the past decade(s).
> there are tech-savvy non-developers who are actually building and shipping stuff with AI. I personally know a few who have been successful in acquiring initial customers.
It'll shake your world, but tech-savvy non-developers were building and shipping long before AI.
> they probably have a better intuitive sense for digital product design than a 30 or 40-something engineer who has been staring at an IDE for the past decade(s).
Because developers only stare at IDE 24/7, and never interact with anyone besides mother who brings tendies to their basement? What am I even reading?
> It'll shake your world, but tech-savvy non-developers were building and shipping long before AI.
They weren't building and shipping by themselves though. They were hiring people to do the work.
AI has made it possible for people with motivation and time to do what was previously only possible with motivation, time and money.
> Because developers only stare at IDE 24/7, and never interact with anyone besides mother who brings tendies to their basement? What am I even reading?
Why is so hard to acknowledge the fact that many of the people who are good at developing aren't as good at coming up with ideas for digital products and building businesses on them?
> there are tech-savvy non-developers who are actually building and shipping stuff with AI
I absolutely believe that. I think those are people with "software brain" who are on their way to becoming real developers.
By the point they can write apps that are secure and scale... they'll have learned enough about software development to be employable as software developers. They'll be part of a new breed of developer who never memorized the syntax of a programming language, but they'll still be at the starting point of learning a HUGE volume of other stuff that's necessary to build good software.
If we want to stay employed, we need to be notably better at building software than they are.
I agree, and I want to add that 'better' doesn't necessarily mean 'creates more robust, elegant, resilient software'. Better means from a business perspective. If we (I'm one of the people you're discussing) end up cheaper or more fungible, for example, we still might be worth hiring from a business perspective even if the code we create is shit.
I've also seen an assumption that you've made here that I think is worth drawing attention to and questioning: that the tech-savvy non-developers are starting from zero or near zero when it comes to programming and software development. Right now, that's probably mostly true, but I'm not sure that will continue to be the case. I'm not a developer (depending on how fuzzy we want the boundaries around the idea to be, anyway). I do understand the building blocks of programming languages (e.g. I can answer all the questions fragmede posed in a sister comment), the trade-offs between rolling your own and using existing libraries, the need to evaluate tools, frameworks, and languages to determine which is best for your use case, why version control matters, why access rights matter, why backups and a test environment are necessary, why it matters to write code another human can read, etc.
Do I understand as much as an active working developer? Absolutely not and I'd never claim to, but I'm far from starting at zero.
The reason for this is that I was raised by programmers. There are far, far more programmers and general tech nerds now than there were in 1988 (when I was born). Which means that in 10-20 years, there are going to be a lot more children, grandchildren, nieces, nephews, and so on of developers, and a lot of them are not going to be starting at zero. For pretty much of all computing history, there's been a substantial opportunity cost to developing a deep understanding of coding and software development: either a person has to be so into the domain that they devote a lot of their waking hours to it (usually in adolescence or young adulthood, when that trade off closes the most doors and makes developing certain other time intensive skills difficult), or they have to obtain a CS degree, which means not getting a different kind of degree and often incurring significant front-loaded financial costs. The opportunity cost for people born into programming or tech families is much lower. You can start younger and spread out the hours needed to learn across a greater amount of years, you can acquire knowledge in less time-intensive ways and while practicing other skills (e.g. my cousins also have 'software brain' and we could all hang out and develop those skills while also developing in person social skills), and you have a built in network of experienced people who want to help you + that can give you extremely individualized, personalized attention.
If what you suggest comes to pass, I think that one of the greatest threats to SDE as a career is going to be your own children and grandchildren.
> I absolutely believe that. I think those are people with "software brain" who are on their way to becoming real developers.
In my opinion, this is a software developer-centric way of thinking that reminds me of the saying, "if all you have is a hammer, everything is a nail."
Here's an alternative perspective:
For billions of people, technology products are an integral part of daily life. As a result, lots of people have an interest in building technology products, particularly software. Thanks to AI, you no longer need to be a "real developer" to build software. You can learn enough to build things that are commercially viable without seeking to be employed as a developer.
> If we want to stay employed, we need to be notably better at building software than they are.
While I don't believe that the market for developers will shrink to 0, unfortunately, I think this type of comment reflects the fear, existential angst and denial that has overtaken many people in this industry.
The reality is that developers are no different than all the displaced workers who came before them. One day you had a job that seemed secure and capable of providing for a comfortable life and the next you were facing the prospect of diminished wages and unemployment because the world simply needs fewer people with your skills and there's no way around the secular trend.
The sad irony is that when software was eating the world and new CompSci grads could take their pick of $150,000+ job offers before ever writing a line of production code, a lot of people in the industry had a smug "tough luck" attitude towards all the workers being displaced by the tech boom. Now it's their turn.
Maybe the tools are going to get to a point where this isn't true but today even with Claude Code at whatever at hand you're going to have to learn enough about software to basically be a developer in the traditional sense to deliver a multi-tenant application that has to deal with high TPS or whatever. At least at present you're positing there's no need for carpenters because the home gamer can knock together a table or birdhouse at home.
> ...to deliver a multi-tenant application that has to deal with high TPS or whatever.
There's a whole world of opportunity that lives below complex multi-tenant applications that have to deal with high TPS.
> At least at present you're positing there's no need for carpenters because the home gamer can knock together a table or birdhouse at home.
This is an extreme, straw man argument. And here's the thing: I don't know a home gamer who framed a house. But I do know tech-savvy people who have used AI to build web apps that they have launched and been able to get customers to pay for.
Not every tech-savvy person has the ability to do this but the whole "you can't do that if you're not a software developer" argument looks to me like a denial mechanism more than a reflection of reality. People are doing it because the AI tools have advanced to the point where they can.