I don't read code anymore | Hacker News Reader

I don't read code anymore

blog.duyet.net

11 pointsduyetdev28 comments

>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.

Why should we read your fucking blog then

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.

One might wonder what value he's bringing to the business, then, but it's hard to parse out much information from three sentences.

I’m good at dealing with customers… what about that is hard to understand!

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?

Then the software you're writing isn't at all critical to justify keeping your job.

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.

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.

I think what some engineers don't realize is that mostly we will all move to abstraction level of product managers. If you are not slowly moving up to that level of abstraction as the model capabilities improve, it is likely that you are in for a bad time.

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.

There is no need for as many product managers as there are currently developers and the vast majority of developers are not going to become good product managers even if they embrace AI so it is likely that everyone is in for a bad time anyway. The existing product managers have access to AI too, have years of experience, and aren't going to take kindly to ex-developers trying to take their jobs.

I understand the “one more abstraction” aspect, and thoroughly agree with you, though it seems counter-productive and rather illogical to me to never read code and be proud of it. It’s one thing to leave the grunt work to the AI, but to not even review code? That sounds like a bad idea.

Prompting is being automated.

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 can see some of the process being automated, but entirely? Sounds like a ticking time bomb to me.

I don't believe so. I am sure you've also notice that Claude is already ridiculously good these days, and becoming better for every month. That goes for other providers as well.

I don't know where they are today, but when I left they were very very enthusiastic.

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.

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.

I suspect you never really read code in the first place, to see so little value in it now

> I don't read code anymore

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 specification and read/create proper ADR-s - this is crucial for me. In addition I plan strict automated tests (unit and functional) + I run mutation tests to check tests quality and find gaps. Moreover after every stage of development (not task, but several ones) I perform security review.

which code reviewer are you using?

CodeRabbit, Open Code Review and some more custom skills/workflows for specific repositories

do any of those actually help with prod risk before merge, or are they mostly focused on the code itself?

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.

We desperately need some personal responsibility for the software you distribute.

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.

Reply on news.ycombinator.com