The Code Isn't the Craft Anymore. The Quality Still Is.

A confession first.

I don't write code anymore.

I know. Hardly an original confession these days.

Well, almost. I still type the occasional correction or small tweak myself. But the bulk of it? AI writes it. I describe, steer, review, correct. And honestly? I don't miss it.

But lately, a second phrase keeps showing up next to it:

"I don't look at the code anymore."

That one, I don't fully agree with.

The two sound similar. They're not. The first is about how code gets produced. The second is about who is still responsible for understanding it.

And hidden in that second phrase is a question: if nobody writes the code and nobody reads it, does readability still matter?

I don't think that's true. But I also don't think the answer is to go back to the old way.

Readable Code Has Never Been Cheaper

For years, readability was a trade-off.

We all knew it mattered. But it cost time, and under deadline pressure, time was the first thing to go.

"We'll clean it up later."

We rarely did.

That trade-off is disappearing.

With the right instructions and some feedback, AI writes remarkably readable code. Descriptive names. Small, focused methods. Consistent patterns. Often cleaner than what most of us wrote at five on a Friday afternoon.

Unreadable code is becoming harder to excuse as a consequence of time pressure. Generating something understandable has never been easier. Making sure it actually makes sense is still our responsibility.

Readable code has never been cheaper! So there's never been less reason to skip it.

You're not writing the code anymore. You're defining what good looks like, and setting the bar it has to clear.

"I Don't Look at the Code" Needs Context

"I don't look at the code anymore" usually comes without any context.

Which app? Which audience? What's at stake?

So before agreeing or disagreeing, I'd like to know:

• Who are the users, and how much breakage will they tolerate?
• What happens when it fails? An annoyance, lost work, leaked data, a double charge?
• How long does this code need to live?

As I wrote earlier, not all fragility is bad. A quick internal tool doesn't need the same care as a payment flow.

The higher the stakes, the stronger the evidence you need that the software actually works. Reading code is one way to build that confidence, but it isn't the only one.

The statement isn't wrong. It's incomplete.

Fixed Within a Day

There's a pattern I've seen more than once.

A bug slips through. It reaches users. It frustrates them for a day or two. Then it's fixed.

From the builder's side, that looks like success. But the cost didn't disappear. It moved.

The user hit the bug. Lost some time. Maybe reported it. Maybe just quietly lost a little confidence in the product. Every one of those moments is a small withdrawal from a trust account that most teams never look at.

Speed over quality isn't new. "Move fast and break things" has been around for years. What AI changes is that breaking things got cheaper for the builder.

For the user, the cost hasn't changed.

And there's a follow-up question nobody seems to ask: if nobody read the code that caused the bug, what gives us confidence in the fix?

Where They Have a Point

To be fair, the other side has a point.

Not everything deserves careful reading. One-off scripts. Prototypes. Doodle apps that live for an afternoon. A game you build for fun, where a crash just means starting over. Reading every line there is effort better spent elsewhere.

And the tooling isn't standing still. AI reviewers, generated test suites, static analysis, better verification. It's very possible that in a few years, humans will read far less code than we do today.

That could be perfectly fine. Right now, I can't blindly trust what gets generated. But that's a statement about today, not forever.

But reading every line was never the point.

Read the System, Not Every Line

In the previous article, I wrote that architecture is guidance for AI. Clear boundaries tell it where responsibility lives.

But there's a second reader.

You.

With the right abstractions, you don't have to look at all the code.

We already work this way. Nobody needs to read the internals of Laravel or the PHP interpreter to ship a feature. We rely on their contracts, tests, maintainers, and track records.

AI-generated implementations haven't earned that same trust automatically. We have to establish it.

That's where the developer's role changes.

Humans remain responsible for the structure. The boundaries, the contracts, the responsibilities. What each part promises, and what it should never do.

AI fills in the implementations behind them, guarded by tests, types, and clear interfaces.

You review the shape of the system. You verify its behavior. You don't necessarily inspect every line.

That moves readability up a level. You don't need to read all the code. You need to be able to read the system.

Two caveats.

First: abstractions leak. Joel Spolsky wrote about this more than twenty years ago, and it still holds. When something breaks at the edge of an abstraction, you have to go below it. So the code underneath still needs to be readable enough to dive into. But when the incident hits at 3 AM, "I don't look at the code" stops being a choice.

Second: choosing the right abstractions is still one of the hardest parts. AI can propose structures, but without clear direction, it can just as easily introduce unnecessary layers or flatten responsibilities that should remain separate.

And what about the code underneath those boundaries?

It still needs to be readable. For the next AI agent that has to modify it, and for the human who occasionally needs to dive in.

But the bar is different. Above the boundary, the system needs to be easy to understand. Below it, the implementation needs to be understandable when necessary, not necessarily reviewed line by line.

And none of this guarantees quality. Beautifully structured code can still do the wrong thing.

The goal isn't to read less for the sake of reading less. It's to establish confidence in the software without having to personally inspect every implementation detail.

The Conductor Knows the Score

Earlier in this series, I compared working with AI to conducting an orchestra. You don't play every instrument.

The conductor doesn't read every note during the performance either.

But they know the score. They know how the parts fit together. And when something sounds off, they know exactly where to look.

I don't write the code anymore. I don't read every line anymore. But I still need to understand the system, know where to look when something goes wrong, and make sure what we ship deserves the user's trust.

The code isn't the craft anymore. The quality still is.