Hacker News Daily: The AI Psychosis Edition—When Code Writes Code and Breaks Itself

Engineers are starting to report that for some complex systems, AI-generated code changes are now causing more defects than they fix. Last week we talked about the human cost of this explosion, the AI burnout pushing academics out of places like MIT, but today we're seeing the machine side of that same coin: a phenomenon some are calling "AI psychosis." It’s the idea that our own creations are becoming so complex, so layered with AI-generated code, that they're becoming unstable beyond our ability to repair them. This isn't just a theoretical problem anymore. Consultants are now being hired as AI rescue teams, to come in and stabilize systems that have effectively lost their minds.

This is the top discussion on Hacker News today, and it's a big one, because it asks a fundamental question: what happens when the thing we built to solve problems starts creating more than it solves? It’s a moment where the tool starts to look a lot like the problem. That’s the lead story, but the theme of hitting a complexity wall is echoing across the board today. A major thread is digging into the security of open source software. The conversation is coalescing around a new phrase: the "strip mining" era. For years, the mantra was that more eyeballs on the code makes it more secure. But now, with automated tools and a firehose of zero-day vulnerabilities being exposed, that visibility might be turning into a liability.

The fear is that the sheer volume of discovered bugs will scare people away from using open source projects, which… ironically, would reduce the number of eyeballs and make the problem worse. One commenter framed it as a tsunami of bug reports that we just have to weather, hoping things plateau and return to a manageable cadence. But the question is whether the ecosystem can handle the flood in the meantime. Then we have a very different, very physical kind of problem from the world of autonomous vehicles. It turns out, self-driving cars have a huge blind spot: they can’t reliably tell the difference between a harmless patch of wet pavement and a dangerously deep puddle of water.

Which, to be fair, is a mistake humans make all the time. But when you’re programming a two-ton robot, you can’t just hope for the best. The proposed solution is almost charmingly low-tech. One engineer, who worked on the DARPA Grand Challenge back in 2005, mentioned their vehicle had a simple water sensor. It would literally dip a toe in, so to speak, to check the depth before proceeding. It’s a reminder that sometimes the most futuristic problems require solutions that are incredibly grounded and physical. We’re building these sci-fi machines, but they might need the robot equivalent of galoshes. And finally, a little bit of light from the "Ask Hacker News: What are you working on?" thread.

It’s always a great snapshot of where independent developers are focusing their energy. This month, a lot of it is about focus itself. One standout is a macOS app called Drawers. The creator explained that native interfaces just mix all your projects together, creating constant distraction. So they built a tool that creates project-specific docks and spaces. You open your "Video Editing" drawer, and only your video apps, files, and notes are there. You switch to your "Coding" drawer, and everything else vanishes. It’s a direct response to the digital noise we’re all drowning in. It feels like for every big company building systems of overwhelming complexity, there's a solo developer building a tool to help us find a little bit of quiet.

Okay, let’s go back to that lead story, because "AI psychosis" is a term that really sticks with you. The quote that kicked off the entire discussion is worth hearing in full. A user wrote: "Purely AI written systems will scale to a point of complexity that no human can ever understand… and eventually AI changes will cause on average more defects than they close and the whole system will be unstable." This isn't just about buggy code. We've had buggy code forever. This is about a system that is actively, continuously, and automatically making itself worse. The defect closure rate goes down, the cost in tokens and compute to even try to fix a bug goes up, until you reach a tipping point.

The system becomes a net-negative. It breaks more than it builds. So where have we seen this before? This is the core question. My first thought was the giant, legacy mainframe systems from the seventies and eighties. You know, the sprawling COBOL codebases that run a bank or an airline. Those systems are famously complex. They grew over decades, with layers upon layers of patches and fixes. No single person understands the whole thing. There’s a small priesthood of engineers, often nearing retirement, who are the only ones who know how to maintain them. One commenter made this exact point, saying, "Humans who have been writing systems like that for many years know how to maintain and modify them successfully." The argument is, this is just a new version of an old problem.

We just need more "elbow grease," more experienced engineers who aren't afraid to get their hands dirty. And that analogy holds up, to a point. The shape of the problem is similar: a system has exceeded the cognitive capacity of a single human maintainer. But here’s where the analogy breaks, and this is the part that’s genuinely new. Those old COBOL systems? They're static. They're complicated, yes, but they don't grow on their own. The complexity is a known, albeit massive, quantity. The AI-driven system is different. It’s generative. It is actively writing its own future, creating new pathways, new functions, new layers of abstraction, all without direct human intervention.

It’s the difference between exploring a vast, ancient, un-mapped ruin… and exploring a ruin that is simultaneously building new corridors and bricking up old ones around you while you explore. That’s a fundamentally different challenge. The proposed solution from the original poster is also telling. They say the only way out is a "clean room" rebuild. You don't try to fix the psychotic system. You can't. It's too far gone. Instead, you put it in a box, you observe its behavior from the outside, and you start over. You try to distill its core design, its original purpose, and you build a new, simpler, sane version from scratch. You're not debugging code; you're performing an exorcism.

You’re trying to save the soul of the application while letting the body die. This also connects to another idea that was floating in the comments—the idea of stacked sigmoid curves. We love to talk about exponential growth in AI, this line that just goes straight up. But real technological progress doesn't look like that. It looks like an S-curve. It starts slow, then accelerates rapidly, and then it flattens out. A plateau. To get another exponential-looking curve, you need a new breakthrough to start a new S-curve on top of the old one. What we might be seeing with AI psychosis is the natural plateau of our current approach. We’ve pushed generative code as far as it can go without a new paradigm for management and verification.

We’re hitting the ceiling of one S-curve, and we don't know what the next one looks like, or if it’s coming at all. So what does this all set up for us? We have AI systems becoming too complex to manage. We have open source security buckling under the pressure of too much information. We have autonomous cars stumped by a puddle of water. And in the middle of it all, we have developers building clever little apps to help us simply focus on one task at a time. There’s a pattern here. For the last decade, the primary question in tech has been about capability. Can we do it? Can we build a model that writes code? Can we build a car that drives itself? The answer, increasingly, is yes.

But we're now entering an era where the primary question is shifting from capability to sustainability. It's not "can we build it?" anymore. It's "can we maintain it?" Can we secure it? Can we control it? Can we even understand it? The struggles we're seeing this week aren't failures of ambition. They're consequences of success. We've built systems so powerful and complex that our old methods of management are breaking down. The rescue consultants for "AI psychosis," the debates over open source visibility, the water sensors on a self-driving car—these are the early, ad-hoc responses to a new class of problems. We are moving from the age of construction to the age of maintenance.