3 ms·

It's alright until you have a bug the LLM can't solve, then you have to go in the code yourself and you realize what a mess it has made.

by phito 1y ago

dimitri-vs 1y ago
I haven't found such a bug yet. If it fails to debug on its second attempt I usually switch to a different model or tell it to carpet bomb the code with console logs, write test scripts and do a web search, etc. The strength (and weakness) of these models is their patience is infinite.
- phito 1y ago
  Well I don't have the patience of waiting for it to find the right solution ahah
zmmmmm 1y ago
Perhaps you set a very high quality bar, but I don't see the LLMs creating messy code. If anything, they are far more diligent in structuring it well and making it logically sequenced and clear than I would be. For example, very often I name a variable slightly incorrectly at the start and realise it should be just slightly different at the end and only occasionally do I bother to go rename it everywhere. Even with automated refactoring tools to do it, it's just more work than I have time for. I might just add a comment above it somewhere explaining the meaning is slightly different to how it is named. This sort of thing x 100 though.
- itsalotoffun 1y ago
  > hey are far more diligent in structuring it well and making it logically sequenced and clear than I would be Yes, with the caveat: only on the first/zeroth shot. But even when they keep most/all of the code in context if you vibe code without incredibly strict structuring/guardrails, by the time you are 3-4 shots in, the model has "forgotten" the original arch, is duplicating data structures for what it needs _this_ shot and will gleefully end up with amnesiac-level repetitions, duplicate code that does "mostly the same" thing, all of which acts as further poison for progress. The deeper you go without human intervention the worse this gets. You can go the other way, and it really does work. Setup strict types, clear patterns, clear structures. And intervene to explain + direct. The type of things senior engineers push back on in junior PRs. "Why didn't you just extend this existing data structure and factor that call into the trivially obvious extension of XYZ??". "You're absolutely right!" etc.
- bluefirebrand 1y ago
  > Perhaps you set a very high quality bar Yes, of course. Do you not? Aren't you embarrassed to admit that you use AI because you don't care about quality? I would be ashamed to think "you set a high quality bar" is some kind of critique

It's alright until you have a bug the LLM can't solve, then you have to go in the code yourself and you realize what a mess it has made.

by phito 1y ago

It's alright until you have a bug the LLM can't solve, then you have to go in the code yourself and you realize what a mess it has made.

dimitri-vs 1y ago

I haven't found such a bug yet. If it fails to debug on its second attempt I usually switch to a different model or tell it to carpet bomb the code with console logs, write test scripts and do a web search, etc. The strength (and weakness) of these models is their patience is infinite.

phito 1y ago
Well I don't have the patience of waiting for it to find the right solution ahah

zmmmmm 1y ago

Perhaps you set a very high quality bar, but I don't see the LLMs creating messy code. If anything, they are far more diligent in structuring it well and making it logically sequenced and clear than I would be. For example, very often I name a variable slightly incorrectly at the start and realise it should be just slightly different at the end and only occasionally do I bother to go rename it everywhere. Even with automated refactoring tools to do it, it's just more work than I have time for. I might just add a comment above it somewhere explaining the meaning is slightly different to how it is named. This sort of thing x 100 though.

itsalotoffun 1y ago
> hey are far more diligent in structuring it well and making it logically sequenced and clear than I would be Yes, with the caveat: only on the first/zeroth shot. But even when they keep most/all of the code in context if you vibe code without incredibly strict structuring/guardrails, by the time you are 3-4 shots in, the model has "forgotten" the original arch, is duplicating data structures for what it needs _this_ shot and will gleefully end up with amnesiac-level repetitions, duplicate code that does "mostly the same" thing, all of which acts as further poison for progress. The deeper you go without human intervention the worse this gets. You can go the other way, and it really does work. Setup strict types, clear patterns, clear structures. And intervene to explain + direct. The type of things senior engineers push back on in junior PRs. "Why didn't you just extend this existing data structure and factor that call into the trivially obvious extension of XYZ??". "You're absolutely right!" etc.
bluefirebrand 1y ago
> Perhaps you set a very high quality bar Yes, of course. Do you not? Aren't you embarrassed to admit that you use AI because you don't care about quality? I would be ashamed to think "you set a high quality bar" is some kind of critique