In 2023 I wrote Can GitHub Copilot make you a worse programmer?. At the time, Copilot was one of the first introductions of AI into mainstream programming. My main predictions were:

• Copilot would boost productivity for senior programmers but dull their chops
• Prevent junior programmers from building expertise through repetition

In some ways I was right, and in other ways I completely missed the broader changes. When I wrote about programming in that post, it was more about physically writing lines of code. I didn’t consider software engineering as a broader topic. Now I’m prompting and guiding agents, not typing out code.

Writing was the first step

Historically, a computer was a person. When computing devices were invented, the code they executed was written by humans. Eventually, higher-level languages and compilers took over the role of writing machine code. Today, the code computers execute is, at least in my world, almost entirely written by agents. The higher level language now is English and the prompts I provide to agents.

Reviewing is the bottleneck

OK, sure. I’m not writing code anymore. What about reviewing code? If writing code requires 1x effort, I’d say reviewing it takes 0.25x effort. Earlier this year, AI assisted coding was like 4x the velocity of doing it manually. At that pace, it was reasonable to still review code manually. Today, it feels more like 100x. Reviewing code the same way isn’t practical anymore.

My solution is to use tooling and AI to support reviews at that scale. What I review is shifting from the lines of code to the API contracts, architecture changes, invariants, algorithms, schemas, and specifications.

What I still need to read

Programming languages and compilers have well-defined and specific behavior. The transformation from a high level language to machine code is precise. The prompts I provide my agents in English generally are not. Agents also do not always write excellent code. That means I still need to confirm:

• it does what I intended
• it follows my style and conventions

The top frontier agents often seem to intuitively “get” what I prompt them to do, but I find that other models struggle. They might think too shallowly or treat a symptom of a bug instead of the root cause.

I’ve found (especially with frontier LLMs) that with solid rules and guidance files (AGENTS.md, CLAUDE.md), code review skills, charters, code maps, and package maps, agents are better at finding bugs and enforcing consistent style—and doing it systematically.

I’m having them do more and more code reviews. And as time goes on, the proportion of PRs where I still read the diff is decreasing. Reviewing a change doesn’t always require me to read its implementation.

The changes where I definitely don’t need to read the code are those isolated to a single file or package, with no changes to APIs or package interfaces. When a change crosses package boundaries or involves something beyond straightforward CRUD, that’s where I’ll at least take a peek.

Agents do what I prompt them to do, and often I don’t tell them to think through the long-term consequences of their work.¹ As an architect (and especially as a technical founder), I know that decisions I make today may affect things tomorrow, a week from now, or even a year from now. That makes me more careful about how I design or implement things. For now, those are decisions where I still want to understand the implementation.

LLMs are improving every week. These limitations and problems are temporary. As with SQL, where humans declare what a query should return and a machine planner and executor determine execution, what will matter most is how I define the intent and objective. Then let the machines and agents figure out how to execute.

What I learned from my own experience is that more of my work building software now is about thinking through architecture (the structure and processes involved in software), requirements, specifications, and UX. Turns out this is way more complex to reason through than individual lines of code and things like how to best write a certain for-loop.

It’s been a while since I’ve written any significant code by hand. I may have gotten a little rusty with my programming. But what I have been improving a lot is software design and architecture, and reasoning through complexity.

I still wonder what will happen to the junior programmers who are yet to put in all their reps. I learned a lot by writing code and living with my mistakes. Whether that kind of experience will still be worth it in the future, I don’t know. Knowing assembly isn’t as useful as it once used to be.

So the question is not whether I will stop reading code. It will happen. The question is how long it will take to get there.