I've been writing code for decades, with breaks in between. In that time, the conversation flipped from "learn to code" to "AI will replace coders." Both camps make the same mistake: they treat programming as typing syntax. That was never the job.

The joy of programming was never about translating ideas into the right syntax. It was about maximizing what computers can do: better, faster, easier, cheaper than we could alone.

Once you see this, the current moment stops feeling like a threat. It becomes the most exciting time to be a developer since the internet. (Stick around for the practical suggestions at the end.)

What Programmers Actually Do

Here's what I've learned from shipping multiple projects, some in rapid cycles: the hard part was never the typing.

The hard part is figuring out what to build. It's understanding the problem well enough to know which solution actually matters. It's catching yourself when you're solving the wrong problem with more code instead of a better question.

Syntax is just notation. The real work happens before and after the code appears on screen.

Before: What does this need to do? Why? For whom? What's the simplest version that delivers value?

After: Does it work? Does it solve the real problem? What did I learn? What needs to change?

AI handles the middle part increasingly well. But the bookends, the thinking that makes the typing meaningful, remain stubbornly human. At least for now. And I'd bet forever, at some level, even as that level grows more abstract.

This isn't new. We've seen this pattern before.

The Pattern We Keep Forgetting

In the 1950s, programmers wrote machine code by hand. They punched cards. They debugged by staring at hexadecimal dumps. Then FORTRAN arrived in 1957, and many dismissed it.¹ "Programs compiled from high-level language would be less efficient than those written directly in machine code," they said.

Sound familiar?

The skeptics were technically right. Early FORTRAN programs sometimes ran slower than hand-tuned assembly (which I have brief experience with). But they missed the bigger picture: FORTRAN let programmers "focus on solving problems rather than managing low-level hardware details."² The leverage was enormous. One programmer could now do what previously took a team.

This pattern keeps repeating. Assembly to FORTRAN. FORTRAN to C. C to Ruby (my preference) or Python. Each jump traded some control for massive gains in what one person could build.

The Leverage Mindset

Photography taught me this. When I got my first good camera, I thought the equipment would make me a better photographer. It didn't. The camera just removed friction between seeing and capturing. The skill was always in the seeing.

Programming works the same way. AI tools remove friction between deciding and implementing. But they don't decide for you, not in any meaningful way yet. They amplify whatever clarity or confusion you bring to the problem.

That's why some developers ship in days what used to take weeks, while others generate mountains of code that does nothing useful. Same tool. Different operator.

That shift in scarcity is the whole point of The New Bottleneck: building got cheaper, so judgment got more expensive.

85% of developers now regularly use AI tools for coding, according to JetBrains' 2025 survey.³ But adoption doesn't equal mastery. The developers pulling ahead aren't generating the most code. They're the ones who know what code to generate.

So what separates them?

What Actually Matters Now

The skills that matter haven't changed. They've just become impossible to ignore.

Taste. Knowing what to build and what to skip. This compounds slower than technical knowledge but lasts longer. AI can generate a thousand variations. Choosing the right one still requires judgment, even when AI helps filter.

I push that idea further in The Uber-Engineer Doesn't Write Code, where the leverage moves from typing toward orchestration and decision quality.

Problem definition. The question shapes the answer. Vague prompts produce vague results, whether you're prompting AI or your own brain. Getting specific about what you actually need unlocks everything else.

Context beyond the codebase. AI context windows keep growing, and they're getting better at understanding how code connects. But some context never lives in code: the business constraints, the user who'll actually touch this, the politics of your team, what your competitor just shipped. The calls that matter most depend on information the AI doesn't have.

Speed of iteration. Not typing speed. Thinking speed. How quickly can you try something, learn from it, and adjust? AI accelerates the trying. You still have to learn to make better calls and ask better questions.

The Opportunity Hiding in Plain Sight

Here's what excites me: the barriers to building have never been lower. One person with good taste and clear thinking can now build what used to require a team.

This isn't about AI replacing programmers. It's about programming becoming higher-leverage. Less time fighting syntax. More time solving problems worth solving.

The developers who thrive won't be the ones who memorized the most APIs or wrote the most algorithms by hand. Knowing what exists is enough, and AI will become a better researcher than any of us. The winners will be those who understand what computers can do for people and keep finding new answers to that question.

The joy was always in the leverage. The tools just got better.

The Practical Bit

If you're wondering how to adapt:

  1. Get specific about problems. Before touching code, write down exactly what you're trying to accomplish and why. This pays dividends with or without AI. AI can help here too, but the decisions are yours.
  2. Build more, polish less. The cost of trying things dropped dramatically. Use that freedom to run more experiments, not to gold-plate fewer projects. Soon AI will handle more polish too, but taste will remain yours.
  3. Ship and learn. The feedback loop matters more than the first draft. AI gets you to something testable faster. Use that advantage.
  4. Study taste, not just technique. Read about product decisions, not just implementation details. The bottleneck shifted.

The best time to be a programmer was always now. That's still true. The tools just make "now" more interesting than ever.

Rabbit Hole

  1. History of programming languages, Wikipedia
  2. The Evolution of Programming Languages, Kodegasm, Medium
  3. The State of Developer Ecosystem 2025, JetBrains Research