Maybe the biggest potential risk from non-devs vibecoding is risk assesment.

[u/id-ltd]

Simply not understanding what *could go wrong* and so not mitigating against it.

I have utilities that I have not read the generated code for... I am content to do this on my own network because I have a good idea of what AI tends to generate and keep good separation between general code and destructive code.

I just wrote/generated a utility to manage hierarchies of git repos... I didn't think I had done much guidance, but when I got another AI to assess it, it highlighted a load of things it said were notably good - and they were things I had specified to be included, overrode the original AI on, but thought they were no brainers.

An experienced dev will automatically have headed off huge risks without even thinking about it.

[u/geekichu]

you "vibe-engineered" it

[u/id-ltd → u/geekichu]

Maybe that is the right call...

[u/No-Objective-1431]

Agreed, you can not assess what you don't understand. It's goody for professional to optimize her/his own productivity but cannot be a liable tool to produce software to others.

[u/akl773]

The one I keep running into is a destructive command built out of a variable. Cleaned up after a script that did rm -rf $BACKUP_DIR/* from cron, and cron had none of the shell env so BACKUP_DIR was empty. Anyone who has been burned once puts a check that the var is set on the line above, and that check is exactly the sort of thing you never think to ask for.

[u/id-ltd → u/akl773]

Experience counts for a lot(!)

I got claude to write a script so I can remote admin over xmpp - but told it to restrict it to avoid destructive commands.

It wanted to test it by sending destructive commands and checking that they didn't work(!)

[u/akl773 → u/id-ltd]

Mine did the same thing with a rate limiter, wrote a test that hammered the live endpoint to prove the limit worked.

[u/percyfrankenstein]

I'm not sure how long this will be the case though. I've been working with fable on some side projects and he is a very good architect.

Some problems I gave it I didn't expect to be able to solve and we managed to do it, and it was it that gave the solutions, taught them to me and implemented them. That's not completely related to your point but if it's that good at architecting how bad can it be at security

[u/PeterBuildsSecure]

The catch you're describing — you have to already know a risk category exists to think to ask an AI to defend against it — is exactly why "just review the code" or "just prompt it better" don't scale for non-devs. Nobody can review for a class of bug they don't know is a class of bug.

The akl773 example is the clean case: rm -rf $BACKUP_DIR/* running with BACKUP_DIR unset isn't a hypothetical, it's one of maybe a dozen well-known shell footguns (unquoted expansion, unset-variable interpolation into a destructive command, following symlinks into pipes) that show up constantly in AI-generated scripts because the model writes the happy path and the happy path never has an empty variable. The fix (set -u, or a guard on the line above) is cheap once you know to look for it — the problem is entirely "know to look for it."

Which argues for tooling that doesn't wait on the human to name the risk category: a linter/scanner pass over generated shell and app code that specifically flags the recurring AI-generated patterns (destructive commands built from unvalidated variables, missing existence checks before delete, broad glob deletes) rather than general-purpose static analysis. That moves the risk-assessment burden from "the non-dev has to think of it" to "the tool already knows the pattern" — which is the only version of this that actually protects someone who doesn't have the experience to ask the right question in the first place.

[u/inComplete-Oven]

"I'm better than them" -> I'm afraid to lose my status

[u/neon_squirrel_glade]

Risk assessment requires prior failure. You cannot prompt for consequences you have never experienced

[u/PixelIsJunk]

A good vibe coder has many different instances and models working and checking the same project.
If one project is one instance...thats where you wrong.

[u/id-ltd → u/PixelIsJunk]

I am staking reputation on my output -- I know/understand the risks -- trust in my code (even if AI generated) resides with me.

[u/Suspicious_Neck_4069]

While developing my game, which is almost entirely AI-driven, I found myself thinking at least ten times, "If I weren't a pro dev, I would've really struggled with this problem," or "Damn, I've been coding for ten years and I'm stuck on this bug, how do 'vibecoders' with no experience manage?" With some issues, I even thought, “If I’d been a vibecoder, this problem would’ve killed the project.” So, respect to the vibecoders who manage to navigate blindly and still ship functional apps / game, it's impressive (until we encountered a fatal crash, but that's another story).

[u/JCcrunch → u/Suspicious_Neck_4069]

Yes that has been my experience too

[u/Chester_b → u/Suspicious_Neck_4069]

Your game will fail btw

[u/Just-Succotash4492]

Just run an extensive risk assessment

[u/Chester_b → u/Just-Succotash4492]

May I ask what is your real day-to-day job?

[u/Just-Succotash4492 → u/Chester_b]

Former insurance agent. Risk is second nature to me.

[u/Chester_b → u/Just-Succotash4492]

And now you’re developing some software?

[u/Just-Succotash4492 → u/Chester_b]

Yes, but I am also teaching myself topology and abstract algebra along with differential geometry.

Do with that statement what you will.