I've Been a Multiplier for 12 Years. Now Everyone Is.

The most useful thing I learned in twelve years of building software isn't a framework. It's the moment, on every project, where the value stops coming from how fast you type.

I noticed it at year three. The mainframe-modernization rewrite I led wasn't won by syntax. It was won by knowing which conversations had to happen on a whiteboard before any code got written. The COBOL didn't matter. The order of the meetings did.

At year seven I noticed it again. Mid-career, leading the team that designed our healthcare AI agent platform, I was barely writing the agents myself. I was sitting with compliance, then with the SREs, then with the eval lead, then with the product manager — and the platform got built because I'd kept the dependency graph in my head and translated each conversation into the next one's vocabulary.

That's what senior engineering has always been. Translation, sequencing, and the courage to make decisions on incomplete information. The 12 years of pattern-matching aren't a shortcut to writing code faster. They're a shortcut to writing the right code at all.

The frame people are getting wrong

Now AI shows up. The frame everyone leads with is: senior engineers are about to be commoditized. The juniors get a 10x multiplier, the seniors lose their moat, the gap collapses.

I think the opposite is happening, and I think people are missing it because they're measuring the wrong skill.

Here's what AI actually compresses:

The cost of execution drops by 10x. Implementation that took 6 hours takes 30 minutes. This is real. I'm not arguing with that part.

The cost of judgment doesn't change. Knowing which 30-minute task to point at, in what order, with what acceptance criteria, with what rollback plan — that didn't get cheaper. It got more important, because now the failure mode is faster too.

What I see daily in Fortune 10 production AI

In an environment shipping production AI to half of US hospitals, this plays out every week. A junior engineer with Claude Code can produce more agent scaffolding in a week than a team of five did in 2021. What they can't yet do is know which scaffolding actually matters when an audit lands. Which prompt regression should hold the deploy. Which "small change" will quietly invalidate three months of eval baselines.

That's not a typing problem. That's a translation problem.

Three rules I've come to believe

1. Your value is in the boundary, not the body.

Anyone with a good LLM can write the function. The senior job is to know which function should exist, what contract it owes the rest of the system, and what the cost is when that contract changes. Boundaries are still hand-drawn.

2. The new skill is taste in feedback loops.

When AI implements 10x faster, the bottleneck moves to verification. Whoever can design the eval, the regression, the canary, the rollback — that person is doing senior engineering. Whoever can't is going to ship junk fast.

3. Compounding is back on the menu.

Pre-AI, your 12 years of pattern recognition compounded inside your head. Post-AI, they can compound inside your tools. Write your team's heuristics into agent instructions. Codify your code-review intuition into eval prompts. The senior engineers who don't compress their judgment into reusable artifacts are the ones who'll feel commoditized. The ones who do will feel ten feet tall.

The lesson

Twelve years of asking "how do you build software that thinks" turned into a career, an IEEE Senior membership, seven papers, and a Fortune 10 architect role. None of that was about typing. All of it was about translation.

AI changes the typing cost. The translation cost — what we actually get paid for — just became the only thing that matters.

What's your take?