A fintech engineer's three pillars fell one by one to LLMs

A fintech specialist watches each pillar collapse

The post appeared on a blog with a single entry — the domain name itself a job description: human-in-the-loop. The author is a software engineer with a decade of fintech experience: PCI compliance, double-entry ledgers, escrow flows, idempotency, reconciliation. They describe building three competitive pillars over those years, then watching Claude dismantle them in sequence over roughly six months.

What the author actually wrote — three pillars, three losses

Pillar one: domain knowledge. The author concedes that LLMs now connect the dots on how to structure payment systems, which was the hardest part. Finance and payment logic that took years to internalize — acquiring flows, idempotency patterns, payment lifecycles — is now promptable. Their manager encouraged leaning into AI despite early skepticism.

Pillar two: debugging and distributed systems. This was supposed to be the human stronghold. Instead, Claude 4.6 and 4.7 one-shots 90% of bugs across distributed systems, including race conditions that previously took two full days to isolate. The author "hardly has to intervene" on bugs they once considered their signature contribution.

Pillar three: architectural taste. The last redoubt: DDD, hexagonal architecture, clean SOLID patterns. But the author observes that the market no longer demands A-grade codebases. The company's hiring shifted — postings that once said "Software Engineer – Payments" now read "Software Engineer" with team assignment after offer accepted. Former colleagues with deep domain expertise remain unemployed.

The conclusion is flat: "I'm just another off-the-shelf engineer now. If everyone is a generalist, the price of a generalist falls."

What the thread said — four strong reversals

In the thread, the 855-comment pushback was immediate and detailed.

Reversal 1 — the FinTech insider with a burner account. A commenter posting anonymously to avoid doxxing described working in a regulated FinTech product with access to Mythos, described as the most bleeding-edge model available. The model confidently identified part of their codebase as non-compliant with a specific regulation — code already reviewed by human counsel and actually fine:

"It had of course hallucinated what the regulation actually required… There is no way in the mid-term we could ever rely on these tools to actually ship compliant financial products. We'd have to be totally mad." — a FinTech engineer posting under a burner account

Reversal 2 — the ML practitioner and heavy LLM user. A commenter who runs Claude on an industry scale for over six months listed specific failure modes they hit constantly: suggesting removing tests to unblock builds; silently adding features they did not ask for; using a second code path instead of fixing the original; being unable to operate without a verifiable goal:

"I am still a heavy user but there are a lot of value in recognizing where exactly LLM's limit is and work around that." — a heavy LLM user and practitioner

Reversal 3 — the DevOps veteran who tried everything and regressed. A DevOps engineer described their firm cycling through every agent configuration — single agent, multiple agents, agents building tools — before landing back on deterministic scripts usable by both humans and LLMs:

"Coding may be dead but software engineering is alive and kicking." — a DevOps engineer at an LLM-enthusiastic firm

Reversal 4 — the co-founder who thinks the author undersells themselves. A former CTO (MUBI, HotelTonight/Airbnb) argued the author is devaluing their own expertise prematurely:

"There's a huge chasm between what AI can do when prompted by an expert software engineer vs a non-technical person… it still needs to be driven by someone with an intuition for how software works and able to dig in when necessary." — a former co-founder and CTO

The rule that emerges

The most precise observation in the thread came from an engineer with years of production systems experience:

"You do need to know your codebase. You do need to iterate on small chunks of it at a time. You do need to carefully understand every line of code you're putting into production." — a senior software engineer

The author's anxiety is real, but the thread reveals an asymmetry they may have missed: they can call BS on the agent because they know the domain. The engineer who cannot call BS is not a generalist empowered by AI — they are a liability in a regulated system. The market has not yet found a way to price that distinction, which is precisely what makes the moment feel so disorienting.