One interesting possible future of the emergence of “vibe coding” as common terminology is the possibility to position an alternative. “Real coding”? Future think pieces:
‘You can get yourself up and running quickly with “vibe coding” but when you get traction you’re going to want have people doing “real coding”’
‘switching from vibe coding to real coding will typically cost you X% of you initial development, so don’t put off switching too late’
You simply fix vibe coding by kicking out 100% of the code and then let a professional take over.
Yeah, even before LLMs, we’d frequently get requests like “we’ve written this Python script, which already does what we want, we just need someone to professionalize it”.
And it’s just grounded in this massive misconception that getting the core logic down is the hard part. We’d frequently spend 6-24 months to actually get it to where they want to be, namely interfacing with regular users and various existing systems.
It was always well worth it to start over with a more appropriate technology stack, and to understand what design decisions actually went into this initial draft.When people have the core logic done, at least you have a reasonable benchmark to which to measure up to.
For example, I designed an audio compression algorithm years ago, and I made the design in C, because it was easy to build and verify. I then used this to do the real implementation in VHDL. A complete change of framework, but the first implementation was totally necessary.
I mean, yeah, it can serve as a proof-of-concept, but usually when folks come to you like that, they have a concrete real-world problem they want solved. So, it’s not just an algorithm, but rather needs to be a whole application, which interacts with the real world. And then the core logic is typically less than 10% of the code. Error handling, monitoring, configurability, persistence, usability, interactions with other systems, authorization, deployment code etc., that’s all stuff which isn’t solved by the PoC. All the hard parts are still unsolved.
But even in your example, the benefit of the PoC was that you learned how to implement it and in particular also the many ways which don’t work for implementing it. If someone else or an LLM had written that algorithm in C, you would have had a much harder time writing it in VHDL, because you wouldn’t know what to look out for when debugging and why things are implemented the way they are. Some design decisions might be easy to implement in C, but hard in VHDL, and if you don’t know the why, you can’t decide to do it differently, or might have to explore doing it anyways and then find out why it’s a bad idea.
Roguelike coding, where you take randomly generated pieces of code, mash them together and see what happens. But also you gotta fight your boss at the end.

