I very much would like to stop reading the code, but when I read it, I see insidious problems - not at the lowest level but at the medium and high level abstractions.

For example - we have an internal system for tracking the staus of jobs - draft, ready, waiting for hardware, running, complete, error ... its used across some 15 different task types in our codebase.

The non-code reading engineer submitted two new modules and their prompts, the prompts were specifically told to examine the other modules and follow the architectural patterns.

The two new modules worked in the sense that they ran to completion, however once I looked at the code I see it had implemented new staus objects rather than reuse our internal task system, and worse it had implemented custom task objects twice, each for the two modules, each with a different set of possible statuses.

The AI psychosis people will say "YoU cAN fIX tHaT bY pROmtiNG iT" which of course is true and it totally, utterly not the point here - these sorts of problems are only discovered by reading the code.

Worse, if we had merged it in, (because by visual inspection it executed fine) we would only realize after 5 or 6 more merges like this when the codebase quality has severely degraded and then things like every single task having a different set of statuses and status transitions would make understanding system problems a giant mess of spaghetti.

I know that reading code is hard (for intermediates and juniors) and the idea that you dont need to is alluring, but the reality is that you still need to (for now) because lurking skin deep below that code that appears to be working is a dragon that WILL bite you later. Can the LLM get rid of the dragon, of course it can, but my point is that unless you actually read the code, you wouldn't have even known it was there.