Should I Read Code Anymore?
End of 2025, Claude Code dropped with Opus and the internet lost its mind. "This is the end for software developers." Memes, hot takes, the usual cycle.
Some background. I've been coding for 17 years. Microsoft (Teams, Outlook), then built a Metaverse at Invact. Took a break from hands-on coding in 2023, picked it back up mid-2024. I've used all of it — ChatGPT copy-paste, Copilot tab completions, Cursor, Claude Code, Codex. My GitHub has never been greener. I'm not on the sidelines of AI-assisted engineering. I'm in it every day.
So when someone says "if you're reading the code your agent writes, you're ngmi" — I take it seriously. I've thought about it against my own work, which ranges from quick prototypes to production code used by thousands.
My answer: it depends.
How Serious Is Your Output?
500-line script to convert video files so I can watch Dragon Ball on my TV? I don't read the code. If it works, it works. If it doesn't, "fix it" usually handles it.
Learning a new language? Different story. I picked up Golang in July 2025. Bought books. Wrote hello worlds and APIs by hand. Turned off tab suggestions in VSCode. When you're building a new mental model, you need the reps. No shortcuts.
Frontier work? I built a custom 5M-parameter language model from scratch to learn how LLMs work. Claude and Codex wrote most of the code. But I read every line. Tweaked, adjusted, broke things deliberately. I didn't know what I was doing — which is exactly why I had to read. You can't reason about the next enhancement if you don't understand how the current thing is built. Result: a 5M-parameter model producing Grade 8 level English. Couldn't have prompted my way there.
Here's the key insight: after doing that work, I can now prompt my way through similar tasks easily. Because I know the moving parts. Reading code builds the mental model that makes prompting effective.
Production apps with 100+ users? Always read. You owe it to your users.
Garbage In, Garbage Out
I learned GIGO in second grade computer class. Never been more relevant.
When I build something for a real audience, I don't write the code. But my inputs are serious. I don't let the LLM choose the library, the architecture, the file names, even function names. I spec things out in detail. EPICs, tickets, all of it. I read every ticket and refine until it matches what I want.
That spec-writing process runs my mental compiler. When Claude Code starts writing, I'm watching the screen — reasoning steps, diffs — and I can tell in real time if it's going right. If something doesn't match my mental model or it enters a doom loop, I hit Esc and tell it exactly what to do.
This ability to parse code at speed? It's earned. If you haven't done the time writing and reading code, you can't do it. And this is where I disagree with anyone saying "don't read code, you're slowing down your harness." They haven't built the skill to parse at that level.
The Doom Scenario
You've been prompting your way through a codebase. Small, then large, then larger. You don't really know what's where. And one day you need to implement something that touches frontend, backend, and workflows. You prompt and prompt and hit the ceiling. Users complain about bugs in every release. But you can't reason about the system because you never read the code.
This isn't hypothetical. A well-funded startup — raised $15M+ — recently admitted their code grew so far out of control they had to rewrite everything from scratch. Their feature velocity went negative: more bugs introduced than features shipped.
This happened before LLMs too. It's always been a problem. Not reading code just accelerates it.
For toy projects, do whatever you want. For anything with real users, I don't want to be in that situation. Ever.
Code Is the Truth
Someone asked me: what about specs and walkthroughs? Wouldn't reading those be enough?
Code is the highest-fidelity spec that exists right now. It's the literal truth of what your system does. And you can dig as deep as you want — controller to repository to service to DTO. No other document gives you that.
Software is coordination. The more features you build, the more they need to coordinate with each other. Banking workflows, healthcare systems, manufacturing pipelines — tons of business rules, authorization layers, code interacting at every level.
Humans have to pay the coordinator tax. And if you've done the input work right — serious specs, clear architecture — then reading code is the least taxing way to pay it.
I'd love a future where I just ask and the genie grants it. We're not there yet. Until then, read the code.
I first made this argument at MLDS 2025 — that the translator era is over and what survives is systems understanding. This piece is the practical version: how I actually work with AI tools day-to-day. For how this applies outside of software — in high-stakes operational systems — see how we approached emergency dispatch.