A response to “LLMs are Eroding My Software Engineering Career and I Don’t Know What To Do” - and to everyone I keep hearing this same anguish from. You’re not wrong that the ground is moving. You’re wrong about which ground.
I read this post twice. The fear was palpable. Ten years of payment systems expertise, distributed systems debugging chops, hard-won taste about code quality - and the punchline is that a model can now produce a passable explanation of double-entry ledgers in 30 seconds. I get it. I’ve talked to a dozen engineers in the last six months who sound exactly like this.
But I want to push back. Not on the symptoms - those are real. On the diagnosis.
The Misdiagnosis
The author’s argument is that three pillars - domain expertise, debugging skill, and code quality judgment - have each been individually commoditized by LLMs. Therefore the career is eroding.
That’s not how moats work. A moat was never any single one of those things. It was the combination, applied to a specific problem, in a specific business, under specific constraints, with skin in the game.
When you say “all my finance and payment domain expertise is now promptable” - what’s actually promptable is the textbook. The model knows what ACH is, what a chargeback is, how PCI-DSS reads. That knowledge was always cheap. It was in books. It was on Wikipedia. It was in the heads of a thousand junior PMs. Hell, I have NO IDEA what those really mean, but it’s 3 seconds away via prompt.
What was never cheap, and still isn’t, is this (completely fabricated things):
- Knowing that your settlement system has a 3:47am edge case where the FedWire cutoff collides with your retry logic
- Knowing that your compliance team will accept Option A but lose its mind over Option B even though they’re functionally identical
- Knowing which of your eight payment partners actually honors their idempotency keys
- Knowing that the “race condition” the new engineer is panicking about is actually fine because of a guarantee buried in a contract from 2019
That isn’t promptable. It isn’t even Google-able. It lives in your head and in the scar tissue of your team.
The Real Superpower: Domain × Software × AI
Here’s the formula I keep coming back to:
Domain knowledge alone? Commoditized.
Software skill alone? Commoditized.
Domain knowledge × software skill × AI fluency? Multiplied.
The author treats these as three separate moats that each got drained. They were never separate. The value was always in the product, not the sum. A payments domain expert who can’t ship code is a consultant. A great coder who doesn’t understand payments is a contractor who will build the wrong thing beautifully. The person who can do both - and now wields an AI agent that translates intent into ten thousand lines of working scaffolding overnight - that person is operating at a level the industry has literally never seen before.
This isn’t theoretical. I’ve written about this productivity shift - 100x on scaffolding, real numbers. But that 100x only lands if you know what to scaffold. The agent has no opinion about whether to use a saga pattern or a two-phase commit for your settlement flow. It has no idea which of your downstream consumers will silently fail if you change the message schema. It doesn’t know that your CFO reads every Tuesday’s reconciliation report personally.
You do. That’s the moat. The agent is the lever, not the fulcrum.
What the LLM Genuinely Cannot Do (Yet)
Let me be concrete. I run agents constantly. Here is what they’re great at:
- Producing plausible code that matches public patterns
- Summarizing public knowledge
- Drafting tests against a spec I wrote
- Refactoring within a clearly defined boundary
- Explaining unfamiliar code I drop into context
And here is what they consistently fail at - even Claude 4.7, even with massive context windows:
- Knowing what the right thing to build is, when the requirements are political
- Holding the actual business invariants that aren’t written down anywhere
- Smelling that a “clean” abstraction will break under a load pattern only you have seen
- Negotiating with a stakeholder who is technically wrong but organizationally right
- Owning the production page at 2am when the wire transfer didn’t go through and a customer’s payroll is at risk
Every one of those is a domain × software task. Every one of them is exactly the work that an experienced engineer in a specific business does every day. And every one of them is more valuable now, not less, because the cost of generating code has cratered while the cost of generating the wrong code at scale has gone up.
Also, the damn AI is not always right! Your domain knowledge and experience gives you good judgement - the kind that let’s you prompt back “verify that, since that’s not my understanding.” And you get the “I’m sorry, you were right to ask that…” response.
Domain expertise and judgement MATTER.
To the Author (and Everyone Feeling This)
You wrote that your career strategy was “become a deep specialist” and you’re worried that strategy is dead. I’d argue your strategy was never just “deep specialist.” You also became a competent engineer who can ship. You also learned to debug distributed systems. You also developed “good coding taste.”
What you have is exactly the stack that wins right now. What you’re missing is the third multiplier: fluency with the new tools.
If you spent the next 90 days doing this:
- Build one non-trivial payment workflow project using Claude Code or Cursor in agent mode - from spec, to plan, to tests, to code. End to end. Open source it.
- Write up what the agent got wrong about payments domain reasoning. Specifically. With examples. (Spoiler: there’s a lot. It’s incredibly useful content.)
- Build an MCP server that exposes your domain’s primitives - a sandboxed ledger, a settlement simulator, a compliance rule evaluator - so agents can actually reason against domain truth instead of guessing
- Post about all of it publicly
…you would not be a commoditized generalist at the end of those 90 days. You would be one of a very small number of people in the world who can credibly speak to “how do you actually do payments engineering in the agent era.” That is a more defensible position than “10 years of payments experience,” not a less defensible one.
The Pattern I Keep Seeing
The engineers I see panicking right now are mostly engineers who built their identity around one of the three pillars in isolation:
- “I’m the Kafka person” - they’re scared because the agent reads Kafka docs faster than they can
- “I’m the senior IC who writes elegant code” - they’re scared because the agent writes ugly code that passes the tests
- “I’m the domain expert” - they’re scared because the agent can summarize the domain on demand
In every case, the answer is the same: stop standing on one pillar. The job was never to be the best at one of those things. The job was to fuse them into shipped product that actually works in the real world for real customers under real constraints.
The agent didn’t take that job. The agent made that job bigger. One person with all three multipliers can now do what used to take a team of eight.
The Thing Nobody Says Out Loud
There is going to be a culling. I wrote about the three tiers and I stand by it. People who only ever had one pillar are going to have a rough decade.
But people with domain depth plus software skill plus agentic tooling fluency? You’re not the casualty of this transition. You’re the entire reason it works. Without you, the AI generates beautiful nonsense at scale. With you, it generates leveraged production systems.
Stop mourning the moat you thought you had. You have a much better one. You just need to pick up the new tool and start using it like it belongs in your hand.
That’s what’s eroding - not your career, but the version of your career where the tools never changed. Good. That version was always going to end. The one waiting for you on the other side is better.
Now go build something.