5 ms·

I don't use LLMs for programming

70 points by ms7892 7mo ago

baCist 7mo ago
I mostly use AI as an assistant, not as a replacement. I actually enjoy the process of programming and learning new things along the way. I’m not really interested in outsourcing that to an LLM just to save a few minutes.
shanjai_raj7 7mo ago
I've gone the other direction completely. Run claude code basically unsupervised on my codebase for months now and honestly I write way less by hand. still understand everything it does but I spend time on what actually matters — the architecture, the decisions. for me the fun part was always shipping things, not the syntax.
voidUpdate 7mo ago
I don't see the point in supporting the hoovering up of anything anyone has ever wrote online, without attribution, just so I don't get to do the thing I actually like doing, programming
- cbeach 7mo ago
  Claude has helped me learn that the thing I enjoyed was actually delivering good software, as opposed to crafting syntax.
  - abirch 7mo ago
    If people enjoy coding by hand: GREAT DO IT!!! My mental model is that coding by hand is similar to horseback riding, sail boating, etc. These skills are still enjoyed by people and in some circumstances they are invaluable.
imdsm 7mo ago
I've written code for almost 30 years, and the last 4 years I've slowly used AI more and more, starting with GitHub Copilot beta, ChatGPT, Cursor, Windsurf, Claude, Gemini, Jules, Codex. Now I mostly work with Claude, and I don't write any code myself. Even configuring servers is easier with Claude. I still understand how everything works, but I now change how I work so I can do a lot more, cover a lot more, and rely less on people. It isn't much different to how it works with a team. You have an architecture who understands the broader landscape, you have developers who implement certain subsystems, you have a testing strategy, you have communication, teaching, management. The only difference now is that I can do all this with my team being LLMs/agents, while I focus on the leadership stuff: docs, designs, tests, direction, vision. I do miss coding, but it just isn't worth it anymore.
- mikedd 7mo ago
  I like this perspective.
- alansaber 7mo ago
  I've seen this at a few orgs i've visited, where the seniors have leaned into LLM programming more than the juniors for these reasons.
  - qsort 7mo ago
    I don't think the split is along seniority lines. Many juniors have adopted LLMs even faster. In many quarters it has also become a kind of political issue where "all the people I hate love LLMs so I must hate them."
- teiferer 7mo ago
  Sorry, good for you, but how is this relevant? Imagine somebody writes a blog post "why I bike to work". They detail that they love it, the fresh air, nature experience biking through a forest, yes sometimes it's raining but that's just part of the experience, and they get fit along the way. You respond with "well I take the car, it's just easier". Well, good for you, but not engaging with what they wrote.
deleted 7mo ago
[deleted]
mattmanser 7mo ago
I am really finding this. By the time I've specced out a feature properly to an LLM, I could have just written most of it quicker myself. But I often find that with jobs I want to give to other people, so maybe I over specify? There's some tasks where it's pretty clear what you want though and are just boring jobs that are totally not worth speccing well and an LLM will blaze through. Things like: - add oauth support to this API - add a language switcher in this menu, an API endpoint, save it to the UserSettings table - make a 404 page
- cbeach 7mo ago
  If you use plan mode, parallel agents and voice dictation, LLM-powered development becomes much faster and more powerful.
- teiferer 7mo ago
  > But I often find that with jobs I want to give to other people, so maybe I over specify? The difference is that with other people, you are training somebody else in your team who will eventually internalize what you taught them and then be able to carry the philosophy forward. Even if it took exactly the same amount of time for you to explain (+ code review etc), it's a clear net benefit in the long run. Not so with an LLM. There it's just lost time.
w-m 7mo ago
I don’t think learning and understanding is hard-coupled to performing all low level steps yourself. The LLM can be a developer, sure. But it can also take on the role of rubber duck, architect, teacher or pupil. Have a large LLM-written change set that works but that you’re not sure you fully understand? Make the coding agent quiz you on the design and implementation decisions. This can be a lot more engaging than trying to do a normal code review. And you might even learn something from it. Probably not the same amount as if you did this yourself fully. But that’s just a question of how much effort you want to invest in the understanding?
ml-anon 7mo ago
[flagged]
- apples_oranges 7mo ago
  please stop wasting our attention with such comments
bambax 7mo ago
The quote from Douglas Adams is perfectly consistent with using AI for programming. The difficulty of programming, indeed the whole point, is to understand the problem; it's not typing if-then-else cases for the millionth time. Explaining the problem to an LLM and having it ask pointed questions is helpful IMHO, as well as being able to iterate fast (output new versions fast). As an example, I'm currently making simple Windows utilities with the help of AI. Parsing config files in C is something the AI does perfectly. But an interesting part of the process is: what should go into a config file, or not, what are the best defaults, what should not be configurable: questions that don't have a perfect answer and that can only be solved by using each program for weeks, on different machines / in different contexts.
- zimpenfish 7mo ago
  > The difficulty of programming, indeed the whole point, is to understand the problem I'd dispute "the whole point" - there's a whole bunch of problems I can understand but would struggle to implement effectively in code (which is another big point - there's little use in a solution that takes, e.g., two months to calculate last week's numbers when your revenue/profit/planning depends on those numbers.) At a minimum, for me, the difficulties of programming are many stepped: understanding the problem -> converting that understanding to algorithms/whatnot -> implementing that understanding -> making it efficient (if required) -> verifying the solution. Trying to boil it down to "ONE COOL TRICK!" that justifies vibe-coding is daft. [There's also a whole bunch of things I can implement but don't really understand (business logic, sales/tax rules, that kind of thing) but that's why we have project managers, domain experts, etc.]
- anthk 7mo ago
  > is to understand the problem; it's not typing if-then-else cases for the millionth time. Edit macros and awk+grep solved that.
mikkupikku 7mo ago
This morning while sitting on the shitter, claude wrote me a complete plugbox interface for wiring together A/V filters, rendered with libASS subtitles to be embedded in an mpv video player.
NewEntryHN 7mo ago
This assumes you always learn something new with every new program you write.
ivanvoid 7mo ago
I genuinely don’t understand how anyone (with technical background) can see LLMs anything more then fancy autocomplete. If you know anything about NNs and about average code quality, that LLMs never will be able to generate high quality code. Im ready to get downvotes again for my takes, but as a person who writes and trains DL models, I will die on the hill: “people need to produce high quality data” it can be code it can be art, but we can’t rely on those models and trust in the things that they provide.
- s_dev 7mo ago
  The new bottle neck isn't writing code, it's testing. You're right you can't blindly trust the output of an LLM but you can trust the testing regime to ensure a certain standard has been met. In hindsight this actually sort of obvious, the more things change the more they stay the same etc.
  - ivanvoid 7mo ago
    Well it’s not obvious that is true. If you ask LLM to write tests, it will generate versions of them that code passes, that doesn’t guarantee good code. If you write tests yourself and just pray for great LLM pull, it’s easier to just write code yourself, in my humble opinion
    - s_dev 7mo ago
      That's a useless approach as you point out but doesn't meant there isn't a valid testing regime to be explored and upheld. Manual testing is going to be a lot more important, I see QA teams/roles becoming very valuable assets in the coming years.
  - deleted 7mo ago
    [deleted]
  - em-bee 7mo ago
    you can trust the tests that you have written, but what about the tests that you didn't write? can you be sure that your testsuite is complete? when i do test driven development, all the thinking goes into the tests, and the actual code writes itself. LLMs hardly help make that any faster. having a complete testsuite may make it easier to use LLMs for refactoring, and adding features, but then you still have to write he tests for the new functionality.
nananana9 7mo ago
I may start using LLMs to filter out these kinds of posts. At this point it's worth considering a permanent, pinned "HN Flamewar: Will LLMs turn you into the next Ken Thompson or are you just a poser who can't write code" thread. We're having this same discussion, constantly, on 5 different threads on the frontpage.
- traxler 7mo ago
  I've seen a page offering the latest of AI news from HN and my reaction was basically yours. I wish I could have a HN frontpage with everything but AI news. Both postive or negative.
- anthk 7mo ago
  Ken would just write awk and rc scripts to define half of the code boilerplate.
- leoc 7mo ago
  Right, we do seem to have hit diminishing returns on dueling "I have seen the light" and "I haven't fallen for it" blogposts based on personal experience and the author's hunches about where things are going, and we definitely don't need to restart the same discussion from 0 every time another one lands. One thing which would be very interesting at this point is some actual software engineering research measuring the actual, not just user-perceived, impacts.
  - nananana9 7mo ago
    We don't do measurable metrics to evaluate our processes, ever. We pick up a trend and go at it for 10 years, until we have a 1,000,000 line monstrosity that's impossible to work on. Unfortunately people need to experience a 1 million line codebase a dynamic language to figure out that types are actually pretty nice, and they need to write getters and setters for every field for a few years to figure out OOP is stupid, and they need to do 10 HTTP requests for something that could be 10 function calls to figure out microservices are stupid. In none of these trends did the industry pause to evaluate if what's being written is completely idiotic, it's only with a few decades of hindsight, after a lot of money is lost that we learn the lesson.
timonoko 7mo ago
Gemini parsed 5000 lines assembly program. And it understood everything. I wanted to change it from 32-bit MSDOS to 64-bit Linux. But it realized that the segmented memory model cannot be implemented in large memory without massive changes which breaks everything else. It was willing to construct new program with seemingly same functionality, but the assembly code was so incomprehensible that whole project was useless as a learning tool. And C-version would have been faster already. Sorry to say, but less talented humans like me-myself are already totally useless in this.
- qsera 7mo ago
  > but the assembly code was so incomprehensible Wait, I thought you said it understood everything..
  - timonoko 7mo ago
    What? I mean it made its own version, but it was so full of incomprehensible squiggles that it was useless as a learning tool. I just wanted to see what it would look like. Lesson learned.
adamddev1 7mo ago
> By the time you’ve sorted out a complicated idea into little steps that even a stupid machine can deal with, you’ve certainly learned something about it yourself. I love these quotes. I got a much deeper, more elegant understanding of the grammar of a human language as I wrote a phrase generator and parser for it. Writing and refactoring it gave me an understanding of how the grammar works. (And LLMs still confidently fail at really basic tasks I ask them for in this language.)
prohobo 7mo ago
Seeing a lot of "ok boomer" reactions to posts like this, and honestly I think I kind of agree - but more accurately the author hasn't considered the current landscape properly. Grady Booch (co-creator of UML) has this to say about AI: this is a shift of the abstraction of software engineering up a level. It's very similar to when we moved from programming in assembly to structured languages, which abstracted away the machine. Now we're abstracting away the code itself. That means specs and architectural understanding are now the locus of work - which is exactly what Neil is claiming to be trying to preserve. I mean, yeah you can give that up to the AI as well but then you just get vibecoded garbage with huge security/functionality holes.
mixtureoftakes 7mo ago
Ironically, author doesnt realize that not everyone wants to learn everything There is nothing wrong whatsoever with just getting things done.
- deleted 7mo ago
  [deleted]
7777332215 7mo ago
A large issue is that I am not going to give up my private source code/IP to be trained on. As an individual, not a billion dollar enterprise.
yunseo47 7mo ago
Coding without AI will likely take on the nature of leisure activities like cycling, jogging, horseback riding, or swimming. The invention of cars, trains, and ships didn't eliminate them. It's clear the latter are overwhelmingly more efficient, while the former now remain in the realm of hobbies or exercise. I also deliberately avoid using AI for some small projects and code them myself, but I consider this purely a hobby now, not work. As the original author pointed out, the advice to jog or ride a bike because driving all the time is bad for your health is sound, but the Red Flag Act has proven to be a foolish endeavor. I believe the same phenomenon will occur.
- missingdays 7mo ago
  Cycling is not just a leisure activity and cars are not a full bike replacements.
  - yunseo47 7mo ago
    The point I was trying to make is that whether you should use AI for coding depends on the scale and nature of the task. To continue the original analogy, even if it's not leisure, a bicycle is a practical choice for short-distance travel. Of course, a car doesn't perfectly replace a bicycle. But would that still be true for distances of tens or hundreds of kilometers? And this is just an analogy; if you don't like cars, an electric bike, a scooter, or something similar is fine.
    - duskdozer 7mo ago
      >if you don't like cars, an electric bike, a scooter, or something similar is fine. Assuming that society hasn't been stroaded into artificially favoring cars, to the point where other options become effectively removed, even if they would otherwise have been better-suited to the use case.
axegon_ 7mo ago
I don't either. I'm genuinely considering registering an NGO dedicated to anti-slop. I tried AI and it didn't work on all accounts - bugs, edge cases are never covered, horrible security, slow and over complicated. The reason people keep saying that it does work is just the perception they had of programming: A lot of people were lead to believe that anyone can be a programmer. Much like everyone believes that they can be an artist and spoilers - that's not true. I am saying this as the child of two artists - I am incapable of creating art, despite numerous swings in that direction when I was a child - it was just not for me. People looking from the outside saw the tons of apps pouring out over the years, some making billions and though "well if those losers can do it, so can I". A 20 hour course on web development did not cut it, even though the hiring spree around COVID made many think that it did and did not attribute it to the instant rise in demand for online services. But that, for better or worse, did not last. So the alternative came in the form of AI slop and now an active generation that is in their mid 20's thinking that seemingly functioning slop and stable software are the same thing, completely brushing off a century of collective knowledge in what we know as computer science. The metric became lines of code, although those of us that started off coding as children when MySpace was a thing and goto was the best performing search engine, are well aware that lines of code is the stupidest metric you can come up with. But slop machines produce so much of it, it's easy to see why many people are like "see? see this? it works! And you are gonna be doing this 2 days as a caveman". Gladly, because two data pipelines that do the exact same thing take 4 days to run on slop code, whereas my caveman approach takes single digit hours and does not produce several billion rows of unusable garbage. Not to mention the countless times when someone has asked he to help them when they are stuck and a simple question such as "where do you define the path to the output directory?" leads to 10 minutes of scrolling on project that contains a total of 10000 lines of code. The good news for us mortals, is that this is that this approach is starting to bite people back and for the companies that manage to survive the inevitable head on collision, they will have to dig deep in their pockets to get people to clean up the mess.
Petersroberrt 7mo ago
[dead]

70 points by ms7892 7mo ago

I mostly use AI as an assistant, not as a replacement. I actually enjoy the process of programming and learning new things along the way. I’m not really interested in outsourcing that to an LLM just to save a few minutes.

shanjai_raj7 7mo ago

I've gone the other direction completely. Run claude code basically unsupervised on my codebase for months now and honestly I write way less by hand. still understand everything it does but I spend time on what actually matters — the architecture, the decisions. for me the fun part was always shipping things, not the syntax.

voidUpdate 7mo ago

I don't see the point in supporting the hoovering up of anything anyone has ever wrote online, without attribution, just so I don't get to do the thing I actually like doing, programming

cbeach 7mo ago
Claude has helped me learn that the thing I enjoyed was actually delivering good software, as opposed to crafting syntax.
- abirch 7mo ago
  If people enjoy coding by hand: GREAT DO IT!!! My mental model is that coding by hand is similar to horseback riding, sail boating, etc. These skills are still enjoyed by people and in some circumstances they are invaluable.

imdsm 7mo ago

I've written code for almost 30 years, and the last 4 years I've slowly used AI more and more, starting with GitHub Copilot beta, ChatGPT, Cursor, Windsurf, Claude, Gemini, Jules, Codex. Now I mostly work with Claude, and I don't write any code myself. Even configuring servers is easier with Claude. I still understand how everything works, but I now change how I work so I can do a lot more, cover a lot more, and rely less on people. It isn't much different to how it works with a team. You have an architecture who understands the broader landscape, you have developers who implement certain subsystems, you have a testing strategy, you have communication, teaching, management. The only difference now is that I can do all this with my team being LLMs/agents, while I focus on the leadership stuff: docs, designs, tests, direction, vision. I do miss coding, but it just isn't worth it anymore.

mikedd 7mo ago
I like this perspective.
alansaber 7mo ago
I've seen this at a few orgs i've visited, where the seniors have leaned into LLM programming more than the juniors for these reasons.
- qsort 7mo ago
  I don't think the split is along seniority lines. Many juniors have adopted LLMs even faster. In many quarters it has also become a kind of political issue where "all the people I hate love LLMs so I must hate them."
teiferer 7mo ago
Sorry, good for you, but how is this relevant? Imagine somebody writes a blog post "why I bike to work". They detail that they love it, the fresh air, nature experience biking through a forest, yes sometimes it's raining but that's just part of the experience, and they get fit along the way. You respond with "well I take the car, it's just easier". Well, good for you, but not engaging with what they wrote.

deleted 7mo ago

[deleted]

mattmanser 7mo ago

I am really finding this. By the time I've specced out a feature properly to an LLM, I could have just written most of it quicker myself. But I often find that with jobs I want to give to other people, so maybe I over specify? There's some tasks where it's pretty clear what you want though and are just boring jobs that are totally not worth speccing well and an LLM will blaze through. Things like: - add oauth support to this API - add a language switcher in this menu, an API endpoint, save it to the UserSettings table - make a 404 page

cbeach 7mo ago
If you use plan mode, parallel agents and voice dictation, LLM-powered development becomes much faster and more powerful.
teiferer 7mo ago
> But I often find that with jobs I want to give to other people, so maybe I over specify? The difference is that with other people, you are training somebody else in your team who will eventually internalize what you taught them and then be able to carry the philosophy forward. Even if it took exactly the same amount of time for you to explain (+ code review etc), it's a clear net benefit in the long run. Not so with an LLM. There it's just lost time.

w-m 7mo ago

I don’t think learning and understanding is hard-coupled to performing all low level steps yourself. The LLM can be a developer, sure. But it can also take on the role of rubber duck, architect, teacher or pupil. Have a large LLM-written change set that works but that you’re not sure you fully understand? Make the coding agent quiz you on the design and implementation decisions. This can be a lot more engaging than trying to do a normal code review. And you might even learn something from it. Probably not the same amount as if you did this yourself fully. But that’s just a question of how much effort you want to invest in the understanding?

ml-anon 7mo ago

[flagged]

apples_oranges 7mo ago
please stop wasting our attention with such comments

bambax 7mo ago

The quote from Douglas Adams is perfectly consistent with using AI for programming. The difficulty of programming, indeed the whole point, is to understand the problem; it's not typing if-then-else cases for the millionth time. Explaining the problem to an LLM and having it ask pointed questions is helpful IMHO, as well as being able to iterate fast (output new versions fast). As an example, I'm currently making simple Windows utilities with the help of AI. Parsing config files in C is something the AI does perfectly. But an interesting part of the process is: what should go into a config file, or not, what are the best defaults, what should not be configurable: questions that don't have a perfect answer and that can only be solved by using each program for weeks, on different machines / in different contexts.

zimpenfish 7mo ago
> The difficulty of programming, indeed the whole point, is to understand the problem I'd dispute "the whole point" - there's a whole bunch of problems I can understand but would struggle to implement effectively in code (which is another big point - there's little use in a solution that takes, e.g., two months to calculate last week's numbers when your revenue/profit/planning depends on those numbers.) At a minimum, for me, the difficulties of programming are many stepped: understanding the problem -> converting that understanding to algorithms/whatnot -> implementing that understanding -> making it efficient (if required) -> verifying the solution. Trying to boil it down to "ONE COOL TRICK!" that justifies vibe-coding is daft. [There's also a whole bunch of things I can implement but don't really understand (business logic, sales/tax rules, that kind of thing) but that's why we have project managers, domain experts, etc.]
anthk 7mo ago
> is to understand the problem; it's not typing if-then-else cases for the millionth time. Edit macros and awk+grep solved that.

mikkupikku 7mo ago

This morning while sitting on the shitter, claude wrote me a complete plugbox interface for wiring together A/V filters, rendered with libASS subtitles to be embedded in an mpv video player.

NewEntryHN 7mo ago

This assumes you always learn something new with every new program you write.

ivanvoid 7mo ago

I genuinely don’t understand how anyone (with technical background) can see LLMs anything more then fancy autocomplete. If you know anything about NNs and about average code quality, that LLMs never will be able to generate high quality code. Im ready to get downvotes again for my takes, but as a person who writes and trains DL models, I will die on the hill: “people need to produce high quality data” it can be code it can be art, but we can’t rely on those models and trust in the things that they provide.

s_dev 7mo ago
The new bottle neck isn't writing code, it's testing. You're right you can't blindly trust the output of an LLM but you can trust the testing regime to ensure a certain standard has been met. In hindsight this actually sort of obvious, the more things change the more they stay the same etc.
- ivanvoid 7mo ago
  Well it’s not obvious that is true. If you ask LLM to write tests, it will generate versions of them that code passes, that doesn’t guarantee good code. If you write tests yourself and just pray for great LLM pull, it’s easier to just write code yourself, in my humble opinion
  - s_dev 7mo ago
    That's a useless approach as you point out but doesn't meant there isn't a valid testing regime to be explored and upheld. Manual testing is going to be a lot more important, I see QA teams/roles becoming very valuable assets in the coming years.
- deleted 7mo ago
  [deleted]
- em-bee 7mo ago
  you can trust the tests that you have written, but what about the tests that you didn't write? can you be sure that your testsuite is complete? when i do test driven development, all the thinking goes into the tests, and the actual code writes itself. LLMs hardly help make that any faster. having a complete testsuite may make it easier to use LLMs for refactoring, and adding features, but then you still have to write he tests for the new functionality.

nananana9 7mo ago

I may start using LLMs to filter out these kinds of posts. At this point it's worth considering a permanent, pinned "HN Flamewar: Will LLMs turn you into the next Ken Thompson or are you just a poser who can't write code" thread. We're having this same discussion, constantly, on 5 different threads on the frontpage.

traxler 7mo ago
I've seen a page offering the latest of AI news from HN and my reaction was basically yours. I wish I could have a HN frontpage with everything but AI news. Both postive or negative.
anthk 7mo ago
Ken would just write awk and rc scripts to define half of the code boilerplate.
leoc 7mo ago
Right, we do seem to have hit diminishing returns on dueling "I have seen the light" and "I haven't fallen for it" blogposts based on personal experience and the author's hunches about where things are going, and we definitely don't need to restart the same discussion from 0 every time another one lands. One thing which would be very interesting at this point is some actual software engineering research measuring the actual, not just user-perceived, impacts.
- nananana9 7mo ago
  We don't do measurable metrics to evaluate our processes, ever. We pick up a trend and go at it for 10 years, until we have a 1,000,000 line monstrosity that's impossible to work on. Unfortunately people need to experience a 1 million line codebase a dynamic language to figure out that types are actually pretty nice, and they need to write getters and setters for every field for a few years to figure out OOP is stupid, and they need to do 10 HTTP requests for something that could be 10 function calls to figure out microservices are stupid. In none of these trends did the industry pause to evaluate if what's being written is completely idiotic, it's only with a few decades of hindsight, after a lot of money is lost that we learn the lesson.

timonoko 7mo ago

Gemini parsed 5000 lines assembly program. And it understood everything. I wanted to change it from 32-bit MSDOS to 64-bit Linux. But it realized that the segmented memory model cannot be implemented in large memory without massive changes which breaks everything else. It was willing to construct new program with seemingly same functionality, but the assembly code was so incomprehensible that whole project was useless as a learning tool. And C-version would have been faster already. Sorry to say, but less talented humans like me-myself are already totally useless in this.

qsera 7mo ago
> but the assembly code was so incomprehensible Wait, I thought you said it understood everything..
- timonoko 7mo ago
  What? I mean it made its own version, but it was so full of incomprehensible squiggles that it was useless as a learning tool. I just wanted to see what it would look like. Lesson learned.

adamddev1 7mo ago

> By the time you’ve sorted out a complicated idea into little steps that even a stupid machine can deal with, you’ve certainly learned something about it yourself. I love these quotes. I got a much deeper, more elegant understanding of the grammar of a human language as I wrote a phrase generator and parser for it. Writing and refactoring it gave me an understanding of how the grammar works. (And LLMs still confidently fail at really basic tasks I ask them for in this language.)

prohobo 7mo ago

Seeing a lot of "ok boomer" reactions to posts like this, and honestly I think I kind of agree - but more accurately the author hasn't considered the current landscape properly. Grady Booch (co-creator of UML) has this to say about AI: this is a shift of the abstraction of software engineering up a level. It's very similar to when we moved from programming in assembly to structured languages, which abstracted away the machine. Now we're abstracting away the code itself. That means specs and architectural understanding are now the locus of work - which is exactly what Neil is claiming to be trying to preserve. I mean, yeah you can give that up to the AI as well but then you just get vibecoded garbage with huge security/functionality holes.

mixtureoftakes 7mo ago

Ironically, author doesnt realize that not everyone wants to learn everything There is nothing wrong whatsoever with just getting things done.

deleted 7mo ago
[deleted]

7777332215 7mo ago

A large issue is that I am not going to give up my private source code/IP to be trained on. As an individual, not a billion dollar enterprise.

yunseo47 7mo ago

Coding without AI will likely take on the nature of leisure activities like cycling, jogging, horseback riding, or swimming. The invention of cars, trains, and ships didn't eliminate them. It's clear the latter are overwhelmingly more efficient, while the former now remain in the realm of hobbies or exercise. I also deliberately avoid using AI for some small projects and code them myself, but I consider this purely a hobby now, not work. As the original author pointed out, the advice to jog or ride a bike because driving all the time is bad for your health is sound, but the Red Flag Act has proven to be a foolish endeavor. I believe the same phenomenon will occur.

missingdays 7mo ago
Cycling is not just a leisure activity and cars are not a full bike replacements.
- yunseo47 7mo ago
  The point I was trying to make is that whether you should use AI for coding depends on the scale and nature of the task. To continue the original analogy, even if it's not leisure, a bicycle is a practical choice for short-distance travel. Of course, a car doesn't perfectly replace a bicycle. But would that still be true for distances of tens or hundreds of kilometers? And this is just an analogy; if you don't like cars, an electric bike, a scooter, or something similar is fine.
  - duskdozer 7mo ago
    >if you don't like cars, an electric bike, a scooter, or something similar is fine. Assuming that society hasn't been stroaded into artificially favoring cars, to the point where other options become effectively removed, even if they would otherwise have been better-suited to the use case.

axegon_ 7mo ago

I don't either. I'm genuinely considering registering an NGO dedicated to anti-slop. I tried AI and it didn't work on all accounts - bugs, edge cases are never covered, horrible security, slow and over complicated. The reason people keep saying that it does work is just the perception they had of programming: A lot of people were lead to believe that anyone can be a programmer. Much like everyone believes that they can be an artist and spoilers - that's not true. I am saying this as the child of two artists - I am incapable of creating art, despite numerous swings in that direction when I was a child - it was just not for me. People looking from the outside saw the tons of apps pouring out over the years, some making billions and though "well if those losers can do it, so can I". A 20 hour course on web development did not cut it, even though the hiring spree around COVID made many think that it did and did not attribute it to the instant rise in demand for online services. But that, for better or worse, did not last. So the alternative came in the form of AI slop and now an active generation that is in their mid 20's thinking that seemingly functioning slop and stable software are the same thing, completely brushing off a century of collective knowledge in what we know as computer science. The metric became lines of code, although those of us that started off coding as children when MySpace was a thing and goto was the best performing search engine, are well aware that lines of code is the stupidest metric you can come up with. But slop machines produce so much of it, it's easy to see why many people are like "see? see this? it works! And you are gonna be doing this 2 days as a caveman". Gladly, because two data pipelines that do the exact same thing take 4 days to run on slop code, whereas my caveman approach takes single digit hours and does not produce several billion rows of unusable garbage. Not to mention the countless times when someone has asked he to help them when they are stuck and a simple question such as "where do you define the path to the output directory?" leads to 10 minutes of scrolling on project that contains a total of 10000 lines of code. The good news for us mortals, is that this is that this approach is starting to bite people back and for the companies that manage to survive the inevitable head on collision, they will have to dig deep in their pockets to get people to clean up the mess.

Petersroberrt 7mo ago

[dead]