4 ms·

I get vibe-coders not having a good experience once the honeymoon is over. But I'm fascinated that a professional software developer could have such a different

by CharlesW 10mo ago

I get vibe-coders not having a good experience once the honeymoon is over. But I'm fascinated that a professional software developer could have such a different experience than I do. • LLMs generate junk • LLMs generate a lot of junk

alfalfasprout 10mo ago
Yeah... don't get me wrong I find a lot of value in these tools. They do help with a lot of the tedium, can be helpful as debugging assistants, and in the right hands (with the right oversight) can indeed generate solid code. But we are, even as of Opus 4.5, so wildly far away from what the author is suggesting. FWIW my experience is working in the AI/ML space at a major tech company and as a maintainer + contributor of several OSS projects. People are blindly trusting LLMs and generating mountains of slop. And the slop compounds.
- emseetech 10mo ago
  I use AI as a rubber duck to research my options, sanity-check my code before a PR, and give me a heads up on potential pain points going forward. But I still write my own code. If I'm going to be responsible for it, I'm going to be the one who writes it. It's my belief that velocity up front always comes at a cost down the line. That's been true for abstractions, for frameworks, for all kinds of time-saving tools. Sometimes that cost is felt quickly, as we've seen with vibe coding. So I'm more interested in using AI in the research phase and to increase the breadth of what I can work on than to save time. Over the course of a project, all approaches, even total hand-coding with no LLMs whatever, likely regress to the mean when it comes to hours worked. So I'd rather go with an approach that keeps me fully in control.
  - llmslave3 10mo ago
    Yeah my guess is that it takes roughly the same amount of time regardless if it's AI agents or hand coding, the time just gets spent in different ways (writing vs reading for example).
emseetech 10mo ago
My question is why use AI to output javascript or python? Why not output everything in C and ASM for 500x performance? Why use high level languages meant to be easier for humans? Why not go right to the metal? If anyone's ever tried this, it's clear why: AI is terrible at C and ASM. But that cuts into what AI is at its core: It's not actual programming, it's mechanical reproduction. Which means its incapabilities in C and ASM don't disappear when using it for higher-level languages. They're still there, just temporarily smoothed over due to larger datasets.
- bflesch 10mo ago
  That's a very good example.
- headcanon 10mo ago
  One thing I have been doing is breaking out of my long-held default mode of spinning up a react/nextjs project whenever I need frontend, and generating barebones HTML/CSS/JS for basic web apps. A lot of the reason we went with the former was the easy access to packages and easy-to-understand state management, but now that a lot of the functionality packages used to provide can be just as easily generated, I can get a lot more functionality while keeping dependencies minimal. I haven't tried C or ASM yet, but it has been working very well with a C++ project I've been working on, and I'm sure it would do reasonably well with bare-bones C as well. I'd be willing to bet it would struggle more with a lower-level language initially, but give it a solid set of guardrails with a testing/eval infrastructure and it'll get its way to what you want.
  - fud101 10mo ago
    Pretty interesting take this. I wonder if there is a minimal state management we could evolve which would be sufficient for LLMs to use while still making it possible for a human to reason about the abstraction. It won't be as bloated as the existing ones we came up with organically however.
  - moron4hire 10mo ago
    I mean, you're basically LLM-washing other people's code, then. All those UI components that other people wrote and at least expected attribution may not be libraries anymore, sure. But you've basically just copied and maybe lightly modified that code into your project and then slapped a sticker on it saying "mine." If you did that manually with open source code, you'd be in violation of the attribution terms almost all the licenses have in common. But somehow it's okay if the computer does it for you?
deleted 10mo ago
[deleted]
glemion43 10mo ago
[dead]
lazide 10mo ago
For some people, code == junk?
- michaelbuckbee 10mo ago
  Depends on what it is, the quick bash script I write to verify something or the core of SaaS that's being launched have different levels of strictness, style, testing, etc.
  - lazide 10mo ago
    Apparently not as much anymore!
EMM_386 10mo ago
I've been a software engineer professionally for over two decades and I use AI heavily both for personal projects and at work. At work the projects are huge (200+ large projects in various languages, C#, TypeScript front-end libs, Python, Redis, AWS, Azure, SQL, all sorts of things). AI can go into huge codebases perfectly fine and get a root cause + fix in minutes - you just need to know how to use it properly. Personally I do "recon" before I send it off into the field by creating a markdown document explaining the issue, the files involved, and any "gotchas" it may encounter. It's exactly the same as I would do with another senior software engineer. They need that information to figure out what is going on. And with that? They will hand you back a markdown document with a Root Cause Analysis, identify potential fixes, and explain why. It works amazingly well if you work with it as a peer.

alfalfasprout 10mo ago

Yeah... don't get me wrong I find a lot of value in these tools. They do help with a lot of the tedium, can be helpful as debugging assistants, and in the right hands (with the right oversight) can indeed generate solid code. But we are, even as of Opus 4.5, so wildly far away from what the author is suggesting. FWIW my experience is working in the AI/ML space at a major tech company and as a maintainer + contributor of several OSS projects. People are blindly trusting LLMs and generating mountains of slop. And the slop compounds.

emseetech 10mo ago
I use AI as a rubber duck to research my options, sanity-check my code before a PR, and give me a heads up on potential pain points going forward. But I still write my own code. If I'm going to be responsible for it, I'm going to be the one who writes it. It's my belief that velocity up front always comes at a cost down the line. That's been true for abstractions, for frameworks, for all kinds of time-saving tools. Sometimes that cost is felt quickly, as we've seen with vibe coding. So I'm more interested in using AI in the research phase and to increase the breadth of what I can work on than to save time. Over the course of a project, all approaches, even total hand-coding with no LLMs whatever, likely regress to the mean when it comes to hours worked. So I'd rather go with an approach that keeps me fully in control.
- llmslave3 10mo ago
  Yeah my guess is that it takes roughly the same amount of time regardless if it's AI agents or hand coding, the time just gets spent in different ways (writing vs reading for example).

emseetech 10mo ago

My question is why use AI to output javascript or python? Why not output everything in C and ASM for 500x performance? Why use high level languages meant to be easier for humans? Why not go right to the metal? If anyone's ever tried this, it's clear why: AI is terrible at C and ASM. But that cuts into what AI is at its core: It's not actual programming, it's mechanical reproduction. Which means its incapabilities in C and ASM don't disappear when using it for higher-level languages. They're still there, just temporarily smoothed over due to larger datasets.

bflesch 10mo ago
That's a very good example.
headcanon 10mo ago
One thing I have been doing is breaking out of my long-held default mode of spinning up a react/nextjs project whenever I need frontend, and generating barebones HTML/CSS/JS for basic web apps. A lot of the reason we went with the former was the easy access to packages and easy-to-understand state management, but now that a lot of the functionality packages used to provide can be just as easily generated, I can get a lot more functionality while keeping dependencies minimal. I haven't tried C or ASM yet, but it has been working very well with a C++ project I've been working on, and I'm sure it would do reasonably well with bare-bones C as well. I'd be willing to bet it would struggle more with a lower-level language initially, but give it a solid set of guardrails with a testing/eval infrastructure and it'll get its way to what you want.
- fud101 10mo ago
  Pretty interesting take this. I wonder if there is a minimal state management we could evolve which would be sufficient for LLMs to use while still making it possible for a human to reason about the abstraction. It won't be as bloated as the existing ones we came up with organically however.
- moron4hire 10mo ago
  I mean, you're basically LLM-washing other people's code, then. All those UI components that other people wrote and at least expected attribution may not be libraries anymore, sure. But you've basically just copied and maybe lightly modified that code into your project and then slapped a sticker on it saying "mine." If you did that manually with open source code, you'd be in violation of the attribution terms almost all the licenses have in common. But somehow it's okay if the computer does it for you?

deleted 10mo ago

[deleted]

glemion43 10mo ago

[dead]

lazide 10mo ago

For some people, code == junk?

michaelbuckbee 10mo ago
Depends on what it is, the quick bash script I write to verify something or the core of SaaS that's being launched have different levels of strictness, style, testing, etc.
- lazide 10mo ago
  Apparently not as much anymore!

EMM_386 10mo ago

I've been a software engineer professionally for over two decades and I use AI heavily both for personal projects and at work. At work the projects are huge (200+ large projects in various languages, C#, TypeScript front-end libs, Python, Redis, AWS, Azure, SQL, all sorts of things). AI can go into huge codebases perfectly fine and get a root cause + fix in minutes - you just need to know how to use it properly. Personally I do "recon" before I send it off into the field by creating a markdown document explaining the issue, the files involved, and any "gotchas" it may encounter. It's exactly the same as I would do with another senior software engineer. They need that information to figure out what is going on. And with that? They will hand you back a markdown document with a Root Cause Analysis, identify potential fixes, and explain why. It works amazingly well if you work with it as a peer.