LLMs Eroding Your Career? Domain Knowledge Is Your Moat

Recently, a post titled "LLMs are eroding my software engineering career and I don't know what to do" hit the front page of Hacker News and sparked a firestorm of 360 comments. The author, a senior engineer with a decade of experience, articulated the fear that skills honed over years are being commoditized overnight. But is the story accurate? And more importantly, what should builders do about it?

The HN Story: How LLMs Are Devaluing Code Writing

The author describes three pillars of his career—writing code, understanding systems at scale, and deep domain expertise (specifically in financial transaction systems)—and argues each is being dismantled by frontier LLMs. He shares how AI can now produce production-quality code, reason about distributed systems, and explain complex business logic. The implication: if an LLM can do what took you a decade to learn, what value do you bring? The tone is genuine distress, and it resonates because it touches a raw nerve.

Hacker News Reacts: Domain Expertise Still Matters

The community reacted with a mix of sympathy, skepticism, and pushback. Many challenged the premise, pointing out that LLMs still fail in nuanced, business-critical ways. One commenter wrote:

"LLMs routinely fail at our business specifics: Local tax regulations, particularities of the accounting process, specifics of our ledger implementations. They're great at refactoring, translating between languages, tracing bugs on existing code even, but there is always many things subtly wrong iterating and expanding our domain."

Another added a blunt reality check:

"Wut? I pilot LLMs all day but there's no way in hell I'd agree to be at the helm of a finance product. That first pillar is still there."

These comments highlight a critical gap: LLMs excel at generic patterns but struggle with the messy, specific constraints that define real software. The thread collectively argues that domain expertise—knowing what not to do—remains the engineer's strongest moat.

My Take: Engineering Judgment Over Code Production

The author's fear is understandable, but I think he's drawing the wrong conclusion. Yes, LLMs can generate plausible code and summarize system architectures. But software engineering has never been just about producing output. It's about making judgment calls under uncertainty: choosing the right tradeoff, spotting a subtle security flaw, or knowing when to say "no" to a request that would break the system.

LLMs are probabilistic machines. They don't understand the domain; they pattern-match. In finance, health, or any regulated space, a 95% accuracy rate is a disaster. The human in the loop is not a relic—it's the only thing that prevents catastrophic releases. The author's first pillar—writing code—may be shrinking, but the pillars of reviewing code, validating outputs, and battling for correctness are taller than ever.

Moreover, the HN thread suggests the author's experience may be an outlier. Many engineers report that LLMs still need heavy guidance for non-trivial tasks. The real shift is not that expertise is dead, but that the nature of expertise is changing. We are moving from being producers to being conductors—directing the machine, catching its errors, and integrating its work into a coherent, safe whole.

What Builders Should Do: Deepen Domain Knowledge, Become Reviewers

If you're a developer feeling the heat, here are concrete implications:

Deepen your domain knowledge. The more you know about your business logic—regulations, edge cases, user behavior—the more irreplaceable you become. LLMs can't reason about your specific financial compliance rules or the quirks of your legacy monolith.

Become a reviewer, not a writer. Shift your workflow: let the LLM generate a draft, then spend your energy refining, testing, and verifying. This is harder than writing from scratch because you must think critically about what the machine produced.

Build systems that check the LLM. For example, if you're using an LLM to generate SQL queries, wrap it with a validation layer. Here's a simple Python example using the re module:

import re

def validate_query(sql):
    # Whitelist allowed operations
    allowed = ["SELECT", "INSERT", "UPDATE", "DELETE"]
    for op in re.findall(r'\b\w+\b', sql):
        if op.upper() in ["DROP", "TRUNCATE", "ALTER"]:
            raise ValueError(f"Dangerous operation detected: {op}")
    return sql

This is a simple guard, but it shows the pattern. For more robust checks, refer to OWASP's SQL Injection Prevention Cheat Sheet and the Wikipedia article on SQL injection.

Double down on review tooling. Invest in code review practices, automated tests, and monitoring. The best use of your time is to catch the LLM's errors before they reach production.

Don't underestimate the 'care' factor. As one commenter noted, the human willingness to "stay with the thing" is invaluable. LLMs don't care about the midnight outage or the long-term maintainability of your code. That's your job.

Should You Worry? It Depends on Your Domain Depth

Yes, if you're a junior or mid-level engineer who relies on coding speed as your primary value proposition. The bar for raw code production is dropping, and you need to differentiate yourself through system thinking and domain depth. No, if you're already deep in a specialized, high-stakes domain—finance, healthcare, safety-critical systems—your expertise is more valuable than ever because the consequences of the LLM being wrong are too high. The author's pillar may have cracked, but the foundation of engineering judgment is still solid. The key is to stop seeing yourself as a code writer and start seeing yourself as a quality guardian.