Some of it are legit bugs - doesn't even matter whether they're heathooked or vibed - that just need to get fixed. I can also empathize with not having the full LLM review setup in place and it needing time.

Regressions on dot releases are unnecessary tho. If you know what you're doing, with a medium severity thing that nowadays NVD won't even process anymore unless its actively exploited in the field, you have some time to make sure it's right. But for some reason that is not happening. It's easy to blame vibe coding but the problem isn't the LLM, it's the human putting their name on the commit and pressing the release button. Pressure to ship was always a risky method, but now it feels dangerous.

I've defined a quality gate for myself when dealing with bugs in 3rd party code on the integration side that from an OpenVEX point of view (I love that framework), for each known bug, CVE or unpublished but I know of it (or found it), there needs to be a true statement of not_affected and a justification out of the standard enumeration:

• component_not_present - i.e. a scan issue or a CVE scoping issue, like that awful golang stdlib pgp deprecation vuln that triggers on anything that uses x/crypto
• vulnerable_code_not_present - build-time configuration excludes the component, i.e. a bug on openssl x509 but you're only compiling enc
• vulnerable_code_not_in_execute_path - this is the #1 outcome on npm advisories where some dev dependency some retard included in an eslint chain is never run - claude is really good at testing for this and will unleash all "cyber capabilities" as long as you don't ask it to do that
• vulnerable_code_cannot_be_controlled_by_adversary - I don't like this one but if something is hard coded then you can just monitor the code)
• inline_mitigations_already_exist - I am doing this more and more often: gate the hell out of a 3rd party lib so that the trigger conditions for the bug go away.

Any bug that cannot be marked as mitigated in this way is a threat and a process failure (or at the very least suboptimal process.) I had to invest heavily in my frameworks to be able to keep track of all the 3rd party bugs - and in some cases the mitigations. I'm tracking close to 500 actively mitigated bugs right now.

Now, with all the sAfEtY bs going on, I have to invest a lot of time into harnesses that do not only flag the bug, but actually help me to reproduce the error, because how else do I know that something is fixed - trust the LLM without evidence? The other day I was reconstructing vuln vectors from tool call logs from Opus traces because it was refusing to simply give me the vector it said it proved. Deleted the files from the workspace, refused to give me a tarball with the harness AND refused to analyze the tracefile. So I just went over it call-by-call, found the test harness, normalized the tool calls in text editor, extracted and manually tested the vectors, and at least found out it wasn't lying. Then mitigated it. It's still cheaper than doing it end-to-end manually but this sAfEtY shit is expensive gate keeping that doesn't work - after all if I can get the vectors then so can a bad actor. This is a failure of the US AI labs and the Chinese labs are copying bits of it to not get sanctioned. Hell will freeze over before some service is running processes on my hardware and be successful in hiding that from me - I will simply log more if I have to.