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.
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 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.
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.
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.
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.
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.
One might wonder what value he's bringing to the business, then, but it's hard to parse out much information from three sentences.
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.
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.
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.