Claude Is Great at Building Software. It's Also Great at Breaking It.
In the last four months, almost a third of my commits were just security patches. 22 separate days updating dependencies. The same AI tools that make building easy are accelerating how fast vulnerabilities get found and exploited. And maintenance is becoming unbearable.
Everyone's celebrating how easy it is to build software now. And they're right. It's never been this accessible.
But nobody's talking about the other side of this. The same tools that let a non-coder spin up a full-stack app in an afternoon are also being used to find holes in the software the rest of us depend on. And it's making maintenance unbearable.
My GitHub Has Become a Vulnerability Ticker
In the last four months, across just one of my projects, I've made 29 security-related commits out of 94 total. That's almost a third of all my work just keeping things patched. On 22 separate days since December, I was dealing with dependency updates triggered by Dependabot alerts. Almost every other day.
The packages? axios, lodash, next, rollup, tar, undici, webpack, qs, flatted. These aren't obscure libraries. These are the backbone of modern web development. And they keep getting flagged, patched, flagged again.
I'm not building new features during those commits. I'm not improving the product. I'm running in place.
The CVEs Keep Coming
Let me give you some real numbers.
In March 2025, Next.js disclosed CVE-2025-29927. A critical vulnerability with a severity score of 9.1 out of 10. An attacker could bypass all your middleware-based authentication by adding a single HTTP header. Every Next.js version from 11.1.4 to 15.2.2 was affected. That's years of releases, all vulnerable.
Then came CVE-2025-57822. Server-side request forgery in Next.js. If you were self-hosting and using next() in middleware without explicitly passing the request object, your app was open to SSRF attacks. Fixed in 14.2.32 and 15.4.7.
These aren't theoretical. These are frameworks that millions of apps run on. Including mine. Including my clients'.
AI Didn't Create the Vulnerabilities. It Found Them Faster.
Here's the part that keeps me up at night.
Security researchers have always looked for vulnerabilities. That's their job. But now they have Claude, GPT, and every other LLM accelerating that work by orders of magnitude. Code that sat unexamined for years is suddenly getting audited by anyone with a chat window.
And that includes people who aren't security researchers.
The npm ecosystem is already feeling it. Supply chain attacks averaged 13 per month in early 2024. By late 2025, that number hit 25 per month. Over 6,000 malicious packages were flagged in a single month. One campaign, IndonesianFoods, was publishing a new malicious package every seven seconds. 100,000+ packages in days.
Unit 42 found AI-generated malicious payloads in the Shai-Hulud attack, complete with comments and emojis that screamed "an LLM wrote this." Sonatype's 2026 report showed that 28% of LLM-assisted dependency upgrades recommended package versions that didn't even exist. Attackers register those phantom packages, and suddenly your AI-assisted dependency update has installed malware.
Everyone Talks About Building. Nobody Talks About Maintaining.
The conversation around AI and software is stuck on creation. "I built an app in 10 minutes!" Great. Now maintain it for three years.
I'm not against non-coders building software. I'm genuinely all for it. The more people who can create things, the better. But the same tools that lower the barrier to building also lower the barrier to attacking. And the people building those weekend apps aren't the ones waking up to Dependabot alerts on a Tuesday morning.
I am. And I'm getting tired.
Over the last few months, I've spent more time updating dependencies than writing actual features. You implement best practices. You follow security guidelines. You think you've covered your bases. Then you wake up and there's a new critical CVE in a package you didn't even import directly. It came in through a dependency of a dependency.
What This Means for My Business
This is the real reason I'm writing this. I've decided to slow down on taking new projects.
Not because I can't build them. Building was never the hard part. The hard part is the maintenance overhead that keeps growing. Every new project is another repo getting Dependabot alerts. Another codebase that needs patches. Another thing I'm responsible for when the next CVE drops.
And I can only imagine what it's like for the maintainers of the packages I depend on. If I'm stressed about my handful of projects, imagine maintaining something like lodash or webpack with millions of weekly downloads. Every vulnerability disclosure, every patch, every breaking change. The stakes are incomparably higher for them.
I Don't Have a Solution
I usually try to end my posts with some kind of practical takeaway. This one doesn't have that.
The trend is clear. AI is accelerating both sides of the equation. Faster building, faster breaking. More software, more attack surface. More creators, more attackers.
There's no going back. There's no regulation that will stop someone from asking an LLM to analyze a codebase for exploitable patterns. The information is out there, the tools are free, and the barrier is gone.
What I can do is be honest about what this means for the work I take on. If you're a client or considering working with me, know that a significant part of what you're paying for isn't the initial build. It's the ongoing vigilance. The patches at 7am. The dependency updates that don't add a single visible feature but keep your app from being the next headline.
That work is invisible. It's unglamorous. And it's getting harder every week.
About the Author
Kemal Esensoy
Kemal Esensoy, founder of Wunderlandmedia, started his journey as a freelance web developer and designer. He conducted web design courses with over 3,000 students. Today, he leads an award-winning full-stack agency specializing in web development, SEO, and digital marketing.