Reading is the new writing

Most people learning to code right now are learning to write it. That was the right skill for fifteen years. It isn't anymore.

The work has shifted. An AI hands you working-looking code, and you decide whether to ship it. The bottleneck is no longer how fast you can write. It's how well you can read what got handed to you.

I spend a lot of my time auditing AI-built systems, and most of them fail in the same handful of ways. Exposed API keys in client code. Database calls with no auth check in front of them. Tests that don't actually test anything, they just call a function and assert it returns. Architecture decisions that were never made deliberately, just defaulted into. The patterns are remarkably consistent across projects, and they share the same root cause. Nobody read what the AI produced closely enough to catch them.

the curriculum has the order backwards

Most coding curricula still treat reading as the thing you do after you've learned to write. You start with syntax, then small programs, then small projects, then maybe testing and security somewhere near the end. The skill you actually need to be useful right now, reading code other people or other models wrote, sits at the bottom of the stack if it shows up at all.

That order made sense when most code in front of you was code you wrote. It doesn't now. Most code in front of you on any given workday is code you didn't write. The skill of looking at it and knowing what to ask is the skill that pays.

what to focus on instead

A different order, in roughly the priority I'd give it:

1. Read more than you write. Start with the basics: syntax, language structure, enough to recognize what you're looking at. Don't skip the foundation, but don't linger there either. Real learning happens when you read real code from real projects, not just code you're generating. Have an AI walk you through it line by line if you need a tutor, but don't outsource the noticing.

2. Learn what good structure looks like. Architecture, data flow, boundaries, what calls what, what changes together when you change one thing. Watch for the same fact stored in multiple places: config values, magic numbers, repeated strings. Duplicated facts are how systems drift over time. This is what AI agents are worst at and where you're most likely to be the only one catching the problem.

3. Treat security as a default habit, not a final pass. AI almost never raises it on its own. Learn how secrets get exposed, how auth flows work, where SQL injection comes from, what a leaked key actually looks like in the wild.

4. Use version control like a safety net. When an agent goes sideways (and they do), git is the difference between losing an hour and losing a week.

5. Build things, then audit your own. Every project you finish is reading material. Re-read your own code two weeks later. You'll see what an audit feels like from the inside, and you'll start to recognize the patterns in other people's work.

the bigger thing

What I see in the systems I audit is rarely a writing failure. It's a reading failure. The code worked when it shipped, because nobody asked the questions a reader would ask. Six months later, those unasked questions are bugs, breaches, and rewrites.

Treat AI output as a hypothesis, not a result. Until you've read it, you don't know what you have.

The bar to write code has collapsed. The bar to read it well hasn't moved. That's where the work is now, and that's the skill to build.