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.
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!
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.
But yes - once it's that easy you have to step up your ambitions.
it used to be that i pay your due at some enterpise and learn some corner of codebase really well and become go to person. that would give you job security.
Now I’m basically expected to do what my boss wants me to do every minute of the day, it’s gotten much more micromanaged.
Before: "I learned very little this year, because I was placed in charge of the same stuff as last year, and I've already learned most of what I could from studying those systems and dealing with those recurring problems."
Soon: "I learned very little this year, because I don't really understand what's going on, they want me to pull the lever on the babbling slot-machine until I get lucky and things seems to quiet down."
This describes the expectation my managers had of me at every software job I've had, and I've been doing this for a decade and a half
It's definitely not a new thing since LLMs came around, if that is what you were implying
The vibe coders have a key advantage you don’t: they don’t give a fuck.
They blow through a task and move onto the next one. Management sees this as progress, and the vibe coders are rewarded.
When shit breaks later on down the line, and fires have to be put out and things rewritten, the vibe coders do NOT get the blame. They do NOT get punished. Most engineering teams operate on a blameless culture. If code was approved for production, then it should have been good enough. Vibe coders will keep on doing what they do, and skilled experts will be left cleaning up their messes.
For anyone who actually cares, it’s over. You are not steering development anymore.
We've had plenty of technology trends in the past that have promised faster development but has later turned out to have problems. Organizations that stick around learn lessons about what works and what doesn't.
If in a year's time organizations aren't feeling severe downsides from all of the unreviewed vibe-coded junk they put into production then maybe the vibe-coders were right. I'll believe that when I see it.
The vibe coders aren’t “right”, they just get lucky.
Here’s a secret: I haven’t really bothered reviewing any PRs since September of last year or so. I just click approve and don’t even read it. It has been way less stressful for me.
Do bugs get through? Sure. But someone will just come in and vibe it out anyway. And I have yet to see a vibe coder or anyone who approved their flawed work get any repercussions. So yea, it doesn’t matter.
No one’s going to come after you asking “why did you approve this shitty PR?” And if they do you can forward it to the author and ask why they wrote a shitty PR. But that just doesn’t happen. It doesn’t matter.
Now with LLM tools, what you got is a slew of projects their creators aren’t even interested in. It’s theater.
This weekend I'm playing with a SwiftUI MusicKit player (everything I'm doing lately has been Swift/SwiftUI, itself a radical change from just a couple months ago when everything was a TUI, and then a few months back from that and all the way back to 1993, when everything was a CLI) with a Responses API hookup that turns the player into an agent, with tool calls to let the model see what I've been playing. "Keep a continuous queue of music playing while I'm working in the wood shop".
Worked a treat. I'm genuinely interested in where I can take this. I have a real problem, one that's been annoying me since ~2000, which is that I "own" a lot of music but find myself stuck in an epicycle of the same 200 songs. Problem solved-ish. I never, ever, in a million years, would have built anything like this before.
It's really hard to sell me on the idea that nothing profound has changed here in terms of the projects we now pick up. Go build an operating system. I'm serious! Claude will practically one-shot it. Mine has smoltcp hooked up to a Rust virtio-net driver Claude pulled out of its butt.
In 2018 I witnessed one guy with no prior coding experience who built a tool that after a month of coding was making very decent money (more than me), just because he was aware of a particular niche.
He showed me parts of his code and it was as bad as my first program, but his was solving a real life problem.
My best effort, so far, at an analogy is a modern drill driver compared to a screw driver/brace and bit/etc:
You can get some remarkable results in a very short time compared to the "old school" gear.
You can get some "amazing" anecdotes eg "I screwed down an entire floor at 16" x 1" c/c within an hour instead of an entire day and I took loads of fag breaks" (I could have used a nail gun instead in half the time but I'll never raise that floor easily in the future, and probably done at twice the cost)
I have several on prem LLMs and access to the rest and I'm pretty sure I'll be extending my analogy to ... brand, eventually.
What I do not expect to be doing is looking for a new job. A drill driver is not a carpenter/site labourer/useful without a person!
cc -> local automated testing -> github -> PR -> heavy integration tests -> review (github ui, +/-) -> manual test locally -> merge -> deploy -> manual test remotely -> synthetic user testing -> repeat
I've never used breakpoint debugging, was always a printf debugger. And now an agent can do that loop for me.
Prompt is usually something along the lines of:
>I would expect the behavior of this to be [X] - instead I'm observing [Y]
And the agent will form hypothesis, place printf statements, compile, and scrape logs on loop - each loop ruling out hypothesis or narrowing down what portion of the code is responsible for the unexpected behavior.
It has been able to pin-point the exact line(s) of code responsible every time I've reached for it so far.
From what I've seen they're more likely to run a python -c "import your_code; your_code.do_stuff()" experiment to figure out what's going on though.
Tests stick around and prevent future problems, whereas the debugger only shows me something once.
https://mastodon.gamedev.place/@JeremiahFieldhaven/116654345...
In other words, there won't be 20-year-old code in this future.
We'll see if that comes to pass, but there's a lot of money betting that will happen; enough to where people will disregard what the downsides are.
We are going to see a new generation of models which effectively “solves” these problems for most businesses. Likely within the next two years- then we’ll talk about some other problems which limit adoption.
Don’t quote me on this, just trying to make a point:
They’ll say you need perfect symmetry to do well in sports, which is highly correlated to development stability in the womb; higher symmetry = perfect development.
Then after some years, news will come: Bruce Lee’s one leg is shorter than the other by a significant amount, and Usain Bolt has a similar asymmetrical development.
Then they’ll flip-flop around their initial argument by claiming that they are outliers so the general rule need not apply.
brother just build what you find interesting and it may work :)
Little thing to keep in mind about AI: a technology is only called AI while it doesn’t work yet. Once it works reliable, we give it a proper name and something else becomes AI.
If that's true, any statements defining what is necessary to do should be ignored in that context. I'm still interested in hearing about what people tried, what results they think they saw, and then trying to apply those findings to my own processes.
Which is to say I don't think the pontificating is pointless, but as statements of Real Truth, I agree they're likely wrong. We're too early in the game.
For new construction and commercial work the moat is a contractor's license. They don't allow LLMs to take the licensing exam yet.
"don't want to buy tools, and don't want to get shit on their hands"
Thats closer to the truth. The rest of your post is fluff. Its pure economics, not rocket science.
Someone needs to spot when a linked list is better than a map. And the other needs to spot when clinical trial coding should happen before claims, audits, or patient outreach.
if nobody has any idea what to do, talking about it is the right approach
> How much pontificating needs to be done before people acknowledge nobody has any idea what to do with AI on an individual level?
I explained the idea of what I do with AI on an individual level. Hope that helps.
What type of software do you produce?
Search
It's reading my requests more clearly than (for example) Google's search input ever did, and it's got (some) understanding of how close the result (or fragments of results) are to what I want.
I can ask it about things I know about, and it can answer with strategies I hadn't thought of.
HOWEVER - I still need to understand the results AND AI can overreach - it can say (figuratively) "Oh you are searching for Event handling, therefore I will write a orchestration saga" - which, if I am not across, can get us both in trouble.
Further, we KNOW that AI has no (real) understanding of the responses - it's just token adjacency - and it fails basic logic tests
Current AI is just awesome natural language processing, but it's still got a ways to go to where I would say "It can replace people"
Edit: LLMs demonstrate (almost perfectly) the difference between correlation and causality. LLMs identify correlative patterns, but the job still needs (us) to make the causative judgments.
I see this take a lot and it puzzles me.
While I think LLMs provide some advantages over traditional search in some modestly nontrivial contexts, they tend to be inferior to traditional search at its peak. I attribute this attitude to two things: the broad progressive enshittification and productization of search, and the fact that (re)search is a skill that most people tend to be bad at. Without massaging, LLMs spit out the most utterly braindead boneheaded queries, which are fine in cases where the problem is very well understood with minimum uncertainty or critical nuance. If your problem has either, God help you. But perhaps those queries are at least as good as the average human generated query
AI has changed how I find and synthesise information in ways Google never managed - we've always had the problem with Google that we couldn't express exactly what we were looking for - that much I think we can both agree has changed dramatically for the better with LLMs
Edit: I have always held that searching for an answer (whether it be internet or human) has always been about asking the right person, the right question, at the right time.
LLMs most certainly improve that - I don't need to know the exact technical term I am looking to solve in order to get the results I want (eg. I can ask how to "stop (a) function from running too many times" instead of the industry terms "throttling" or "debouncing")
But because the result sounds right (and in cases with good data it actually is) people tend to trust it. I do not dismiss the potential, but for me the line is crossed when you take the result for granted without verifying and while I'm sure many here think that is implied, I bet you, at large, it is not and will be even less so in the future.
Brave New World!
My observation on AI is that some frankly less intelligent folks think they don't need smart people any more because AI makes them smarter. I disagree.
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.
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
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.
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?
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..
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...)
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.
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?
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.
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 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.
Probably similar to hand writing notes (while digesting + synthesizing and not just being a scribe) vs reading notes somebody else took.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
This is the moat. It was before AI and still is.
Meanwhile, as a generalist who has a basic understanding of general things, everything from how to design efficient network protocols, to how cache lines affect the performance of sorting algorithms, without being a real expert in any of those things, I act as a constant course correction for AI agents doing work on my behalf, in a way that LLM context windows simply cannot replicate.
To give a concrete example, I recently used agents to build a specialized sync protocol that broadly resembles Dropbox. It's nowhere near as efficient in terms of how blocks are synced (because it entirely happens on a LAN and the cost difference is minimal), but I constantly had to make objectively more valuable course corrections on how the sync actually traversed the participating nodes. If I'd just let the LLM drive, it would have come up with a reasonably efficient algorithm (better than I probably would have done on my first try in the same timeframe) that would have had an obvious (to me) single bottleneck.
Using AI to more rapidly learn a domain will help in the short term
But in the long term, all moats will evaporate
One of the things I say is when I’m on my soapbox is: we are all engineers. We have different tools in our toolbox to solve problems. We get paid to solve problems, not (for example) write software. Software is just a tool.
Writing software has never been difficult. It is the domain that has been the issue. Always.
That's not true at all, sure CRUD might not have been that difficult, but absolutely there is extremely complicated software out there that is really difficult to write in a performant and correct manner.
That too is "domain" even it feels like it is NOT. Domain of signal processing, Euclidian spaces, information theory and what not. Thar too is all "domain" and that "domain" part is difficult to write.
It just does not matter. The ideas matter. Novel functionality matters. But that isn't what any of that is. Same old. And the effort spent, the resources, the energy. All for more polygons on Lara Croft.
For well funded organisations, ISDN video conferencing facilities were reasonably common.
Mordern GPUs are streaming multiprocessors. Complaining that GPUs use a ton of resources is like complaining that a firehose uses a ton of water. Maximum data throughput is the point!
>But that isn't what any of that is. Same old. And the effort spent, the resources, the energy. All for more polygons on Lara Croft
There are MANY novel games being released every year. It's up to you to find them.
I was a developer for 20 years, before I pivoted to cybersecurity. My hobby projects were always more complex than the software I wrote at my day job.
The majority of software developers are writing some type of CRUD code or glue code for business processes. A small minority are writing complex code at big tech companies.
AI will most likely replace the need for many software developers.
For example, it takes years to develop the knowledge and idioms required to effectively write high-performance systems code, which is separate from the language the code is written in. You can have decades of experience in a systems language and zero experience writing modern systems code in that language. Same with embedded code, supercomputing code, etc.
Writing software is only "not difficult" if you've already learned how to write it.
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.
It takes a LOT of time to validate every path, possibly an infinite amount of time, depending on the complexity of the domain.
I don't think that's the moat.
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 say this as someone who uses AI a lot. Its still a far cry from cheap, especially with that pesky “working” word in there.
I am still bothered that domain experts still keep confusing closing orders with generating a delivery note, or stopping to say articles when they mean a product or a product when they mean an item.
Writing good specs require lots of domain knowledge but a very engineeristic approach these people just don't have.
revelations never stop coming do they
If the inputs and outputs are only and exactly those of the domain, sure. But software is more than that. And your logistics operator (or my actual work example: our extremely talented designers with deep understanding of our product) can validate parts of the agents output, but the rest of it they can’t and it makes a mess.
I’m sure this will change, but it hasn’t yet.
The more analogous question is: as a civil engineer, could you tell which structure was designed with the help of a civil engineer, and which was designed by a domain expert (e.g. a transportation administrator) with automated civil engineering?
Not yet.
We won't be there until AI is more like a virtual person, where the domain expert trains the AI in a similar manner to training a real person.
At this point, agentic coding only eliminates the engineer when creating very simple applications. Once the application gets complex, either the domain expert needs to become an engineer, or an engineer is needed.
That person has zero skill in actually making tight automation that doesn't just fall over. And I have yet to see an AI agent that tells them "look, your requirements are contradictory, given this and that, these two cannot coexist".
Those little sycophants will just go and try to please the domain expert and placate him in all ways possible. Bend backwards rather then forcing them to reassess their assumptions.
My suspicion is we are still moving up along a continuum of capability.
Models didn’t used to produce coherent sentences (GPT-2 era) and now they can. Past models (GPT-3 era) made syntax errors and now models can write well structured code. Past models didn’t reliably emit correct syntax to request a tool call, or track context across multiple tool calls - and now they can.
Frontier models can’t write code without glaring security flaws, even as they already follow other best practices. So on those two criteria of code quality we are still in need of models improvements.
All these forms of correctness lie along a continuum. Today’s models can’t assess what’s needed in a domain for work to be “good” - but if current trends hold it’s just a matter of time.
If you have particularly specific knowledge in pretty much any domain, combining that with AI can lead to huge gains.
It's absolutely true that domain knowledge is incredibly useful, and developers aren't always great at gaining it. But there's also something about decomposing systems into their component parts, understanding algorithms, and knowing how code works that's also incredibly useful, even with agents in the picture. A really good developer needs both of those skills.
Take that example, of the generated shift that's illegal (by coincidence, I do freight optimization and work with examples like that in my day job). A domain expert will know the specific example is illegal. So they'll tell the agent to fix it. The agent will probably fix it for that case.
How does the domain expert then know that the agent has produced a thorough fix, as opposed to just that scenario? Not because the agent says so. So it is because they test it manually (but which cases)? Or because they review the strategy of the agent's tests, and know how the algorithms work, and know the edge cases that the tests need to cover? But they can't do that, by stipulation, because they're not experienced with code, they're just using the agent.
So yes, if the agent gets to the point where it can design robust software that avoids edge cases in a complex domain, doing complex operations and is thoroughly tested, and so on, then half of my skills are going to be irrelevant.
Out of the box, agents don't do that today. Perhaps they'll get to that point, but until then, your knowledge of where to put a semicolon has become less useful, but your ability to specify and test processes precisely has not.
But yeah, knowing your domain well is a damn good idea.
Yes, and its price law all the way down to the metal, hasn't it always been?
I think this article is stating the obvious. In software, it has always been a requirement to learn the domain, and then capitalize on that in any way the software can be written (by hand, as a tech lead, or managing others, or lately, using ai).
So far the evidence seems to be pointing to a different adage, Sutton's Bitter Lesson, which (generalized) says to not bring human expertise to a problem that can be "solved" with unfathomable volumes of data. Because the latter has historically slaughtered the former for decades. But somehow people believe this time it's different?
I will counter there is one thing that is a persistent moat, and it's not domain expertise; it's sales. Convincing other humans to part with their money. Humans have shown they will trust a person/human touch to part with their money more than an AI.
But I'm not convinced today's AI or tomorrow's won't be able to replicate domain expertise in domain X for any X.
They are already significantly better than humans at persuasion (according to a study from Princeton).
What do you mean by this? Most human white collar workers still have their jobs. I can't see the future, but yes, so far, human expertise is doing ok.
We'll see what happens in 2027, and 2028, and...
Successful software results from the intersection of expertise in two domains: the application domain, and software engineering.
They really do want to know the ins-and-outs of the HVAC service business, for example, because they hope their agents will be handling it in a few years.
If you ask me and a logistics dispatcher the task of building logistics dispatching software (whatever that is), I will get there first.
Much ink has and will continue to be spilled over this simple and obvious truth.
But that was never the hard part!
Come now.
After twenty plus years as a professional software developer I can name two hard problems, not more. One is related to the article, the other is not:
1. Getting that clear idea out of a stakeholder's brain. Traditionally this would be a specification but doesn't need to be that formal. Remember, remember the first panel of https://i.redd.it/i2aeyrivmjoz.jpg An LLM doesn't help here because it doesn't push back. It'll do whatever you tell it to do even if it's not what you really wanted. The software developer here operates very similarly as a translator and it always has been true a translator who speaks both sides well will be able to do the highest quality work. This is not at all new. It always has been the advice that if you know things like, say, logistics and software or any such pair then you'll be well off financially either because you can do this translation well or because you realize what's missing and can do a product for it.
2. The other problem, of course, is debugging. Since LLMs fundamentally work from a training set any debugging problem not blatantly obvious to a sr developer is hopeless for them.
With my sincere apologies to the author if I'm wrong, I'm pretty darn sure this was written by AI.
Guys, c'mon. I don't get it. It's one thing to have an AI write code for you, because code is ultimately functional. At least in the general case, the primary purpose isn't to express an idea.
Prose is different. Your writing represents what you think. You are your writing. Why would you outsource that?
I don't get it! Unless you're a (cheating) student, or you're writing marketing drivel.... what is the point? Just don't write the blog post. It's okay. Telling the robot to write the blog post doesn't accomplish anything. I don't care what a robot thinks!
I'm sorry, I'm just getting really tired of AI generated articles on Hacker News. Please, please don't outsource your own speech.
What’s the truth, though? Are we still relevant?
My experience is that three years ago, when this kind of AI work first started becoming usable, I had to talk to the AI a lot. I had to review a lot. I had to change a lot.
These days, I talk to the AI less and fix less, while the amount and quality of the output we make together has gone up and the time required has gone down.
That suggests to me that AI is like a coworker coming up through the ranks. At first, it was like a capable, hard-working junior: useful, maybe even like a small team, but still making lots of mistakes and needing a lot of communication. Now it’s mostly on board. It almost always knows what I’m talking about, but not always. I have to fix less, but taste, architectural judgment, and domain knowledge still matter.
I’m aware of the value of my domain knowledge in browser instrumentation, and the nuances of CDP commands that may never have been documented anywhere. The commands are documented, but their quirks, behaviors, and the way you can combine them to create a working system are not. I can still suggest things to agents that help them.
I don’t know if that gap is closing. I do know that I’m learning less new domain knowledge because I don’t have to be in the code as much. But I also know my hard-won technical nuance and architectural lessons still matter. Maybe agents will eventually be able to hit iteration repeatedly until they figure all of that out. That seems more likely as they get more capable. But that’s still a hypothesis. I haven’t seen it directly yet, just a vague sense of where the capability is going.
With advances in memory and the models themselves, I don’t see why they don’t end up with something like that. And I agree with the top comments: the goalposts are always moving for the people trying to redefine their own relevance in a changing world.
The main pattern I’ve noticed in myself is that I spent years, really a decade, chasing down random bugs in the web platform, JavaScript frameworks, and browser instrumentation. I was very deep in that for a long time. That helped me build the products I built.
But over the last three years, I’ve started growing in a new direction: big-picture business, go-to-market, sales, and marketing. I guess that’s adaptation. You spend a decade building technical IP assets, and then you can build more of the same because you have the domain knowledge, while working with agents to massively increase the speed of production.
The situation feels analogous to having hired a small team of capable juniors three years ago who have now grown into A-players. If that had happened, we’d have the capability we’re operating at today. It’s just that we’re using AI and paying a lot less for it.
That’s my experience building a set of large, highly nuanced technical tools around the web platform.
AI changed the shape of my company. I migrated into a role where I’m not just doing the taxes every year or writing all the code myself, but thinking seriously about marketing, GTM strategy, and sales. For me personally, my evolution is in that direction now.
That doesn’t mean I’m not still growing in product sense or technical judgment, but it’s very different from the deep technical stuff I was in before. Now I’m freed up to focus on other parts of the business.
A fun benefit is that I get more time to rapidly build things that interest me: little side bets that may just be fun, or may actually become cool products.
The transition into sales and marketing is new to me, but I welcome it in 2026.
I think AI may be easier to deal with if you have your own small company than if you’re watching it affect your job inside a workplace. I’m not sure. I’ve heard people say good things about that too.
I’m not making an argument. I’m not trying to convince anyone. I’m just sharing my experience.
Knowing the caveats and pitfalls of this through years of (often-painful) experience is what, at least for me, allows me to preempt a lot of the sloppy assumptions or omissions that even the frontier models make when working on systems at scale. This means I can leverage my domain expertise on these high-level areas while delegating the grunt work that is harder to screw up to the agents. I find this enables me to work faster while avoiding the slop making its way into critical engineering decisions.
so it takes a domain expert to remove unnecessary things, similar to how stone carvers create by removing material, not adding
Knowing "too much" and not knowing what belongs to the core and what is a secondary detail is exactly a lack of domain expertise.
The problem is that more and more people are getting convinced by the AI's that they're domain experts when they're really not.
The work product probably offends real software engineers in the way that a normal home cooked meal would offend a Michelin star chef. Yet, before last summer, these people never contemplated the ability to cook their own meals before. The fact that they can do this now is a very big deal.
anthropic is making billions of dollars proving how little domain expertise matters.
the philosophical route towards understanding how little domain expertise matters would take paragraphs to write...
My take is much less charitable. I think a lot of senior devs are lonely and enjoy talking to chatbots all day. Saying it amplifies their productivity is a justification.
But they know nothing about the scaling, performance or maintenance of a system that will inevitably come up in production.
They also can't tell if the code created is maintainable, or unmaintainable sphagetti code.
What happens if there is a race condition, or a memory leak?
So AI can easily replace the domain knowledge of software engineers but not of evey other profession?
Coding is not engineering but I'm glad that we will finally be able to prove that definitively thanks to AI. It's going to be a bumpy ride.
Any software engineer who has built software to solve domain problems in multiple industries knows that the engineering domain knowledge and systems thinking approach is far more difficult to attain than industry-specific domain knowledge... This is why there are software consulting firms which can work across multiple domains. Understanding the problem domain is not that difficult.
Now these skills don't matter as much because LLM's/Cloud/Java abstract out these problems.
What makes domain expertise a different category itself that lends it to be not automated out by LLM? Example: Why can't I go to into an agri-startup and become better than anyone else by querying an LLM even when I have no domain expertise? Much the same way I beat the dev who was good at DB internals?
That engineer still is indispensable. Any organization foolish enough to replace such a person with an LLM is going to find itself in deep water when the pile of hallucinations becomes too much to endure.
The only moat is that there is so much more work for domain experts since they and many of the bureaucratic processes in between aren't the bottleneck anymore
I think it's important to be clear on what's really happening. Companies were accomplishing 5% of their annual plans, and now they're taking a realistic swing at all 100% to likely reach 20-25%. It's a crazy amount of work, for the same specialists and more human workers.
if you’re actually building these things, you know they and the CEOs they’re hearing from are all 6 months behind. the executive’s frantic pivot to shove “AI” down everyone’s throat didn’t pan out in one quarter and had nothing to do with the actual concept at all
that, and every industry is different. I wouldn’t listen to analysts, I’m in an industry that even Anthropic thinks wont be touched by AI (even though they can read ours and everyone else’s sessions)
all public discourse is just flat wrong, and just like every week this year, you’re just going to wake up seeing a new AI capability headline that makes you question your role in society. So play devil’s advocate all you want, the silver lining is that there’s more work to do than ever before and more of it can be tackled at once
Edit: Yes "expert" was too strong a word. Proficient would be better. A lot of the barrier to entry in a field is just not understanding the domain.
I've consulted for and led large teams for real estate title insurance and escrow companies for many years, and the domain expertise is so incredibly deep, nuanced, and multivariate (especially depending on jurisdiction) that building valuable and viable products in the space is incredibly difficult - before LLMs, and even now, with LLMs.
Without getting too deep into it, I'm pretty bullish on AI (and have been very close to it and deep in it for a long time, while also very apprehensive about the effects it'll have on society), and I can tell you, from extensive attempts from myself and many on my teams to leverage the latest frontier LLMs to bring deep domain experience to bear to help drive valuable products: we have not yet seen success. It's not helping engineering folks, it's not helping product folks. It's creating a ton of questionable output and hasn't resulted in real ROI, and it's not capable of accurately answering deep domain questions without hallucinations or assuming what works in one jurisdiction works in all.
I've seen success in many other areas, but not this domain - and, importantly, the regulatory environment in which title insurance operates is incredibly complex and strict, meaning you can't just YOLO LLM output into production (as much as we'd love to try so we can learn at a faster clip).
And the kicker: we've found the way for us to build the best products is still going out into the field, sitting with escrow and title folks, watching them work, asking them questions, and designing for the real world, the regulatory nuances, the local client nuances, etc. You can't get that from an LLM.
I work in e-commerce and warehouse management.
We have put lots of effort at documenting the domain, creating precise unambiguous language, glossaries, E2Es written as user stories etc, etc.
And still models are simply not able to translate Jira tasks to clear specs, even for this well understood and common use case.
Also, they don't understand how changes in one part of the business domain will impact other parts. They can get it right 9 times out of 10, but even that is too little and compounds to deeply wrong implementations.
And they don't understand or know the people involved in these processes and what they REALLY care for or what the real priorities are. Very often political.
And that's not even mentioning the code, that ends up with the lack of proper abstractions or harness.
Or the lack of push back against bad ideas at business or code level.
AI is, at best, as useful as those masses. Actual discoveries, actual novel software, actual human advancement is beyond AI and the domain of the same humans who've always advanced technology.
So yeah, AI is ok for copy-pasting the same shit that we used to plug together web frameworks for, it's fine for internet research (Gemini for me is like a supercharged Google with no ads or SEO garbage), it's fine for repetitive emails and making my "fuck you" emails sound professional, but actual expertise isn't going away any time soon.
Also, I disagree that software engineers can "just learn" non-software domains. If there's one thing I've found about most people who call themselves "engineers", it's that their thinking is way too rigid for many other domains.
I’m tired of these endless articles on HN about software engineers trying to reinvent their identity while trying not to lose touch with reality.
One way of dealing with LLMs is to deny the skill level of LLMs. Claim they can’t code as well as you. This excuse works to a certain extent but it also fails because not only are their multitudes of cases where the LLM IS intrinsically worse than me… but there are multitudes of cases where it is better. So this excuse cannot be universally true.
The other way is to claim software engineering was never the hard part of engineering and that other things were harder and that was always where your primary skill was located. This excuse is also idiotic. First, Software engineering is hard. It is genuinely not something that anyone can pick up very quickly. Second, all those other “skills” like “domain expertise” are STILL targets for the LLM. It’s not like the LLM exclusively is only good at software.
Just face the goddamn truth. AI is on a trajectory to dominate. That’s what all the trendlines say. It’s not currently dominating, but it’s close, and the trajectory points to an endgame where it is fundamentally better. The trendline could be wrong but the trendline is the best quantitative predictor we have and it’s been trumping all the half baked theories on HN where people were claiming self driving cars would never happen and AI could never code. HN was historically wrong… the trendlines and the VCs who made those bets have been right. So who’s the bigger idiot? Those VCs creating the AI bubble or HNers who have been continuously wrong about everything? (Minus crypto, HNers were right about crypto).
If the trendline is true our skills as engineers not just the software part is on track to being dominated by an artificial intelligence. The tools trivialize your skills until all the moats are gone. Not only that… AI is becoming better at art. Poetry, writing, paintings, music… AI shows us how trivially reproduceable all of it is. That is the truth. We aren’t not unique and all the meaning behind being human is just an algorithm. It’s all reproducible. Even your self delusional attempt to deny and delude yourself away from these truths is predictable. I can see someone formulating a retort right now.
Even people whose job can't be done by AI will be impacted because there will be far less demand for their services (everyone whose job IS directly AI replaceable will be a brokie) and there will also be far more supply of people moving into their field to escape all the jobs AI does directly replace.
"Join the trades" is the new "learn to code" in terms of seeming like good advice but having a very short shelf life.
The trades are great, but not a panacea. Maybe emigrate to a country with better conditions for the working class.
Why do you think people get trained by a PT in person? Its not simply training - it actually goes well beyond into the realm of 'wellness'. man you are a certified bozo.
It takes a lot of balls to call me a bozo when it's obvious you're the one who's an idiot.
Have you?
I still drive my car and self driving cars have yet to displace human drivers. I think the sentiment on HN and other places when Google started talking self driving cars circa 2009 is that it's harder than it looks. Typically the first 80% of progress is easy and the rest isn't as easy. We're almost 20 years after a "pretty good self driving car" and we're still not at "self driving cars outperform humans under all situations".
Today humans use AI. You can't fire up Claude and ask it "what do you want to work on today". The amount of context we have as humans is vastly larger than the context LLMs have. If you give LLMs vague context they're completely lost. They are mind blowing in many ways but they are not anywhere close to AGI. They're also not close to being able to build complex software only guided by someone who has no idea what software is and how computers work. They can do some of that but I've yet to see any major successful piece of software built that way. They also consume vast physical resources to get the job done.
Before LLMs I think it was a given that at some point we would have AGI that's smarter than us. Machines we build aren't constrained by the biological constraints we are subject to and can evolve faster than we have. But when that's gonna happen, whether that's actually LLM-like in architecture, and what things will look like once that happens, are fairly open questions at this point. In the mean time LLMs can certainly generate a lot of code and we can use them to build more stuff.
It was always true even before AI, AI just makes it more evident since Transformers are LITERALLY an algorithm that produces content nearly identical to content humans produce.
