The John Henry Problem - Why Racing Against AI is a Losing Game

The John Henry Problem - Why Racing Against AI is a Losing Game

You know the story of John Henry. Steel-driving man. When the railroad company brought in a steam-powered drill, Henry challenged the machine to a contest. He'd prove that a man could outwork any machine.

He won. Drove more steel than the steam drill. Then his heart gave out and he died with his hammer in his hand.

The folk song celebrates this as a triumph. It's not. It's a cautionary tale about vanity and misplaced pride. John Henry "won" by destroying himself. Meanwhile, the workers who picked up the steam drill kept their jobs, went home to their families, and built more railroad than Henry ever could have imagined.

I think about John Henry when I see developers competing against AI coding assistants.

The vanity of winning

Every few weeks, someone posts a thread showing how they wrote cleaner code than Claude. Spotted a bug the AI missed. Architected a better solution. And sure, maybe they're right. Maybe their implementation was genuinely superior.

But at what cost?

You spent three hours proving you're better than a tool. The tool doesn't care. It doesn't have an ego. It's not keeping score. You are.

This is the John Henry problem. You're optimizing for winning a contest that doesn't matter. The question isn't whether you can outcode an AI in a specific instance. The question is whether that's how you want to spend your time.

The wrong competitor

Here's what's actually happening: you're treating AI as your competitor when it's your steam drill.

The steam drill wasn't the enemy. It was leverage. The railroad workers who understood this thrived. They could bore tunnels faster, safer, more efficiently. They became operators instead of laborers. Their skills shifted from raw physical strength to judgment, planning, and problem-solving.

The workers who refused the drill? History forgot them. Not because they were bad at their jobs, but because they were competing in a contest the market had already declared over.

AI coding assistants are the same dynamic. You can race them if you want. You can prove that in this specific instance, on this particular problem, you wrote better code. But while you're doing that, other developers are using AI to ship ten times as much. They're not competing against the tool. They're wielding it.

The real fear

I get it. The anxiety is real. If AI can write code, what's my value as a developer?

But this question reveals a fundamental misunderstanding about what developers actually do. You're not a code-writing machine. You never were. The value you provide has always been judgment, context, and systems thinking.

AI can generate implementations. It can't decide what to build. It can't navigate organizational politics. It can't determine which technical debt to pay down and which to leave alone. It can't look at a product roadmap and identify the six-month detour disguised as a two-week feature.

These skills don't disappear when AI writes your for-loops. They become more valuable. The bottleneck shifts from "how fast can we type code" to "how well do we understand what code to write."

The steam drill operators thrived

Let's go back to the railroad. After the steam drill arrived, what happened to the workers who adopted it?

They didn't become obsolete. They became more valuable. A worker with a steam drill could accomplish what ten workers with hammers used to do. That worker got paid more. Had more job security. Became harder to replace.

But the skill wasn't "operate steam drill." The skill was "understand railroad construction well enough to apply a powerful tool effectively." The drill amplified their expertise. It didn't replace it.

AI coding assistants work the same way. A developer with AI can ship what a team of five used to ship. But that's only true if the developer knows what to ship, how to architect it, and which corners are safe to cut.

The AI doesn't have that judgment. You do. The AI is your steam drill. The question is whether you're going to pick it up or challenge it to a race.

How to be the drill operator

So what does this actually look like in practice?

Stop optimizing for the typing. If you're still measuring your value by lines of code written per hour, you're measuring the wrong thing. The keyboard is not your bottleneck anymore. Your bottleneck is understanding the problem well enough to specify a solution.

Get better at prompting. This sounds obvious, but most developers treat AI assistants like fancy autocomplete. They're not. They're reasoning engines. The better you are at articulating what you want, the more leverage you get. This is a skill. Develop it.

Focus on the parts AI is bad at. AI struggles with ambiguity, organizational context, and long-term architectural decisions. These are exactly the skills that make senior developers valuable. Double down on them.

Use AI to explore faster. Want to understand how a library works? Ask the AI to generate examples. Evaluating architectural tradeoffs? Have it scaffold both approaches. You're not abdicating judgment—you're expanding the solution space you can consider.

The developers who thrive in the AI era will be the ones who stopped competing with their tools and started wielding them.

The death knell

Here's the uncomfortable truth: if you're still trying to prove you're better than AI at writing code, you've already lost.

Not because AI is better. But because you're playing the wrong game. You're John Henry, focused on winning a contest while the world moves on without you.

The developers who picked up the drill aren't worried about whether they can out-code an AI. They're busy shipping products, solving real problems, and building things that matter. They're using AI to handle the tedious parts so they can focus on the interesting parts.

They're not racing the machine. They're operating it.

The choice

Every time you open your editor, you make a choice. You can compete against your tools, or you can use them.

You can spend three hours hand-crafting a solution to prove a point, or you can spend thirty minutes directing an AI and two and a half hours solving the next problem.

You can be John Henry, winning a pyrrhic victory, or you can be the operator who went home at the end of the day and came back tomorrow to build more.

The folk song doesn't mention those operators. But they're the ones who built the transcontinental railroad. They're the ones who fed their families. They're the ones who lived.

The steam drill operators thrived. The question is whether you will.

If you want to go deeper on integrating AI into your development workflow, I put together a free study guide that covers the fundamentals. It's the resource I wish I had when I started questioning whether I should compete with these tools or learn to wield them. Get the AI Study Guide