There’s a narrative floating around that AI will replace domain experts. That if the model can generate code, write architecture docs, and explain EMV flows, then maybe you don’t need the person who spent years learning those things.

That narrative is wrong. And it’s wrong for a specific, structural reason — not a sentimental one.

Domain Expertise Is a Multiplier, Not a Commodity

There’s a pattern worth noticing in how people get real value from AI tools: domain expertise acts as a multiplier. The more you understand a field, the better you prompt — not because you’ve learned “prompt engineering” as a standalone skill, but because you already have the vocabulary, the mental models, and the intuition to ask precise questions.

If you understand ISO 8583, you don’t ask “how do payment messages work.” You ask “what’s the correct DE 55 TLV structure for a contactless Visa ARQC with CDA.” The model gives you a dramatically better answer — because you gave it a dramatically better input.

But prompting is only half the equation.

The Verification Problem

More critically, domain experts are better at verification. You can cross-check outputs against what you already know, spot inconsistencies, and catch hallucinations that a non-expert would simply accept.

This is the part that doesn’t get enough attention. Language models are fluent. They produce coherent, confident, well-structured output. And that fluency is precisely what makes them dangerous to non-experts — because the output looks right even when it isn’t.

An experienced payment architect will immediately notice when a model invents an EMV tag that doesn’t exist, or describes a CVM fallback sequence that violates scheme rules, or suggests a DUKPT key derivation step that’s subtly wrong. A non-expert won’t. They’ll accept the output, build on it, and discover the error much later — during certification, during production, or during an incident.

This is why AI in its current form is better understood as amplified intelligence — it scales what you already bring to the table. It doesn’t replace the need to know things. It makes knowing things more powerful.

The Implication for Technical Fields

This has an important implication for fields like payment systems architecture, cryptography, and EMV certification: depth of expertise doesn’t become less valuable as AI improves. It becomes more valuable, because it’s precisely that depth that determines the quality of the collaboration.

The engineer who deeply understands terminal risk management will use AI to generate configuration options faster and explore edge cases more broadly. The engineer who doesn’t understand terminal risk management will use AI to generate plausible-looking configurations that fail certification.

Same tool. Opposite outcomes. The variable is the human.

Why Language Models Worked in the First Place

The success of language models is often misunderstood. People focus on the reasoning capabilities — the apparent logic, the coherent arguments — but that’s only part of the story. What actually happened is more subtle, and more surprising.

Humans have spent decades assigning machine-readable labels to the world. Every image captioned, every concept described, every experience written down. Language became a proxy for reality. And it turns out that in roughly 40 words, you can describe an enormous variety of things — spatial relationships, causal chains, abstract ideas. Language is more like code than we realized: compact, composable, and remarkably general.

That generality is what scaled. Not because anyone designed it that way, but because the world had already done the labeling work. AI didn’t need to see the world directly — it just needed to read what people wrote about it.

There is an irony here worth sitting with: the closer you are to a technical breakthrough, the harder it is to see it coming. Proximity creates blind spots. The people who should have anticipated the impact of language models were often the last to grasp their implications — not because they lacked intelligence, but because their existing mental models got in the way.

What This Means in Practice

If you’re an engineer working with AI today, the takeaway is concrete:

Invest in depth, not shortcuts. The engineers who get the most from AI are the ones who already know their domain deeply. AI amplifies competence; it doesn’t create it.

Verify everything. Fluency is not accuracy. The model will confidently tell you something wrong with perfect grammar and impeccable structure. Your domain knowledge is the only filter that catches this.

Prompt with precision. The quality of AI output is directly proportional to the specificity of your input. Vague questions get vague answers. Expert-level questions get expert-level answers — or at least answers you can meaningfully evaluate.

Understand the tool’s limits. AI reads what people wrote about the world. It doesn’t understand the world itself. It doesn’t know what happens when your terminal loses connectivity mid-transaction, or what the issuer will actually do with a malformed DE 55. You do.

The Bottom Line

AI is not coming for the experts. It’s coming for the people who thought they could skip becoming one.

The best engineers I work with don’t use AI to avoid thinking. They use it to think faster, explore more broadly, and validate more rigorously. The tool amplifies what’s already there.

If what’s already there is deep, the amplification is extraordinary. If what’s already there is shallow, the amplification is noise.

Build the depth. The tools will follow.

References

• Andreessen, M., & Casado, M. “The Verification Problem.” The a16z Show, Andreessen Horowitz, 2024.
• The Obsolescence Paradox: Why the Best Engineers Will Thrive in the AI Era — the case for why engineering expertise becomes more valuable in the AI era
• AI Sycophancy: Your Model Is Trained to Please You, Not to Be Right — related post on AI’s tendency to agree rather than challenge
• Prompt Engineering for POS — companion post on structuring AI inputs in payment systems