I see where you’re getting at, but AI still requires someone to prompt it to do something. It has no free will so the meat proxy, as you put it, is still relevant and necessary.
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.
>Disagree or debate me all you want, but soon you'll realize and admit I was right.
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.
I am really sorry if I upset you,I do not mean to be proud of that. I think we should accept that read/write code it is over now. People will not care how good my code is anymore. "I don't read code anymore" is for those who are still surprised when I say that.
Agents write my code but I still read and make sure I understand it, like I would read the code written by a junior dev. If I don’t understand it, or if I don’t agree with the approach, I ask questions and those questions often lead to better code. More importantly, it helps ensure I remain “connected” with the codebase which in turn informs future requests and discussions with an agent.
Exactly. And there is architectural things missed by agents or just wrong. There is equally things I learn all the time from agents doing things, or things I have missed. Together we’re a better team.
Just curious what if your teammate gets 10x better every month and is now an expert in everything? My point is that agents will get much much better soon and we need to pivot. Also things like prompting are being automated.
I'm not worried. The rate of change hasn't been that huge. The models still struggle with the same weaknesses from day 1. And if my job was ever threatened, many other fields would be before that.
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.
I've stopped reading all lines but I read very carefully specyfication and read/creare proper ADR-s - this is curial for me. In addition I plan strict automated tests (unit and functional) + I run mutation tests to check tests quality and find gaps. Morover after every stage of development (not task, but several ones) I perform security review.
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 servos 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.
i was poking around your site and went here https://blog.duyet.net/2026/07/anyrouter/ and ran into an error: "Something went wrong! Minified React error #300; visit https://react.dev/errors/300 for the full message or use the non-minified dev environment for full errors and additional helpful warnings."
Perhaps you should read your code just a little bit?
They only helped with code issues, performance, etc. You also need smoke test skills to validate live deployment right after it is deployed and then make it automatically roll back for any issues found, or just improve your CI/CD.
I am also trying to schedule make them run as much as real use cases so that runtime bugs happen and are sent to Sentry/bugsink/logs/... Another agent will triage them, create issues, and then continue to push more fixes.
Nah, I don't think we are at this point yet. AI without control just creates non usable products. We don't literally write the code but we still give direction and review output.
We just found the bottleneck moved to the reviewing part, and AI can help there too, we tried many AI reviewers and even mostly just add more noise and slop we found some that are quite good and even do not replace humans they take most of the consuming work out.
Once we get to the point code is not the problem, remember that we started coding because we wanted to create software that solved problems. What I mean by this is don't forget we are here to solve problems, not to write code.
25 comments
[ 0.26 ms ] story [ 44.5 ms ] threadYou'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.
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.
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.
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 servos 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.
Perhaps you should read your code just a little bit?
I am also trying to schedule make them run as much as real use cases so that runtime bugs happen and are sent to Sentry/bugsink/logs/... Another agent will triage them, create issues, and then continue to push more fixes.
If you think that AI can do it all, fine, but you should spend some time in jail when the code you didn't read wreaks havoc.
We just found the bottleneck moved to the reviewing part, and AI can help there too, we tried many AI reviewers and even mostly just add more noise and slop we found some that are quite good and even do not replace humans they take most of the consuming work out.
Once we get to the point code is not the problem, remember that we started coding because we wanted to create software that solved problems. What I mean by this is don't forget we are here to solve problems, not to write code.