theprestige
Penultimate Amazing
Flailing about as a student is one thing.
I've never seen it in 30+ years of systems administration, agile devops, and site reliability engineering.
And like I said before, what Dr. Sid describes as "vibe coding" is nothing like the practice we actually call vibe coding - the practice that wasn't even really possible until a couple years ago.
@Dr.Sid "vibe coding" is the practice of telling an AI agent to write code for you, based on goals and requirements you give it. You use natural language, the agent produces code that hopefully matches what you had in mind.
If the code does seem to match what you had in mind, you think no more about it and press the "release" button. If it doesn't match, you use natural language to tell the agent what's wrong, and try again.
It's called "vibe coding" because the goal is to get the AI to match the "vibes" - the general feeling and concept of what you had in mind - with the results it produces. You don't ever actually sit down and think through the program, module by module, function by function. You never personally lay hands on logic structures that loop on conditionals, handle secrets, import modules, etc.
The result is code that runs, at least for the most basic use case that the vibe coder had in mind, but is potentially a mess of bugs, inefficiencies, and security failures under the hood. More so than usual, I mean. And with nobody on the team actually qualified to go in and fix any of those problems.
My employer has me doing vibe coding. But it's small stuff. It doesn't touch production. It doesn't overwrite data in sources of truth. It's all just data organization and presentation code. The only thing that happens if I get it wrong is that a chart or graph doesn't show up on a dashboard properly.
Most of my vibe coding time is spent telling the agent things like:
- "Make a pass looking for security flaws; suggest fixes" The agent discovers its storing secrets in the clear, in the code. Suggests a perfectly cromulent new module to handle secrets in a secure way.
- "Make a pass looking for inefficiencies; suggest fixes". Same as above.
- "Make a pass looking for reliability gaps; suggest fixes". Same as above.
In the end, my stuff works well enough for internal use. Thanks to my attention to larger concerns in software development, it tends to be more secure and less buggy than baseline "vibe coding" would be. Even with five or more cleanup passes, I'm still ten times more productive than I used to be.
And I've even started assembling (well, having an agent assemble) a catalog of rules files for it to reference, that build the security, efficiency, reliability checks into the spec from the beginning, cutting down on the number of cleanup passes that need to be done.
Vibe coding is its own whole thing. It has its uses, but also some risks.
Ironically, it's best used for minor, internal projects like I use it. But as we're learning, the resource cost is probably too high to justify such small results. Millions of mediocre programmers drying up seas and burning down rain forests, just to pass tokens of the form, "this time try not to send your auth code in plaintext to the read_data API".
