The only viewpoint I really agree with in this article is the "use it or lose it" mentality. Skills are developed and maintained by practicing them, but if all the author really wants to do is write code, then LLMs are literally an answer to their prayers!
You can enable virtually free test driven development. Write the test names down and let the LLM implement them for you. You save 50% of your time and you get to go to town on implementation and or optimizations.
You can have the LLM take the non-tech-counterparts description of a bug and have it point you at precise lines of code to investigate rather than grepping around a codebase you might not know well.
You can onboard to new languages, frameworks, repositories extremely fast by having a partner (the LLM) explain implementation patterns and approaches on demand! You don't even need to talk to another human being! Get your questions answered in seconds and start coding!
You can rapidly prototype. You can get immediate code reviews. You can rubber duck. You can visualize business/logic flows and code branching to better understand existing implementations. You can even have the LLM write an implementation plan for you then write the code yourself!
If you cant find a way to write more code with LLMs, its either an imagination or skill issue.
> You can enable virtually free test driven development. Write the test names down and let the LLM implement them for you. You save 50% of your time and you get to go to town on implementation and or optimizations.
That's assuming that it writes good tests, and that you don't care to take the time to verify the tests it wrote, no?
I do find LLMs useful for scaffolding this stuff, but yeah, good test writing still seems to require a lot of hand-holding. I don't mind. I'm happy with my tests and they get written faster. Hand-holding and verifying is still faster than how I used to do it, and the LLMs admittedly capture more cases than I did without them. They will try to create test cases that make no sense too, but it's worth having to delete if it means it also comes up with test cases that I didn't.
The whole point of my post is that you get to pick and choose what parts this magical software automates for you. Based on your response, it's an imagination issue for you.
I think the reason this discussion keeps coming up is that the people who are getting a lot out of these tools are people who are, at best, the software-equivalent of assembly-line workers. If something can be easily understood by passively reading it then it probably isn't complicated or novel and therefore it's not surprising a pseudorandom bullshit generator can do it for you; all it lacks is a unit testing system which can verify that its interpretation of the problem-statement matches the interpretation which would be most obvious to a human and that is evidently not a solved problem thus far.
If the hardest part of your job is understanding code written by other people and even code written by yourself in the distant past, then LLMs are of literal use because the problem they solve was never a significant bottleneck and in fact their "solution" only serves to pump a higher volume of fluid through the neck of the proverbial bottle.
It's the difference between reading somebody's paper in a mathematical journal to understand how they came to the conclusion they are presenting, and merely using the identity they have proven on faith. If all that mattered was to perform some calculation based on their work then its clear which approach will get more work done in less time but if you don't take it for granted that everything in the journal is correct or if you want to be able to further develop ideas based upon their proof then you have to spend a few days or even weeks trying to understand how each step leads to its successor.
It's also why i hate the old adage about not reinventing wheels, it promotes ignorance by asserting that education itself is ignorance.
I’m glad to hear someone say that. I’ve been wrestling for weeks with the idea of reinventing a particular wheel in my profession, for a personal coding project. The problem is that my implementation can’t ever be as complete or as useful as the existing solutions because it’s way too much for one person to accomplish in a reasonable amount of time.
But, I like it, I’ve reinvented many wheels in my work and it’s benefited me greatly. So I will reinvent this particular wheel as well…
We can't uninvent LLMs. They're here already and the best course of action for everyone is to learn to live with them.
That being said I noticed that the more opinionated a language/framework/library is, the worse off one is using LLMs.
I was surprised by this, but then I put a particularly fishy line into GitHub's search box. What I saw were piles upon piles of bad practices and incorrect usages. There's a lot of bad code there and LLMs are learning from it.
If you're working on something where the cost of bugs is high and they're tricky to detect, LLM generated code may not be a winning strategy if you're already a skilled programmer. However, LLMs are great for code review in these circumstances - there is a class of bugs that are hard to spot if you're the author.
As a simple example, accidentally inverting feature flag logic will not cause tests to fail if the new behavior you're guarding does not actually break existing tests. I and very senior developers I know have occasionally made this mistake and the "thinking" models are very good at catching issues like this, especially when prompted with a list of error categories to look for. Writing an LLM prompt for an issue class is much easier than a compiler plugin or static analysis pass, and in many cases works better because it can infer intent from comments and symbol names. False positives on issues can be annoying but aren't risky, and also can be a useful signal that the code is not written in a clear way.
“a new paradigm for software development that you must learn or be left behind” that’s a completely inaccurate statement. Nobody is saying that you will be “left behind”. It certainly is a new paradigm but it doesn’t mean the old way of doing things won’t continue to exist. Just like there are still some problems that require code to be written in C or even assembly. Just like there are hand-made goods. The size of the opportunity is a whole different story.
not all of course as there’ll be morons always but a lot of people who are saying “will be left behind” see an amazing tool which in hands of the right people is a great multiplier…
What I don't understand in all that noise from the LLM critics - they keep talking about how LLMs are so horrendously bad at writing code as if that's the only thing we're trying to use them for. As if they're not even genuine programmers, working on real projects, touching code every day.
Software crafting is so much more than merely writing code. There's a significant amount of reading code that goes into it. Code written by you. Code written by someone else. Someone else's code that you butchered with your edits, your own code butchered by someone else, and everything intertwined in between. Code that can't easily be explained by looking at it - sometimes you have to find relevant PRs, tickets, documentation, related online communication, some loosely-related code sitting someplace else, etc.
LLMs absolutely can help you read code, just as they are very capable of helping someone study a book or an academic paper. Denying that fact simply is ignorance. Of course, LLMs are absolutely capable of leading you in the wrong direction, confusing you, and giving you incorrect facts, even when you're studying text in plain English, just like it's possible to end up at the bottom of a lake when driving a car. Everyone needs to exercise caution and "know what the fuck they're doing" when using a model. But calling LLMs "bullshit generators" and "magic 8 balls" is so stupid. Sure, if you use it to perform bullshit stuff, it will generate nothing but bullshit.
I can’t take this article seriously, and neither should you. Being anti AI/anti LLM is solidly in the Luddite camp; there’s really no more debates to be had. Every serious inquiry shows productivity gains by using ai.
It’s anyone’s prerogative to continue to advocate for the horse and buggy over the automobile, but most people won’t bother to take the discussion seriously.
>Being anti AI/anti LLM is solidly in the Luddite camp; there’s really no more debates to be had. Every serious inquiry shows productivity gains by using ai.
These two sentences appear to be at odds with one another.
> Being anti AI/anti LLM is solidly in the Luddite camp; there’s really no more debates to be had. Every serious inquiry shows productivity gains by using ai.
"Guys this debate is so stupid. Every serious inquiry shows productivity gains when we take away all senses, jack workers into the matrix and feed them a steady diet of speed intravenously. This put debate to rest. Now we are post-debate"
Something can increase productivity and still not be good.
The Luddites had some great ideas and were driven by a more sophisticated philosophy than people tend to give them credit for. I think their motivations are still applicable and worth considering today.
Then put me solidly in the Luddite camp. I think you should look into the history of the Luddites though. They were not against technology; they were against technology that destroyed jobs.
AI is about destroying working-class jobs so that corporations and the owning class can profit. It's not about writing code or summarizing articles. Those are just things workers can do with it. That's not what it's actually for. Its purpose is to reduce payroll costs for companies by replacing workers.
> They were not against technology; they were against technology that destroyed jobs.
They were not against technology; they were against technology that their destroyed jobs. If we had followed what they wanted, we'd still be in a semi pre industrial artisnal economy, and the worse off for it.
The only viewpoint I really agree with in this article is the "use it or lose it" mentality. Skills are developed and maintained by practicing them, but if all the author really wants to do is write code, then LLMs are literally an answer to their prayers!
You can enable virtually free test driven development. Write the test names down and let the LLM implement them for you. You save 50% of your time and you get to go to town on implementation and or optimizations.
You can have the LLM take the non-tech-counterparts description of a bug and have it point you at precise lines of code to investigate rather than grepping around a codebase you might not know well.
You can onboard to new languages, frameworks, repositories extremely fast by having a partner (the LLM) explain implementation patterns and approaches on demand! You don't even need to talk to another human being! Get your questions answered in seconds and start coding!
You can rapidly prototype. You can get immediate code reviews. You can rubber duck. You can visualize business/logic flows and code branching to better understand existing implementations. You can even have the LLM write an implementation plan for you then write the code yourself!
If you cant find a way to write more code with LLMs, its either an imagination or skill issue.
> You can enable virtually free test driven development. Write the test names down and let the LLM implement them for you. You save 50% of your time and you get to go to town on implementation and or optimizations.
That's assuming that it writes good tests, and that you don't care to take the time to verify the tests it wrote, no?
I do find LLMs useful for scaffolding this stuff, but yeah, good test writing still seems to require a lot of hand-holding. I don't mind. I'm happy with my tests and they get written faster. Hand-holding and verifying is still faster than how I used to do it, and the LLMs admittedly capture more cases than I did without them. They will try to create test cases that make no sense too, but it's worth having to delete if it means it also comes up with test cases that I didn't.
No. There's a difference between writing code, and getting code written. LLMs are the second.
I feel like we are still using it when cleaning up the code that we often get I guess.
all of this sounds awful
The whole point of my post is that you get to pick and choose what parts this magical software automates for you. Based on your response, it's an imagination issue for you.
2 replies →
LLM’s can write documentation well, too.
>Reviewing is worse than writing
I think the reason this discussion keeps coming up is that the people who are getting a lot out of these tools are people who are, at best, the software-equivalent of assembly-line workers. If something can be easily understood by passively reading it then it probably isn't complicated or novel and therefore it's not surprising a pseudorandom bullshit generator can do it for you; all it lacks is a unit testing system which can verify that its interpretation of the problem-statement matches the interpretation which would be most obvious to a human and that is evidently not a solved problem thus far.
If the hardest part of your job is understanding code written by other people and even code written by yourself in the distant past, then LLMs are of literal use because the problem they solve was never a significant bottleneck and in fact their "solution" only serves to pump a higher volume of fluid through the neck of the proverbial bottle.
It's the difference between reading somebody's paper in a mathematical journal to understand how they came to the conclusion they are presenting, and merely using the identity they have proven on faith. If all that mattered was to perform some calculation based on their work then its clear which approach will get more work done in less time but if you don't take it for granted that everything in the journal is correct or if you want to be able to further develop ideas based upon their proof then you have to spend a few days or even weeks trying to understand how each step leads to its successor.
It's also why i hate the old adage about not reinventing wheels, it promotes ignorance by asserting that education itself is ignorance.
I’m glad to hear someone say that. I’ve been wrestling for weeks with the idea of reinventing a particular wheel in my profession, for a personal coding project. The problem is that my implementation can’t ever be as complete or as useful as the existing solutions because it’s way too much for one person to accomplish in a reasonable amount of time.
But, I like it, I’ve reinvented many wheels in my work and it’s benefited me greatly. So I will reinvent this particular wheel as well…
We can't uninvent LLMs. They're here already and the best course of action for everyone is to learn to live with them.
That being said I noticed that the more opinionated a language/framework/library is, the worse off one is using LLMs.
I was surprised by this, but then I put a particularly fishy line into GitHub's search box. What I saw were piles upon piles of bad practices and incorrect usages. There's a lot of bad code there and LLMs are learning from it.
If you're working on something where the cost of bugs is high and they're tricky to detect, LLM generated code may not be a winning strategy if you're already a skilled programmer. However, LLMs are great for code review in these circumstances - there is a class of bugs that are hard to spot if you're the author.
As a simple example, accidentally inverting feature flag logic will not cause tests to fail if the new behavior you're guarding does not actually break existing tests. I and very senior developers I know have occasionally made this mistake and the "thinking" models are very good at catching issues like this, especially when prompted with a list of error categories to look for. Writing an LLM prompt for an issue class is much easier than a compiler plugin or static analysis pass, and in many cases works better because it can infer intent from comments and symbol names. False positives on issues can be annoying but aren't risky, and also can be a useful signal that the code is not written in a clear way.
“a new paradigm for software development that you must learn or be left behind” that’s a completely inaccurate statement. Nobody is saying that you will be “left behind”. It certainly is a new paradigm but it doesn’t mean the old way of doing things won’t continue to exist. Just like there are still some problems that require code to be written in C or even assembly. Just like there are hand-made goods. The size of the opportunity is a whole different story.
I disagree - a lot of people with positions of power are unfortunately saying the “will be left behind “ bit
not all of course as there’ll be morons always but a lot of people who are saying “will be left behind” see an amazing tool which in hands of the right people is a great multiplier…
I think you wrong the problem is not LLM , the problem is you .
What I don't understand in all that noise from the LLM critics - they keep talking about how LLMs are so horrendously bad at writing code as if that's the only thing we're trying to use them for. As if they're not even genuine programmers, working on real projects, touching code every day.
Software crafting is so much more than merely writing code. There's a significant amount of reading code that goes into it. Code written by you. Code written by someone else. Someone else's code that you butchered with your edits, your own code butchered by someone else, and everything intertwined in between. Code that can't easily be explained by looking at it - sometimes you have to find relevant PRs, tickets, documentation, related online communication, some loosely-related code sitting someplace else, etc.
LLMs absolutely can help you read code, just as they are very capable of helping someone study a book or an academic paper. Denying that fact simply is ignorance. Of course, LLMs are absolutely capable of leading you in the wrong direction, confusing you, and giving you incorrect facts, even when you're studying text in plain English, just like it's possible to end up at the bottom of a lake when driving a car. Everyone needs to exercise caution and "know what the fuck they're doing" when using a model. But calling LLMs "bullshit generators" and "magic 8 balls" is so stupid. Sure, if you use it to perform bullshit stuff, it will generate nothing but bullshit.
You're free not to. Time will tell who's right
I can’t take this article seriously, and neither should you. Being anti AI/anti LLM is solidly in the Luddite camp; there’s really no more debates to be had. Every serious inquiry shows productivity gains by using ai.
It’s anyone’s prerogative to continue to advocate for the horse and buggy over the automobile, but most people won’t bother to take the discussion seriously.
>Being anti AI/anti LLM is solidly in the Luddite camp; there’s really no more debates to be had. Every serious inquiry shows productivity gains by using ai.
These two sentences appear to be at odds with one another.
The data showed llms are better. This put debate to rest. Now we are post-debate.
16 replies →
> Being anti AI/anti LLM is solidly in the Luddite camp; there’s really no more debates to be had. Every serious inquiry shows productivity gains by using ai.
"Guys this debate is so stupid. Every serious inquiry shows productivity gains when we take away all senses, jack workers into the matrix and feed them a steady diet of speed intravenously. This put debate to rest. Now we are post-debate"
Something can increase productivity and still not be good.
You mean like the study that found a 20% productivity drop instead of gain?
It didn't really show that if you break down the data, and its methodology was pretty bad
https://www.fightforthehuman.com/are-developers-slowed-down-...
The Luddites had some great ideas and were driven by a more sophisticated philosophy than people tend to give them credit for. I think their motivations are still applicable and worth considering today.
Then put me solidly in the Luddite camp. I think you should look into the history of the Luddites though. They were not against technology; they were against technology that destroyed jobs.
AI is about destroying working-class jobs so that corporations and the owning class can profit. It's not about writing code or summarizing articles. Those are just things workers can do with it. That's not what it's actually for. Its purpose is to reduce payroll costs for companies by replacing workers.
> They were not against technology; they were against technology that destroyed jobs.
They were not against technology; they were against technology that their destroyed jobs. If we had followed what they wanted, we'd still be in a semi pre industrial artisnal economy, and the worse off for it.
1 reply →
you're absolutely correct!