Skip to main content
You can generate a million lines of code in an afternoon. You can also delete all of it before dinner and start fresh. When code is that cheap to make and that cheap to throw away, any single line of it is worth less than it used to be. Code matters less than ever now. It also matters more than ever. I’ve been trying to work out why both feel true.

​
The naive version

The easy conclusion is that code no longer matters at all. AI writes it, AI rewrites it, you ship it. Why read it? Why care how it’s structured? This is the vibe coding pitch, and I understand the appeal. For a weekend project or a throwaway prototype, it’s often the right call. But “the code doesn’t matter” falls apart the moment you have to live with what you built.

​
What I stopped caring about

AI did change how I work, though not in that direction. It let me step back from the code and look at how my application behaves. That shift only works if you can see the behavior, which is where observability earns its keep. Good metrics, traces, and logs let me watch what the application does in production without reading a line of it. The less I lean on the code, the more I lean on that. I care that my application filters rows in the SQL query, not in memory after fetching everything. I care that it uses the thread pool instead of spawning a thread per request. I care that it reaches for the standard library instead of shelling out to run something a built-in function already does. I care that it isn’t calling an external server in the middle of a request. Or reading every file on disk when it needs one. Or skipping a cache that should be there. None of this is premature optimization. It’s about not being wasteful for no reason. And it’s about keeping things simple enough that I can still reason about them. A thousand threads, each running its own slightly different logic, is a system nobody can hold in their head. I don’t want to work on that, and I don’t want to build it.

​
Why I still care about the code

The naive version misses something, though. I may not care about the code for its own sake, but I care a lot about what good code gives me. I care about debugging. When something breaks at 2am, I need to understand what the application is doing. If it does everything in a convoluted way I’ve never looked at, that night gets very long. I care about reviewing. I work in regulated environments, with governance controls that don’t let me push unreviewed changes. Reviewing changes is good practice regardless. And you cannot review a 10,000-line diff. It isn’t humanly possible, barring the rare exception. I care about velocity. When modules are tightly coupled and the logic is scattered, every change risks breaking three things you didn’t touch. That’s the opposite of fast. If you skip the code entirely, you don’t escape the work. You move it. The bill arrives later, when you’re debugging something you don’t understand and can’t safely change.

​
Software, not code

Tell me the code isn’t the prettiest, but it’s straightforward to debug, quick to review, and safe to change, and I’ll take it. In practice you rarely get those three without readable code, but readability was never the goal. It was a proxy. That’s the shift AI pushed me toward, and I think it’s a healthy one. We’ve spent a long time attached to code, defending it, treating it as the goal. It was always a means to an end. We maintain software, not code.
Last modified on June 9, 2026