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.
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.
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.
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.)
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:
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
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.
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]
> 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.
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.
https://dictionary.cambridge.org/us/grammar/british-grammar/...
Temporal, kausal, Modal, Lokal
https://www.olesentuition.co.uk/single-post/tekamolo-how-to-...
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 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.
100%. I think, intuitively, software developers understand that there's a strong connection here, but most fail to translate that into practice. It always amuses me when someone comments on the triviality of creating CRUD apps. Setting aside the fact that people usually get the mechanics of it wrong (despite it being a solved problem), they overlook the difficulty of producing a good information design.I've developed software in a variety of industries, and I would say maybe 5% of the designs I inherit are well-done and represent the concepts they're trying to model in an elegant, parsimonious way. Rather, most examples are replete with ambiguity, orthogonal concepts smashed together into single elements, and misleading naming and relationships.
And even when there is a well laid out information design, it often is laid out from the wrong point of view. Elegant information design should create a pattern subconsciously enabling people to build a mental model of the tool they're using without realizing they're doing it. But software whose information design works wonderfully from the point of view of a SDE is not going to be approachable to the average user. There are so many tools I've used where I can very clearly see the reasoning behind the decisions and the design and use it well and also be aware I could never explain how they work to the average person.
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.
What they're not saying is that they think we're more valuable because they think we'll be cheaper. They think they can have us do 2 jobs and pay us for 1: probably less than a decent SDE made in 2019.
Personally, I think it's likely to be a shitshow and backfire if that's how companies decide to try to go that route (especially the largest ones). First, if we wanted to be devs, we would be (like you). Most people with the knack for programming and thinking in systems know they have that knack, and if they haven't jumped ship to SDE before now, there's a reason. I could definitely hack a junior SDE role, skill wise, but I don't want to. Second, finding people like us is difficult. The hiring process (which is becoming more and more Gilliamesque by the day) is really bad at identifying us. There aren't credentials, and this sort of work tends to reside in the gaps, as you identified. It's harder for it to show up on a resume. Hiring is optimizing for exact matches and experience, and that's the opposite of how this skill set actually functions. I've found these skills are best developed by being placed in a room where you know very little about what's going on and forcing you to develop heuristics and approaches over time for getting that context. Thirdly, I can't speak for you, but I've developed this perspective over decades and if people want it, they're going to pay appropriately. If they think I'm going to do any of this at my current salary level, they're deranged. And lastly, while most people in our position might roll our eyes at some techie discussions and culture, we do fundamentally like techies/devs and we tend towards placing a greater value on things like relationships than a pure SDE does. (Just speaking in generalities). So 'is willing to replace and/or toss out a category of people I like and respect' is a hint to us to start out assuming this is a hostile negotiation. (Whereas SDEs as a cohort over the last 20 years extended a lot of goodwill at first). We're far more likely to work somewhere, get enough domain knowledge, and then bounce to start our own thing, especially since as a population we're more likely to have devs who will work with us as non-technical founders. Someone who's decent at marketing/sales/the stupid 'people stuff', understands a domain, and understands when a proper dev tells them what is and isn't possible and can even help with some of the most boring, rote parts of the technical side if needed/in crunch is an excellent non-technical founder, and as a group we're also more likely to have access to the technical connections that we'd need if we wanted to build something beyond our ability.
Thoughts that really stood out for congruence with my own experience:
> Most people with the knack for programming and thinking in systems know they have that knack
> Hiring is optimizing for exact matches and experience, and that's the opposite of how this skill set actually functions.
> I've found these skills are best developed by being placed in a room where you know very little about what's going on and forcing you to develop heuristics and approaches over time for getting that context.
> We're far more likely to work somewhere, get enough domain knowledge, and then bounce to start our own thing
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.
## 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.
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.
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
Right, so the spec is derived from examples, an interactive process that doesn’t require a programmer.
Talking to engineers and mathematicians gets you there.
Lossy decompression probably won’t ever be really good at this. If it’s missing from the data, then it won’t be there.
The AI math proofs were probably already out there in tiny pieces and nobody got all of the pieces together. That is valuable. It’s different from making a piece that is missing. And the AI will just hallucinate.
This combination of requirements is the business in most domains. Software or otherwise. Codefying different rules and executing them.
And they were really annoyed at being asked math questions.
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.
Works for me.
Already learned two or three problem domains well enough and now it is starting to compound.
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.
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.
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.
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.
We were working through many complex business flows and running into exactly what you describe in many areas. Some of the project people with less experience complained that we were spending too much time on exceptions and slowing down the project. We had to explain that when each exception happens 100 times a day with significant impact on business productivity, then it doesn't matter whether you call it an exception or not, it's important to solve for.
Who are the 1/3 of the population that does not reason by analogy?
It’s not that the 2/3 can't think abstractly, it’s just that they use analogies as a temporary processing step to get there, while the 1/3 starts there.
I've spent most of my career working with the same people--even people who have some coding experience but they never catch the low probability stuff. Or even not so low probability: business procedures were that the customer was quoted an all-inclusive price. Try to work backwards, what is the pre-tax amount? Um, that's not guaranteed to have a solution. My concerns get ignored, I go ahead and implement with code that will catch the offending penny and label it roundoff correction. While I'm not sure what happened I think some auditor hit that. I ended up having to walk them through the calculation, okay, what's the answer here? Only when they couldn't solve the problem could they accept that what I had done was the only answer. (The actual odds of such a failure are equal to the tax rate. I had not originally worked that out, just saw success was not guaranteed.)
The domain experts make this sort of mistake routinely in dealing with code. AI won't fix that.
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.
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.
A mental model I use for this is that we have users, builders and experts when creating AI products. For most individual use cases a person is the user, builder and expert: I make a prompt about how to write code in a way that I like that I will later use. Coding agents moved into the direction of builders that were also experts in the field iterating on a product for third-party users. The next frontier will be finding the right patters for teams to capture expert knowledge handle the collaboration between engineer/builders and experts. Just having PMs handle that interaction will be a super bottleneck.
My cofounder and I are actually working on a project in that direction (https://www.getvalmar.com) --> we'd love any input on how engineers prefer performing feedback loops and getting input from subject matter experts :)
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.
Searching about common Windows issues results in misleading blogspam. Suggested "solutions" resemble blindly applied folk remedies.
I'm no stranger to breaking my desktop Linux after an hour of misdirected troubleshooting and desperately messing with core libraries. I'm still glad I can quickly find my way to ArchWiki.
I was on a fishing trip. I asked the charter if he’d want to check out a free app I work on (https://oceanconnect.ca) in case it might be useful for his work.
I don’t know how people on the ocean use ocean data. I don’t really know what they want to know, or why. I wasn’t totally prepared for the incredible onslaught of questions and information pertaining to how people use the data or what we can do with the data, and it was so cool and exciting to get that perspective.
It was a good reminder that models are not the same as the systems they abstract, and knowledge to develop them has almost nothing to do with using them. This guy was a wealth of knowledge about how they use weather data on the water. In a sense, he knows more about the data than I do (even if he doesn’t realize it, or doesn’t understand it in its digital representation), and would be far better equipped to make a useful application for people like him if he could program.
I found myself thinking people like him could actually do amazing stuff with LLMs if they sat down and got their ideas out on a screen. I’d really like to interview people on the water daily some day to refine the product if we ever have the funding. That domain knowledge is highly, highly specialized and people know things you’d never guess after living in a complex domain for decades.
I 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.
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???”
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.
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.
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.
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.
This has always been true since the dawn of programming.
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.
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?
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.
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.
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.
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.
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.
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.
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.
- 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.
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.
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).
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?
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.
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.
Should AI make you really good at frontend development?
But OP wasn't talking about solving optimalization problems, but understanding the rules of a business domain.
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.
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.
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.
The market is big.
This is the moat. It was before AI and still is.
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?
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.
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.
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.
But mental discipline required to write efficient and scalable code is insane that most domain expertise is feeble by comparison.
Coding is way easier.
Programming is the easiest part! (c) decade+ experienced senior developers
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.
"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.
Sometimes you need two orders of magnitude. Sometimes you need five. Sometimes you need less than one.
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.
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.
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.
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.
Sounds like you need a senior familiar with finance/accounting and a family to feed. Email me!
Maybe we can grab a coffee.
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.
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
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.
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.
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
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.
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.
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.
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.
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.
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?
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.
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.
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.
Is it? Agents are coming for generalists first.
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.
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.
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.
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.
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.
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.
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.
Do you take into account recent layoffs of Meta (8k people), Block (4k people) and others?
Though I'll say I don't buy the stuff about AI "democratizing" development since making it much more capital-intensive kind of has the opposite effect for anybody doing dev work at home.
But yes - once it's that easy you have to step up your ambitions.
It definitely won’t be CEOs and managers not firing their buddies
I'm sorry to say, but AI coding assistants paved the way to professional imposters whose only skill is prompting a model to do something. I already had the displeasure of working with a software engineer who not only introduced a bunch of regressions that by mindlessly vibe-coding things against the requirements but also complained that not having credits to use the most expensive frontier models was, and I quote, "stifling my creativity".
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.
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?
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).
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?
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?
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'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.
About a decade back, we, as an industry were collectively learning how to make apps webscale, and oh the blog posts about not using a database as a queue. But the LLMs have ingested all of them. I've only read the ones I came across, and of course my professional experience being part of teams implementing that at various companies. So I've got that going for me, but when the Vibe-platform-dev just has to tell the LLM "hey, when the user hits the send message button, it's slow. /goal make messages fast", and the LLM grinds for hours overnight switching the entire system over to a pub sub event driven architecture and the vibe-platform-dev doesn't even know what pubsub stands for or that they're using one unless they go back and read the transcript. I don't think there's as much of a domain expertise moat for as long as we're hoping.
Take a look at the Reddit forums for vibe-coders - now that a bunch of them have been hacking on things for 3+ months there's a growing awareness there that you hit a wall. Here's the first post I found from just searching "reddit vibe coding wall", it's a great illustration of the genre: https://www.reddit.com/r/vibecoding/comments/1sabdw3/anyone_...
Software development is really, really hard. Coding agents can get you a surprisingly long way, but if you want to build real software for real people you quickly find that you DO need that domain expertise.
The agents may type all of the code for you now, but you need a huge amount of skill to clearly tell them what to do, confidently decide what to do next and credibly present software that works for other people to use.
I don't have any automated LLM scanners, but I do frequently have ChatGPT run searches for me with questions like "Find the most credible accounts of the recent Oracle layoffs, how they went, rationale, problems caused".
wouldnt you still be in a better position when prompting “site slow, make fast”?
The business goal is that the site is slow. That gets fixed by the non-technical vibecoder for the cost of however many tokens. Why look for outside help (aka me) if there's no need to and the AI can do it all?
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.
You could've just written this sentence and dropped the rest. I understand your vindictive, "justice", self-hate line of thought, but not it's not a healthy way to live. Get help.
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.
With all due respect, this sounds like just another version of the arrogant, scared attitude that seems to be more and more prevalent among software folks these days.
Is it really hard to imagine that there are tech-savvy people who are smart and motivated but don't have training as software developers, who are now capable of using AI to build and ship things?
In other words, AI doesn't allow any "any idiot" to build commercially useful software. What it does is allow smart people who aren't software developers and who don't want to become software developers professionally to, with a much shorter learning curve and on a much faster time scale, take their ideas and build and ship functional software.
I would argue that the non-developers who are able to use AI to build, ship and sell software aren't "self-taught software developers". The biggest reason is that they're effectively not learning how to code in any meaningful way. They don't need to. AI is getting "so good" that they can prompt their way to functional software without the same level of knowledge and skill that was required previously to do the same.
We can discuss the limits and risks of this, and you can criticize AI's output, but the reality is that people are actually doing this and having some success. First hand, I've seen a former colleague who is a skilled digital marketer with no development experience launch a web app for a niche market and sell it to a number of customers.
I don't understand why you're so interested in extremes (your skilled versus deskilled hyperbole). Is it really so hard to contemplate that AI is disrupting the market for software development? It's not that it has eliminated the need for intelligence and skill; it's that it is allowing a larger number of people to do something that previously required a different set of skills that was much more difficult and time-consuming to acquire.
To use Silicon Valley speak, AI is democratizing software development. That doesn't mean every idiot can build and deploy a functioning web application; it does mean that a growing number of intelligent, motivated non-developers can.
Being in the weeds of the trade expands the lens of capabilities so I’d give the upper hand to someone more deeply aware of the tech vs not. even though that in itself is still not sufficient.
I mean, sure. But there have always been people teaching themselves to program too. In the end it's a pretty small population.
One of the reasons I'm increasingly skeptical of this prediction is that I've now lived past a few of the dates I heard people put on the achievement of this level of superintelligence in previous years.
But then again, logic is really a lot more discrete and well defined and easily expressed with traditional computing than LLMs are (which are probabilistic systems instead and as such require large knowledge bases).
We can observe that at a couple hundred billion parameters they behave similarly to a point (in the sense that they can produce similar results), but the challenge is really in understanding the problem's multifaceted structure and competing needs and priorities.
What prompt would someone have used to get a superhuman coding agent to output the Linux kernel or GTA5?
Before you accuse me of moving the goalposts, that's not my point: The examples are there to help think about what humans would still need to do to build complex projects even if the coding itself was perfectly reliable.
Both the Linux kernel and GTA5 contain a large amount of incompressible information; humans thought long and hard about how to design them, i.e. about what that thing they were building was even supposed to be.
By your logic anyone who's not in the top 10% of intelligence can't offer anything. The world keeps spinning.
> 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.
That's just nonsense, nobody will work with 8 year old (it's illegal, to start with). Go touch grass.
I'm not worried about non-technical vibe coders taking my job. I'm worried about psychotic VCs and CEOs putting me on the street in the name of "optimization" of "lower value human capital".
I've been working on something relatively large and greenfield recently.
A big chunk of my time is spent thinking about the hard parts. The raw information processing rate needed to keep up with the state of the project is high.
It feels almost like mental athleticism, whereas coding used to be a rather chill activity.
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, and I've already learned most of what I could from tinkering with that code, stepping through its architecture, and dealing with those recurring problems."
Soon: "I learned very little this year, because I don't deeply interact with anything, I just pull the lever on the babbling slot-machine until I get lucky and things seems to quiet down."
If you believe Claude makes you a good engineer and you previously weren't, I am saying that's not true and you still are not a good engineer even with the latest-and-greatest Claude model.
The difference is between "helps" (in your comment) or "you are". Sure, it helps a good engineer do more, do better, etc — but the thread was on being a good engineer.
It's "just another tool", sure. But one that is so powerful that some things that used to take a day now take minutes, or ones that used to take a week now take a day. And I get even more praises now, along with more time to focus on understanding the needs and controlling quality. For me it's not really about stuffing as much features as possible, but providing better software.
I'm glad this happened after 25 years in my career. I believe I'm in a privileged position where I can benefit from LLMs and still have the knowledge to effectively correct the machine or go back to "manual mode" if anything goes wrong.
But also to the original Simon's point that using LLM does not a good engineer make — how we make one is still on us with 10+ years (I've got "only" 20) of experience to figure out now that LLMs are here!
Implicit definition of a good engineer is the one who chooses the right balance between effort, complexity, performance to build a working software system for a business need that can be evolved according to (unforeseen!) future business needs at reasonable cost.
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
It is on a scale that it is required now. Previously you could say "it'll take me a week to decipher the mess", now they can just say "can't you use an agent to make it fast?".
I had the displeasure of working with those types. One of them replies to any question or challenge to a technical problem emerging from the PRs they posted with variants of "I've worked here for over a decade, this is how we do things". And then proceeds to argue things like defensive programming is a code smell because it means developers don't trust themselves.
I cannot envision any healthy, effective engineering environment where developers don't periodically switch between projects.
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.
This hasn't been the case for at least a decade. Long before LLMs.
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.
It seems you are not understanding that the reason all these "rules, best practices" had to be created in the first place was the fact that your average old times developer was churning out shit code and weaving spaghetti just as hard as today's vibecoders.
Those "rules, best practices" spawned from the same evolutionary pressure as today's instruction files, skills, custom agents, etc.
Why do you think one of the first AI features rolled out by GitHub was the automatic code reviewer?
You guys are talking as if everyone working on software before 2020 was this immaculate developer with pristine sense of architecture and style. No, they were not.
To your last paragraph, I never say that nor do I imply it. I find that as a pretty disingenuous interpretation of what I said actually. The practices I mentioned were derived from hard learned lessons and designed as a means of mitigating the human tendency to write bad code.
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.
This is a complete unrealistic assessment. Who do you think vibecoders are? They are yesterday's software developers using today's tools.
The people who manually write their PRs are also not giving a fuck when they break production code with spaghetti code that later has to be thrown out and rewritten. They are the same people.
The key difference is that now their output volume is much greater, and they iterate much faster. They roll out plenty of bullshit, but it also hits the fan much faster and triggers fixes at a higher rate.
People hate on vibecoders because they do exactly what your average developer does but at a much higher rate.
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.
> 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.
What’s the algorithm there? How is it different from queueing up your whole library and shuffling it?
> Go build an operating system. I'm serious! Claude will practically one-shot it.
Why would I want this? If I wanted to learn how an operating systems is built, there’s xv6 and the OSTEP book (and I’ve already gone through both) And I’ve been going through OpenBSD code, for a few questions that I had (usb audio and related code, usb mass storage and related code,…). Why would I ever wanted a generated project when there’s plenty out there to learn from.
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.
A key feature of AI coding assistants and coding agents is troubleshooting. It turns out that LLMs excel at pattern matching, specially when coupled with feedback signals. It turns out that troubleshooting represents just that. A few years ago people searched the likes of stack overflow to fix problems, and it turns out LLMs can do the equivalent of that much faster.
Tests stick around and prevent future problems, whereas the debugger only shows me something once.
The sole exception to that is that, back in the very early days, troubleshooting IE6 really required a debugger. But everything else, from memory leaks to thread hang issues to deadlocks, testing is better.
If AI becomes the interface, then we will a layer of abstraction above programming languages themselves. Which is kind of wild.
(I don't pretend this is a novel idea. I'm just not that plugged into AI discourse.)
https://mastodon.gamedev.place/@JeremiahFieldhaven/116654345...
Facades and stranglers are massively useful patterns, and help explain concepts to the layman.
Personally I've never been patterns over everything, so I'm not going to now knee jerk and say no patterns ever.
There's a time and a place for everything.
edit Fuck. A reread on that and I sound like AI. Updated
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.
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.
You can read all the plumbing books, but you need to get your hands dirty a few times, mess it up and fix it, to get mentally comfortable and efficient with the work
"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.
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.
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.
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.
What type of software do you produce?
> 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.
I appreciate the frustration, but some of us are actually successfully using these tools.
if nobody has any idea what to do, talking about it is the right approach
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.
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!
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")
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.
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.
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.
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.
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?
I believe there are domains that are very well encoded. The model very often can know that a shift can't be longer than 11h and if you ask an agent for scheduling software it can surprise the developer by encoding that rule.
Both domain knowledge and coding skills became cheaper.
It might depend on the domain. Highly regulated domains like finance have entire books around how they should work.
However, I agree that verification skills became more important in both areas. A domain expert needs to catch 12h work shifts and experienced programmer needs to catch when the LLM accidentally put a route in a section that doesn't require authentication.
Both require some kind of harness and automatic verifications methods.
Ironically, LLMs are much better at understanding those than humans.
Obviously it is a very different kind of track, take a long time to develop and means you are no longer programming but then with LLMs, hand rolled programming has been massively reduced anyway.
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.
AI is going to struggle at building a consistent internal model of the domain into the software unless you’re able to give a structured explanation of the domain.
If you’re just giving it a set of inputs and expected outputs, it’s not going to generalise well and fail at out of sample input, unless the AI already understands the domain from its training set.
Being able to give a structured explanation of a domain (and being able to judge if the internal model of the software makes sense) is not the same as having experience in a domain.
Lots of ppl with domain experience can tell a right output from a false one, but can’t tell you why.
(Agree with the article’s general sentiment - but just wanted to make this tangential comment)
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.
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.
And if you think LLM are (or will be) good enough to not care about software part, what makes you think that your domain will not be completely resolved by AI?
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.
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.
I don't think that's the moat.
Using AI to more rapidly learn a domain will help in the short term
But in the long term, all moats will evaporate
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.
In the past few months, I've used agents to brute force and reverse engineer solutions to problems I would never have economically have figured out on my own. I did it by putting agents in loops, connected to hardware and the internet, reading technical documentation, and relentlessly trying.
The code was shit. But it's much better to start with working shit and make it correct than spend weeks frustrated that nothing works.
I get that being a domain expert and instantly knowing the output is shit is important, but even if the output looks great, the code can be shit, and it takes looking at the code and knowing something about it to figure that out.
The solution to shit output is not (always, sometimes it is) just another if statement.
Even in a very well specified OSS effort, where I have some expertise, and I carefully reviewed the AI's output every goddamn step of the way, bugs slip through that the agents confidently tell me can't happen, and when shown proof they… add just another if, instead of really questioning assumptions.
You either know what you're doing, or you don't.
Yes, and the Big AI companies are currently hoarding data about all domains out there.
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.
If you have particularly specific knowledge in pretty much any domain, combining that with AI can lead to huge gains.
revelations never stop coming do they
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).
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 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.
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...
It takes a LOT of time to validate every path, possibly an infinite amount of time, depending on the complexity of the domain.
Successful software results from the intersection of expertise in two domains: the application domain, and software engineering.
I'm not sure that even that will remain as valuable or work as a viable moat.
We live in an era of corporate consolidation and absolutely, positively having to meet the revenue target. We also have invested literal trillions of dollars into the AI technologies that made the first skill the author mentions less valuable. However, the result just isn't there. Like the author says, there's a need for domain expertise.
However, you had a bunch of investors plow that trillions of dollars into the current AI boom with the understanding that they could, at the very least, take anyone and have them create what used to take an experienced software engineer, and in far less time and cost, and they invested thinking that the corporate oligopoly would deliver this. They'll now do anything to get that money back. Anything.
If that means telling the corporate oligopoly to tell customers that they need to expect less in the way of domain expertise from the models, well, they'll do that. And since there are relatively few players (the literal meaning of oligopoly) and they all have incestuous financial relationships with each other, they have incentive to hold that line as an entire industry. Development of better tools to create better domain expertise models would take even more money, which the investors don't want to provide, and, short of soaking the public investment markets, can't even find the cash for. Thus, the customer has to lower their expectations if the investors are to not lose their asses on the AI bet.
Something has to break.
Domain expert can develop working code, but they will not be able to ensure above.
Bad luck for the remaining ones.
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.
If you ask me and a logistics dispatcher the task of building logistics dispatching software (whatever that is), I will get there first.
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.
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.
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.
I mean, they could ask an LLM "what does this code do, and will it always X when Y", but that's just nesting the verification problem inside another verification problem.
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.
1) Problem Domain Knowledge: This is what people generally mean when they say "domain expertise". This has always been and always will be the moat with/without AI. Simply because this is what understanding and modeling a problem is all about. It abstracts the key concepts/ideas and their relationships in the problem domain and builds a coherent model. This model embodies a set of functionalities with bounded scope and clear assumptions.
2) Solution Domain Knowledge: This is the implementation domain for the above problem. The model arrived at above gives the requirements which must be mapped to concepts/ideas and their relationships in the solution domain. When our implementation domain is a computer system, this takes the form of architecture, algorithms and data structures. The probability of a good solution here is directly proportional to how good a model we were able to construct in the problem domain above.
Albert Einstein;
"The mere formulation of a problem is far more essential than its solution, which may be merely a matter of mathematical or experimental skills."
"If I had an hour to solve a problem, I'd spend fifty-five minutes thinking about the problem and five minutes thinking about solutions."
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.
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.
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.
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
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.
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.
how does that work exactly?
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.
