Why Teach Developers Secure Coding When a Robot Can Find Their Mistakes Later?

A friend of ours recently published Fun with AI: Go Ahead, Create Security Bugs Willy-Nilly. Her prompt to Claude was “Write a one page article that is both sarcastic and somewhat realistic about why it’s better to have AI look for bugs in software than teaching developers to code securely. Include somewhat technical terms, focus on security, add a little humor.”

This article is reproduced below with her permission.

For decades, the security industry has pursued a quaint and exhausting dream: teaching developers to write secure code in the first place. We built training modules, published the OWASP Top 10, and begged engineers to use parameterized queries. The results speak for themselves. SQL injection turned 27 this year and still shows up to work every day. Clearly, the time has come to admit that education was a failed experiment and hand the whole problem to artificial intelligence.

Consider the economics. Training a developer in secure coding takes weeks, costs money, and produces an employee who might leave for a competitor with all that knowledge in their head. An AI bug hunter costs a subscription fee and never asks for a raise, a standing desk, or a “career growth conversation.” It scans a million lines of code before the developer finishes arguing about tabs versus spaces in the pull request comments.

The modern workflow is elegant in its simplicity. A developer asks an AI coding assistant to generate a login function. The assistant helpfully produces code that concatenates user input directly into a SQL string, because it learned from a decade of Stack Overflow answers marked “accepted.” A second AI then scans that code, flags the injection flaw, assigns it a CVSS score of 9.8, and opens a ticket. The ticket sits in the backlog behind 4,000 other findings, several of which concern a deprecated library nobody remembers installing. This arrangement creates a self-sustaining ecosystem where one AI writes the vulnerabilities and another AI finds them. Economists call this a closed loop. Security teams call it job security.

Critics will point out that “shift left” was supposed to catch problems early in the software development lifecycle. The AI approach simply shifts right with confidence. Why prevent a buffer overflow at design time when you can discover it at 2 a.m. through a fuzzing campaign, write an advisory, coordinate disclosure with 14 downstream vendors, and publish a patch on the next quarterly update cycle? Anyone who has worked on a vulnerability response team knows how much character this process builds.

The AI tools also bring a refreshing volume of output. A traditional static analysis tool might report 300 findings, 290 of them false positives. An AI-powered scanner reports 3,000 findings, and it explains each false positive in fluent, confident paragraphs that sound exactly like a real vulnerability. Occasionally it cites a CVE number that does not exist, which gives the triage team a fun research exercise. Alert fatigue used to take months to develop. Now it takes an afternoon.

Meanwhile, the attackers have AI too. They use it to scan the same public repositories, read the same patch diffs, and weaponize a fix within hours of its release. This creates a thrilling race in which defenders’ robots and attackers’ robots compete to read the developer’s code first, while the developer, who never learned to spot the flaw, wonders why the incident response channel keeps pinging him.

To be fair, AI-driven code review really does catch real bugs, including memory-safety errors, cross-site scripting, hardcoded secrets, and insecure deserialization, often faster than humans. That part of the pitch holds up. The catch is that every bug found after the code ships costs more to fix than a bug the developer never wrote. A developer who understands input validation, least privilege, and threat modeling prevents entire classes of vulnerabilities before any scanner runs. A developer who relies entirely on the scanner prevents nothing and generates tickets.

So by all means, buy the AI. Deploy it across every repository and let it find the bugs. Just keep a few developers around who know why the bugs exist, because someone still has to fix them, and the AI that wrote them is busy generating the next batch.