Your Career Isn't Eroding - You're Just Holding the Wrong Moat · Greg Herlein
Herlein
Home
Posts
About Me
Projects
Resume
Staffing
© 2018-2026. All rights reserved.
Built with Hugo<br>Theme Blackburn
Your Career Isn't Eroding - You're Just Holding the Wrong Moat
08 Jun 2026, 00:00
ai /
career /
software-engineering /
domain-knowledge /
llm /
agents
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...