3 ms·

Yeah, that happens when you vibe code and just let the LLM be in control of everything. If you take responsibility for the architecture and instruct it to do th

by sfn42 2mo ago

Yeah, that happens when you vibe code and just let the LLM be in control of everything. If you take responsibility for the architecture and instruct it to do things properly it will do them properly. You can tell it exactly how to do it or you can ask it to handle it in a way that avoids duplication, you can tell it to design a reusable abstraction for this usecase etc.

qsera 2mo ago
>If you take responsibility for the architecture and instruct it to do things properly it will do them properly. The problem here is that after a while it is impossible to detect when such potential abstractions is overlooked in the generated code. Because it has become hard to reason about the existing code. Not all work is green field.
- voakbasda 2mo ago
  I have wondered about this. Can’t you ask the AI to find the patterns than need abstracting?
  - fortzi 2mo ago
    Yes you can. Sometimes it’ll find them, sometimes it won’t. I find myself having to use Claude to untangle its own mess piece by piece, a as it charged full steam ahead with the design we made together. However, not everything can be foreseen in a design, unless you go full waterfall. Sometimes I find myself in front of a mountain of bad abstractions stemming from a subtle oversight in the design. Before AI coding, I would find details while coding and catch them in time before they became sinful abominations
  - sfn42 2mo ago
    You can do that, with varying results. Or you can just do actual software engineering like we used to do, and tell it what patterns to abstract and how. You choose your level of effort and involvement. The LLM can write whatever you tell it to write. If you send a drawing of an app and say "make this" then you'll get whatever it comes up with. If you tell it how to make it then it will make it the way you tell it to. If your AI code is trash that's because you're trash at directing it.
- Izkata 2mo ago
  My personal suspicion is that a lot of preexisting codebases are running on inertia. The abstractions exist and are used well so the generated code also uses it most of the time, with only occasional breaks to the abstraction that look like an acceptable tradeoff in isolation. But those would keep piling up to where the existing abstraction is no longer so identifiable and that's where the major spaghetti code issues start happening.

by sfn42 2mo ago

qsera 2mo ago

>If you take responsibility for the architecture and instruct it to do things properly it will do them properly. The problem here is that after a while it is impossible to detect when such potential abstractions is overlooked in the generated code. Because it has become hard to reason about the existing code. Not all work is green field.

voakbasda 2mo ago
I have wondered about this. Can’t you ask the AI to find the patterns than need abstracting?
- fortzi 2mo ago
  Yes you can. Sometimes it’ll find them, sometimes it won’t. I find myself having to use Claude to untangle its own mess piece by piece, a as it charged full steam ahead with the design we made together. However, not everything can be foreseen in a design, unless you go full waterfall. Sometimes I find myself in front of a mountain of bad abstractions stemming from a subtle oversight in the design. Before AI coding, I would find details while coding and catch them in time before they became sinful abominations
- sfn42 2mo ago
  You can do that, with varying results. Or you can just do actual software engineering like we used to do, and tell it what patterns to abstract and how. You choose your level of effort and involvement. The LLM can write whatever you tell it to write. If you send a drawing of an app and say "make this" then you'll get whatever it comes up with. If you tell it how to make it then it will make it the way you tell it to. If your AI code is trash that's because you're trash at directing it.
Izkata 2mo ago
My personal suspicion is that a lot of preexisting codebases are running on inertia. The abstractions exist and are used well so the generated code also uses it most of the time, with only occasional breaks to the abstraction that look like an acceptable tradeoff in isolation. But those would keep piling up to where the existing abstraction is no longer so identifiable and that's where the major spaghetti code issues start happening.