First one need to define what they mean by "read" and clarify the context its being used in; then we can talk about agreeing/disagreeing part. Otherwise, we all will be playing/participating in some sort of a language game.
Right about what? Your own irrelevance? Fine, I won't disagree. Your mind, your skills and your talents no longer matter to anyone. Not even to you, apparently.
I don't know why you're so proud of that, or why you think anyone would care.
You're just standing in the way of business margins by being an unnecessary expense.
Or for lack of a better word, a meat proxy.
Not sure why the author is so arrogantly proud of not doing the absolute bare minimum expected of a developer (of any rank), though? Maybe a click-bait strategy? So weird.
Never thought I’d see “I’m bad at my job” used as a badge of honour.
There are certainly mission critical systems with a low tolerance for failure, but even there the essential work will be specification. I'm not sure how long even that is primarily human driven. Cost of formal verification of software drops dramatically.
A company I am consulted at last month is working on a process to have Figma drawings and business requirements written by BA's to be translated to Angular.
Their goal is to have the software engineering steps entirely done by AI.
I don't know where they are today, but when I left they were very very enthusiastic.
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.