I think this policy is probably more prescriptive than I would go with myself. I like to think of my risk tolerance first to help make that determination.
For example, I use a vibecoded internal tool written in Go. I don’t even know how to write Go. Haven’t read a single line of the code. I just wanted to move from bash scripts to using cloud SDKs for performance reasons.
But the internal tool is a convenience tool, and you can do everything it does using alternative methods. So if it break, there is no real negative impact besides personal convenience of anyone using it. There’s some documentation on how to do everything manually if needed.
Here’s another example: you’re making a static website. No JavaScript, no interactivity. Truly, what could go wrong? And while I do understand HTML a lot better than Go, it wouldn’t really matter if I didn’t.
> I just wanted to move from bash scripts to using cloud SDKs for performance reasons.
What is this supposed to mean? How is a “cloud sdk” more performant than a shell script?
The shell script wasn’t the performance issue, it was the fact that the shell script was calling the AWS CLI rather than the SDK.
There’s a bit less waiting around.
> Here’s another example: you’re making a static website. No JavaScript, no interactivity.
Linking a huge file consuming clients’s bandwith for no reason. Embedding PII in the html source? And if setting up your own server, misconfiguring it?…
“Setting up your own server” isn’t part of this, as you’d almost certainly deploy a static site using something simple and serverless.
You also don’t need to know how to read HTML to recognize large files. You can catch issues like this with a simple website performance testing tool like pagespeed.web.dev
I’m also not sure how PII would enter the HTML source.