> 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.

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.

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.

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.

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.

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.

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.

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.

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

> 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.