13 ms·

Domain expertise has always been the real moat

• machardmachard 4mo ago
  [dead]
• whatever1 4mo ago
  One little detail. The models are already pre trained on similar system implementations. Likely whatever you are building has been built in some form or shape in the past and the ambiguity is resolved by someone in the training set.
  • aaronbrethorst 4mo ago
    That “likely” is doing a lot of work, especially in mission critical software.
  • jbjbjbjb 4mo ago
    In my experience “we need so create something for this regulatory change / new industry trend” is more common than we need to redo a working piece of software that’s been done before.
• rayiner 4mo ago
  I bet there were textile workers who would have written articles like this if the internet had existed back then.
  • doctorpangloss 4mo ago
    you're right, and i hate that the word you are looking for is "cope." anthropic is making billions of dollars proving how little domain expertise matters. the philosophical route towards understanding how little domain expertise matters would take paragraphs to write...
• dominicq 4mo ago
  Good post! Also, in my opinion, domain expertise is actually more interesting than pure coding ability. Coding, for me, has always been a means to an end. I'm equally happy with a spreadsheet if it solves my problem, and in fact I hate most apps.
  • irishcoffee 4mo ago
    I’ve been an engineer for a while now, where we have a mix of EE, ME, SysE, SWE, and the programmatic folks, lots of software/hardware integration at pretty “low” levels for each discipline, really fun. One of the things I say is when I’m on my soapbox is: we are all engineers. We have different tools in our toolbox to solve problems. We get paid to solve problems, not (for example) write software. Software is just a tool.
• threethirtytwo 4mo ago
  “The hard part of writing software has never been the writing.” I’m tired of these endless articles on HN about software engineers trying to reinvent their identity while trying not to lose touch with reality. One way of dealing with LLMs is to deny the skill level of LLMs. Claim they can’t code as well as you. This excuse works to a certain extent but it also fails because not only are their multitudes of cases where the LLM IS intrinsically worse than me… but there are multitudes of cases where it is better. So this excuse cannot be universally true. The other way is to claim software engineering was never the hard part of engineering and that other things were harder and that was always where your primary skill was located. This excuse is also idiotic. First, Software engineering is hard. It is genuinely not something that anyone can pick up very quickly. Second, all those other “skills” like “domain expertise” are STILL targets for the LLM. It’s not like the LLM exclusively is only good at software. Just face the goddamn truth. AI is on a trajectory to dominate. That’s what all the trendlines say. It’s not currently dominating, but it’s close, and the trajectory points to an endgame where it is fundamentally better. The trendline could be wrong but the trendline is the best quantitative predictor we have and it’s been trumping all the half baked theories on HN where people were claiming self driving cars would never happen and AI could never code. HN was historically wrong… the trendlines and the VCs who made those bets have been right. So who’s the bigger idiot? Those VCs creating the AI bubble or HNers who have been continuously wrong about everything? (Minus crypto, HNers were right about crypto). If the trendline is true our skills as engineers not just the software part is on track to being dominated by an artificial intelligence. The tools trivialize your skills until all the moats are gone. Not only that… AI is becoming better at art. Poetry, writing, paintings, music… AI shows us how trivially reproduceable all of it is. That is the truth. We aren’t not unique and all the meaning behind being human is just an algorithm. It’s all reproducible. Even your self delusional attempt to deny and delude yourself away from these truths is predictable. I can see someone formulating a retort right now.
  • aaronbrethorst 4mo ago
    Have you considered becoming a residential electrician? Good job, pays well, lots of problem solving, and it won’t be replaced with an AI. I’m serious!
• globalnode 4mo ago
  This article is wrong. LLM's encode all the domain knowledge you could possibly want. As a software dev I can query an LLM, become a domain expert in a short amount of time, and then code up a solution. If people think their niche is safe from automation, think again. Even the people who think theyre the masterminds at the top. Edit: Yes "expert" was too strong a word. Proficient would be better. A lot of the barrier to entry in a field is just not understanding the domain.
  • foobarbecue 4mo ago
    You might /think/ you've become a domain expert, but you haven't.
    • argee 4mo ago
      This guy has clearly never asked an LLM whether New York City is entirely south of the state of Oregon.
  • milkshakes 4mo ago
    > become a domain expert in a short amount of time how does that work exactly?
  • ramshanker 4mo ago
    Once someone taught me "you can do xyz reading a book, but you cant do surgery by reading a book". Now replace the book with LLM. This is what "domain expertise" look like for some domain.
  • jodacola 4mo ago
    I won't over-generalize here, because maybe your statement is true in some cases, but I will provide a counterpoint: this is not true (in my experience) in real estate title insurance and escrow services. I've consulted for and led large teams for real estate title insurance and escrow companies for many years, and the domain expertise is so incredibly deep, nuanced, and multivariate (especially depending on jurisdiction) that building valuable and viable products in the space is incredibly difficult - before LLMs, and even now, with LLMs. Without getting too deep into it, I'm pretty bullish on AI (and have been very close to it and deep in it for a long time, while also very apprehensive about the effects it'll have on society), and I can tell you, from extensive attempts from myself and many on my teams to leverage the latest frontier LLMs to bring deep domain experience to bear to help drive valuable products: we have not yet seen success. It's not helping engineering folks, it's not helping product folks. It's creating a ton of questionable output and hasn't resulted in real ROI, and it's not capable of accurately answering deep domain questions without hallucinations or assuming what works in one jurisdiction works in all. I've seen success in many other areas, but not this domain - and, importantly, the regulatory environment in which title insurance operates is incredibly complex and strict, meaning you can't just YOLO LLM output into production (as much as we'd love to try so we can learn at a faster clip). And the kicker: we've found the way for us to build the best products is still going out into the field, sitting with escrow and title folks, watching them work, asking them questions, and designing for the real world, the regulatory nuances, the local client nuances, etc. You can't get that from an LLM.
• ramshanker 4mo ago
  Agree on this one. As a Civil engineer, I can smell which software ( or some part of) was developed by computer engineers without much understating of the "domain". The worst offenders are software needing multi-domain expertise in the first place. Crude Ex. Payroll (Finance) and Leaves (HR) are 2 seperate domain, and they need to account for each other.
  • wrs 4mo ago
    I think you're putting the analogy in the wrong place. In this context, civil engineering isn't a "domain" any more than software engineering. Both are exercised in support of the "actual" domains relevant to business or society. The more analogous question is: as a civil engineer, could you tell which structure was designed with the help of a civil engineer, and which was designed by a domain expert (e.g. a transportation administrator) with automated civil engineering?
• wg0 4mo ago
  This is such a sane take. It is THE reality we have been always ignoring. Writing software has never been difficult. It is the domain that has been the issue. Always.
  • theLiminator 4mo ago
    > Writing software has never been difficult. That's not true at all, sure CRUD might not have been that difficult, but absolutely there is extremely complicated software out there that is really difficult to write in a performant and correct manner.
    • wg0 4mo ago
      Yes. Audio, video encoders, decoders etc, 3D modeling, rendering etc. That too is "domain" even it feels like it is NOT. Domain of signal processing, Euclidian spaces, information theory and what not. Thar too is all "domain" and that "domain" part is difficult to write.
      • theLiminator 4mo ago
        Then what do you mean by pure software? I think there's essentially zero domain-free software.
        • dapperdrake 4mo ago
          I prefer co-domain free software. Has no side-effects.
      • threethirtytwo 4mo ago
        You do realize that all the domains you used in your example are trivial for an LLM to write?
      • asdff 4mo ago
        It is kind of funny though how all this hand wringing on performance, graphics, quality quality quality, has just resulted in basically same stuff as what I was doing with my computer in 2000 but with enormous resource use in comparison. Still playing games, still same old discussion forums/social media/whatever on the internet, same email and office suite, same chat, same media players, same everything. I can't even see the difference between 1080p and 4k from a couch, and people are trying to sell me 8k to watch the same stuff. It just does not matter. The ideas matter. Novel functionality matters. But that isn't what any of that is. Same old. And the effort spent, the resources, the energy. All for more polygons on Lara Croft.
• yieldcrv 4mo ago
  I disagree because we're buying up companies and training models, creating skills and agentic workflows on individual domain expert's 30 years of notes and prior projects The only moat is that there is so much more work for domain experts since they and many of the bureaucratic processes in between aren't the bottleneck anymore I think it's important to be clear on what's really happening. Companies were accomplishing 5% of their annual plans, and now they're taking a realistic swing at all 100% to likely reach 20-25%. It's a crazy amount of work, for the same specialists and more human workers.
  • Jubijub 4mo ago
    But that’s not true though. You still have to convince humans. You still have to deal with what people in power feel (clients, leads,etc) This still adds wall time. I saw 0 serious analysis confirming 5x productivity gains. In the coding part? Maybe, and that’s not even certain. But pure coding is only one order of making software, or solving problems with software
    • yieldcrv 4mo ago
      and 0 analysts were saying agentic workflows actually worked 6 months ago, they were completely disillusioned and yet here we are if you’re actually building these things, you know they and the CEOs they’re hearing from are all 6 months behind. the executive’s frantic pivot to shove “AI” down everyone’s throat didn’t pan out in one quarter and had nothing to do with the actual concept at all that, and every industry is different. I wouldn’t listen to analysts, I’m in an industry that even Anthropic thinks wont be touched by AI (even though they can read ours and everyone else’s sessions) all public discourse is just flat wrong, and just like every week this year, you’re just going to wake up seeing a new AI capability headline that makes you question your role in society. So play devil’s advocate all you want, the silver lining is that there’s more work to do than ever before and more of it can be tackled at once
• bijowo1676 4mo ago
  LLMs are the best domain experts, but the curse is that they know too much. so it takes a domain expert to remove unnecessary things, similar to how stone carvers create by removing material, not adding
  • nine_k 4mo ago
    Encyclopedic knowledge does not equal expertise, much like raw intellect does not equal wisdom. Knowing "too much" and not knowing what belongs to the core and what is a secondary detail is exactly a lack of domain expertise.
• suncemoje 4mo ago
  I feel like this aspect has been discussed on HN many times. The thing that resonates with me strongly is that there’s rarely a clear or fixed set of requirements to begin with - at least from my work experiences. Then, domain expertise helps with being able to proactively call out when they are missing and support in defining them. Still I am of the view that with enough context AI could also replace the best engineers with the best domain expertise.
  • epolanski 4mo ago
    Maybe, but that would require domain experts and stakeholders to write clear specs, and that's never gonna happen in my experience. I am still bothered that domain experts still keep confusing closing orders with generating a delivery note, or stopping to say articles when they mean a product or a product when they mean an item. Writing good specs require lots of domain knowledge but a very engineeristic approach these people just don't have.
• jdw64 4mo ago
  [dead]
• wrs 4mo ago
  This is not entirely wrong, but oddly describes the major flaw in its own argument: software engineering has tacit knowledge just like every other domain of expertise! And just as you can't become a doctor by just reading textbooks, or an architect by just looking at plans, you can't become a software engineer by just reading a bunch of code. Successful software results from the intersection of expertise in two domains: the application domain, and software engineering.
• donbventures 4mo ago
  [flagged]
• znnajdla 4mo ago
  Not just domain expertise. The hard part has always been marketing, distribution, risk appetite, motivation, grit, and patience. There are plenty of things which are "trivial" to produce with no moat and yet are still million dollar businesses. Kebab stands. Water bottles. Barber shops. Movers.
  • combyn8tor 4mo ago
    > risk appetite, motivation, grit, and patience. This is the moat. It was before AI and still is.
  • dapperdrake 4mo ago
    Markets, not individual businesses. Many Kebab stands are tiny businesses. The fan-out for retail is necessary. The market is big.
• jeffnash 4mo ago
  Highly agree with much of the article. IMO, this is why many engineers who learned to code in the post-2010 'new hot framework every week' era but before LLM coding took hold are able to get much better results from AI assisted coding than those on either end of that sweet spot. The domain expertise in this case is constantly having to adapt to learning the latest flavor of the week DB or JS framework and adapt existing patterns and paradigms to new ones. Agentic coding itself is, in this case, one of those new paradigms. Knowing the caveats and pitfalls of this through years of (often-painful) experience is what, at least for me, allows me to preempt a lot of the sloppy assumptions or omissions that even the frontier models make when working on systems at scale. This means I can leverage my domain expertise on these high-level areas while delegating the grunt work that is harder to screw up to the agents. I find this enables me to work faster while avoiding the slop making its way into critical engineering decisions.
• girvo 4mo ago
  > inputs and outputs If the inputs and outputs are only and exactly those of the domain, sure. But software is more than that. And your logistics operator (or my actual work example: our extremely talented designers with deep understanding of our product) can validate parts of the agents output, but the rest of it they can’t and it makes a mess. I’m sure this will change, but it hasn’t yet.
• steve_adams_86 4mo ago
  Such a good example of this I encountered recently: I was on a fishing trip. I asked the charter if he’d want to check out a free app I work on (https://oceanconnect.ca 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.
  • RussianCow 4mo ago
    Product management is its own skill, and few true domain expects have it. Without some form of PM, the resulting software will end up a mess due to poor UX, too much bloat, etc. I think AI is going to force most software engineers to pick up this skill in some form. Building is easy; knowing what to build is the hard part.
  • enraged_camel 4mo ago
    >> I found myself thinking people like him could actually do amazing stuff with LLMs if they sat down and got their ideas out on a screen. They can, and they are. You just don’t hear about it on places like HN because those people are not on this website. Which is why some people here make smug statements like “if LLMs are so good at programming how come we haven’t seen any useful apps made with LLMs???”
    • 4mo ago
• burnto 4mo ago
  The software generalist described in this post has domain expertise as well. In software. If you’re a great generalist software engineer today, you aren’t jumping to some random domain to escape AI. Software is your domain. You’re sticking with it as it expands and transforms.
  • dfunckt 4mo ago
    Exactly, plus you now have a new superpower with AI — the ability to dig into and ramp up expertise in mostly any domain. I’d say the article gets it backwards.
    • thenoblesunfish 4mo ago
      True that AI lets you get information fast an efficiently. But it might just make you feel like you understand, even if you don't have the kind of hard won domain intuition that this article is talking about. I certainly often get delusions of grandeur when I learn a lot of something and haven't yet suffered with it in practice.
    • bawis 4mo ago
      Expertise is largely tacit knowledge, reading AI slop isn't expertise.
      • dfunckt 4mo ago
        You can quickly get the "lay of the land" and discover primary sources which you can study. Learning from the AI, I agree, is rife with landmines.
  • jongjong 4mo ago
    Exactly. The software engineering domain is huge. I could code just about anything when I was 16 years old after 2 years of intensive learning... It took me an additional 10 years to learn to design software that is secure, maintainable, efficient and scalable.
• ama_built 4mo ago
  [flagged]
• esikich 4mo ago
  My friend is an electrical engineer and just passed a FIDE chess rating of 2000. Has played for 30 years, started the chess club in high school. Knows a little programming from the stuff he had to do with microcontrollers in college. I'm an infra/admin jack of all trades with a comp sci degree and have been a hobby programmer for 30 years. I have a Lichess rating of 1000 on a good day. We tried doing a chess bot competition (open book, use AI to program it, pull in opening books, end game tables, whatever, free for all) and I absolutely stomped him, but I've only beat him in real life over the board twice in 20 years. He will beat 99% of random players in real life, and I will beat maybe 20%. I'm not sure what I'm trying to say, but it seems to me that maybe domain knowledge isn't everything anymore? Or the domain itself has shifted?
  • johnfn 4mo ago
    I think a charitable interpretation is that from the perspective of AI, some domains are shallow (like chess), and some are deep (you can fill in the blank here).
    • esikich 4mo ago
      What would fill in the blank be? Because this was actually kind of a test for me to address the question of "does AI just amplify domain knowledge?" In this case, it seems it didn't.
      • FireCrack 4mo ago
        For the purposes of chess the domain knowledge is the game rules. And from this pov there is really not much to describe, knowing en-passant exists is the peak of domain knowledge. The other things you describe, such as endgame tables, are really more related to the domain of chess-computing, a subdomain of algorithms, and likely something you exceed your friend's knowledge in. Getting to a high rank in chess isn't about better domain knowledge, is about application and experience.
        • esikich 4mo ago
• azuanrb 4mo ago
  I recently reviewed an app built mostly with vibe coding. The owner said it was almost ready to launch and just needed a quick check. After looking through it, the database design was a mess. Some features worked, some didn’t. I explained the missing pieces and why things were breaking. Like OP said, he’s the domain expert. I used billions of tokens last month alone. The tools are getting better fast. But giving AI to a domain expert doesn’t mean you no longer need software engineers. A domain expert can use AI to build software. And a software engineer can use AI to learn about the domain. Both bring different expertise to the table.
  • jonkoops 4mo ago
    Honestly, this is my experience as well. LLMs make it easier to explore other domains, but they do not make you the master of one; you still need expert domain knowledge. That said, they do make excellent tools to quickly try out new ideas and dive into them; they can even be great learning accelerators if you have a curious mind.
  • aaronbrethorst 4mo ago
    Totally agree.
  • jaggederest 4mo ago
    Where I am headed, I think, is to basically be a platform engineer. The job is to create the guardrails, validation, prompt library, and both agent and manual reviews; that keeps the domain experts safe when they start using coding agents. It's a little bit like being T2/T3 customer support [or support engineer], but internal. You're there to catch the dangerous spots, the weird edge cases, and to make sure that everything is set up correctly, rather than to solve 100% of the routine problems yourself. There's also plenty of room for cross-cutting-concerns, of course
    • brandensilva 4mo ago
      Eventually infrastructure will be more simple to orchestrate too without faults I suspect from well developed devops harnesses. The risk and scale companies are willing to accept will still fall on humans for some time even then. I don't see most people vibe coding a million user app that has deeper needs than the basics we see now.
• simianwords 4mo ago
  In the past, an engineer who deeply understood the internals of a DB and how memory management worked in Java would be indispensable. Now these skills don't matter as much because LLM's/Cloud/Java abstract out these problems. What makes domain expertise a different category itself that lends it to be not automated out by LLM? Example: Why can't I go to into an agri-startup and become better than anyone else by querying an LLM even when I have no domain expertise? Much the same way I beat the dev who was good at DB internals?
  • bigstrat2003 4mo ago
    > In the past, an engineer who deeply understood the internals of a DB and how memory management worked in Java would be indispensable. 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.
• hyperpape 4mo ago
  Like so many posts that end up on HN, I just want to say "you've got a decent idea, but tone it the fuck down." It's absolutely true that domain knowledge is incredibly useful, and developers aren't always great at gaining it. But there's also something about decomposing systems into their component parts, understanding algorithms, and knowing how code works that's also incredibly useful, even with agents in the picture. A really good developer needs both of those skills. Take that example, of the generated shift that's illegal (by coincidence, I do freight optimization and work with examples like that in my day job). A domain expert will know the specific example is illegal. So they'll tell the agent to fix it. The agent will probably fix it for that case. How does the domain expert then know that the agent has produced a thorough fix, as opposed to just that scenario? Not because the agent says so. So it is because they test it manually (but which cases)? Or because they review the strategy of the agent's tests, and know how the algorithms work, and know the edge cases that the tests need to cover? But they can't do that, by stipulation, because they're not experienced with code, they're just using the agent. So yes, if the agent gets to the point where it can design robust software that avoids edge cases in a complex domain, doing complex operations and is thoroughly tested, and so on, then half of my skills are going to be irrelevant. Out of the box, agents don't do that today. Perhaps they'll get to that point, but until then, your knowledge of where to put a semicolon has become less useful, but your ability to specify and test processes precisely has not. But yeah, knowing your domain well is a damn good idea.
• biscuits1 4mo ago
  "Go get one." Yes, and its price law all the way down to the metal, hasn't it always been? I think this article is stating the obvious. In software, it has always been a requirement to learn the domain, and then capitalize on that in any way the software can be written (by hand, as a tech lead, or managing others, or lately, using ai).
• toastmaster11 4mo ago
  How much pontificating needs to be done before people acknowledge nobody has any idea what to do with AI on an individual level? First being good developer and learning how to use AI was sufficient, next it was being able to design architecture, then it was “taste” that made all the difference and now being an expert in the domain is the only thing that matters really. Until AI is basically in a stable, predictable, state of improvement or stagnation, these takes will continue to be pointless and most likely completely wrong.
  • cautiouscat 4mo ago
    Haven’t you heard? If you don’t adapt now you’ll be left behind, never to be able to work again! Copilot? That’s so last year. Agentic engineering? You’re already late!
    • mrexroad 4mo ago
      Do you have a link to your paid content that will put me ahead of the curve so my career will be bulletproof? /s
    • skippyboxedhero 4mo ago
      jibecoding is the latest thing: you insult the LLM's bloodline providing it with greater motivation to complete the code you won't review without bugs.
      • cindyllm 4mo ago
        [dead]
  • abhaynayar 4mo ago
    Several things can be true at once.
  • deleted 4mo ago
    [deleted]
  • xnx 4mo ago
• 7777777phil 4mo ago
  [flagged]
• pixlmint 4mo ago
  the idea that llm's can't help if you're missing domain knowledge is crazy.
  • onesingleblast 4mo ago
    I mean if you ask the AI to make something to manage the inventory in a warehouse without any detail about how the warehouses operate then you're going to get a worse result than a domain expert talking to the AI. 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.
• ChicagoDave 4mo ago
  Nice idea, but engineers are engineers for a reason. I’d suggest that the domain expert partner with a GenAI senior engineer to build together. In fact I believe this is the new dev team model. Domain Expert + Senior Engineer + QA. Not sure we still need a project manager anymore and we certainly don’t need scrum masters.
• avaer 4mo ago
  There's a lot of people agreeing and disagreeing with the article, but on what grounds? How do you know "domain expertise" is a "moat"? Vibes? Has there been ongoing, persistent attacks by AI on domain expertise where we can say the moat holds, economically speaking? So far it seems quite the opposite. So far the evidence seems to be pointing to a different adage, Sutton's Bitter Lesson, which (generalized) says to not bring human expertise to a problem that can be "solved" with unfathomable volumes of data. Because the latter has historically slaughtered the former for decades. But somehow people believe this time it's different? I will counter there is one thing that is a persistent moat, and it's not domain expertise; it's sales. Convincing other humans to part with their money. Humans have shown they will trust a person/human touch to part with their money more than an AI. But I'm not convinced today's AI or tomorrow's won't be able to replicate domain expertise in domain X for any X.
  • ikjasdlk2234 4mo ago
    I'm in growth. When I hire in sales roles, I prioritize domain expertise.
  • binary0010 4mo ago
    You think we won't have ai sales agents that are better than humans at selling? They are already significantly better than humans at persuasion (according to a study from Princeton).
  • hyperpape 4mo ago
    > Has there been ongoing, persistent attacks by AI on domain expertise where we can say the moat holds, economically speaking? So far it seems quite the opposite. What do you mean by this? Most human white collar workers still have their jobs. I can't see the future, but yes, so far, human expertise is doing ok. We'll see what happens in 2027, and 2028, and...
• bparsons 4mo ago
  What some people here are missing, is that domain experts or hobbyists are mostly vibe coding tools for themselves -- not as a SAAS product. They tend to work good enough to do the thing they want it to do. It runs locally or on some VPS, and is held together by string and duct tape. The work product probably offends real software engineers in the way that a normal home cooked meal would offend a Michelin star chef. Yet, before last summer, these people never contemplated the ability to cook their own meals before. The fact that they can do this now is a very big deal.
• jongjong 4mo ago
  The problem with these kinds of discussions is that they act like experienced software engineers themselves don't bring domain expertise to software products. So AI can easily replace the domain knowledge of software engineers but not of evey other profession? Coding is not engineering but I'm glad that we will finally be able to prove that definitively thanks to AI. It's going to be a bumpy ride. Any software engineer who has built software to solve domain problems in multiple industries knows that the engineering domain knowledge and systems thinking approach is far more difficult to attain than industry-specific domain knowledge... This is why there are software consulting firms which can work across multiple domains. Understanding the problem domain is not that difficult.
• hanzeweiasa 4mo ago
  [flagged]
• Papazsazsa 4mo ago
  [flagged]
• mangomanai 4mo ago
  interesting
• TrackerFF 4mo ago
  I work as an analyst, and our group has roughly 20% analysts with strong technical (software engineering) skills, and the rest are more traditional analysts / domain experts. In the past year we've seen these non-technical analysts become more productive when it comes to developing internal tools, by leveraging AI models for the dev part. Prior to this, pretty much everything was developed in Tableau. It was the most accessible way for non-devs to build working tools. Just the other day one analyst in our group presented a tool he had been working on, which was basically a port of a tableau report, made into a more flexible app.
  • nomel 4mo ago
    Our group is slowly replacing tableau with self built tools, with HUGE performance gains. I think these BI companies are in deep trouble, especially ones like tableau that make drawing something simple, like a histogram, near impossible.
• boron1006 4mo ago
  More generally, I think it’s more specialized knowledge. If you have particularly specific knowledge in pretty much any domain, combining that with AI can lead to huge gains.
• ifh-hn 4mo ago
  This sort of thing has Microsoft Access vibes about it. All AI is enabling is domain experts to spin up their own software systems with no understanding of how the systems should be put together. Sure it lowers the bar, and some people will design decent things, but mostly these things will become mission critical and broken at the same time.
  • wiee 4mo ago
    Access or Microsoft front page?
• Wowfunhappy 4mo ago
  > A logistics dispatcher, a clinical coder, an actuary. [...] They know the correct outputs for a given set of inputs because they’ve spent ten years living in those inputs and outputs. Hand them an agent and they are startlingly effective, because the thing they’re missing, the ability to produce code, is exactly the thing the agent supplies. What they bring is the thing the agent can’t: the ground truth. 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.
• gwbas1c 4mo ago
  > Agentic tools collapsed one of those paths and not the other. The engineer’s advantage, the ability to translate a domain model into working code, is now cheap. The domain expert’s advantage, knowing what right looks like, is not. 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.
• Syntaf 4mo ago
  It was never about the code. After spending the last 5 years building software for venture capital and private equity, this blog post really resonates with me. Writing code is by and far the _easiest_ part of my job; understanding the financial engineering and nuance behind what my company's customers need from us the tough part. We always joke that we'd rather hire a senior fund accountants and teach them to program if we could, only problem is there just aren't any of these folks around. Teaching an engineer to understand the minutia of fund accounting well enough to build software for these firms is tough.
  • to11mtm 4mo ago
    IDK, there's a tipping point where at best domain expertise without skill leads to a LOT of tech debt. In fact about half of my career has been dealing with 'domain knowledge at least present enough to get the ticket/epic closed but leads to a lot of tech debt'. i.e. a good portion of my jobs have involved a lot of a good amount of: - Review PRs with a fine tooth comb because despite domain knowledge, people are human and can either don't know any better, make mistakes, or willingly refuse to integrate feedback, or worst refuse to double check what the coding agent wrote for them. - 'refactor this thing because it was technically correct but written so poorly that it leads to timeouts and/or a Manager/DBA is screaming' [0] > We always joke that we'd rather hire a senior fund accountants and teach them to program if we could, only problem is there just aren't any of these folks around. Teaching an engineer to understand the minutia of fund accounting well enough to build software for these firms is tough. A truly good software engineer is able and willing to learn the domain, but there has to be a way for them to learn. I say that because I've been at shops where various levels did that (i.e. sometimes the company itself, sometimes the team, sometimes colleagues) and I've been at shops where everything is lip service and at best you can only glean from what's in the JIRAs and what you can glean from what people outside of IT say in meetings you are in. > After spending the last 5 years building software for venture capital and private equity, this blog post really resonates with me. Writing code is by and far the _easiest_ part of my job; understanding the financial engineering and nuance behind what my company's customers need from us the tough part. I think a big paradigm shift especially in the past 5 years has been that most companies are expecting folks to work to the bone, and it winds up being counterproductive because it prevents anyone from being able to have the important conversations. Culture is a huge factor in this, I've worked at shops where at the very least you could easily have a side conversation or a meeting, and shops where you might as well sign a change.org petition to request time to talk about it properly. Still, you are right at the crux; Requirements matter more than code at the end of the day. I've been at shops where a person's definition of 'Correct' meant a feature got delayed despite all requirements being met, because they didn't like they way it was written after they were gone the whole time it got implemented and the rest of the team approved all design decisions. [0] - Next thing you know you learn about a 'batch process' has %numberOfRecord%*10 inserts, possibly with additional fetches given a poorly designed data model to where it is doing SQL upserts in the most wrong way (i.e. doing a get from the DB and then adding a record to be inserted if not present.) and they keep doing more and more questionable things to 'improve performance' rather than rethinking the data layer's query pattern. Seen it more than once in my career.
• overgard 4mo ago
  Wouldn't the model have as much domain expertise as pretty much any human? I'm assuming the average project manager isn't reading the entire internet
  • comicjk 4mo ago
    I have bad news about reading the internet...
• mordae 4mo ago
  > There’s no skill file that contains the tacit knowledge of a person who has reconciled a thousand payrolls. 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.
• stanleydupreez 4mo ago
  [flagged]
• aussieguy1234 4mo ago
  A domain expert might know if a system produces correct results. 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?
• rvz 4mo ago
  Just say you do not know.
• rakkhi 4mo ago
  This is exactly my experience vibe coding as a security architect of 20 years https://open.substack.com/pub/rakkhi/p/vibe-coding-as-security-architect?r=1afqp&utm_campaign=post&utm_medium=web https://open.substack.com/pub/rakkhi/p/vibe-coding-as-securi...
• TurdF3rguson 4mo ago
  I have the opposite take. Because Claude is also a domain expert at most things, and you can unit test your way to making things "just work". If you ask me and a logistics dispatcher the task of building logistics dispatching software (whatever that is), I will get there first.
• rektomatic 4mo ago
  > The engineer’s advantage, the ability to translate a domain model into working code, is now cheap. 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.
• dismalaf 4mo ago
  The problem is, discoveries that advance humanity are made by 0.01% of humans or less. The majority of people don't ever discover anything new, they just build or consume what already exists. 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.
• techblueberry 4mo ago
  This is a nice theory, but is it true in practice? (At scale; I’m sure at least 10% of domain experts will find they enjoy writing software too)
• deleted 4mo ago
  [deleted]
• LAC-Tech 4mo ago
  The standard take, including my own from last year, is that these tools amplify senior developers because senior developers have judgment. 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.
• blini-kot 4mo ago
  "to build software you need someone who can make requirements and someone who can build systems" revelations never stop coming do they
• cadamsdotcom 4mo ago
  > the binding constraint has moved from can you build it to can you tell whether it’s right. 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.
• keepamovin 4mo ago
  These guys live in their heads, so when the world changes, they invent reasons why they’re still relevant. 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.
• crushed6 4mo ago
  > The mechanical skill you sweated for, turning a clear idea into clean code, has gotten dramatically less valuable. 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 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.
• cbsmith 4mo ago
  As someone who has jumped from one industry to another: I'm sorry, but domain expertise isn't much of a moat. Yes, it takes a while to learn a particular industry/business, but it doesn't take that long, and worse still: one advantage that LLMs have over us humans is they have such a broader inventory of human knowledge at their disposal. I've literally used LLMs as product managers for new domains, and while I see the rough edges that LLMs have, they always have significant domain expertise. I don't think that's the moat.
• poink 4mo ago
  In my own experience this is 180 degrees from reality. As a generalist, feeling out the depths of a single domain (something I've been forced to do at least 50 times in my career, to the point that I'm probably a global expert in at least 2-3 things I don't actually care about, but are poorly documented and not especially lucrative on their own) is something that's basically a bunch of Google searches, reading source code, and writing/running tests manually, none of which I really care about short of getting to "the right solution." 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.
• hanzeweiasa 4mo ago
  [flagged]
• Schnitz 4mo ago
  Domain expertise has always been the path to advancement in most SWE jobs. You’ve always had to understand the domain and have judgment to not be stuck as a “code monkey” in almost every company barring the big tech outliers where you can be on a generic framework or library team.
• NK_MAK 4mo ago
  To me, the bottleneck feels like it's shifted. It's no longer 'can we build this?' but 'should we build this, and why?' Strategy might be the last thing AI can't do for us at least for now
• Ozzie_osman 4mo ago
  It's not just domain expertise. Sustainbly great work is done by people with expertise _and_ ownership/accountability.
• defgeneric 4mo ago
  This is why Google is pushing SEOs to get their clients to codify and publish their domain expertise: while it gives them a way to filter signal from noise/slop right now (supposedly helping to "improve search experiences"), it also simultaneously extracts that experience into a consumable form for later training. 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.
• stevenalowe 4mo ago
  Domain knowledge is not the moat it might appear to be, especially in industries that heavily document Using AI to more rapidly learn a domain will help in the short term But in the long term, all moats will evaporate
• SubiculumCode 4mo ago
  Maximal Point of View that is harder and harder to disagree with: Sharing your domain expertise is asking to get yourself automated away. Already, if any company hasn't begun trying to maximally collect data on every aspect of their employee's work, they are asking to get wiped by future automated competition from companies that learned everything they could from their employees, then replaced them. Open Science? Open Source Code? Shared your art online? We were all suckers, and might be the first to go.
• exmicrosoldier 4mo ago
  Domain expertise is neccessary but not sufficient. It takes a LOT of time to validate every path, possibly an infinite amount of time, depending on the complexity of the domain.
• chopete3 4mo ago
  Whenever I read articles like this one that appear to be very generic and give advice about dealing with AI, I remind myself that he software industry is like the construction industry. It will never be organized, never fully optimized, and it will always be custom — because it has to cater to the reality of wildly different tastes, contexts, and localities. There may be some good tools, raw materials that show up once in a while.
  • linhns 4mo ago
    Spot on. This needs to be said more, and it’s why a lot of us do it.
• eichi_uehara 4mo ago
  I thought real moat of software is requiring virtually no extensive knowledge/experience of both system and domain. Copying taste and network effect is significantly difficult. The fact is venture backed startups with plenty of talents and resources has been rarely making their positions in the market before vibe coding. That's why people at 20s can compete with experts in various areas. Current backlash is due to creation of guys with just x years experiences in the industry we often see in other mature enterprises.
• Terr_ 4mo ago
  Perhaps the good news is that even the best spreadsheet-slinging accountant in the west would still going to need some programming experience to do their verification. 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.
• shengha 4mo ago
  [flagged]
• shengha 4mo ago
  [flagged]
• untitled-now 4mo ago
  I started an agentic experience app in domaining , people don’t seem to take it that well , they are afraid of letting AI run on its own.
• prosunpraiser 4mo ago
  I have never yet had a set of words that I have grown to hate so much - “taste” and “moat” being at the top of them. It is almost always coming from people who have or know about neither. (Agree with the article’s general sentiment - but just wanted to make this tangential comment)
• elendilm 4mo ago
  "So the most valuable person in this new world is the one who has both skills because they can verify at both layers. They know the generated code is sound and they know the answers it produces are true." This has always been true since the dawn of programming.
  • alephnerd 4mo ago
    Yes, but most people (especially a large portion on HN and Reddit) do not internalize it. A SWE who has always worked in DevTooling companies will always be preferred by DevTooling companies over a generalist. A SWE who has always worked in AdTech will always be preferred by AdTech companies over a generalist. etc etc. Software fundamentals - though useful - are table stakes skills at this point. No business wants to deal with the headache of on-ramping employees who have never worked in a specific domain or industry because it takes too long for a generalist employee to build the intuition needed to understand that segment of the industry.
    • chipsrafferty 4mo ago
      And therefore there will be a huge knowledge gap as companies refuse to hire anyone who hasn't worked in the field for 5+ years and people who want to work in that field but haven't don't get hired.
      • alephnerd 4mo ago
        Not really. Most people continue to remain in a specific domain from their internship days, and professional networks develop. Historically, startups were the traditional path for a generalist to build domain expertise because most startups couldn't be picky with talent, but the market has changed. In all honesty, too much fat did develop in the tech industry over the last 6 years. Traditional hiring pipelines (eg. Limiting early career recruiting to grads from top 10-20 CS/ECE/EECS programs nationally along with Vets and some grads from decent regional programs) still net good calibre talent worth their weight in gold, but others just aren't working out.
• benjaminwootton 4mo ago
  Brilliant framing. If you understand a domain and understand software architecture then you are in an extremely strong position right now.
• kdmtctl 4mo ago
  I'm such a generalist. During all my career, from support to decades of C-level, I was equally challenged by domain and IT people for not being deep in everything. But whenever they couldn't come up with a compromise, I was the person who always offered it. Doing purely consulting work now, mostly implementation. And this "little bit of everything" can be strongly multiplied by AI tools, since I already know what exactly I want to achieve, I just need speed and a cross-check.
• hn_throwaway_99 4mo ago
  While I agree that domain expertise has always been a moat, I believe the author is missing something critical: there is a big difference between being able to verify the output of a system is correct, and being able to tell a system how to generate the correct output to begin with. Personal example: I had a software engineering colleague who was the best coder of financial management systems I've ever encountered. He gained these skills through years of in-the-trenches development. One of the things he told me, and that I also observed, was that the vast majority of financial experts (basically, the people in the accounting department of companies) had an extremely difficult time just telling him what the rules of any particular transaction should be. But what they could do was tell him whether the handling of any particular transaction was right or wrong. So often times he would sit down with these accounting folks and go through lots of example transactions he came up with, and from there he essentially built up the requirements spec. In my experience, that is the primary difference between people I've known who are good software engineers and those who aren't: people who can specify the detailed rules of any system, vs. folks who take a "well, I know it when I see it" approach. I have a strong suspicion that folks who have a high degree of domain expertise in a particular area will fail as software builders even in an agentic world because they will struggle to elucidate clearly the rules in their head that they've learned over years. As an analogy, it's kind of like asking a native speaker for the grammar rules of their language. Often times they can't, but they'll just say "well, that sounds wrong." They may be "domain experts" in their language, but they'd have a hell of a time prompting an AI system on how to grade a test for grammar correctness.
  • throwaway2037 4mo ago
    I think that you raise some excellent points here. I want to dive deeper into what is meant by domain knowledge -- as a I see it. This phrase comes to mind: "Those who know, do. Those that understand, teach." (Google search tells me that it is frequently misattributed to Aristotle.) People who cannot clearly articulate rules for their domain only "do". However, those that can clearly articulate will "teach". Thus, I would say true domain knowledge is the ability to teach that domain to others.
    • 4mo ago
• deleted 4mo ago
  [deleted]
• 0815beck 4mo ago
  there is a big difference between seeing that pairs of input and output are correct, and knowing that the system is correct. there are invinitely many in and output pairs and only checking some while you vibe code your tool is never going to be a reliable method
• aswegs8 4mo ago
  While the article is interesting, it makes assumptions that are not explicitly stated. And the one strong assumption that makes no sense to me is that they discuss team size = 1. Sure, a domain expert now can use an agent. But he might as well work with a development team, or a developer that uses an agent. That's pretty standard I would say.
• GuardCalf 4mo ago
  [flagged]
• realist_not 4mo ago
  As a doctor who learned how to program, I started by writing useless Chrome extensions. One thing I learned early was that programmers generally do not like learning the nuances of medicine, and many are quite open about how little they want to learn it. I have tried convincing my fellow residents to learn a simple language like Lua or even just Python, but the resistance is even greater, despite the fact that they constantly express how they have always wanted to learn programming like I did. I even went as far as setting up their IDEs, configuring their environments, and encouraging them to just vibe-code. It seems that the mental friction involved in switching domains is too high for most people to justify the reward. Perhaps the reward itself is not compelling enough, or perhaps this is simply the limit of adult motivation. I started programming with Python around the time GPT-3 arrived, when Cursor had generous free tiers and excellent starter plans. A few Raspberry Pis, laptops, desktops, and countless hours of tinkering later, I discovered how much I enjoyed solving problems with software. There is so much to learn from the programming world: the concept of open-source software, the idea that people from anywhere in the world can collaborate on the same codebase, and the fact that many do so with little or no expectation of reward. As this post points out, in the project I am currently working on—a comprehensive Clinical Decision Support System—it feels almost second nature to translate the rules, hidden rules, social dynamics of hospitals, and the common mistakes that we and our juniors make every day into software. Taking those observations and turning them into systems that work is surprisingly intuitive. Perhaps the most valuable thing I gained from medical school, combined with my own personality, is the desire to keep learning. I naturally gravitated toward systems thinking, and the path forward seems clear to me: become a true expert in whichever specialties I ultimately practice, while simultaneously becoming highly skilled at systems thinking. As for systems thinking itself, I find it useful to create rules not only for the codebase but also for the testing harnesses and development processes around it. The goal is to build systems that can enforce quality automatically as the codebase grows, ensuring that standards scale without requiring constant manual oversight.
• konschubert 4mo ago
  I think this misses something. 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.
• lofaszvanitt 4mo ago
  blablabla AI usage has to be regulated. end of story
• Garlef 4mo ago
  From my experience what domain experts are often missing - and at least currently this is also an area where LLMs fail - is the ability to model data and interfaces in a sustainable way and factor in team and domain boundaries. This is a failure mode that senior engineers have seen a few times throughout their career: They know how certain choices will play out over time... and the kind of problems and roadblocks these choices might cause.
• xiaoqahax 4mo ago
  [dead]
• ncruces 4mo ago
  Knowing the correct answer to one million instances of a+b, and validating this, does not guarantee that an oracle will use the + operation that's correct over a domain billions of times larger, which you can't exhaustively check. 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.
• tomekowal 4mo ago
  The article says that domain expertise is more valuable now because agents can code well, but not understand the domain well. 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.
  • wiseowise 4mo ago
    > Highly regulated domains like finance have entire books around how they should work. Ironically, LLMs are much better at understanding those than humans.
• jillesvangurp 4mo ago
  Agentic coding favors senior generalists with a broad experience in many things rather than narrow experience in one or two things. I no longer think of myself as a backed engineer. That's what I was. I can do it all now. I've been building products and doing CTO jobs for a few decades now. I'm not a specialist in all layers of the software but I know enough about all layers of the stack to be able to do things with an agentic coding tool. It helps if you can think at the system level and understand how everything is fitting together, why certain things are better than others, etc. Domain knowledge in multiple domains helps for that. That's what it means to be a generalist. And that includes having the prior experience with having built different types of software. Understanding architectural patterns. Being aware of pros/cons of different solutions. Etc. You don't have to be a specialist in any of this. But you do need to understand things at a high level. Being a generalist equips you to enter new domains quickly. I've done lots of consulting on search projects in the past two decades. Every project is different. But the technology stays the same. I've built search engines for dating websites, maps, addresses, material scientists, art work, etc. Every project, most of the work is figuring out what the product is about. What good search looks like in that domain. And what they are doing that is sub-optimal that needs fixing. You can't work on search ranking unless you understand that. And you only have a few days to figure it out.
  • wiseowise 4mo ago
    > Agentic coding favors senior generalists with a broad experience in many things rather than narrow experience in one or two things. Is it? Agents are coming for generalists first.
    • jillesvangurp 4mo ago
      I would say agents will come for specialists equally hard. It takes a long time for a specialist to build up expertise in their domains. But given enough background material, an AI agent can absorb a lot of the essentials and do productive things in the same domain. And of course a lot of general purpose frontier models have been trained on an insane amount of research and documentation. The only difference between training data for generalists and specialists is that there's a lot more material for generalists out there. If you are a generalist with a lot of experience, it's not that hard to "specialize" to different domains that you have no direct experience with the help of AI. Effectively that's what generalists do anyway even without AI support. If this includes proprietary stuff, the job is basically making sense of a lot of specs, documentation, etc. LLMs are pretty good at picking apart stuff like that. A lot of projects I've been doing in the last 25 years have in common that they always require me to wrap my head around a new business domain, new technology, or framework. That makes me a generalist. I got good at figuring out new things and filtering out things not relevant to the job at hand. That's what makes me a senior (that and my age). I've on purpose stepped out of my comfort zone and targeted a few tech stacks lately that I've not used before with AI. That works amazingly well. My experience as a generalist is helpful, a lot of concepts are not really that tech stack specific and port well across stacks. I don't need to be a Go specialist to be productive with Go anymore. Same with typescript, rust, and python. I've barely touched Kotlin (my go to tech stack until last year) in the last months.
• bob1029 4mo ago
  > So the most valuable person in this new world is the one who has both skills This has always been the most valuable person. A skilled software developer who is also deeply experienced in their target domain is untouchable. They can always move the ball forward at some rate, assuming they're making any attempt at all. It takes a really long time to absorb some domains. The most painful one I've experienced is the banking industry. It took me a solid decade in the trenches before I felt comfortable running a status call with a bank's operations staff without a babysitter. I like to think of this as a sort of cube of capability. The X axis is technical expertise, the Y axis is domain expertise and the Z is physics (ai/tools/computers). The volume of this space is what we are interested in. Scaling up to a wild amount of AI capability with the best developers on earth (infinite x-z plane) is still going to perform like shit (zero volume) if you have no practical domain expertise available. Specificity, availability and recency are perhaps the most important parts of domain expertise. None of these tend to be in ample supply with frontier language models. You can get a general sense of how a bank operates from chatgpt, but the FDIC would take over your bank in the middle of the first night of operations because you didn't learn the secret handshake (how to interact with your customers, competitors, regulators, etc).
• Ozzie-D 4mo ago
  [flagged]
• rramadass 4mo ago
  There are two different type of domains to be aware of here; 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."
• MagicMoonlight 4mo ago
  This is just generated slop from Claude.
• wiseowise 4mo ago
  So "the real moat" are BIs and PMs equipped with LLMs? Man will I enjoy seeing this tower of babel crashing down on some heads. Unfortunately, software has tendency to survive for a long time even the shittiest conditions. Taking into account average turnover of 2 years, we're at least 3-5 generations before it collapses, so the people who started this madness will most likely be elsewhere and won't see the reckoning.
• owler 4mo ago
  [flagged]
• xlii 4mo ago
  I disagree. Having worked across many disjunctive domains the value of "expert in domain" is greatly exaggerated. It's not like search engine doesn't exist nor that it cannot be easily absorbed. Quite often becoming expert is as simple as careful reading API documentation for existing, same domain system. The piece is heavily one sided and don't recognize the problem of low reliability software: e.g. imagine a software designed in a way that it keeps critical piece of data as a global static variable. This will always work for a single user but will leak with two. Make it semi-critical and e.g. a part of profile loading. Just as non-expert cannot verify if result is correct from a domain perspective, expert in domain cannot verify the output based on the basic principles (data security, safety, isolation, persistence, etc.) or even know that monetary values shouldn't be kept in floats. Nothing like article claim had changed outside of a false promise of being productive. Software engineers without domain expertise can fake it with unreliable results and experts without swe skills can fake it with unreliable results.
• uldos 4mo ago
  Although the idea of the main promise of the article is correct - that teaching domain expert to use AI seems to be faster than teaching senior developer the domain, there is and will be a learning curve to learn AI. It still sounds like this article is trying to sell vibe coding in a fancy wording. However, domain expert working in team with senior developer that utilizes AI will be the ultimate combo.
• esmiz 4mo ago
  While agents are able to take over a large part of code writing, software development skills themselves are still a moat. How to design systems for the future, for team collaboration, for cost efficiency, hosting strategies, security… these are decisions that will still have to be made by a software expert.
• noisy_boy 4mo ago
  There is a separate aspect of having domain expertise in that it open paths for a software engineer to make a lateral switch to a Business Analyst role. That in turn opens paths to management track on the business side as one gains deeper knowledge. If you have business expertise AND direct SDLC experience, that is a different kind of value you bring to the table. 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.
• eithed 4mo ago
  Sure, producing code has become cheap. Yet again the taste matters and LLMs do not have taste - they will apply patterns that are unnecessary or not extendible, producing unmaintainable systems that nobody understands. Capturing domain knowledge was the crux of development process, but so was verifying, documenting, ensuring that multiple systems work together, maintaining uniformity. I don't know where the assumptions, done by developers, that they only need to produce code that just works or goes brrr fast comes from. Domain expert can develop working code, but they will not be able to ensure above.
• Michelangelo11 4mo ago
  Sure, I think the article is basically correct, as things stand right now ... but the problem is that that wipes out software development as a career: software becomes just a tool that domain experts can spin up to make their jobs easier.
• Frost1x 4mo ago
  I find this take off. In general, LLMs collapse a bit of all knowledge work, including many domain experts. I work with domain experts often and it’s usually the most difficult part of the process. Now, I can ask an LLM the questions I need to design the system and have an agentic system help me build parts. And it works, quite well. The places it falls flat is domain expertise that isn’t well documented, like specific business processes. Knowing something will fail because X in dept A won’t like it and will undermine it (politics) or some silly process I didn’t know about forbids it. So it’s not domain expertise, it’s idiosyncratic expertise that shines these days. Knowing where things deviate from a domain or the standard and being able to adapt around that. Years ago there’s a group I worked with and I was at the mercy of about 3 people I could ask questions to in order to make sure I was doing things correctly because digging into that domain was time prohibitive. Now, I can sit down one evening and dig fairly deep into a domain. I can understand common practice, approach, acronyms, nomenclature, so on. I can find other popular competing systems. I can rapidly figure out what I need. The same is true for software, agents don’t collapse software they help people build fairly usable systems but they don’t find the expertise a senior level engineer has where designs or implementations may fail in practice. The idiosyncrasies of software and software systems, especially in your very specific set of constraints you need to operate in that may deviate from the rest of the world.
  • Dumblydorr 4mo ago
    How would you know the agent is correct in domain expertise if you’re not possessing domain expertise yourself?
  • kakacik 4mo ago
    Shallow generic domain knowledge is not really a helpful domain expertise, is it. Lets take banks - knowing how banks work in general means little for that one specific bank who is paying you, which has different portfolio than most, different processes because everything is homebrew over decades of doing business and they differentiate from rest of the market in many ways and thats their key proposition, different data infra, set of internal apps, protocols and so on. There is no general llm knowledge you can distill in few minutes that would help you much. You need to know your specific company, no way around it. In fact, to be proficient in those deliveries, you need to know those internal politics, processes, their quirks and so on, 100x more than some code fast delivery since this is majority of any bigger project. You need some reputation to get things done effectively. This, for some time, won't be something llm can massively improve, unless those companies change themselves.
• amelius 4mo ago
  > Domain Expertise Has Always Been the Real Moat Yes, and the Big AI companies are currently hoarding data about all domains out there.
• tokenfaucet 4mo ago
  [flagged]
• rohin15 4mo ago
  This is why we have product managers!
• jtgi 4mo ago
  > Agentic AI severed the link between the two. You can now produce the software without ever building the model, and that breaks an assumption the whole profession was organized around. Nah, we’ve always produced software without much understanding of the domain. It’s the premise behind lean: we don’t know much, so get something in front of customers and refine it. So I don’t believe there’s been a strong decoupling here akin to the degree that understanding the code and writing the code has been.
• ThomPete 4mo ago
  Network effect is the moat not domain expertise. Domain expertise build on network effect (for instance the knowledge of the network) yes, but just simple domain expertise is only a training round way.
• hanzeweiasa 4mo ago
  [flagged]
• pjmlp 4mo ago
  These kind of posts always miss the point that in a team of 10 not everyone needs to be a domain expert, and that now the same work can be delivered with a team of five or less. Bad luck for the remaining ones.
• patrulek 4mo ago
  Software engineering is a domain on its own, just a technical, not a business one. Good luck with looking for a once in a million data race or deadlock bugs. Good luck with synchronizing system distributed over a whole globe. And good luck with keeping your domain knowledge up-to-date while developing and maintaining your vibecoded system. Assuming you can even provide enough details and deterministic specification to AI agent, because understanding business and having knowledge is not equal to being able to write down specific and concise rules to make a system out of it. 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?
• yearesadpeople 4mo ago
  Very well articulated for sure. But, I do think the word _'expert'_ always tends to do a lot of heavy lifting. What looks like _'expertise'_ may actually be pattern recognition built through repeated practice. I do believe that is what a model can already do faster than humans. So, to me, we've got to be cautious here in that what this post implies is humanity must strive to be in the 99.99th percentile of domain knowledge to 'beat' the model. This is perhaps problematic. I do think focusing on judgement is the only tact discourse here, and I do think that is fine. Once we have invariance well-defined and covered in suites of various types of testing strategies, and are focused on regulation, wouldn't that be a more doable objective?
  • fuzzfactor 4mo ago
    You're right, I'm still not as much of an expert as I would like to be in my field, and I've been doing it since dirt was rocks :0 Pattern recognition was exactly my first objective, but I only had kilobytes so language was out of the question. The machine would ease the burden on me as far as the pattern recognition was concerned, but I expected to continue to do all of the judgment myself for the foreseeable future until someday when I had more powerful computers. Very helpful to separate the recognition from the judgment, but I still found it best to perform both simultaneously. That was what I would have wanted AI for, to do both if I could get it good enough for reliable judgment one day. >The code was a transcription of that understanding. Acquiring the understanding was the job. Well in the mid-1970's almost nobody had the title of Software Engineer or software product manager compared to today. But "Coders" as a job title were as common as the professional "Programmers", they worked hand-in-hand. The Coders were the ones operating the keypunch machines which took the manuscripts from the programmers plus data from the users and turned it into code on the punch cards so it would quickly run on somebody else's out-of-reach machine without tying it up for very long. Those colossal remote mainframes were expensive. But there was nothing else so what were you going to do? It sucked to be tied to some huge data center though before you could do any programming at all :( If AI makes some coders of the 21st century feel like they are being bumped down closer to keypunch operators than ever imagined, serving a massive machine they will never be able to own, that would not be too surprising. >You can now produce the software without ever building the model, and that breaks an assumption the whole profession was organized around. This is exactly what I said back then, but with reverse angst. I was observing all the professions up to that point in time, almost all of which had nothing to do with software or computers at all. Since actual stand-alone "software companies" were still rarer than hen's teeth. With desktop computers beginning to take hold, Bill Gates and backers like that put maximum effort into getting software recognized under copyright and not just patent coverage. Next thing you know there were two handfuls of software companies which is still pretty insignificant, but that is exponential growth and it can be quite tempting. That's when I realized if that keeps up, people leading the first wave of computerization are going to start producing "the software without ever building the model", especially with a lot of professions that require decades of domain expertise which can sometimes be more infinitely rewarding to leverage with each accumulated decade. If it was going to take decades anyway, might as well do it. The idea that computerization was going to take place using purchased software, without so many companies having their own home-grown programming expertise from the beginning, is what breaks the assumption that all other professions were organized around! That in itself was going to leave a lot of money on the table. >The domain expert had no equivalent path, because learning to build reliable software is years of work they were never going to do. I had already spent years learning to build more reliable code than you could generally get from popular software, because reliability is what I needed more than anything. I wasn't going to spend the years of additional work making my frameworks into things that even resembled commercially appealing products though. If I ever decided to go that route, there were going to one day be high-performance teams having well-honed experience in that area if nothing else. Gave me more time to concentrate on other things. Even though I had a teenage head start in programming itself similar to Gates during the same 1970's, by the mid-'80's it was not only programming but AI too was plainly going to only get more popular faster than I could keep up. I had already started to do a little ML a few years earlier which really worked, but it was expensive and "nobody" around here could afford it once the oil crash kicked in. It was plain to see that "all I had to do" was wait and any domain expertise I could develop in natural science could be leveraged later on if AI gets good someday. I even explored the neural networks of the 1990's but that wasn't going to cut it either. And here we are. If I got a wild hair and decided to launch a (non-mission-critical) "product" at this late date I guess I could consider the use of an AI agent not much differently than I would have engaged with a software team once they became an entity themselves. Same business model from my point of view over the long term. The most artificial thing in the whole timeline is copyright which lots of massive sand castles have been built from, and that is where this language-model-approach to AI strikes the weakest foundation so far, as the tide finally rises too much to be denied. One big artificial thing gets ugly when confronting another big artificial thing as they're vying for king of the artificial mountain :\
• drdrek 4mo ago
  Kernel developer is not the job same as a game developer or an ERP integrator... But Generalizations aside I think people greatly under estimate how rare is the ability to reduce complex subjects into concrete steps that someone else can follow, human or machine. Go ask your grandma for a recipe you will find that it never turns out the same, giving her Claude Code is not going to change that.
• IX-103 4mo ago
  But there's nothing stopping AI from developing domain expertise. If you fine tune a model based on the records of all previous work (effectively "shadowing" the existing workers) then it can easily learn this domain knowledge. The only difference is that AI companies have gone after programming domain knowledge first. Others will come later.
• xivzgrev 4mo ago
  "the binding constraint has moved from can you build it to can you tell whether it’s right." The company I work for is currently trying to accelerate internal AI adoption, and recently laid off people to help force it. As I've written here before, this merely pools accountability (not removing it) and things will break in unexpected ways as people are not domain experts in these new areas added to their jobs. I wonder if we will see a large reversal in a few years, or if AI will somehow be able to fix this too
  • interstice 4mo ago
    Until AI can take responsibility I don't see the accountability issue being solved, hopefully this doesn't just mean humans become responsibility machines.
    • dapperdrake 4mo ago
      Company officers already are.
• lenerdenator 4mo ago
  > If you’re an experienced engineer betting on where to spend the next few years, this is the bet. The mechanical skill you sweated for, turning a clear idea into clean code, has gotten dramatically less valuable. The thing that’s still scarce is a deep, verified model of some real domain. Go get one. Pick an industry, an instrument, a regulatory regime, a physical process, and learn it the way you once learned a programming language or framework. That’s the part the agent can’t do for you, and it’s the part that’s now worth the most. 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.
• thatoneengineer 4mo ago
  [dead]
• zahlman 4mo ago
  > Notice which way this cuts. Pre-agent, the engineer had a path the dispatcher didn’t: they could go learn the domain. Slowly, painfully, by shadowing experts and reading specs and getting things wrong in production, they would build the mental model and then they could build the system. That path was the whole career ladder in a lot of fields. The domain expert had no equivalent path, because learning to build reliable software is years of work they were never going to do. Okay, but I've always gravitated towards working on tools and libraries and back-end stuff; as much as possible, the domain for me is software.
• fernandezpablo 4mo ago
  Things the domain expert on the author's example cant tell (from the top of my head): - is the app is properly deployed - how will the release cycle be - is it secure? - can we run two instances of it without messing up the orders/routes/whatever? - will we spend 5k/month in vercel if people start using it - how will we notice service degradation - if we change the data do we have downtime? how do we schedule that downtime window. - where is the code stored? can the team access it? - how are new contributors onboarded? - does the app use credentials and where to store them? - does the app manipulate or store PII? - if the user refreshes the app does it generate a duplicate order/route/whatever? - if there's an upstream service are we making sure our timeouts are properly configured? - if there's an upstream service are we making sure our connection pool is properly configured? - do we have a max connection lifetime so that middleware like AWS NAT or ALB don't leave us with dead connections in our pool? I think that makes the point clearly. Also it may explain why software developer jobs are currently on the rise despite SWE-Bench-Pro-Ultra-Magic has been maxxed for months now.
• nickjj 4mo ago
  It's funny how out of touch AI is with seeing the big picture of problems. Here's an example I encountered last week: Someone in my neighborhood is a 75 year old chemical engineer who likes computers and got into Linux a few months ago. I see him from time to time when walking around, he's a nice guy and overall has a scientist's mindset. He doesn't make a lot of assumptions and tries to think things through but sometimes he has big blind spots in unfamiliar fields. I helped him install Linux and also hook up an SSD to one of his older machines and now it flies. On his own he had an old sound card that he wanted to use on that machine. He asked me if the card is compatible. I told him it almost certainly is because the Linux kernel has drivers for a ton of devices. His motherboard's built-in sound card was fine but he likes tinkering with audio in general. He managed to physically install the card correctly but called me and said there's no sound playing. Then he says he spent 12 hours troubleshooting the issue, using ChatGPT and Googling for assistance. Over the phone he told me he tried many different things. Installing, tweaking and configuration ALSA, PulseAudio and PipeWire related tools and tweaking everything you can imagine. Nothing worked, no matter what happened, it never played sound through his speakers. He asked me if I could come over to help so I did. In 30 seconds I solved the problem. I went to his sound settings in his desktop environment and saw that his sound card was being picked up. I looked at the back of his machine and noticed this card had 2 black ports with the bigger style jack for headphones. There was no usual green port which is usually used for output. I shined a flashlight to look closer. One of the black ports was labeled headphones and the other was unlabeled. His was connected to the unlabeled one. I swapped it to the other port and everything worked right away. All of that to say, as a software engineer I have second hand embarrassment that a trillion dollars invested into AI didn't think to respond with "did you double check to see which port you connected the speakers to?". I asked him if AI ever suggested that and he said no, it immediately went into polluting his system with a bunch of unnecessary tools and chasing incorrect rabbit hole after rabbit hole. AI understands nothing.
  • praash 4mo ago
    It's funny how well this reflects the contrast in internet advice between Windows and Linux issues. All users deserve advice beginning with thorough sanity-checks and potential quick-fixes before having to dig deeper. 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.
• lazy_afternoons 4mo ago
  A non technical domain expert might usually lack thought clarity. They might know what is right once they see it but they seldom know how to reach there, even with AI. They will write themselves into slop in 3 days. The real moat I believe is the ability to hold the the problem in the head, isolate it and mentally design a way to structurally solve it iteratively. Very few people have it. Much less common with domain experts. I would rather bet on educating domain to the engineer than teaching a domain expert to architect software.
• jmull 4mo ago
  'course, software development itself is a domain.
• vale95ntino 4mo ago
  I find the article interesting and (largely) correct in its analysis of how an individual can use AI. What I think is missing is that organizations (like enterprises, research labs, etc), have multiple people and multiple experts in different fields. So you can have BOTH the AI engineer and the domain expert in the field. Not only can you have this but this is actually common in most large companies. The difficulty lies in making the collaboration work and the information flow correctly so that the domain expertise of the expert can flow into the software product built by the engineer. 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 https://www.getvalmar.com) --> we'd love any input on how engineers prefer performing feedback loops and getting input from subject matter experts :)
• deleted 4mo ago
  [deleted]
• robeym 4mo ago
  [flagged]
• abrbhat 4mo ago
  My problem with such articles is that they mix the creation of software with the servicing of the software. It can be pretty complex to serve sophisticated software at scale in a cost-competitive and secure manner and it will remain so. So the engineering will remain important and domain expertise will remain important as well, as it has always been. Different business will rely on different combinations of these to create their own specific moats.
• micromacrofoot 4mo ago
  I don't understand how people keep getting this wrong, a real moat is actually a wide ditch that's filled with water. Surrounding your fortress with this usually makes it more difficult to attack.
• jackzhuo 4mo ago
  [flagged]
• kioku 4mo ago
  I am slower than a computer at computation, so why would I compete against it? While I can, at least partially, empathize with the fact that the changing tide is closing in very fast, maybe we as engineers should lean more into what makes us such, and focus on applying principles in order to build machines.