> Imagine taking a picture on autoshot mode and refusing to look at it.

I don't have to imagine it, I did it for decades. You went on holiday and you had a budget 26 photos, all shot on auto and each one was precious.

I've got tens of thousands of lines of code I've never looked at, and it wouldn't matter if I did look at them because I don't even understand the languages that they're written in. I get Claude to write in Rust because the edit-compile cycle is shorter due to great error messages. I don't know it at all. I've got projects written in Erlang and Scheme - I've never written a line of Erlang either, and I only know Scheme from reading SCP.

"But it doesn't work." - This entire comment was written using a voice to text system Claude produced in Rust. My firewall was set up using Claude, my i3wm setup was done with it, I've had it installed Debian for a PXE using iScsi - an iScsi server Claude also wrote in Rust.

https://github.com/lawless-m/iscsi-crate

I’m not sure I buy this framing.

I agree that reading every dependency isn’t realistic. But “not reading the code” as a principle feels risky.

In my experience, abstractions hold until they don’t. The first time you hit a production incident and the docs stop helping, reading the source stops being academic and starts being survival.

We once had a performance issue caused by a library making assumptions about concurrency that weren’t obvious from the API. The fix only became clear after stepping through the source.

I think the real skill isn’t avoiding reading code, it’s knowing when to escalate from trust to understanding.

For glue code or low stakes utilities, sure. For auth, billing, or core infra, I’d argue reading at least the critical paths pays dividends.