3. evaluating whether the end result works as intended.
I have some news for the author about what 80% of a programmer's job consists of already today.
There is also the issue #4, that "idea guy" types frequently gloss over: If things do not work as intended, find out why they don't do so and work out a way to fix the root cause. It's not impossible that an AI can get good at that, but I haven't seen it so far and it definitely doesn't fit into the standard "write down what I want to have, press button, get results" AI workflows.
Generally, I feel this ignores the inherent value that there is in having an actual understanding of a system.
You make a good point and those kind of senior engineer skills may be the least affected. My post does not argue against that. It argues that writing code manually may quickly become obsolete.
What I am trying to say is that people who see the output of their work as "code" will be replaced just like human computers did. I believe even debugging will be increasingly aided by AI. I do not believe that AI will eliminate the need for system understanding, just to be clear.
Then again, you might argue that writing lines of code and manually debugging issues is exactly what builds your understanding of the system. I agree with that too, I suppose the challenge will be maintaining deep system knowledge as more tasks become automated.
The current implementations of LLMs are focusing on providing good answers, but the real effort of modern day programming is to ask good questions, of both the system, the data, and the people that supposedly understand the requirements
LLMs might become good at this, but nobody seems to be doing much of this commercially just yet
I strongly disagree with this. “Computers” would have not been replaced with the machines that replaced them if those machines routinely produced incorrect results.
One could argue that for applications where correctness is not critical my position does not apply, however this is not the analogy that the article is making.
The trajectory of LLMs "routinely producing incorrect results" is heading downwards as we are getting more advanced reasoning models with test-time compute.
I don't know whether you used some of the more recent models like Claude 3.5 Sonnet and o1. But to me it is very clear where the trajectory is headed. o3 is just around the corner, and o4 is currently in training.
People found value even in a model like GPT 3.5 Turbo, and that thing was really bad. But hey, at least it could write some short scripts and boilerplate code.
You are also comparing mathematical computation - which has only 1 correct solution - with programming, where the solution space is much broader. There are multiple valid solutions. Some are more optimal than others. It is up to the human to evaluate that solution, as I've said in the post. Today, you may even need to fix the LLM's output. But in my experience, I'm finding I need to do this far less often than before.
Wait what? Human programmers produce incorrect results all the time, they are called bugs. If anything, we use automated systems when correctness is important - fuzzers, static analyzers, etc. And the "AI" systems are improving by leaps and bounds every month, look at SWE-Bench [1] for example. It's pretty obvious where this is all going.
Sure, people make mistakes all the time. But would you prefer those mistakes be sprinkled randomly throughout your data crunching, or be systematic errors?
The point that that post is making is that a machine isn't going to make a mistake in adding two numbers. It reduces arithmetic errors to 0 (unless you count overflow which can be detected), and if it didn't it would only be useful in the rare case you don't care about accuracy.
AI in it's current state does not do for logical accuracy what computers did for arithmetic accuracy; You still need to verify every output from an LLM, which I doubt you've done for the many billions of arithmetic operations that happened this second on the computer you're on right now.
Think of electronic calculators. They have a significantly lower error rate than human calculators. Both statistically significant and practically significant.
> Even he, subconsciously, knows it doesn't pay off to waste cognitive energy on what a machine could do instead.
> It's not laziness, but efficiency.
It's only efficient in the short-term, not long-term. Now the programmer never understood the problem, and that is a problem in the long-run. As any experienced engineer knows - understanding problems is how anyone gets better in the engineering field.
My post did not take the position that understanding problems isn't important.
Using LLMs can even help you understand the problem better. And it can bring you towards the solution faster. Using an LLM to solve a problem does not prevent understanding it. Does using a calculator prevent us from understanding mathematical concepts?
Technical understanding will still be valuable. Typing out code by hand will not.
For this I've always called myself "software plumber".
I quite liked that analogy about excavator because I think along similar lines. Mechanising drudgery work in construction industry enabled us to build superstructures that are hundreds of stories tall. I wonder if LLMs will enable us to do something similar when it comes to software.
Okay, but what will you actually do when your LLM writes code which doesn't actually error but produces incorrect behaviour, and no matter how long you spend refining your prompt or trying different models it can't fix it for you?
Obviously you'll have to debug the code yourself, for which you'll need those programming skills that you claimed weren't relevant any more.
Eventually you'll ask a software engineer, who will probably be paid more than you because "knowing what to build" and "evaluating the end result" are skills more closely related to product management - a difficult and valuable job that just doesn't require the same level of specialisation.
Lots of us have been the engineer here, confused and asking why you took approach X to solve this problem and sheepishly being told "Oh I actually didn't write this code, I don't know how it works".
You are confidently asserting that people can safely skip learning a whole way of thinking, not just some syntax and API specs. Some programmers can be replaced by an LLM, but not most of them.
I agree that you still need programming skills (today, at least). Yet people are using those programming skills less and less, as you can clearly see in the article [1] I referenced.
You are also making the assumption that LLMs won't improve, which I think is shortsighted.
I fully agree with the part about the job becoming more like product management. I would like to cite an excerpt of a post [2] by Andrew Ng, which I found valuable:
Writing software, especially prototypes, is becoming cheaper. This will lead to increased demand for people who can decide what to build. AI Product Management has a bright future! Software is often written by teams that comprise Product Managers (PMs), who decide what to build (such as what features to implement for what users) and Software Developers, who write the code to build the product. Economics shows that when two goods are complements — such as cars (with internal-combustion engines) and gasoline — falling prices in one leads to higher demand for the other. For example, as cars became cheaper, more people bought them, which led to increased demand for gas. Something similar will happen in software. Given a clear specification for what to build, AI is making the building itself much faster and cheaper. This will significantly increase demand for people who can come up with clear specs for valuable things to build. (...) Many companies have an Engineer:PM ratio of, say, 6:1. (The ratio varies widely by company and industry, and anywhere from 4:1 to 10:1 is typical.) As coding becomes more efficient, teams will need more product management work (as well as design work) as a fraction of the total workforce.
To address your last point - no, I am not saying people should skip learning a whole way of thinking. In fact, the skills I outline for the future (supervising AI, evaluating results) all require understanding programming concepts and system thinking. They do not, however, require manual debugging, writing lines of code by hand, a deep understanding of syntax, reading stack traces and googling for answers.
Obviously I assume LLMs will continue to improve, I don't know why you'd think I don't.
But the actual relevant prediction here (the one you're confident enough about to give skills development advice on) is whether they'll improve sufficiently that programming is no longer a relevant skill.
I think that's possible, but I'm not nearly so confident I'd write your article: LLMs went mainstream ~2 years ago, and they still have some pretty basic limitations when it comes to computational/mathematical reasoning, which they'll need to solve novel software engineering tasks. (Articles about these limitations get posted here pretty frequently)
To your second point, I'm still not sure how you will debug someone else's code without learning to write code yourself, because you need to be able to read code, and understand it well enough to execute it inside your mind. I am not totally convinced you understand the difference between "understanding programming concepts" and "being able to understand whether this code works".
Sorry if this comes across as rude, but I think the reason the feedback on your post is overall quite negative is that you're excited about AI making this job much easier, and your advice about which skills are worth learning are too confident. Ironically I think an LLM would give a more balanced view than you have.
LLMs have already improved sufficiently that people are worried their programming skills are decaying, debugging skills included (based on the article I referenced). I'm curious to see how you envision LLMs improving without this not becoming even more pronounced. Isn't that the definition of a skill slowly becoming irrelevant? The fact that you can see you are not using it as much?
As for the reception, I did not expect it to be positive. People usually have a strong negative emotional reaction when you suggest their skills are, or are going to become, less relevant.
Not really? Your thinking about the definition of the word "relevant" seems a bit confused here... By your logic, home insurance is "irrelevant" because you don't seem to use it much, then one day it's suddenly extremely relevant (at which point then it's too late to buy it).
I guess we'd probably agree that "writing code is an irrelevant skill" actually all comes down to whether LLMs will improve enough to match humans at programming, and thus comprehensively remove the need for fixing their work.
They currently don't, so at the time you claimed this it was incorrect. Maybe they will in the future, at which point it would be correct.
So, would it be responsible for me to bet my career on your advice today? Obviously not, which is why most people here disagree with your article.
You were prepared in advance to explain that criticism as people having a strong negative emotional reaction, so I'm not sure why you posted it here in the first place instead of LinkedIn where it might reach a more supportive audience.
The insurance analogy doesn't work - programming skills exist on a spectrum of daily relevance. Insurance becomes relevant in rare emergencies. Programming skills are becoming less relevant in day-to-day.
What I pointed out in my post is a trend I notice where an LLM can do more and more of a developer's work. Nowhere did I claim LLMs can replace human developers today, but when a technology consistently reduces the need for manual programming while improving its capabilities, the trajectory is clear. You can disagree with the timeline, but the transformation is already underway.
I posted on HN precisely because I wanted rigorous technical discussion, not validation.
Ah okay, I think it's a perfect analogy, and this helps clarify where our disagreement is.
I do believe it's a binary thing: One day a model gets released which is sufficiently good at programming that I don't need to be able to debug or write code any more. That's the exact day my skills aren't relevant.
They aren't only 50% relevant 6 months before that date, because I need to entirely maintain my code during that 6 months, so that 50% is effectively 100%.
Seeing it as a spectrum carries a specific risk: you neglect your skills before that point is actually reached, at which point you're relying on code you can't understand properly or debug.
I think if you wanted rigorous technical discussion, this is the sort of specificity your article would've needed.
Oh boy, I sure love to see some guy with a blog waxing poetic about the future of AI. The insistence that "most people haven't realized come to terms with it yet", and then proceeding to make a total fucking guess out of his ass.
Reminds me of that one asshole who couldn't find a pen, and wrote a whole NYT article about "the demise of the pen".
Premises seems completely flawed to me. It’s like if we would say because we have calculators, knowing basic arithmetic mentally will no longer be a necessary step to go through. All the more when the these calculators are actually not giving you exacts results, but excel at producing a lot of plausible lookalike approximations based on large corpus of computation samples.
So it seems not only very wrong on what is the hard part in programming, but also misguided about where (current) LLM use can shine, including in programming context.
'Did the computer create a generation of "illiterate mathematicians"?
No, it only freed us to solve higher-level problems.'
I'm not so sure LLM-based code-assistants/writers are directly comparable to the almost perfectly deterministic logic gate chips and monitors/printers and so on that we call "the computer".
Wordpress is likely a better comparison, which allowed more web sites to come into existence with little effort, but as far as I can tell didn't free anyone to "solve higher-level problems". Deterministic code generation might have to some extent, but it's mainly used in enterprise software where the problem domains are quite old, quite stable, like accounting, and the ontologies haven't changed since before "the computer" and the established knowledge professionals (accountants, 'legal') have a strong dominance over discourse, software rules and how compliance is achieved.
While I have been amazed by the progress of LLMs and believe that this ultimately leads to AGI, I still think that LLM aided development is limited to things that are often done and are well documented in the training corpus. Writing code with new libraries or less documented lower level apis still requires you to actually do it. LLMs slowly separate you from your understanding of what your code is doing, and if they don’t meet a minimum threshold of proficiency on a topic, they will slowly and insidiously degrade your codebase until you realize Claude (or whoever else) has built a house of cards.
Except that going from human computers to mechanical computers made us more precise and more accurate at doing calculations, not less.
Modern AI assistants have yet to demonstrate greater level of competence than even an inexperienced human programmer. Anyone telling you otherwise has fallen victim to extrapolation.
Just ask yourself if this AI generated software is what you want managing your bank account or the monitor next to your bed in the hospital. The lack of determinism makes LLMs unsuited for many tasks where precise outcomes are necessary.
> Anyone who tells you otherwise is deluding themselves.
Always good when a blog author ends with an ad hominem not supported by their claims.
It would have been more useful if they had explained how Rice's theorm was falsified, and that HALT/FRAME have been invalidated.
In my experience, for any problem that is non-trivial, LLMs require more knowledge and tacit experience.
Programming has always been more about domain understanding etc...
Things will change, but this is new tooling which requires new knowledge. I have had to start explaining Diaconescu's Theorem to a lot more people as an example.
This article read like one of those annoying LinkedIn “hot takes” that keeps showing up on my feed. I’d suggest sharing this type of content there rather than on HN, please.
"Those are the very skills that are going to become a lot less relevant, for the precise reason that, now, the machine can do those things."
A photocopier could steal books, a VHS recorder could steal movies, a computer could steal digital works.
LLMs now steal pseudo-legally. Any person without morals could have done the exact same thing before LLM laundromats by just using Google search and GitHub.
"Anyone who tells you otherwise is deluding themselves."
While I don’t disagree with the author, I think he misses the larger point that there are two distinct groups of programming code writers, that I’ll call “eager” and “reluctant” until I can think of better terms.
“Eager” programmers find great joy in producing reams of computer code. They prefer to have iron-clad requirements handed to them and then work uninterrupted turning those requirements into a program.
“Reluctant” programmers have problems to solve, and have found that the quickest way to do that is to write code. If solving the problem is faster by not writing code they will do that.
“Computers”, that is, the job formerly performed by humans, favored the “eager” type of person. The people giving work to Computers were “reluctant”, and moved that work to faster tools when they became available.
The issue is that we have armies of “eager” programmers. Can they adapt to become “reluctant” or does the thought of writing less code cause them to resist change?
I sure wish I had access to the crystal ball people like the author and linked-in top-voices have that enable them to utter with unawavering conviction those decrees, while warning that everyone that doesn't agree with them are "deluding themselves."
[...]
3. evaluating whether the end result works as intended.
I have some news for the author about what 80% of a programmer's job consists of already today.
There is also the issue #4, that "idea guy" types frequently gloss over: If things do not work as intended, find out why they don't do so and work out a way to fix the root cause. It's not impossible that an AI can get good at that, but I haven't seen it so far and it definitely doesn't fit into the standard "write down what I want to have, press button, get results" AI workflows.
Generally, I feel this ignores the inherent value that there is in having an actual understanding of a system.
What I am trying to say is that people who see the output of their work as "code" will be replaced just like human computers did. I believe even debugging will be increasingly aided by AI. I do not believe that AI will eliminate the need for system understanding, just to be clear.
Then again, you might argue that writing lines of code and manually debugging issues is exactly what builds your understanding of the system. I agree with that too, I suppose the challenge will be maintaining deep system knowledge as more tasks become automated.
LLMs might become good at this, but nobody seems to be doing much of this commercially just yet
That is not the same thing.
One could argue that for applications where correctness is not critical my position does not apply, however this is not the analogy that the article is making.
I don't know whether you used some of the more recent models like Claude 3.5 Sonnet and o1. But to me it is very clear where the trajectory is headed. o3 is just around the corner, and o4 is currently in training.
People found value even in a model like GPT 3.5 Turbo, and that thing was really bad. But hey, at least it could write some short scripts and boilerplate code.
You are also comparing mathematical computation - which has only 1 correct solution - with programming, where the solution space is much broader. There are multiple valid solutions. Some are more optimal than others. It is up to the human to evaluate that solution, as I've said in the post. Today, you may even need to fix the LLM's output. But in my experience, I'm finding I need to do this far less often than before.
[1] https://www.swebench.com/
The point that that post is making is that a machine isn't going to make a mistake in adding two numbers. It reduces arithmetic errors to 0 (unless you count overflow which can be detected), and if it didn't it would only be useful in the rare case you don't care about accuracy.
AI in it's current state does not do for logical accuracy what computers did for arithmetic accuracy; You still need to verify every output from an LLM, which I doubt you've done for the many billions of arithmetic operations that happened this second on the computer you're on right now.
edit: fixed typo
Think of electronic calculators. They have a significantly lower error rate than human calculators. Both statistically significant and practically significant.
> Even he, subconsciously, knows it doesn't pay off to waste cognitive energy on what a machine could do instead.
> It's not laziness, but efficiency.
It's only efficient in the short-term, not long-term. Now the programmer never understood the problem, and that is a problem in the long-run. As any experienced engineer knows - understanding problems is how anyone gets better in the engineering field.
Using LLMs can even help you understand the problem better. And it can bring you towards the solution faster. Using an LLM to solve a problem does not prevent understanding it. Does using a calculator prevent us from understanding mathematical concepts?
Technical understanding will still be valuable. Typing out code by hand will not.
Effectiveness counts. Effective people rarely need to wag the efficiency dog.
/s
Oh wait. You get a "car". And you get a "car". And everyone gets a "car".
I quite liked that analogy about excavator because I think along similar lines. Mechanising drudgery work in construction industry enabled us to build superstructures that are hundreds of stories tall. I wonder if LLMs will enable us to do something similar when it comes to software.
Obviously you'll have to debug the code yourself, for which you'll need those programming skills that you claimed weren't relevant any more.
Eventually you'll ask a software engineer, who will probably be paid more than you because "knowing what to build" and "evaluating the end result" are skills more closely related to product management - a difficult and valuable job that just doesn't require the same level of specialisation.
Lots of us have been the engineer here, confused and asking why you took approach X to solve this problem and sheepishly being told "Oh I actually didn't write this code, I don't know how it works".
You are confidently asserting that people can safely skip learning a whole way of thinking, not just some syntax and API specs. Some programmers can be replaced by an LLM, but not most of them.
You are also making the assumption that LLMs won't improve, which I think is shortsighted.
I fully agree with the part about the job becoming more like product management. I would like to cite an excerpt of a post [2] by Andrew Ng, which I found valuable:
Writing software, especially prototypes, is becoming cheaper. This will lead to increased demand for people who can decide what to build. AI Product Management has a bright future! Software is often written by teams that comprise Product Managers (PMs), who decide what to build (such as what features to implement for what users) and Software Developers, who write the code to build the product. Economics shows that when two goods are complements — such as cars (with internal-combustion engines) and gasoline — falling prices in one leads to higher demand for the other. For example, as cars became cheaper, more people bought them, which led to increased demand for gas. Something similar will happen in software. Given a clear specification for what to build, AI is making the building itself much faster and cheaper. This will significantly increase demand for people who can come up with clear specs for valuable things to build. (...) Many companies have an Engineer:PM ratio of, say, 6:1. (The ratio varies widely by company and industry, and anywhere from 4:1 to 10:1 is typical.) As coding becomes more efficient, teams will need more product management work (as well as design work) as a fraction of the total workforce.
To address your last point - no, I am not saying people should skip learning a whole way of thinking. In fact, the skills I outline for the future (supervising AI, evaluating results) all require understanding programming concepts and system thinking. They do not, however, require manual debugging, writing lines of code by hand, a deep understanding of syntax, reading stack traces and googling for answers.
[1] https://nmn.gl/blog/ai-illiterate-programmers
[2] https://www.deeplearning.ai/the-batch/issue-284/
But the actual relevant prediction here (the one you're confident enough about to give skills development advice on) is whether they'll improve sufficiently that programming is no longer a relevant skill.
I think that's possible, but I'm not nearly so confident I'd write your article: LLMs went mainstream ~2 years ago, and they still have some pretty basic limitations when it comes to computational/mathematical reasoning, which they'll need to solve novel software engineering tasks. (Articles about these limitations get posted here pretty frequently)
To your second point, I'm still not sure how you will debug someone else's code without learning to write code yourself, because you need to be able to read code, and understand it well enough to execute it inside your mind. I am not totally convinced you understand the difference between "understanding programming concepts" and "being able to understand whether this code works".
Sorry if this comes across as rude, but I think the reason the feedback on your post is overall quite negative is that you're excited about AI making this job much easier, and your advice about which skills are worth learning are too confident. Ironically I think an LLM would give a more balanced view than you have.
As for the reception, I did not expect it to be positive. People usually have a strong negative emotional reaction when you suggest their skills are, or are going to become, less relevant.
I guess we'd probably agree that "writing code is an irrelevant skill" actually all comes down to whether LLMs will improve enough to match humans at programming, and thus comprehensively remove the need for fixing their work.
They currently don't, so at the time you claimed this it was incorrect. Maybe they will in the future, at which point it would be correct.
So, would it be responsible for me to bet my career on your advice today? Obviously not, which is why most people here disagree with your article.
You were prepared in advance to explain that criticism as people having a strong negative emotional reaction, so I'm not sure why you posted it here in the first place instead of LinkedIn where it might reach a more supportive audience.
What I pointed out in my post is a trend I notice where an LLM can do more and more of a developer's work. Nowhere did I claim LLMs can replace human developers today, but when a technology consistently reduces the need for manual programming while improving its capabilities, the trajectory is clear. You can disagree with the timeline, but the transformation is already underway.
I posted on HN precisely because I wanted rigorous technical discussion, not validation.
I do believe it's a binary thing: One day a model gets released which is sufficiently good at programming that I don't need to be able to debug or write code any more. That's the exact day my skills aren't relevant.
They aren't only 50% relevant 6 months before that date, because I need to entirely maintain my code during that 6 months, so that 50% is effectively 100%.
Seeing it as a spectrum carries a specific risk: you neglect your skills before that point is actually reached, at which point you're relying on code you can't understand properly or debug.
I think if you wanted rigorous technical discussion, this is the sort of specificity your article would've needed.
Reminds me of that one asshole who couldn't find a pen, and wrote a whole NYT article about "the demise of the pen".
Makes people wish for the demise of stupidity.
So it seems not only very wrong on what is the hard part in programming, but also misguided about where (current) LLM use can shine, including in programming context.
No, it only freed us to solve higher-level problems.'
I'm not so sure LLM-based code-assistants/writers are directly comparable to the almost perfectly deterministic logic gate chips and monitors/printers and so on that we call "the computer".
Wordpress is likely a better comparison, which allowed more web sites to come into existence with little effort, but as far as I can tell didn't free anyone to "solve higher-level problems". Deterministic code generation might have to some extent, but it's mainly used in enterprise software where the problem domains are quite old, quite stable, like accounting, and the ontologies haven't changed since before "the computer" and the established knowledge professionals (accountants, 'legal') have a strong dominance over discourse, software rules and how compliance is achieved.
Modern AI assistants have yet to demonstrate greater level of competence than even an inexperienced human programmer. Anyone telling you otherwise has fallen victim to extrapolation.
Now you can buy a command-line interface to marketing copy at less than $1000 per month that never applies for sick days.
Not saying that I like it, but that seems to be what it is.
Always good when a blog author ends with an ad hominem not supported by their claims.
It would have been more useful if they had explained how Rice's theorm was falsified, and that HALT/FRAME have been invalidated.
In my experience, for any problem that is non-trivial, LLMs require more knowledge and tacit experience.
Programming has always been more about domain understanding etc...
Things will change, but this is new tooling which requires new knowledge. I have had to start explaining Diaconescu's Theorem to a lot more people as an example.
A photocopier could steal books, a VHS recorder could steal movies, a computer could steal digital works.
LLMs now steal pseudo-legally. Any person without morals could have done the exact same thing before LLM laundromats by just using Google search and GitHub.
"Anyone who tells you otherwise is deluding themselves."
No, you are deluding yourself.
“Eager” programmers find great joy in producing reams of computer code. They prefer to have iron-clad requirements handed to them and then work uninterrupted turning those requirements into a program.
“Reluctant” programmers have problems to solve, and have found that the quickest way to do that is to write code. If solving the problem is faster by not writing code they will do that.
“Computers”, that is, the job formerly performed by humans, favored the “eager” type of person. The people giving work to Computers were “reluctant”, and moved that work to faster tools when they became available.
The issue is that we have armies of “eager” programmers. Can they adapt to become “reluctant” or does the thought of writing less code cause them to resist change?