I’ve been building with Claude Code (Opus 4.6) across multiple projects for a while now, and a pattern has become impossible to ignore. It’s not the pattern most people are talking about.

The dominant narrative is that AI coding tools will flatten the engineering landscape — that junior developers will suddenly produce senior-level output, that domain expertise will matter less, that we’re all about to be replaced by a prompt. I think this is almost exactly backwards.

What I’m actually seeing

I’m building a DEX aggregator. The core of it is a min-cost max-flow solver written in Rust — the kind of algorithm where you’re jointly optimizing swap routes across 20+ decentralized exchanges within a 300ms batching window. This is not “build me a CRUD app” territory. This is graph theory, network flow optimization, and real-time systems design all colliding at once.

Claude Code has genuinely changed my velocity on this project. But here’s the thing people miss: it changed my velocity because I already knew what to ask for.

When I’m exploring whether a particular LP fee structure breaks my cost function’s convexity, I can describe the problem precisely and iterate on solutions in minutes instead of hours. When I want to test whether a ring trade detection heuristic actually improves output quality, I can spin up the experiment fast. When I need to refactor how pool state gets synchronized from a local node, I can describe the architectural constraint and get useful code back.

But none of this works if I don’t understand the problem deeply enough to evaluate the output. Claude Code doesn’t know that a particular approach will blow up my latency budget. It doesn’t know that a theoretically elegant solution will fail in practice because on-chain pool reserves are stale by the time the transaction lands. I do. And that knowledge is what turns the tool from a fancy autocomplete into a genuine multiplier.

The amplifier thesis

Here’s what I think is actually happening: AI coding tools are amplifiers, not equalizers.

If you’re an engineer who has spent years building intuition about systems — who can look at a proposed architecture and smell that it won’t scale, who knows which algorithmic approach to reach for before writing a single line of code, who understands the domain deeply enough to reject a plausible-looking but subtly wrong solution — then Claude Code hands you a jet engine. You already knew where to fly. Now you get there in a fraction of the time.

If you don’t have that foundation, you get… a very confident generator of code that you can’t properly evaluate. And in domains where correctness matters — finance, infrastructure, anything touching real money or real users — code you can’t evaluate is worse than no code at all.

I’ve been doing competitive programming for most of my career. ACM ICPC, olympiad-level algorithmic work. The mental models I built during those years — graph decomposition, flow networks, dynamic programming on exotic structures — are exactly what let me have a productive conversation with Claude Code about hard optimization problems. The AI didn’t give me those models. But it lets me apply them at a speed I never could before.

What this means in practice

A few concrete observations from months of building this way:

The guidance overhead is real but worth it. I still spend significant time framing problems, reviewing output, and course-correcting. This isn’t “fire and forget.” It’s more like pair programming with a very fast, very knowledgeable partner who has no long-term memory and occasionally confident blind spots. The net productivity gain is enormous, but it comes from the quality of direction I provide, not from abdicating it.

Experimentation speed is the real unlock. The biggest change isn’t that I write code faster. It’s that I can test ideas faster. I had a hypothesis about whether yield-bearing limit orders could work as a go-to-market wedge for the aggregator. Previously, validating that would have taken me days of implementation before I could even see if the economics worked. Now I can prototype, stress-test, and either commit or discard in a fraction of the time. The loop from “I wonder if…” to “here’s the data” has compressed dramatically.

Domain expertise becomes more valuable, not less. Every hour I’ve spent understanding AMM mechanics, studying how different DEX architectures handle slippage, or analyzing how pool reserve freshness affects routing quality — all of that knowledge compounds harder now. Because each piece of domain insight lets me direct the AI more precisely, and more precise direction produces better output. The returns on deep expertise just went up.

Who should be worried, and who shouldn’t

If your engineering work consists primarily of translating well-understood requirements into standard implementations — standard web apps, routine data pipelines, CRUD with a framework — then yes, AI tools are going to compress the value of that work. Not because the tools are brilliant, but because those problems are well-specified enough that the AI can handle them with minimal guidance.

If your work involves navigating genuinely hard technical trade-offs, inventing novel approaches to unsolved problems, or operating in domains where the difference between “looks right” and “is right” requires deep expertise to judge — then you just got a massive upgrade. The hard part was never typing. It was thinking. And thinking just got a much faster feedback loop.

The bottom line

Claude Code Opus 4.6 is the best coding tool I’ve ever used. But it’s the best tool for me specifically because I’ve spent two decades building the judgment to use it well. It doesn’t replace the years I spent on competitive programming. It capitalizes on them.

The engineers and researchers who are going to pull ahead in the next few years aren’t the ones who learn to prompt better. They’re the ones who already have deep technical foundations and now get to iterate on hard problems at a speed that was previously impossible.

The gap between “good engineer with AI tools” and “average engineer with AI tools” isn’t closing. It’s widening. And if you’re on the right side of that gap, this is the most exciting time to be building.