Do I still need to read the code?

“Do I still need to read the code?” is fundamentally the wrong question.

Maybe you’ve seen Steve Yegge’s recent essays about Wheelhouse — his harness for running a whole fleet of coding agents on his 30-year-old game (Yegge, 2026). They take the current discussions about code reviews, code generation, “is software solved,” etc. to their logical conclusion: no pull requests, no human review — just agents doing agentic things, end to end.

Your clients and users don’t think about your code — who reads it, or whether an automated process wrote it. The code is just a means to an end. The real-world questions are way more boring and way, way more complex. So should you read the code? … “It depends.”

Let’s take a standalone UI component as an example (just happened to me on a mid-size pet project). I care about how it feels, so I can just skip the code… Yeah, but what about theming — am I sure the component implements our design system correctly? Okay, let’s have an automated review agent that can check this. Now, what if we change some fundamental principles in our design system? Will the review agent judge them correctly? How much can we spend on this? Does it even bring value? It gets complex very quickly.

Instead of discussing implementation details, focus on the first principles:

Does your product work? Is it easy to use? Is my data safe with you? Can I trust your SLA? How fast can you fix issues and provide support? How do you deal with incidents?