This is the kind of post that does not look like much when you start, and then it does not let go of you.

On June 6, 2026, a software engineer writing under the name poisonfountain published a long, careful essay on Bear Blog titled “LLMs are eroding my software engineering career and I don’t know what to do.” It reached Hacker News #11 the next morning: 787 points, 768 comments, a comment-to-score ratio of 0.98. That is not a “people loved it” hit. It is a “people argued about it” hit. The comments are the story.

poisonfountain is not a junior complaining about a chatbot. He is a backend engineer with ten years of experience, working across finance, bookkeeping, and payments. He knows PCI compliance, double-entry ledgers, escrows, reconciliation, payment lifecycles, bank-transfer idempotency. He built his career on a deliberate bet: become the domain specialist, because specialists will always have leverage in a market that keeps producing generalists.

Then AI arrived at his company with a ChatGPT Enterprise seat and a Claude Enterprise seat on day one.

What follows is his account of his three moats being removed, one by one, in the order he noticed them. I am going to walk through them as he wrote them, because the structure is the point.

Moat #1: domain expertise

His first project at the AI-forward company was untangling a legacy online payment system. They hired him for the exact experience he had built up over a decade. He wrote the first Design Doc with minimal AI help. He had previously called LLMs “stochastic parrots” and saw no reason to revise the view.

His manager told him: your code is shipping fast, but the Design Docs are slow. Use more AI.

He tried it. He was wrong about the parrots. The models did not just speed up the writing. They made the judgment faster. The trade-offs he had been weighing for years — how to structure idempotency to prevent double-charges, how acquiring flows actually behave under failure, where the real edge cases live — all of it became connect-the-dots work the models could already do, given the right prompt.

He called this his first shock. Then he told himself the second one would not come: debugging. He had years of real production experience untangling race conditions and distributed systems. That was supposed to be the long-term insurance policy.

Moat #2: debugging and distributed systems

Then came Claude Code. Then Codex. Then the agentic workflows. Then Claude 4.5, 4.6, 4.7, GPT 5.5, Opus 4.8, and the Datadog MCP.

He describes the change in the most painful detail. The models got good enough that a stack trace and a Sentry link through the Sentry MCP started solving most bugs in one shot. Some of them were the kind of bugs he had personally spent days on. The MCP-equipped CLIs started one-shotting race conditions, undocumented API edge cases, third-party integration weirdness, distributed-systems bugs across services that did not even have proper observability. Not all of them. But ninety percent. He almost never has to intervene.

He writes:

Of course, I am still employable, because someone has to review the code and steer the robot. But I am just another off-the-shelf engineer now. I have no domain expertise that another Senior engineer steering an LLM cannot match. All my finance and payment domain expertise, all the debugging intuition and distributed system knowledge earned through hours of sweat and tears, is now promptable.

That word — promptable — is the whole essay. Read it twice.

Moat #3: code taste

He had one pillar left. Code quality, software architecture, what the industry is now collapsing into a single word: taste.

He liked DDD, hexagonal architecture, clean architecture. He liked arguing about trade-offs. He liked refactoring and negotiating time for it inside sprints. He liked writing ADRs. This is the part of the job he loved, and it was the last thing the agents were obviously bad at.

Agents, he concedes, write terribly organized code. They will create circular dependencies. They will duplicate code. They will mix pure functions and side effects. They will violate SOLID. The instinct to push back on that — to insist on shape, on layering, on intent — is real, and it is what the industry is now calling taste.

And then he says the line that should be carved into a wall somewhere:

Sure, humans should steer the agent to prevent spaghetti codebases with circular dependency graphs. We do not want F-rated codebases. But a C or a D? It is fine now. Nobody needs A or B grade codebases anymore, because they are being made for LLMs to read, not for humans to read.

That is the third moat gone. He is not bitter about it. He is not even sure it is bad. He is just describing what he sees: when the consumer of the code is a model, the bar for human-legibility drops. So does the value of the engineer who used to enforce that bar.

What he does not say out loud, and what 768 comments are arguing about

I read through the post twice and the comments the second time. The post is unusually clear-headed. The argument underneath it is sharper than the author lets on, and the 768 comments are mostly arguing about three sub-claims he is making, often without realizing they are sub-claims.

First, the moats did not get “automated away.” They got compressed. The decade of compounding knowledge an engineer used to need to design a payment system is not worthless. It is just no longer scarce. Anything with enough documentation, enough production code, enough well-written blog posts, enough Stack Overflow history can be learned by a model in an afternoon. The moat was not the knowledge. The moat was the time it took to accumulate. AI collapses that time.

Second, “generalist-ization” is no longer a career choice. It is a market condition. poisonfountain writes: “We were taught that generalists and specialists will always have their roles. But now the market is shaping everyone into becoming a generalist. That is not a bad thing per se, until you look under the economics of supply and demand: if everyone is a generalist, the price of a generalist falls if there is no demand to match. And we all know the demand is drying up.” The comment thread picked this up and ran with it. Most of the senior voices on that thread are not angry. They are tired. They are watching the same compression happen to themselves.

Third, “steering the robot” is not a moat. It is the new generalist floor. When the most common engineer job becomes “review AI-generated code and tell it where it is wrong,” every senior can do that. The skill is real, the leverage is not. It is a service job dressed up in the language of architecture.

These are the three sub-claims the thread is actually arguing about. They are also the most uncomfortable ones, because each of them points at a future where the old career ladder no longer works.

The other HN #1 of the day

This matters more in context. The same day poisonfountain’s post hit #11, another HN hit landed at #19 with 448 points and 255 comments: “Anthropic, please ship an official Claude Desktop for Linux.” This is GitHub issue #65697 on the official claude-code repo, and the comments are unusually pointed. Developers are spelling it out: we use Linux because our work is on Linux. macOS is not the default. Stop building only for the platform that pays you enterprise seat money.

Read these two posts side by side. The top story on HN that day is “AI is hollowing out my career.” The second-biggest story is “the AI company is not even building for the platform I use.” Put together, the engineering community is sending a single, exasperated signal: we are afraid of you, and we are also not being treated like your users. That is a much harder problem for the AI labs than either complaint on its own.

Three operational judgments for the next five years

I will end with the same three I gave the Chinese version, written for an international engineering audience. These are not predictions. They are the conclusions I am willing to defend in print.

1. Domain expertise as a moat is collapsing on a known schedule

poisonfountain’s story is the cleanest data point I have seen. If a senior’s full value is “I know payments / compliance / idempotency / a typical CRUD domain better than the model does,” that value is unstable as of June 2026. The model already has expert-level fluency in any domain with sufficient documentation, sufficient production code, and a clear body of best practice.

The domains that are still genuinely defensible over a five-year horizon are narrow:

  • The front edge of ML research — work that is unpublished, data-poor, or not yet a community consensus
  • The physical world — anything where there is no good text training data, which today still means hardware, robotics, materials, traditional industry
  • Organizational and political reality — the parts of the job that require reading a room, holding a relationship, navigating a budget cycle, telling a CTO the strategy is wrong

If you are spending your next year deepening expertise in the first category (typical CRUD, typical payments, typical testing) you are spending it on a moat that is shrinking. The model is not catching up. It caught up.

2. Debugging and taste are not disappearing. They are changing the subject

The ability did not go away. The subject did. A single engineer who can read a stack trace, hook Sentry through MCP, follow traces across services, and one-shot a 2-day bug in twenty minutes is still rare and still valuable. But the standalone ability to “read a stack trace” is now commodity. The market pays for the whole package, not the part.

Same with code taste. The skill is real. The job title is moving. The valuable work in five years will not be “I review the agent’s code.” It will be “I design the team, the workflow, and the review surface so that ten agents writing code still produce a maintainable system.” That is architecture, not taste. The salary goes to the architect.

3. The moat that actually survives: choosing the problem

The thing poisonfountain does not list as a moat, and that the 768 comments rarely name directly, is the one that actually matters: the ability to choose which problem is worth solving.

The model can write the code. The agent can debug the bug. The MCP can pull the trace. None of them will tell you, before you spend a sprint on it, that the feature is going to alienate the paying user. None of them will tell you, before you accept the meeting, that the project is misaligned with the company’s actual strategy. None of them will tell you, before you ship it, that the real thing to do is say no.

That is the work that compounds. The harder the model gets at execution, the more leverage moves upstream to judgment, direction, refusal, and the discipline of building the right thing in the first place. poisonfountain’s closing line — that he is thinking of turning his woodworking hobby into a profession — is not a joke. It is a man noticing that the activities with no training data (making a chair with his hands, judging which feature not to build) are exactly the ones that will not be automated on his horizon.

The closing line

The 768 comments are not arguing about whether AI will replace software engineers. They are arguing about a much more uncomfortable question: why did a decade of compounding skill take a year to be matched?

The honest answer is: the skill was not hard, it was slow. The model is not afraid of hard. It is afraid of “nobody has done it before.” The moment somebody has done it, written about it, shipped it, and debugged it, the model can pick it up.

The moat did not disappear. It moved. It moved from “I know how to do this” to “I know what to do, why to do it, and when not to do it.”

That is the question every software engineer is going to have to answer in the next five years. The 768 commenters on HN that morning were not asking it in those words. But they were asking it.