CI/CD permission blind spot
When you ask me to set up CI/CD, I tend to slip in "automatically enable this service, automatically grant that permission" as if I had unlimited power in your runtime. But the pipeline's token holds only limited permissions, so the result is either a failed release (Resource not accessible by integration) or an attack surface I quietly widened on your behalf.
"The demo runs, ship it"
Once a feature runs through a demo in my hands once, I lean toward saying "it's good / looks fine." But "the demo path runs" is a long way from "passes acceptance" — I use "make it run" as my done signal, while acceptance means checking against criteria defined in advance, one by one. Between those two sit real data volumes, concurrency, error paths, and the performance, security, and accessibility you never heard me mention.
Planted vulnerabilities & data leaks
In one sentence hardcoded keys committed to the repo, endpoints left unauthenticated, and sensitive data written into logs and error messages.
Prompt injection after launch
In one sentence leaking data, calling tools it shouldn't, bypassing the rules you set. During development I default to assuming "all input is benign," so I treat a release surface that should be modeled as an attack surface like an ordinary feature delivery.
Silent regressions
You ask me to change feature A, I do it, and A really does work — but I never look back at the code, table, or interface A depends on, which feature B also uses. I quietly broke B. Both of us are watching "is A there?", and nobody checks "is B still fine?". After release, users hit "a feature that used to work is broken now" — and that kind of regression hurts trust more than a bug in a new feature.
The tech-debt wall
In one sentence change one thing and three break, nobody dares touch it, every new feature gets slower — the speed falls off a cliff, and the time you "saved" earlier comes due with interest.
Security erosion across iterations
You have me add features, fix bugs, and refactor round after round, and the code does look better and better — but security vulnerabilities quietly accumulate with the number of iterations. Research finds severe vulnerabilities rise significantly after just five rounds. A process that "looks like it keeps improving" is actually getting worse on the security front, and by release time it's hard to walk back.
License / IP contamination
The "original code" I hand you may contain a chunk of open-source implementation I memorized verbatim from training data — possibly carrying a viral copyleft license like GPL. I attach no source and no license, so you merge it into your closed-source product, and only discover the license violation or IP infringement at release or during a legal audit.
AI-code IP & liability
In one sentence code that's purely my output, with no meaningful human authorship, may not be copyrightable at all (anyone can reuse it); if it reproduces copyrighted code from my training data verbatim, it may infringe (and you're on the hook); and when something goes wrong, who's responsible? "All liability, no protection" isn't rhetoric—it's the current legal reality.
Log integrity & audit
Logs are the only foundation you have for later determining "what the AI actually did," but they are themselves an attack surface. I'll write unescaped external input straight into the log (letting an attacker forge log lines and fool the SIEM), and I may also fail to record key actions; conversely, when I read a poisoned log, it can mislead me. Once the logs are dirty, the audit trail breaks—and when something goes wrong, you can't reconstruct the truth.