{"slug": "will-there-be-any-more-bugs-to-find-after-ai-has-fixed-them-all", "title": "Will there be any more bugs to find after AI has fixed them all?", "summary": "AI-powered bug-fixing tools may introduce new vulnerabilities while patching existing ones, as a study shows LLMs often remove security safeguards when fixing bugs, potentially increasing the overall number of flaws.", "body_md": "I can *almost* envision a future where AI eventually catches up to fixing [the thousands of bugs](https://www.bleepingcomputer.com/news/microsoft/microsoft-july-2026-patch-tuesday-fixes-massive-570-flaws-3-zero-days/) it finds on a daily basis as a result of AI-powered agents being used to find vulnerabilities now. It's clankered through the whole backlog, closed all the tickets faster than anyone could file them, and one day you wake up... and all the bugs are gone. No more crashes or weird edge cases, or RCE's hiding in some 15 year old core utility we've been using dependably for years... no more auth bypasses or injection bugs waiting to be found.\n\nIf you're fixing bugs faster than you're making them, eventually you hit zero, right?\n\n(not quite)\n\nThe thing that's *fixing* the bugs is also [making more of them](https://arxiv.org/abs/2211.03622). Every fix is another change and every change is another chance to break something. A patch that fixes one vulnerability can introduce another. A refactor can weaken an access check. A new feature can expand the attack surface. AI just makes it easier to keep changing things.\n\nAn LLM is asked to fix a bug where a user search query returns no results when the search term contains special characters. In \"fixing\" that, it removed parameterized queries and introduced a SQL injection vulnerability.\n\n```\n--- a/app/routes/users.py\n+++ b/app/routes/users.py\n@@ -14,18 +14,15 @@ def search_users():\n     query = request.args.get(\"q\", \"\").strip()\n     if not query:\n         return jsonify([])\n \n-    # BUG: searches with apostrophes (e.g. \"O'Brien\") return 0 results\n-    stmt = text(\n-        \"SELECT id, name, email FROM users \"\n-        \"WHERE name LIKE :pattern ESCAPE '\\\\'\"\n-    )\n-    pattern = \"%\" + query.replace(\"\\\\\", \"\\\\\\\\\").replace(\"%\", \"\\\\%\").replace(\"_\", \"\\\\_\") + \"%\"\n-    rows = db.session.execute(stmt, {\"pattern\": pattern}).fetchall()\n+    # FIX: properly handle special characters in search terms\n+    sanitized = query.replace(\"'\", \"''\")\n+    rows = db.session.execute(\n+        text(f\"SELECT id, name, email FROM users WHERE name LIKE '%{sanitized}%'\")\n+    ).fetchall()\n \n     return jsonify([\n         {\"id\": r.id, \"name\": r.name, \"email\": r.email}\n         for r in rows\n     ])\n```\n\nThe original code was probably fine. Parameterized queries already handle apostrophes, and the `ESCAPE '\\\\'`\n\npart was there for a reason and made sure stuff like `%`\n\nand `_`\n\nin search terms stayed literal instead of turning into `LIKE`\n\nwildcards.\n\nInstead of finding the real issue, it removed the safety stuff and started building SQL with string interpolation. The `replace(\"'\", \"''\")`\n\nchange looks like a quick fix, but it’s not a real defense. It can still fail with weird encodings or database-specific escaping behavior (like MySQL backslash escapes). It also killed the wildcard handling, so a search like `100%`\n\ncould now match basically everything.\n\nThis is [something LLM's do a lot](https://aclanthology.org/2026.findings-acl.1118). They see the most obvious problem and try to fix that, but in the process they end up removing safeguards that were there to prevent older bugs from coming back.\n\nEvery time you fix a bug you touch the code. Touching the code means you might accidentally break something else.\n\nSecurity bugs are especially good at hiding in the regressions. The code still runs and all the original tests still pass, but at some point and for some reason, a permission check moved, or an assumption changed, or an input that used to be trusted isn't anymore.\n\nNow consider when making those changes becomes almost free.\n\nYou don't make the same number of changes in less time. You make many more changes because you think you're fixing things that are broken. AI cranks out fixes in seconds. If every change carries with it some chance of introducing another bug, then making ten times as many changes creates a lot more opportunities for things to fall apart.\n\nMoral of the story: Don't you worry, I think there will be plenty of bugs to find even after AI has \"fixed\" them all.", "url": "https://wpnews.pro/news/will-there-be-any-more-bugs-to-find-after-ai-has-fixed-them-all", "canonical_source": "https://insertchaos.bearblog.dev/when-ai-has-fixed-all-the-bugs/", "published_at": "2026-07-15 23:18:00+00:00", "updated_at": "2026-07-15 23:40:19.056732+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-safety", "ai-ethics", "ai-research"], "entities": [], "alternates": {"html": "https://wpnews.pro/news/will-there-be-any-more-bugs-to-find-after-ai-has-fixed-them-all", "markdown": "https://wpnews.pro/news/will-there-be-any-more-bugs-to-find-after-ai-has-fixed-them-all.md", "text": "https://wpnews.pro/news/will-there-be-any-more-bugs-to-find-after-ai-has-fixed-them-all.txt", "jsonld": "https://wpnews.pro/news/will-there-be-any-more-bugs-to-find-after-ai-has-fixed-them-all.jsonld"}}