6 ms·

I guess we're just going to be in the age of this conversation topic until everyone gets tired of talking about it. Every one of these discussions boils down t

I guess we're just going to be in the age of this conversation topic until everyone gets tired of talking about it. Every one of these discussions boils down to the following: - LLMs are not good at writing code on their own unless it's extremely simple or boilerplate - LLMs can be good at helping you debug existing code - LLMs can be good at brainstorming solutions to new problems - The code that is written by LLMs always needs to be heavily monitored for correctness, style, and design, and then typically edited down, often to at least half its original size - LLMs utility is high enough that it is now going to be a standard tool in the toolbox of every software engineer, but it is definitely not replacing anyone at current capability. - New software engineers are going to suffer the most because they know how to edit the responses the least, but this was true when they wrote their own code with stack overflow. - At senior level, sometimes using LLMs is going to save you a ton of time and sometimes it's going to waste your time. Net-net, it's probably positive, but there are definitely some horrible days where you spend too long going back and forth, when you should have just tried to solve the problem yourself.

deleted 1y ago
[deleted]
MontyCarloHall 1y ago
It's almost as if you could recapitulate each of these discussions using an LLM!
rafaelmn 1y ago
> but this was true when they wrote their own code with stack overflow. Searching for solutions and integrating examples found requires effort that develops into a skill. You would rarely get solutions that would just fit into the codebase from SO. If I give a task to you and you produce a correct solution on the initial review I now know I can trust you to deal with this kind of problem in the future. Especially after a few reviews. If you just vibed through the problem the LLM might have given you the correct solution - but there is no guarantee that it will do it again in the future. Just because you spent less effort on search/official docs/integration into the codebase you learned less about everything surrounding it. So using LLMs as a junior you are just breaking my trust, and we both know you are not a competent reviewer of LLM code - why am I even dealing with you when I'll get LLM outputs faster myself ? This was my experience so far.
- fhd2 1y ago
  Like with any kind of learning, without a feedback loop (as tight as possible IMHO), it's not gonna happen. And there is always some kind of feedback loop. Ultra short cycle: Pairing with a senior, solid manual and automated testing during development. Reasonably short cycle: Code review by a senior within hours and for small subsets of the work ideally, QA testing by a seperate person within hours. Borderline too long cycle: Code review of larger chunks of code by a senior with days of delay, QA testing by a seperate person days or weeks after implementation. Terminally long feedback cycle: Critical bug in production, data loss, negative career consequences. I'm confident that juniors will still learn, eventually. Seniors can help them learn a whole lot faster though, if both sides want that, and if the organisation lets them. And yeah, that's even more the case than in the pre LLM world.
  - DenisM 1y ago
    LLM can also help learning f you ask it what can be done better. Seniors can make prepromt so that company customs are taken into account.
- OvbiousError 1y ago
  > So using LLMs as a junior you are just breaking my trust, and we both know you are not a competent reviewer of LLM code - why am I even dealing with you when I'll get LLM outputs faster myself ? This was my experience so far. So much this. I see a 1000 lines super complicated PR that was whipped up in less than a day and I know they didn't read all of it, let alone understand.
  - theshrike79 1y ago
    This is exactly what code reviews are for, doing reviews with juniors is always time-consuming
    - rafaelmn 1y ago
      Yes but your supposed to reap the benefit of learning from that junior. If there is no progress and no trust in ability acquired they are just a burden.
dawnerd 1y ago
On your last point I’ve found it about a wash in terms of time savings for me. For boiler plate / throw away code it’s decent enough - especially if I don’t care about code quality and only want a result. It’s wasted so much time trying to make it write actual production quality code. The consistency and over-verbose nature kill it for me.
chamomeal 1y ago
Yeah every time I see one of these articles posted on HN I know I'll see a bunch of comments like "well here's how I use claude code: I keep it on a tight leash and have short feedback loops, so that I'm still the driver, and have markdown files that explain the style I'm going for...". Which is fine lol but I'm tired of seeing the exact same conversations. It's exhausting to hear about AI all the time but it's fun to watch history happen. In a decade we'll look back at all these convos and remember how wild of a time it was to be a programmer.
- red-iron-pine 1y ago
  > Which is fine lol but I'm tired of seeing the exact same conversations. makes me think the bots are providing these conversations
  - ezekg 1y ago
    We're definitely moving full force into a dead internet [0], I think. [0]: https://en.m.wikipedia.org/wiki/Dead_Internet_theory https://en.m.wikipedia.org/wiki/Dead_Internet_theory
    - spaceman_2020 1y ago
      LinkedIn and Twitter are the canaries. Text based content is already so easy to produce at scale that there’s no utility in creating it manually
- coldpie 1y ago
  I'm thiiiis close to writing a Firefox extension that auto-hides any HN headline with an LLM/AI-related keyword in the title, just so I can find something interesting on here again.
  - icdtea 1y ago
    You can do this with a custom filter list in Ublock Origin, no custom extension necessary.
sunir 1y ago
All true if you one shot the code. If you have a sophisticated agent system that uses multiple forward and backward passes, the quality improves tremendously. Based on my set up as of today, I’d imagine by sometime next year that will be normal and then the conversation will be very different; mostly around cost control. I wouldn’t be surprised if there is a break out popular agent control flow language by next year as well. The net is that unsupervised AI engineering isn’t really cheaper better or faster than human engineering right now. Does that mean in two years it will be? Possibly. There will be a lot of optimizations in the message traffic, token uses, foundational models, and also just the Moore’s law of the hardware and energy costs. But really it’s the sophistication of the agent systems that control quality more than anything. Simply following waterfall (I know, right? Yuck… but it worked) increased code quality tremoundously. I also gave it the SelfDocumentingCode pattern language that I wrote (on WikiWikiWeb) as a code review agent and quality improved tremendously again.
- theshrike79 1y ago
  > Based on my set up as of today, I’d imagine by sometime next year that will be normal and then the conversation will be very different; mostly around cost control. I wouldn’t be surprised if there is a break out popular agent control flow language by next year as well. Currently it's just VC funded. The $20 packages they're selling are in no way cost-effective (for them). That's why I'm driving all available models like I stole them, building every tool I can think of before they start charging actual money again. By then local models will most likely be at a "good enough" level especially when combined with MCPs and tool use so I don't need to pay per token for APIs except for special cases.
  - tempoponet 1y ago
    Once local models are good enough there will be a $20 cloud provider that can give you more context, parameters, and t/s than you could dream of at home. This is true today with services like groq.
    - hatefulmoron 1y ago
dboreham 1y ago
My experience with the latest Claude Code has been: it's not nearly as bad as you say.
specialist 1y ago
> ...until everyone gets tired of talking about [LLMs] Small price to pay for shuffling Agile Manifesto off the stage.
theshrike79 1y ago
> - The code that is written by LLMs always needs to be heavily monitored for correctness, style, and design, and then typically edited down, often to at least half its original size For this language matters a lot, if whatever you're using has robust tools for linting and style checks, it makes the LLMs job a lot easier. Give it a rule (or a forced hook) to always run tests and linters before claiming a job is done and it'll iterate until what it produces matches the rules. But LLM code has a habit of being very verbose and covers every situation no matter how minuscule. This is especially grating when you're doing a simple project for local use and it's bootstrapping something that's enterprise-ready :D
- WorldMaker 1y ago
  If you force the LLM to solve every test failure this also can lead to the same breakdown models as very junior developers coding to the tests rather than the problems, I've seen all of: 1) I broke the tests, guess I should delete them. 2) I broke the tests, guess the code I wrote was wrong, guess I should delete all of that code I wrote. 3) I broke the tests, guess I should keep adding more code and scaffolding. Another abstraction layer might work? What if I just add skeleton code randomly, does this add random code whack-a-mole work? That last one can be particularly "fun" because already verbose LLM code skyrockets into baroque million line PRs when left truly unsupervised, and that PR still won't build or pass tests. There's no true understanding by an LLM. Forcing it to lint/build can be important/useful, but still not a cure-all, and leads to such fun even more degenerate cases than hand-holding it.
lordgrenville 1y ago
Yes! Reminds me of one of my all-time favourite HN comments https://news.ycombinator.com/item?id=23003595 https://news.ycombinator.com/item?id=23003595
automatic6131 1y ago
>- LLMs utility is high enough that it is now going to be a standard tool in the toolbox of every software engineer, but it is definitely not replacing anyone at current capability. Right! Problem, billions of dollars have been poured into this wrt to infrastructure, datacenters, compute and salaries. LLMs need to be at the level of replacing vast swathes of us to be worth it. LLMs are not going to be doing that. This is a collosal malinvestment.
- utyop22 1y ago
  Yeah eventually reality and fantasy have to converge. Nobody knows when. But it will. TBH the biggest danger is that all the hopes and dreams aren't materialised and the appetite for high-risk investments dissipates. We've had this period in which you can be money losing and its OK. But I believe we have passed the peak on that - and this is destined to blow up.
godelski 1y ago
FWIW, I think this summary is pretty in line with most "anti-LLM" crowd. Being in that "side" myself it is not that I don't use LLMs it is that I do not think LLMs are close to being able to replace me. I also think there's some big variance in each of the "sides" (I think it is more a bimodal spectrum really) with a lot to you last point. Sometimes they save you lots of time, sometimes they waste a lot of time. I expect more senior people are going to get less benefits from them because they've already spent lots of time developing time saving strategies. Plus, writing lines is only a small part of the job. The planning and debugging stages are much more time intensive and can be much more difficult to wrangle an LLM with. Honestly I think it is a lot about trust. Forgetting "speed", do I trust myself to be more likely to catch errors in code that I write or code that I review? Personally, I find that most of the time I end up arguing with the LLM over some critical detail and I've found Claude code will sometimes revert things that I asked it to change (these can be time consuming errors because they are often invisible). It gives the appearance of being productive (even feeling that way) but I think it is a lot more like if you spent time in a meeting vs time coding. Meetings can help and are very time consuming, but can also be a big waste of time when over used. Sometimes it is better to have two engineers go try out their methods independently and see what works out within the larger scope. Something is always learned too.

deleted 1y ago

[deleted]

MontyCarloHall 1y ago

It's almost as if you could recapitulate each of these discussions using an LLM!

rafaelmn 1y ago

> but this was true when they wrote their own code with stack overflow. Searching for solutions and integrating examples found requires effort that develops into a skill. You would rarely get solutions that would just fit into the codebase from SO. If I give a task to you and you produce a correct solution on the initial review I now know I can trust you to deal with this kind of problem in the future. Especially after a few reviews. If you just vibed through the problem the LLM might have given you the correct solution - but there is no guarantee that it will do it again in the future. Just because you spent less effort on search/official docs/integration into the codebase you learned less about everything surrounding it. So using LLMs as a junior you are just breaking my trust, and we both know you are not a competent reviewer of LLM code - why am I even dealing with you when I'll get LLM outputs faster myself ? This was my experience so far.

fhd2 1y ago
Like with any kind of learning, without a feedback loop (as tight as possible IMHO), it's not gonna happen. And there is always some kind of feedback loop. Ultra short cycle: Pairing with a senior, solid manual and automated testing during development. Reasonably short cycle: Code review by a senior within hours and for small subsets of the work ideally, QA testing by a seperate person within hours. Borderline too long cycle: Code review of larger chunks of code by a senior with days of delay, QA testing by a seperate person days or weeks after implementation. Terminally long feedback cycle: Critical bug in production, data loss, negative career consequences. I'm confident that juniors will still learn, eventually. Seniors can help them learn a whole lot faster though, if both sides want that, and if the organisation lets them. And yeah, that's even more the case than in the pre LLM world.
- DenisM 1y ago
  LLM can also help learning f you ask it what can be done better. Seniors can make prepromt so that company customs are taken into account.
OvbiousError 1y ago
> So using LLMs as a junior you are just breaking my trust, and we both know you are not a competent reviewer of LLM code - why am I even dealing with you when I'll get LLM outputs faster myself ? This was my experience so far. So much this. I see a 1000 lines super complicated PR that was whipped up in less than a day and I know they didn't read all of it, let alone understand.
- theshrike79 1y ago
  This is exactly what code reviews are for, doing reviews with juniors is always time-consuming
  - rafaelmn 1y ago
    Yes but your supposed to reap the benefit of learning from that junior. If there is no progress and no trust in ability acquired they are just a burden.

dawnerd 1y ago

On your last point I’ve found it about a wash in terms of time savings for me. For boiler plate / throw away code it’s decent enough - especially if I don’t care about code quality and only want a result. It’s wasted so much time trying to make it write actual production quality code. The consistency and over-verbose nature kill it for me.

chamomeal 1y ago

Yeah every time I see one of these articles posted on HN I know I'll see a bunch of comments like "well here's how I use claude code: I keep it on a tight leash and have short feedback loops, so that I'm still the driver, and have markdown files that explain the style I'm going for...". Which is fine lol but I'm tired of seeing the exact same conversations. It's exhausting to hear about AI all the time but it's fun to watch history happen. In a decade we'll look back at all these convos and remember how wild of a time it was to be a programmer.

red-iron-pine 1y ago
> Which is fine lol but I'm tired of seeing the exact same conversations. makes me think the bots are providing these conversations
- ezekg 1y ago
  We're definitely moving full force into a dead internet [0], I think. [0]: https://en.m.wikipedia.org/wiki/Dead_Internet_theory https://en.m.wikipedia.org/wiki/Dead_Internet_theory
  - spaceman_2020 1y ago
    LinkedIn and Twitter are the canaries. Text based content is already so easy to produce at scale that there’s no utility in creating it manually
coldpie 1y ago
I'm thiiiis close to writing a Firefox extension that auto-hides any HN headline with an LLM/AI-related keyword in the title, just so I can find something interesting on here again.
- icdtea 1y ago
  You can do this with a custom filter list in Ublock Origin, no custom extension necessary.

sunir 1y ago

All true if you one shot the code. If you have a sophisticated agent system that uses multiple forward and backward passes, the quality improves tremendously. Based on my set up as of today, I’d imagine by sometime next year that will be normal and then the conversation will be very different; mostly around cost control. I wouldn’t be surprised if there is a break out popular agent control flow language by next year as well. The net is that unsupervised AI engineering isn’t really cheaper better or faster than human engineering right now. Does that mean in two years it will be? Possibly. There will be a lot of optimizations in the message traffic, token uses, foundational models, and also just the Moore’s law of the hardware and energy costs. But really it’s the sophistication of the agent systems that control quality more than anything. Simply following waterfall (I know, right? Yuck… but it worked) increased code quality tremoundously. I also gave it the SelfDocumentingCode pattern language that I wrote (on WikiWikiWeb) as a code review agent and quality improved tremendously again.

theshrike79 1y ago
> Based on my set up as of today, I’d imagine by sometime next year that will be normal and then the conversation will be very different; mostly around cost control. I wouldn’t be surprised if there is a break out popular agent control flow language by next year as well. Currently it's just VC funded. The $20 packages they're selling are in no way cost-effective (for them). That's why I'm driving all available models like I stole them, building every tool I can think of before they start charging actual money again. By then local models will most likely be at a "good enough" level especially when combined with MCPs and tool use so I don't need to pay per token for APIs except for special cases.
- tempoponet 1y ago
  Once local models are good enough there will be a $20 cloud provider that can give you more context, parameters, and t/s than you could dream of at home. This is true today with services like groq.
  - hatefulmoron 1y ago

dboreham 1y ago

My experience with the latest Claude Code has been: it's not nearly as bad as you say.

specialist 1y ago

> ...until everyone gets tired of talking about [LLMs] Small price to pay for shuffling Agile Manifesto off the stage.

theshrike79 1y ago

> - The code that is written by LLMs always needs to be heavily monitored for correctness, style, and design, and then typically edited down, often to at least half its original size For this language matters a lot, if whatever you're using has robust tools for linting and style checks, it makes the LLMs job a lot easier. Give it a rule (or a forced hook) to always run tests and linters before claiming a job is done and it'll iterate until what it produces matches the rules. But LLM code has a habit of being very verbose and covers every situation no matter how minuscule. This is especially grating when you're doing a simple project for local use and it's bootstrapping something that's enterprise-ready :D

WorldMaker 1y ago
If you force the LLM to solve every test failure this also can lead to the same breakdown models as very junior developers coding to the tests rather than the problems, I've seen all of: 1) I broke the tests, guess I should delete them. 2) I broke the tests, guess the code I wrote was wrong, guess I should delete all of that code I wrote. 3) I broke the tests, guess I should keep adding more code and scaffolding. Another abstraction layer might work? What if I just add skeleton code randomly, does this add random code whack-a-mole work? That last one can be particularly "fun" because already verbose LLM code skyrockets into baroque million line PRs when left truly unsupervised, and that PR still won't build or pass tests. There's no true understanding by an LLM. Forcing it to lint/build can be important/useful, but still not a cure-all, and leads to such fun even more degenerate cases than hand-holding it.

lordgrenville 1y ago

Yes! Reminds me of one of my all-time favourite HN comments https://news.ycombinator.com/item?id=23003595 https://news.ycombinator.com/item?id=23003595

automatic6131 1y ago

>- LLMs utility is high enough that it is now going to be a standard tool in the toolbox of every software engineer, but it is definitely not replacing anyone at current capability. Right! Problem, billions of dollars have been poured into this wrt to infrastructure, datacenters, compute and salaries. LLMs need to be at the level of replacing vast swathes of us to be worth it. LLMs are not going to be doing that. This is a collosal malinvestment.

utyop22 1y ago
Yeah eventually reality and fantasy have to converge. Nobody knows when. But it will. TBH the biggest danger is that all the hopes and dreams aren't materialised and the appetite for high-risk investments dissipates. We've had this period in which you can be money losing and its OK. But I believe we have passed the peak on that - and this is destined to blow up.

godelski 1y ago

FWIW, I think this summary is pretty in line with most "anti-LLM" crowd. Being in that "side" myself it is not that I don't use LLMs it is that I do not think LLMs are close to being able to replace me. I also think there's some big variance in each of the "sides" (I think it is more a bimodal spectrum really) with a lot to you last point. Sometimes they save you lots of time, sometimes they waste a lot of time. I expect more senior people are going to get less benefits from them because they've already spent lots of time developing time saving strategies. Plus, writing lines is only a small part of the job. The planning and debugging stages are much more time intensive and can be much more difficult to wrangle an LLM with. Honestly I think it is a lot about trust. Forgetting "speed", do I trust myself to be more likely to catch errors in code that I write or code that I review? Personally, I find that most of the time I end up arguing with the LLM over some critical detail and I've found Claude code will sometimes revert things that I asked it to change (these can be time consuming errors because they are often invisible). It gives the appearance of being productive (even feeling that way) but I think it is a lot more like if you spent time in a meeting vs time coding. Meetings can help and are very time consuming, but can also be a big waste of time when over used. Sometimes it is better to have two engineers go try out their methods independently and see what works out within the larger scope. Something is always learned too.