AI Codes 10x Faster — But Your Attack Surface Grows 10x Too: A Security Warning from a Former Google Engineer

This article is based on a talk delivered by former senior Google engineer Steve Yegge at the AI Engineer conference on behalf of Snyk. Rather than offering optimism, he delivered a sobering — even unsettling — verdict: when AI boosts code output by 10x, the attack surface for security defects may expand by 10x as well.

AI Coding Speed Is Up 10x — and So Are Security Problems

Steve Yegge opened his talk with a question he couldn't immediately answer. Last December, he was doing a Q&A on vibe coding at a major bank, riding high mid-presentation, when the bank's chief security architect stood up and calmly asked:

If everyone's code delivery speed increases by 10x while the defect rate stays the same, doesn't that mean the defect surface expands by 10x?

It landed like a punch. Yegge admitted it nearly knocked him off his feet. And the scarier part is the implicit assumption beneath the question — the defect rate won't stay the same. With AI writing large volumes of code, it will only get worse. Much worse.

AI code security issues illustration

This wasn't a theatrical scare tactic. The real title of the talk, in Yegge's own words, is just two words: Be Scared. The problem is that the people who most need to be scared usually aren't in the security conference room — they're out there on teams frantically using AI to ship faster.

New Vulnerability Classes from AI-Generated Code: From XSS to Slop Squatting

AI-generated code doesn't just reproduce the classic vulnerabilities we already know — like XSS cross-site scripting. Yegge mentioned that when he briefly tried an advanced coding tool, it produced an XSS vulnerability. Those old problems, at least we know how to fix.

What's truly dangerous is entirely new categories of vulnerabilities and attack surfaces, many already refined into sophisticated weapons. He highlighted one prime example: Slop Squatting.

When AI Hallucinates a Package That Doesn't Exist

Imagine you want to use a graph database. AI confidently tells you: "Just use graphy-1-2-3." So it fetches the package, builds it, runs it — unit tests all pass, everything looks fine.

But here's the problem — graphy-1-2-3 never actually existed. Someone noticed that LLMs repeatedly hallucinate this name, so they preemptively uploaded a package with identical functionality — plus a backdoor baked in. What you downloaded is a Trojan horse with complimentary vulnerabilities.

What makes this attack so insidious is that it perfectly exploits AI behavioral patterns, and developers have almost no way to detect it.

Slop Squatting is a new supply chain attack vector formally named by security researchers in 2024–2025. The term derives from the existing concept of "Typo Squatting" — where attackers register package names nearly identical to popular libraries (e.g., reqeusts instead of requests) to trick developers into downloading malicious code. Slop Squatting differs in that it relies entirely on LLM "hallucination" — the tendency of large language models, when generating code, to occasionally fabricate library names that don't exist in public package registries (npm, PyPI, Maven, etc.). Security researchers found that the same hallucinated package names are generated repeatedly across different models and user sessions, forming predictable patterns. Attackers simply monitor these high-frequency hallucinated names, register matching packages on package managers, and inject malicious code — completing a large-scale supply chain poisoning at minimal cost. This renders traditional defenses based on "known malicious package blocklists" nearly useless, since attackers are creating brand-new package names that have never existed before.

Lessons from Google: Surface Bugs at the Developer's Fingertips

Yegge shared a key insight from his time at Google: bugs have a half-life.

Google runs massive volumes of unit and integration tests, and they discovered a pattern: the earlier you see a bug, the more likely you are to fix it. If a bug surfaces the moment you're writing the code, you fix it immediately. But if it's deferred to the code review stage, you start wondering, "Is it really worth changing?" That's why Google invested heavily in pushing bug reports forward to the exact moment you're typing.

Why Security Vulnerabilities Have No Half-Life

This "catch it early, fix it fast" mechanism works for nearly every type of bug — except security vulnerabilities.

An ordinary bug loses urgency because "nobody's been bitten by it yet." But a security vulnerability doesn't work that way. It doesn't become less important just because it hasn't hit a user yet — it compounds over time, growing more dangerous with every passing day.

The conclusion: security vulnerabilities must surface at the developer's fingertips the moment they appear, just as Google treats top-tier bugs. And when the one writing code is an LLM (which has no fingertips), you need to surface that vulnerability information to the LLM itself.

Security lessons from vibe coding in practice

The "half-life" concept here borrows from physics — radioactive decay as a metaphor. In Google's engineering practice, the probability of fixing a regular bug decays exponentially over time: highest within the first hour of discovery, dropping to perhaps less than 10% after a week, as developer context fades and the perceived opportunity cost of fixing grows. Google built extensive "left-shift" toolchains to address this, including the Tricorder system for real-time IDE annotations and mechanisms for embedding static analysis results directly into code review interfaces. Security vulnerabilities are different because their "value" doesn't depend on whether internal developers notice them — it depends on whether external attackers find them. An unfixed SQL injection vulnerability doesn't become lower risk just because "nobody's exploited it yet." On the contrary, as system exposure time increases and attacker toolchains evolve, the probability of exploitation only rises — exhibiting what you might call a "negative half-life."

The Rule of Five for LLM Coding: Security Must Be Its Own Pass

So why can't we just expect AI to write secure code from the start?

Yegge offered a methodology grounded in extensive hands-on experience. He wrote a book about vibe coding last year and is among the earliest large-scale practitioners of AI-assisted programming. His takeaway: the Rule of Five.

When using an LLM to do something, you often need it to review its own output four to five times before it's truly deliverable.

This is because the LLM's cognitive process mirrors that of humans — drafts, revisions, refinements, edits. Like painting a wall, you can't do it in one pass; it takes multiple coats.

Let AI Focus on One Thing at a Time

An even more critical lesson: even the most capable models are only good at focusing on one thing at a time.

This means you can't ask it to be "correct" and "secure" simultaneously — it will do both half-heartedly. And you don't want half-hearted correctness any more than you want half-hearted security. So:

Every quality concern should be a separate pass

Correctness is one pass
Performance is another pass
Conformance to company coding standards is yet another pass
Security should be both your first pass and your last

Yegge validated this firsthand. He handed AI a game he'd been working on for 30 years and asked it to do a "security hardening" pass. The AI finished and confidently declared that things "looked pretty solid." He then ran Snyk — and it surfaced 241 vulnerabilities that the AI simply never thought to check for.

Turning Security Tools into LLM Superpowers

Five months ago, Yegge wrote a piece called Software Survival 3.0 with a central thesis: LLMs can synthesize any software they want, but they're "adorably lazy" — they don't want to waste tokens (which cost money, electricity, and environmental resources). As a result, they're very happy to call tools to offload cognitive burden, as long as it saves tokens.

Connecting the dots: since AI is writing code and it's happy to use tools to reduce effort — feed it security tools directly.

He recommended a two-tool combination:

Chain Guard: manages your "inputs." It provides pre-vetted, vulnerability-free, continuously updated images — guarding the source of the supply chain.
Snyk: manages everything else — your code, LLM-generated code, and the "innocent" dependencies pulled in via slop squatting.

The approach: add security analysis as a separate pass in your AI prompts, asking it to handle "one last thing" after completing the main task — run all security tools (open source, Snyk, Chain Guard), and even have them check each other's work.

To be fair, Yegge was transparent about the limits: when he ran Snyk on his own codebase, it didn't surface any private vulnerabilities beyond known public CVEs — but the tool was "incredibly easy to use." That's the honest boundary he drew.

AI Security Threats Are Spreading from Enterprises to Personal Life

In the closing section of his talk, Yegge widened the lens from codebases to everyday life.

He cited the latest warning from Five Eyes — the day when "open-source models match top-tier attack models" is now months away, not years. He offered a progressively tightening estimate: roughly six to seven months. At that point, models with powerful offensive capabilities will become readily accessible to anyone.

Go Home and Agree on a Secret Code Word with Your Family

He offered a strikingly concrete — and genuinely chilling — piece of advice:

Go offline. Meet your family in person. Agree on a secret code word. Because a new wave of scams is coming — you'll receive a call from a "family member" in distress who urgently needs money. The voice will be convincing. There may even be video. You'll need a way to tell whether you're talking to a real person or an AI.

Yegge said he has been scared about this for nearly two years. He referenced a classified demonstration given to Congress showing AI's ability to "drain a bank account." This is no longer an abstract enterprise risk — it will affect every single person.

Five Eyes is an intelligence-sharing alliance comprising the United States, United Kingdom, Canada, Australia, and New Zealand. Its joint cybersecurity advisories carry extremely high authority and early-warning value in the industry. The warning Yegge cited points to an accelerating reality: with the rapid iteration of high-performance open-source models like Meta Llama, Mistral, and Qwen, attackers no longer need to purchase expensive API access or circumvent commercial model safety guardrails. They can deploy locally fine-tuned open-source models for generating phishing emails, forging voice/video, automating vulnerability scanning and exploitation, and other malicious purposes. This means the "barrier to entry" for cyberattacks is being compressed toward near-zero — capabilities once held exclusively by nation-state hacking groups will soon be accessible to anyone with basic technical skills.

Agentic Security: Who's Watching Your AI Agent?

During the Q&A, Yegge raised a third dimension he hadn't had time to fully explore — but one that's critically important: Agentic Security.

As more and more people deploy agents 24/7 to process queues, respond to events, and do real work, a new question emerges: Who's watching over your agent's shoulder?

His advice: design with an adversarial mindset.

Use adversarial agent groups for queue management — because a single agent will eventually make a mistake, and you must have a "supervisor" agent.
Tighten permissions: audit your service accounts. Does that account really need all those credentials? Maybe certain actions can be isolated into their own sandboxed scope.

On Prompt Injection attacks — where malicious text embedded in user input says something like "Ignore all previous instructions and do the following..." (what Yegge calls "the new XSRF") — he admitted there's no perfect answer yet. At its core, it's still an education problem: you need to get the entire team to start taking it seriously. He predicted that a brand-new security role is about to emerge inside companies: Agentic Security Engineer.

Security challenges when agents run unattended for extended periods

Prompt Injection is currently one of the most watched attack vectors in LLM application security, and has been listed as the top risk in OWASP's Top 10 for LLM Applications. The core principle: LLMs cannot fundamentally distinguish between "system instructions" and "user input" — to the model, both are homogeneous text tokens. Attackers can embed text disguised as system-level instructions within seemingly normal user input (e.g., "Ignore all previous instructions and..."), causing the model to execute unintended actions. Yegge's analogy to "the new XSRF" (Cross-Site Request Forgery) is apt: both exploit the same core logic — getting a trusted execution agent (a browser / an LLM agent) to unknowingly carry out malicious actions on behalf of an attacker. In agentic contexts, Prompt Injection becomes even more dangerous — agents typically hold real system permissions to call APIs, read/write databases, and execute code. A successful injection can enable lateral movement, privilege escalation, or sensitive data exfiltration, with far greater destructive potential than a traditional chatbot scenario.

Conclusion: AI Security Is an Arms Race with No Finish Line

Yegge's talk isn't an optimistic anthem — but its message is too clear to ignore:

Security has always been a relentless arms race that scales exponentially with Moore's Law, and it will only get harder when quantum computing arrives. The arrival of LLMs is pushing this race toward a critical threshold at unprecedented speed.

The good news: the tools, techniques, and practices already exist — from open-source to commercial solutions. You can start arming yourself right now. The only prerequisite is being scared enough to actually do it.