4 ms·

I'm not going to read code created by an AI. The AI exists to prevent me from having to deal with the complexity of a task. The absolute most I want to read a

I'm not going to read code created by an AI. The AI exists to prevent me from having to deal with the complexity of a task. The absolute most I want to read and write are type signatures. I'll set those up, let the AI go, see if it works. If it doesn't, maybe retry with a better prompt. If it still doesn't work, then I'll have to get involved. Start implementing from the top down, and once there is enough architectural structure, the AI can usually finish up. This still happens quite a bit, and it's just like taking away a hard task from someone less experienced. The difference is there is no point in investing your time teaching or explaining anything to the AI. It can't learn in that way, and it's not a person.

nsxwolf 1y ago
Might as well have it code in assembler then. Get the performance boost.
- stirfish 1y ago
  Too many tokens, imo. I like to vibe code single self-contained pages in html, css, and JavaScript, because there's a very slim chance that something in the browser is going to break my computer.
Cheer2171 1y ago
Then enjoy your security holes, placeholder fake features, and miles of atrocious 'clever' hacks.
- bbqfog 1y ago
  [flagged]
  - chrisjj 1y ago
    > Sounds like every piece of human generated code I’ve ever seen. Good code is less visible.
  - exasperaited 1y ago
    The obvious advantage of making your own framework, or your own libraries, say, is that you can centralise all the security implementation. You either will or you won't do that security work, but you can't centralise it if you don't write some sort of library/framework to do it. And if you don't, you're more likely to leave the hole open in some situations. Vibe coding is "don't write any libraries, just copy-paste and use these existing libraries uncritically". The worst outcome of this will be NPM full of vibe-coded copy-paste code shoved into opaque modules that nobody has ever really read, that other vibe-coding tools will use uncritically.
    - bbqfog 1y ago
      This makes the assumption that vibe coded software is worse than human coded software. I think that’s already false on average and will quickly become “no contest”. We’ve already seen the best humans can do, ai is just getting started.
      - exasperaited 1y ago
        I am making no such assumption, nor does my argument need it. My concern is that the act of surrendering ownership itself is always worse.
jazzyjackson 1y ago
> just like taking away a hard task from someone less experienced except someone less experienced never gets to try, since all the experienced programmers are now busy shepherding AI agents around, they aren't available to mentor the next generation.
dwringer 1y ago
In my experience, it's still possible to learn from the AI's mistakes. I've seen others comment similarly: sometimes the AI will invent a feature, variable, exception type, etc., and while this is wrong for the specific implementation, it's often a pretty good idea for something that may have been overlooked with the initial spec. Reading the AI outputs can still be a valuable step in an interactive feedback process, even if you only ever start a new context from scratch with the AI each time. The user's context is what grows.
- crinkly 1y ago
  Assuming of course than you are both competent enough and attentive enough to identify the AI's mistakes. This is the problem I have seen a lot. From professionals to beginners, unless you actually carved the rock yourself, you don't really have an insight into every detail of what you see. This is incidentally why programmers tend to like to just rewrite stuff than fix it. We're lazy.
exasperaited 1y ago
> see if it works But this is, properly expressed, "see if it works, based on my incomplete understanding of the code that I haven't worked through and corrected by trying to write it, but I have nevertheless communicated directly to an AI that may not have correctly understood it and therefore may not have even the vaguest inkling of the edge cases I haven't thought to mention yet". Vibe-coded output could only properly be said to "work" if we were communicating our intentions in formal methods logic. What you mean is "apparently works".
- ath3nd 1y ago
  LLMs have successfully finally taken the last ounce of "engineering" from software engineering. Now what we have is "lgtm-ing", which is a great selling point for LLMs. You notice how LLMs do good on small tasks and on small projects? The more LLM code you add to your projects, the slower and worse (read: more tokens) they perform. If this was by design (create bigger, unmaintainable projects, so you can slowly squeeze out more and more tokens out of your users), I'd have applauded the LLM creators, but I think it's by accident. Still funny though.
chrisjj 1y ago
> I'll set those up, let the AI go, see if it works. Hmm. And maintenance?
- gorbachev 1y ago
  Pitch deck comes first. /s
jleask 1y ago
The problem is that hidden among that complexity/detail is often the value that software developers bring e.g. security issues, regulatory compliance, diagnosability/monitoring, privacy, scalability, resilience etc. There will be bugs that the AI cannot fix, especially in the short term, which will mean that code needs to be readable and understandable by a human. Without human review that will likely not be the case. I'm also intrigued by "see if it works". How is this being evaluated? Are you writing a test suite, manually testing? Don't get me wrong, this approach will likely work in lower risk software, but I think you'd be brave to go no human review in any non-trivial domain.

nsxwolf 1y ago

Might as well have it code in assembler then. Get the performance boost.

stirfish 1y ago
Too many tokens, imo. I like to vibe code single self-contained pages in html, css, and JavaScript, because there's a very slim chance that something in the browser is going to break my computer.

Cheer2171 1y ago

Then enjoy your security holes, placeholder fake features, and miles of atrocious 'clever' hacks.

bbqfog 1y ago
[flagged]
- chrisjj 1y ago
  > Sounds like every piece of human generated code I’ve ever seen. Good code is less visible.
- exasperaited 1y ago
  The obvious advantage of making your own framework, or your own libraries, say, is that you can centralise all the security implementation. You either will or you won't do that security work, but you can't centralise it if you don't write some sort of library/framework to do it. And if you don't, you're more likely to leave the hole open in some situations. Vibe coding is "don't write any libraries, just copy-paste and use these existing libraries uncritically". The worst outcome of this will be NPM full of vibe-coded copy-paste code shoved into opaque modules that nobody has ever really read, that other vibe-coding tools will use uncritically.
  - bbqfog 1y ago
    This makes the assumption that vibe coded software is worse than human coded software. I think that’s already false on average and will quickly become “no contest”. We’ve already seen the best humans can do, ai is just getting started.
    - exasperaited 1y ago
      I am making no such assumption, nor does my argument need it. My concern is that the act of surrendering ownership itself is always worse.

jazzyjackson 1y ago

> just like taking away a hard task from someone less experienced except someone less experienced never gets to try, since all the experienced programmers are now busy shepherding AI agents around, they aren't available to mentor the next generation.

dwringer 1y ago

In my experience, it's still possible to learn from the AI's mistakes. I've seen others comment similarly: sometimes the AI will invent a feature, variable, exception type, etc., and while this is wrong for the specific implementation, it's often a pretty good idea for something that may have been overlooked with the initial spec. Reading the AI outputs can still be a valuable step in an interactive feedback process, even if you only ever start a new context from scratch with the AI each time. The user's context is what grows.

crinkly 1y ago
Assuming of course than you are both competent enough and attentive enough to identify the AI's mistakes. This is the problem I have seen a lot. From professionals to beginners, unless you actually carved the rock yourself, you don't really have an insight into every detail of what you see. This is incidentally why programmers tend to like to just rewrite stuff than fix it. We're lazy.

exasperaited 1y ago

> see if it works But this is, properly expressed, "see if it works, based on my incomplete understanding of the code that I haven't worked through and corrected by trying to write it, but I have nevertheless communicated directly to an AI that may not have correctly understood it and therefore may not have even the vaguest inkling of the edge cases I haven't thought to mention yet". Vibe-coded output could only properly be said to "work" if we were communicating our intentions in formal methods logic. What you mean is "apparently works".

ath3nd 1y ago
LLMs have successfully finally taken the last ounce of "engineering" from software engineering. Now what we have is "lgtm-ing", which is a great selling point for LLMs. You notice how LLMs do good on small tasks and on small projects? The more LLM code you add to your projects, the slower and worse (read: more tokens) they perform. If this was by design (create bigger, unmaintainable projects, so you can slowly squeeze out more and more tokens out of your users), I'd have applauded the LLM creators, but I think it's by accident. Still funny though.

chrisjj 1y ago

> I'll set those up, let the AI go, see if it works. Hmm. And maintenance?

gorbachev 1y ago
Pitch deck comes first. /s

jleask 1y ago

The problem is that hidden among that complexity/detail is often the value that software developers bring e.g. security issues, regulatory compliance, diagnosability/monitoring, privacy, scalability, resilience etc. There will be bugs that the AI cannot fix, especially in the short term, which will mean that code needs to be readable and understandable by a human. Without human review that will likely not be the case. I'm also intrigued by "see if it works". How is this being evaluated? Are you writing a test suite, manually testing? Don't get me wrong, this approach will likely work in lower risk software, but I think you'd be brave to go no human review in any non-trivial domain.