{"slug": "ai-made-bugs-cheap-to-find", "title": "AI Made Bugs Cheap to Find", "summary": "Anthropic's Project Glasswing update, featuring Claude Mythos Preview, found more than 10,000 high- or critical-severity vulnerabilities across major software systems, including thousands in open source projects. The shift makes vulnerability discovery cheaper but creates a bottleneck in human triage and response, forcing teams to prioritize response capacity over detection.", "body_md": "The most important AI security story right now is not that models can find bugs.\n\nIt is that models can find more bugs than humans can responsibly process.\n\nThat is the part that changes how builders should think about software. For years, security work was constrained by discovery. Could someone find the vulnerability? Could they reproduce it? Could they build an exploit? Could a small team afford enough expert review to catch the important issues before attackers did?\n\nNow that bottleneck is moving.\n\nAnthropic's recent [Project Glasswing update](https://www.anthropic.com/research/glasswing-initial-update) is the clearest signal yet. The company says Claude Mythos Preview and its partners found more than 10,000 high- or critical-severity vulnerabilities across major software systems. In open source alone, Anthropic says it scanned more than 1,000 projects and surfaced thousands of serious findings, with human triage becoming the slow part.\n\nYou do not have to take every number at face value to see the shape of the shift.\n\nAI is making vulnerability discovery cheaper. That sounds like good news, and it is. But it also means every software team is about to face a harder question:\n\n**What happens when the scanner is faster than the organization?**\n\nSecurity used to have a familiar rhythm. A bug was found. A report was filed. A team reproduced it. Someone argued about severity. Someone wrote a patch. Users eventually upgraded.\n\nThat process was never fast enough, but it mostly matched the speed of human discovery.\n\nAI breaks that balance.\n\nIf models can search codebases, reason about exploit paths, generate reports, and repeat that work across thousands of projects, then finding bugs stops being the scarce skill. The scarce skill becomes the system around the finding:\n\nThat is the new security stack. Not just detection. Response capacity.\n\nA vulnerability that sits untriaged for three weeks is not meaningfully safer because an AI found it. In some cases, it is riskier, because the same class of model may soon make the path to exploitation easier for everyone else.\n\nThe patch window is not an operational detail anymore. It is part of the product.\n\nThere is a lazy version of the story where AI agents make security easy.\n\nRun the model. Get the report. Apply the patch. Done.\n\nThat is not how real systems work.\n\nReal systems are full of tradeoffs. The obvious fix can break an integration. The technically correct fix can create a migration problem. The most severe-looking vulnerability might be unreachable in production, while the boring one in a forgotten admin path is exposed to the internet.\n\nAI can help find and explain these problems. It can write a first patch. It can generate a regression test. It can compare similar code paths and look for variants.\n\nBut someone still has to own the decision.\n\nThat is the same pattern I keep seeing across AI-assisted building. The manual work shrinks, but the judgment work expands. The operator has to decide what deserves attention, what can wait, what risk is acceptable, and what needs a deeper human review.\n\nSecurity is just where this becomes impossible to ignore.\n\nThere is a period we are entering that feels especially unstable.\n\nEventually, AI should make software much safer. Every serious codebase should have agents continuously searching for vulnerabilities, proposing patches, generating tests, and checking whether fixes actually landed. That world is better than the one we have now.\n\nBut the transition is messy.\n\nThe discovery side is improving faster than the response side. That creates a gap. More findings, more reports, more possible attack paths, more pressure on teams that already do not have enough security capacity.\n\nThis is especially painful for open source.\n\nA large company can assign security engineers, rotate incident response, and fund dedicated tooling. A maintainer with a popular library might be doing all of this after work, for free, while also reviewing feature requests and answering issue comments. Dumping hundreds of AI-generated reports into that maintainer's inbox does not automatically make the ecosystem safer.\n\nIt might make it worse unless the reports are high quality, reproducible, prioritized, and paired with patches that are easy to review.\n\nAI security only works if it respects the human throughput on the other side.\n\nIf you are building with AI agents, this is not just a cybersecurity industry story. It changes the default operating model for anyone shipping software.\n\nThe old advice was \"move fast and break things.\" The AI-era version needs an asterisk:\n\nMove fast, but build a system that can notice what broke.\n\nThat means security cannot be a quarterly cleanup pass. It has to live inside the same loop as product work.\n\nAI code should not feel like magic output. It should feel like a pull request from a very fast junior-to-mid-level engineer who sometimes has excellent instincts and sometimes misses the reason the system is shaped the way it is.\n\nReview it. Ask what changed. Ask what assumptions it made. Ask what surfaces it touched. If a change affects auth, payments, permissions, file handling, secrets, user data, or external integrations, slow down.\n\nFast does not mean casual.\n\nAI is good at producing tests that increase coverage and bad at knowing which behavior deserves proof unless you tell it.\n\nFor security-sensitive changes, generic tests are not enough. Ask for tests that prove the boundary:\n\nThese tests do more than catch regressions. They teach the agent what matters next time.\n\nThe teams that handle AI-era security well will not be the teams with the most findings. They will be the teams with the shortest path from confirmed issue to shipped fix.\n\nThat means knowing who can approve a security patch. Knowing which tests must run. Knowing how to ship a small hotfix without dragging in unrelated product work. Knowing how to communicate a change if users need to update.\n\nIf your process requires three meetings to patch a serious bug, AI did not solve your security problem. It just made the backlog visible.\n\nThe most underrated security feature is not having the feature.\n\nEvery integration, admin panel, file parser, OAuth scope, background job, and public endpoint becomes another place where a model can find something interesting. AI makes it easier to build all of that. It also makes it easier to discover what you accidentally exposed.\n\nThis is another reason taste matters. Good builders cut surface area. They do not add settings because settings are easy. They do not expose APIs because the model can scaffold them. They ask whether the capability deserves to exist.\n\nThe safest code is still the code you never had to ship.\n\nEvery time AI makes a technical task cheaper, people assume the human role shrinks.\n\nI think the opposite keeps happening.\n\nWhen code generation gets cheaper, product judgment matters more. When content generation gets cheaper, taste and distribution matter more. When vulnerability discovery gets cheaper, triage and patch judgment matter more.\n\nThe bottleneck moves up the stack.\n\nThat is the lesson for builders. Do not measure your AI workflow by how much code it can produce or how many issues it can find. Measure it by how quickly it helps you make good decisions and ship the right fixes.\n\nThe future is not \"AI finds every bug, so security is solved.\"\n\nThe future is closer to this:\n\nAI finds more than you can handle. The winners are the teams that built the judgment, process, and restraint to handle the right things first.\n\nProject Glasswing is a preview of a much larger shift. Software is entering an era where the cost of finding flaws drops dramatically, while the cost of responsibly fixing them remains stubbornly human.\n\nThat is uncomfortable, but it is also useful clarity.\n\nIf you are building with AI, do not wait for a security crisis to design your response loop. Review agent-written code like it matters. Test the boundaries. Keep patches small. Reduce surface area. Build a process that can absorb uncomfortable findings without freezing.\n\nAI made bugs cheap to find.\n\nNow the hard part is proving you can fix them.", "url": "https://wpnews.pro/news/ai-made-bugs-cheap-to-find", "canonical_source": "https://dev.to/prpatel05/ai-made-bugs-cheap-to-find-2j6g", "published_at": "2026-08-17 21:03:08+00:00", "updated_at": "2026-08-17 21:42:53.058246+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-safety", "ai-products", "ai-tools", "ai-research"], "entities": ["Anthropic", "Claude Mythos Preview", "Project Glasswing"], "alternates": {"html": "https://wpnews.pro/news/ai-made-bugs-cheap-to-find", "markdown": "https://wpnews.pro/news/ai-made-bugs-cheap-to-find.md", "text": "https://wpnews.pro/news/ai-made-bugs-cheap-to-find.txt", "jsonld": "https://wpnews.pro/news/ai-made-bugs-cheap-to-find.jsonld"}}