[ricksunny]

I wonder if vibe coding dev-ops will follow the path blazed by virtual machine managers vs bare metal servers. If the bare metal server crashes, you had to go out and, like a rancher’s calf, nurse it back to health. If the VM crashes, you take it out into the pasture and shoot it (and re-spin up another VM).

In the vibe coded world, if a bug is found (or a relied-upon api is deprecated, or a a dependency is found to suffer a security vulnerability, a vendor changes. etc) do we simply kill the codebase and vibecode up a fresh one de novo from the same prompts as the original, adding only knowledge of the recent failure mode?

[georgemcbay]

> In the vibe coded world, if a bug is found [...] do we simply kill the codebase and vibecode up a fresh one de novo from the same prompts as the original, adding only knowledge of the recebt failure mode?

That sounds like a horrible plan, LLMs are non-deterministic (practically speaking, I know they can be run with temperature=0 locally, but not really relevant to the way anyone is writing code with them now).

Feeding the same spec in with some changes to deal with the one bug you discovered and regenerating all the code is likely to create a system that has new bugs (unrelated to the one you fixed by amending the spec) that may not have existed the last go-around.

You'll be playing whack-a-mole forever.

[slopinthebag]

Are you wondering if in the future AI will take a spec in natural language and convert it into thousands or millions of lines of code every time a bug is surfaced?

[ricksunny]

The only thing I wonder is what practices deployment engineers will lobby management for under well-aligned incentive structures