Comment by ang_cire a day ago
This comment section really shows the stark divide between people who love coding and thus hate AI, and people who hate coding and thus love AI.
Honestly, I suspect the people who would prefer to have someone or something else do their coding, are probably the devs who are already outputting the worst code right now.
We're the silent majority, I'm pretty sure. If you love coding, you probably love technology, and if you love technology, you probably love AI, which is inarguably the most interesting tech advancement in this decade.
The others, who are not like us? They've got other priorities. If you hate coding but you love AI, you're probably into software engineering because of the money, not love of technology. If you love coding and you hate AI, you're probably more committed to some sort of ideology than you are the love of technology. If you hate coding and you hate AI, well, I hope you throw your cellphone into the river and find a nice cabin in the woods somewhere to hide in.
I think there are a lot of us, but the people who dislike AI are much more vocal in online conversations about it.
(The hype merchant, LinkedIn influencer, Twitter thread crowd are super noisy but tend to stick to their own echo chambers, it's rare to have them engage in a forum like Hacker News directly.)
> I don't know if I'm a minority
No, there's plenty of top-class engineers who love coding with AI. e.g. Antirez.
I love AI as a concept.
I hate the reality of our current AI, which is benefitting corporations over workers, being used for surveillance and censorship (nevermind direct social control via misinformation bots), and is copying the work of millions without compensating them in order to do it.
And the push for coders to use it to increase their output, will likely just end up meaning expectations of more LoC and more features faster, for the same pay.
But FOSS, self-hosted LLMs? Awesome!
How is using Claude over Llama benefitting corporations over workers? I work with AI every day and sum total of my token spend across all providers is less than a single NVidia H100 card I'd have to buy (from a pretty big corporation!), at the very least, for comparable purpose?
How are self-hosted LLMs not copying the work of millions without compensating them for it?
How is the push for more productivity through better technology somehow bad?
I am pro FOSS but can't understand this comment.
First of all, Lisp, Fortran and COBOL had been around most of the time when assembly was popular. Assembly was used because of resource constraints.
Secondly, you are not writing anything you get from an LLM. You prompt it and it spits out other people's code, stripped of attribution.
This is what children do: Ask someone to fix something for you without understanding the result.
I very much understand the result of code that it writes. But I have never gotten paid to code. I get paid to use my knowledge of computers and the industry to save the company money or to make the company money.
Do you feel the same way when you delegate assignments to more junior developers and they come back with code?
It’s almost like there’s a big range of different comprehension styles among human beings, and a varying set of preferences that go with those.
It is absolutely possible to enjoy both- I have used LLMs to generate code for ideas about alternate paths to take when I write my code- but prompt generation is not coding, and there are WAY too many people who claim to be coding when they have in fact done nothing of the sort.
> a far higher intensity
I'm not sure what this is supposed to mean. The code that I've gotten is riddled with mistakes and fabrications. If I were to use it directly, it would significantly slow my pace. Likewise, when I use LLMs to offer alternative methods to accomplish something, I have to take the time to sit down and understand what they're proposing, how to actually make it work, and whether that route(s) would be better than my original idea. That is a significant speed reduction.
The only way I can imagine LLMs resulting in "far higher intensity" is if I was just yolo'ing the code into my program, and then doing frantic integration, correction, and bugfix work afterwards.
Sure, that's "higher intensity", but that's just working harder and not smarter.
It is not coding the same way riding a bus is not driving
You may get to the same destination, but it is not the same activity
What if I prefer to have a clone of me doing my coding, and then I throw my clone under the bus and start to (angrily) hyperfocus explore and change every piece to be beautiful? Does this mean I love coding or I hate coding?
It's definitely a personality thing, but that's so much more productive for me, than convincing myself to do all the work from scratch after I had a design.
I guess this means I hate coding, and I only love the dopamine from designing and polishing my work instead of making things work. I'm not sure though, this feels like the opposite of hate coding.
> flawed enough starting premise
That's where we start to disagree what future looks like, then.
It's not there yet, in that the LLM-clone isn't good enough. But amusingly a not nearly good enough clone of me already made me more productive, in that I'm able to deliver more while maintaining the same level of personal satisfaction with my code.
The question of increasing productivity and what that means for us as laborers is another entire can of worms, but that aside, I have never yet found LLM-gen'd code that met my personal standards, and sped up my total code output.
If I want to spend my time refactoring and bugfixing and rewriting and integrating, rather than writing from scratch and bugfixing, I can definitely achieve that by using LLM code, but the overall time has never felt different to me, and in many cases I've thrown out the LLM code after several hours due to either sheer frustration with how it's written, or due to discovering that the structure it's using doesn't work with the rest of the program (see: anything related to threading).
I replaced "code" for "singing" to make a point.
> This comment section really shows the stark divide between people who love singing and thus hate AI-assisted singing, and people who hate singing and thus love AI-assisted singing.
> Honestly, I suspect the people who would prefer to have someone or something else do their singing, are probably the singers who are already outputting the worst singing right now.
The point is: just because you love something, doesn't mean you're good at it. It is of course positively correlated with it. I am in fact a better singer because I love to sing compared to if I never practiced. But I am not a good singer, I am mediocre at best (I chose this example for a reason, I love singing as well as coding! :-D)
And while it is easier to become good at coding than at singing - for professional purposes at least - I believe that the effect still holds.
I think the analogy/ substitution falls apart in that singing is generally not very stable or lucrative (for 99.999% of singers), so it is pretty rare to find someone singing who hates it. Much less uncommon to find people working in IT who hate the specific work of their jobs.
And I think we do tend to (rightfully) look down on e.g. singers who lip-sync concerts or use autotune to sing at pitches they otherwise can't, nevermind how we'd react if one used AI singing instead of themselves.
Yes, loving something is no guarantee of skill at it, but hating something is very likely to correspond to not being good at it, since skills take time and dedication to hone. Being bad at something is the default state.
I have been working in IT for 5 years while being a professional musician for 8 years (in France and touring in Europe). I've never met a single singer who told me they hate singing, on other hand, I can't even count how many of my colleagues told me how much they hate coding.
Another analogy would be with sound engineering. I've met sound engineer who hate their job as they would rather play music. They are also the ones whose jobs are likely to be replaced by AI. And I would argue that the argument stand stills. AI Sound Engineers who hate working on sound are often the bad sound engineers.
> I think the analogy/ substitution falls apart in that singing is generally not very stable or lucrative (for 99.999% of singers), so it is pretty rare to find someone singing who hates it.
I tried to cover this particular case with:
> And while it is easier to become good at coding than at singing - for professional purposes at least - I believe that the effect still holds.
---
> Yes, loving something is no guarantee of skill at it, but hating something is very likely to correspond to not being good at it, since skills take time and dedication to hone. Being bad at something is the default state.
I tried to cover this particular case with:
> It is of course positively correlated with it.
---
> Being bad at something is the default state.
Well, skill-wise yes. But being talented at something can happen, even when you hate something.
> And I think we do tend to (rightfully) look down on e.g. singers who lip-sync concerts or use autotune to sing at pitches they otherwise can't, nevermind how we'd react if one used AI singing instead of themselves.
Autotune is de rigueur for popular music.
In general, I'm not sure that I agree with looking down on people.
I love coding - but I am not very good at it. I can describe what I want in great detail, with great specificity. But I am not personally very good at turning that detailed specification into the proper syntax and incantations.
AI is like jet fuel for me. It’s the translation layer between specs and code I’ve always wanted. It’s a great advisor for implementation strategies. It’s a way to try new strategies in code quickly.
I don’t need to get anyone else to review my code. Most of this is for personal projects.
I don’t really write professionally, so I don’t have a ton of need for it to manage realities of software engineering (large codebases, peer reviews, black box internal systems, etc). That being said - I do a reasonable amount of embedded Linux work, and AI understands the Linux kernel and device drivers very well.
To extend your metaphor: AI is like a magic microphone that makes all of my singing sound like Tony Rice, my personal favorite singer. I’ve always wanted to sound like him - but I never will. I don’t have the range or the training. But AI allows my coding level to get to that corresponding level with writing software.
I absolutely love it.
This is really interesting to me.
Do you love coding, or do you love creating programs?
It seems like the latter given your metaphor being a microphone to make you seem like you could sing well, i.e. wanting the end state itself rather than the achievement via the process.
"wanted to sound like him" vs "wanted to sing like him"
I very much like creating programs.
The code is a tool. Nothing more.
I love the shed I built for my family. I don’t have a single feeling for the hammer I used to build it.
For the record: I can sing well. I just can’t sound like Tony Rice. I don’t have his vocal cords or training.
Who write boilerplate this day? I just lift the code from the examples in the docs (especially css frameworks). And I love looking at functions docs, because after doing it a few times, you develop an holistic understanding of the library and your speed increases. Kinda like learning a foreign language. You can use an app to translate everything, or asks for the correct word when the needs arises. The latter is a bit frustrating at the beginning, but that’s the only way to become fluent.
Seriously, I see this claim thrown around as though everyone writes the same starting template 50 times a week. Like, if you've got a piece of "boilerplate" code you're constantly rewriting... Save It! Put it in a repo or a snippet somewhere that you can just copy-paste when you need it.
You don't need a multi-million dollar LLM to give you slightly different boilerplate snippets when you already have a text editor on your computer to save them.
i think everyone here has extremely different ideas of what AI coding actually is and it's frustrating because basically everyone is strawmanning (myself included probably), as if using it means i'm not looking at documentation or not understanding what is goin on at all times.
it's not about having the LLM write some "starter pack" toy scaffold. i means when i implement functionality across different classes and need to package that up and adapt, i can just tell the LLM how to approach it and it can produce entire sections of code that would literally just be adaptations of certain things. or to refactor certain pieces that would just be me re-arranging shit.
maybe that's not "boilerplate", but to me it's a collosal waste of my time that could be spent trying to solve a new problem. you can't package that up into a "code snippet" and it's not worth the time carefully crafting templates. LLM can do it faster, better, and cost me near nothing.
Maybe all code is boilerplate for them? I use libraries and frameworks exactly for the truly boilerplate part. But I still try to understand those code I depends on, as some times I want to deviate from the defaults. Or the bug might be in there.
It’s when you try to use an exotic language, you realize the amount of work that has been done to minimize dev time in more mainstream languages.
Every PR I have to review with an obviously LLM-generated title stuffed with adjectives, and a useless description containing an inaccurate summary of the code changes pushes me a little bit more into trying to make my side projects profitable in the hope that one takes off. It usually only gets worse from there.
Documentation needs to be by humans for humans, it's not a box that's there to be filled with slop.
> The actual documentation needs to be by humans for humans.
This is true for producing the documentation but if there is an LLM that can take said documentation and answer questions about it is a great tool. I think I get the answer far quicker with LLM than sifting through documentation when looking for existence of a function in a library or a property on an object.
The documentation are for answering your questions, it’s not a puzzle to be solved. Using the reference docs assumes that you already have an understanding about the thing that is being documented and you’re looking for specificity or details. If not, the correct move is to go through a book, a tutorial, or the user guide. Aka the introductory materials.
seeing a lot of `const thing = doThing(); // add this line` showing up lately too.
I think that comment is conflating 2 different things: 1) people like you and I who use LLMs for exploring alternative methods to our own, and 2) people who treat LLMs like Stack Overflow answers they don't understand but trust because it's on SO.
Yes, there are tasks or parts of the code that I'm less interested in, and would happily either delegate or negotiate-off to someone else, but I wouldn't give those to a writer who happens to be able to write in a way that approximates program code, I'd give them to another dev on the team. A junior dev gets junior dev tasks, not tasks that they don't have the skills to actually perform, and LLMs aren't even at an actual junior dev level, imhe.
I noted in another comment that I've also used LLMs to get ideas for alternate ways to implement something, or to as you said "jump start" new files or programs. I'm usually not actually pasting that code into my IDE, though- I've tried that, and the work to make LLM-generated code fit into my programs is way more than just writing out the bits I need, where I need. That is clearly not the case for a lot of people using LLMs, though.
I've seen devs submitting PRs with giant blocks of clearly LLM-gen'd code, that they've tried to monkey-wrench into working with the rest of the program (often breaking conventions or secure coding standards). And these aren't junior devs, they're devs that have been working here for years and years.
When you force them to do a code review, they know it's not up to par, but there is a weird attitude that LLM-gen'd code is more acceptable to be submitted with issues than personally-written code. As though it's the LLM's fault or job to fix, even though they prompted and copied and badly-integrated and PR'd it.
And that's where I think there is a stark divide. I think you're on my side of the divide (at least, I didn't get the impression that you hate coding), it just sounds like you haven't really seen the other side.
My personal dime-store psych theory is that it's the same mental mechanism that non-technical computer users fall into of improperly trusting/ believing computers to produce correct information, but now happening to otherwise technical folks too because "AI" is still a black box technology to most of us, like computers in general are to non-techies.
LLMs are really really cool, and really really impressive to me, and I've had 'wow' moments where they did something that makes you forget what they are and how they work, but you can't let that emotional reaction towards it override the part that knows it's just a token chain. When you do, people end up (obviously on the very extreme end) 'dating' them, letting them make consequential "decisions", or just over-trusting their output/code.
I started “coding” in 1986 in assembly on an Apple //e and by the time I graduated from college, I had experience with 4 different processor families - 65C02, 68K, PPC and x86. I spent the first 15 years of my career programming in C and C++ along with other languages.
Coding is just a means to an end - creating enough business value to convince the company I’m working for to give me money that I can exchange for food and shelter.
If AI can help me do that faster, I’m going to use it. Neither do I want to spend months procuring hardware and managing building out a server room (been there done that) when I can just submit some yaml/HCL and have it done for me in a few minutes.
I like solving problems but I hate coding. Wasting 20 minutes because you forgot a semicolon or something is not fun. AI let's me focus on the problem and not bother with the tedious coding bit.
I write code to solve problems for my own use or for my hobby electronics projects. Asking chatgpt to write a script is faster than reading the documentation of some python library.
Just last week it wrote me a whole application and gui to open a webpage at a specific time. Yeah it breaks after the first trigger but it works for what I need.
And that's OK! I'm not trying to gatekeeping anyone from the title of coder or programmer. But what is fine for quick small scripts and throwaway code can be quite bad even for smallish projects. If you're trying to solve a problem in a systematic way, there's a lot of concerns that pertain to the durability of the solution.
There's a lot of literature about these concerns and a lot of methodologies to alleviate them. I (and others) are judging LLMs in light of those concerns. Mostly because speed was never an issue for us in prototypes and scripts (and it can be relaxing to learn about something while scripting it). The issue is always reliability (can it do what I want) and maintainability (can I change it later). Performance can also be a key issue.
Aside: I don't know the exact problem you were solving, but based on the description, that could have been done with systemd timers (macOS services are more of a pain to write). Yes, there's more to learn, but time triggering some command is a problem solved (and systemd has a lot more triggers).
>that could have been done with systemd timers
I could have used Windows Task Scheduler but having a nice gui with a custom icon is much more pleasant to use.
This doesn't even make sense, forgetting a semicolon is immediately caught by the compiler. What positive benefits does AI provide here?
By knowing about libraries that I don't have to read and learn and being able to glue them together to quickly accomplish my task.
I love coding and don't love questioning AI and checking responses.
But the simple fact is I'm much more productive with AI and I believe this is likely true for most programmers once they get adjusted.
So for production, what I love the most doesn't really matter, otherwise I'd be growing tomatoes and guiding river rafting expeditions. I'm resigned to the fact the age of manually writing "for loops" is largely over, at least in my case.
If devs would learn how to document their work properly then there'd be much less use for AI and more people who enjoyed coding.
If you're using those things to do *the core function* of the program you're writing, that's an issue.
SDKs and libraries are there to provide common (as in, used repeatedly, by many) functions that serve as BUILDING BLOCKS.
If you import a library and now your program is complete, then you didn't actually make a useful program, you just made a likely less efficient interface for the library.
BUT ALSO-
SDKs and libraries are *vetted* code. The advantage you are getting isn't just about it having been written for you, it's about the hundreds of hours of human code review, iteration, and thought, that goes into those libraries.
LLM code doesn't have that, so it's not about you benefitting from the knowledge and experience of others, it's purely about reducing personally-typed LoC.
And yes, if you're wholesale copy-pasting major portions of your program from stack overflow, I'd say that's about as bad as copy-pasting from ChatGPT.
This belies the way that LLM code is being used.
People aren't taking LLM code and then thoughtfully refactoring and improving it, they're using it to *avoid* doing that, by treating the generated code as though it's already had that done.
That's why the pro-LLM-code people in this very thread are talking about using it to automate away the parts of the coding they don't like. You really think they're then going to go back and improve on the code past it minimally working?
There will be no advancement from that, just mediocre or bad code going unreviewed and ignored until it breaks.
I love coding but I also love AI.
I don't know if I'm a minority but I'd like to think there are a lot of folks like me out there.
You can compare it to someone who is writing assembly code and now they've been introduced to C. They were happy writing assembly but now they're thrilled they can write things more quickly.
Sure, AI could lead us to write buggier code. Sure, AI could make us dumber because we just have AI write things we don't understand. But neither has to be the case.
With better tools, we'll be able to do more ambitious things.