Vibe Coding Your Way to Success at Any Cost
Just back those new servers up to the loading dock, boss!
Every now and again, the topic of "vibe coding" comes up either internally or with customers or partners.
Internally, it is usually checking in every few months to see if the time investment is worth it to use AI-generated code, then go in and clean everything up.
I could see how it would have been useful in the very beginning, but we haven't seen the ROI (Return on Investment) yet.
That may change in the future.
Or, we see a candidate or project-based contractor produce code that seems to go on a spiritual journey, collect a bunch of errors, but somehow eventually come up with the right answer. Sometimes. We usually realize, when we start asking questions, they weren't writing the code themselves, but were trusting their trusty AI tool in the ultimate imposter syndrome feat ever.
I saw this analogy online, and it is by far the best example of the difficulties in vibe coding.
In this case, the program did, indeed, eventually come up with the right answer for this specific use case.
Move the track at all? Different vehicle? Any other variable? Failure.
Efficient? Absolutely not.
In computery-things, this would mean programs that succeed sometimes, fail sometimes, and you can never quite tell how long they will take or how many resources they will need.
There is one cybersecurity tool in particular I'm thinking of right now, that the EDR defeat (aka, antivirus killer) folks have difficulty with.
NOT because their quality matches their marketing.
Instead, it is because the company started vibe coding, and you are never quite sure what the same program will do from one iteration to the next.
That lack of stability means sometimes the malware is caught, sometimes not.
It also means sometimes the antivirus-killer exploit works, and sometimes it crashes the system. Crazy stuff.
Life is going to be really profitable for software engineers that can debug logic errors, and test for them. Not as much for the ones that can't.
I can't say when, but I would humbly recommend using this "time of innocence" to ensure your debugging and testing skills are ready for the inevitable "the code looks great, and our AI code analysis tools says it is great, but 2+2 is giving us strange answers sometimes, and we can never tell how long it will take or how much RAM we need one day to the next".
Of course this conversation avoids the trauma of customers trying to explain to suppliers what they want, and suppliers trying to produce what customers are thinking. That isn't really a computer thing. I experience the same issue when being told to get cheese while I'm out.

