Claude Code and the future of programming

I’ve been using Claude Code for two weeks and I need to talk about it.

This isn’t GitHub Copilot. Copilot is autocomplete. It guesses the next line based on the lines above it. Useful. Limited. Like a very fast typist who can read over your shoulder.

Claude Code is different. It reads your entire codebase. It understands the architecture. The patterns. The naming conventions. The decisions you made three months ago that created the constraints you’re working within today. And then it writes code that fits. Not generic code. Not template code. Code that belongs in your project.

I asked it to add a new feature to a system I’ve been building for months. It read 40 files, identified the patterns I’d established, and produced an implementation that followed those patterns exactly. Same naming. Same error handling approach. Same file structure. It even added a comment in the style I use.

That last part bothered me a little.

What programming becomes

For most of the history of software, programming meant translating human intention into machine instructions. You know what you want. You figure out how to tell the computer. The skill is in the translation.

Claude Code collapses the translation. You describe what you want. It writes the code. You review the code. You accept, modify, or reject.

The skill shifts from “can you write it” to “can you evaluate it.” From authorship to editorial judgment. From playing the instrument to conducting the orchestra.

I don’t think that makes programmers obsolete. Conductors aren’t obsolete. Editors aren’t obsolete. But the job is different. The bottleneck moves from “can you write this function” to “should this function exist” and “does it fit the system.”

What scared me

I asked Claude Code to refactor a particularly messy section of my codebase. The code I’d written over three days of incremental decisions, each one reasonable in isolation, collectively forming a tangle.

It untangled it in four minutes. The refactored version was cleaner, faster, and easier to understand. It found a subtle bug I’d introduced on day two and fixed it as part of the refactoring. It added error handling for edge cases I hadn’t considered.

The code it produced was better than mine. Not by a lot. But measurably, observably better.

I sat with that for a while.

What I’ve decided, for now

I’m using Claude Code for everything that’s well-defined. Features with clear specifications. Refactoring with obvious targets. Bug fixes where the problem is known. For these tasks, it’s faster and often better than me.

I’m not using it for the parts that require taste. System design. Architecture decisions. The judgment calls about what to build and what to leave out. The “should we” questions that no amount of code quality can answer.

For now, the division feels right. The machine handles execution. I handle intention. But I’m aware that “for now” is doing a lot of work in that sentence.

Programming in five years won’t look like programming today. I’m sure of that. I’m less sure of what it will look like, and whether people like me will recognize our role in it.

I keep using Claude Code. It keeps getting better. And I keep adjusting my definition of what “programmer” means.

Related thinking: