I was handed a pile of vibe code. And you might be surprised to learn that it has a ton of bugs.

And tips on how to dissect it and break it up into something manageable?

  • ultimate_worrier@lemmy.dbzer0.com
    link
    fedilink
    arrow-up
    0
    ·
    10 days ago

    I did this recently. Here’s how I made it sane:

    • clone it to a branch
    • concatenate every line of code and paste it into an LLM with a prompt asking for a summary of the issues with the code
    • make a TODO list so you can work from that (a .md file of the LLM’s output)
    • use that list to aggressively delete the dead code while compiling it with each change
    • committing each change that keeps it working while also paring it down.
    • keep starting a new LLM session with each change and the same “make a detailed analysis of the issues with this code” prompt with it along with the newly concatenated code (this helps a lot to keep hallucinations down)
    • at some point, more cosmetic deletions/changes won’t be necessary and you can start carefull refactoring the code that is actually connected to something while also compiling then committing at every working change.
    • then you can start using the LLM as an assistant but actually USING YOUR BRAIN to decide how to fix the architecture and flow of the code. Of course you can ask for advice but ALWAYS keep in mind that the LLM will give you stupid advice and tell you you’re a genius and blow smoke up your ass if you’re too shy to ask a real person (like I am).
    • If it’s a language like Haskell or Rust or Purescript, you’re in for an easy time. If it’s something ubiquitous but dynamic and unsafe like JavaScript or Python, GOOD LUCK!!!

    I think the biggest problem with vibe-coding is when someone doesn’t take the time to understand the WHY of the changes the code is making. This is why I can’t abide agentic access to my code. Every change must go through me. I won’t even let the AI give me files , preferring to get everything in front of me.

    • reabsorbthelight@lemmy.worldOP
      link
      fedilink
      arrow-up
      0
      ·
      10 days ago

      Yeah. I want to do something like this. I was hoping to run a proper dead code analysis first.

      But this is a good idea. For how to reduce the code volume. I need to reduce the abstraction layers because there are a bunch of unneeded ones

      • ultimate_worrier@lemmy.dbzer0.com
        link
        fedilink
        arrow-up
        0
        ·
        10 days ago

        LLM’s really helped me with this. I am now working with only code that is wired up and can ask for insight into my ideas while being highly skeptical and lucid about any advice.

        I’ve found prompts that make sure to use words like “idiomatic” can prevent LLM’s from going off the reservation to some extent. It’ll try and reinvent the wheel or pull in hallucinated libraries if you’re not careful but it’ll probably also be aware of the idiomatic way to do things in each language.

        Have fun and take a walk if you’re getting burnt out.

        I’ll sometimes send my concatenated code in, ask for advice, then paste that advice into my phone to have it read aloud to me as I walk around. It can go into insane detail. So as long as you stay skeptical of it, it can be a really good tool for what you’re trying to do.

    • grueling_spool@sh.itjust.works
      link
      fedilink
      arrow-up
      0
      ·
      10 days ago

      I guess despite how intimidating it seems, un-fucking vibe code can be approached just like every other complex programming problem: by breaking it down into smaller problems and solving them incrementally.

      • ultimate_worrier@lemmy.dbzer0.com
        link
        fedilink
        arrow-up
        0
        ·
        10 days ago

        Definitely. Also once it starts to take actual logical shape, showing it to real people is also great if you have that luxury (which I don’t). :)