[Jeff_Brown]

Agreed. Some strategies that seem to help exist, though. Write extensive tests before writing the code. They serve as guidance. Commit tests separately from library code, so you can tell the AI didn't change the test. Specify the task with copious examples. Explain why yo so things, not just what to do.

[habinero]

Yeah, this is where I start side-eying people who love vibe coding. Writing lots of tests and documentation and fixing someone else's (read: the LLM's) bad code? That's literally the worst parts of the job.

[ewoodrich]

I also get confused when I see it taken for granted that "vibe coding" removes all the drudgery/chores from programming. When my own experience heavily using Claude Code/etc every day routinely involves a lot of unpleasant clean up of accumulated LLM slop and "WTF" decisions.

I still think it saves me time on net and yes, it typically can handle a lot on its own, but whenever it starts to fuck up the same request repeatedly in different ways, all I can really do is sigh/roll my eyes and then it's on me alone to dig in and figure it out/fix it to keep making progress.

And usually that consists of incredibly ungratifying, unpleasant work I'm very much not happy to be doing.

I definitely have been able to do more side projects for ideas that pop into my head thanks to CC and similar, and that part is super cool! But other times I hit a wall where a project suddenly goes from breezy and fun to me spending hours reading through diffs/chat history trying to untangle a pile of garbage code I barely understand 10% of and have to remind myself I was supposed to be doing this for "fun"/learning, and accomplishing neither while not getting paid for it.

[Jeff_Brown]

Absolutely. Honestly some days I'm not sure the AI saves me any time at all.

But on the other hand, writing thorough tests before coding the library is good practice with or without an assistant.

[zephyrthenoble]

Interesting, I haven't tried tests outside of the code base the LLM is working on.

I could see other elements of isolation being useful, but this kind of feels like a lot of extra work and complexity which is part of the issue...

[Askiir]

The way I do it is write tests, then commit just the tests. Then when you have any agent running and generating code, before committing/reviewing you can check the diff for any changes to files containing tests. The commit panel in Jetbrains for example will enumerate any changed files, and I can easily take a peek there and see if any testing files were changed in the process. It's not necessarily about having a separate codebase.

[danielbln]

Also: detailed planning phase, cross-LLM reviews via subagents, tests, functional QA etc. There at more (and complimentary) ways to ensure the code does what it should then to comb through ever line.