5 Bug Types That Get Worse Every Time You Let AI Fix Them
Last week, a post blew up on Hacker News: three engineers started a company called Slopfix that specializes in deleting AI-generated code, charging $10,000 a week. Business is so good they can't keep up.
The AI Debugging Death Loop
You've definitely been through this scenario:
Your code throws an error. You paste the error message into the AI. The AI makes a change. You run it — the original error is gone, but a new one appears. You paste that into the AI. The AI changes something else. Another new error pops up.
After three rounds, your code has gone from 1 bug to 5 bugs, and you have absolutely no idea what the AI actually changed.
This isn't your fault. Data analysis of thousands of PRs by Shiplight shows: AI-generated code has 1.7x more bugs than human-written code, and 75% more logic errors. In other words, while "fixing bugs," the AI is very likely creating new ones.
Even more painful — a Sonar survey says 96% of developers don't fully review AI-generated code. The AI made three rounds of changes, you ran it without looking closely, and then found it exploded again.
Now someone is making $10,000 a week cleaning up AI code. This shows the "after-sales cost" of AI debugging has grown large enough to support an entire business.
The following 5 types of bugs only get worse the more you let AI fix them.
Type 1: CSS and Styling Issues
The biggest problem with AI fixing CSS: it can't see the cascade.
You say "this button's margin is wrong." The AI adds margin-top: 20px.
But this button is also used on another page, where the margin was originally correct, and now it's affected too.
You tell the AI again. How does the AI fix it? By adding a higher-specificity selector to override.
After two rounds, your stylesheet has two extra layers of overrides, a bunch of !important, and a completely incomprehensible selector specificity chain.
Why AI can't fix CSS well: CSS has global scope; changing one place affects many. The AI only ever looks at the single spot you point it to. Its fix is always "stack another layer on top" rather than finding the root cause. The more layers stack up, the more only a full rewrite can untangle it.
Fix it yourself: Open DevTools, check Computed Styles to find the rule actually taking effect, fix the root cause, and get it right in one shot.
Type 2: Cross-Component State Bugs
A list page and a detail page share a piece of global state. The user makes a change on the detail page, returns to the list page, and it hasn't updated.
You throw the bug at the AI. The AI adds a useEffect on the list page to re-fetch data.
Great, the data updates now. But now every time you return to the list from any page — including the search page or settings page — it re-fetches. The API gets hammered.
You tell the AI "requests are too frequent." The AI adds a debounce. Now the data updates sometimes and doesn't update other times, depending on whether you switch pages fast enough.
Two rounds of fixes = one bug becomes three bugs.
Why AI can't fix state bugs well: The root cause of a state bug is usually not in the component reporting the error, but upstream in the data flow. The AI sees "this component's data is wrong" and its fix is "let this component fetch its own data" — treating the symptom, not the cause. Every time it treats a symptom, it adds one more data flow path, and system complexity rises exponentially.
Fix it yourself: First map out the data flow — which component reads, which component writes, how many layers it passes through. The fix point for a state bug is at the data source, not at the display endpoint.
Type 3: Bugs That Only Appear in Specific Environments
A bug is reported in production, but you can't reproduce it locally.
You throw the error log at the AI. The AI says "maybe a null check is missing" and adds a ?. for you.
You deploy it, and production still throws the error. Because the problem was never about null values — it's that an environment variable has a different value in production than in development.
You throw the new error at the AI. The AI guesses another cause and changes another spot.
This is the most dangerous scenario for AI debugging: it's guessing.
The AI doesn't have your production environment, your logging system, or your monitoring dashboards. It can only "speculate" on the cause based on the few lines of error message you give it. And the root cause of environment-type bugs is usually at the configuration, network, or permissions level — not at the code level.
Every "speculative fix" from the AI stuffs unnecessary defensive logic into your code. After three rounds, your code is full of ?., try-catch, if (!x) return — and not a single real problem has been solved.
Fix it yourself: First confirm whether it's actually a code bug. Check logs, check monitoring, compare environment differences. If you confirm it's a code issue, give the AI full context (error log + environment info + reproduction steps) before letting it help.
Type 4: Dependency Conflicts
After upgrading a certain package, the project won't run.
You tell the AI. The AI says "try downgrading to version X." You downgrade. That package works now, but another package throws an error — because it depends on a higher version.
You tell the AI again. The AI says "then downgrade that other package too." You downgrade it. TypeScript throws a screen full of type errors.
This is dependency hell, and not only can AI not solve it, it will drag you deeper in.
Why AI can't fix dependency conflicts well: The dependency graph is a web, not a line. Changing one version number can affect dozens of packages. The AI's fix is always "change the version number" — it won't read the changelog for you, and it won't help you determine which major version has breaking changes. Every time you change a version number, the possibility space expands exponentially.
Fix it yourself: First read the changelog and peer dependencies of the package throwing the error. Dependency conflicts aren't solved by "trying version numbers"; they're a problem of understanding the compatibility matrix.
Type 5: Async Timing and Race Conditions
Two API calls are made simultaneously. The one sent later returns first, and the page displays old data.
You tell the AI. The AI adds a loading state. Now the page doesn't flicker, but the data is still wrong — because the root cause of the race condition isn't at the rendering layer, it's at the request layer.
You tell the AI again. The AI adds an AbortController. But it's in the wrong place, and sometimes cancels legitimate requests too.
You tell the AI again. The AI adds a request counter. But the counter isn't cleaned up when the component unmounts — memory leak.
Three rounds later: one race condition bug → becomes race condition + request cancellation anomaly + memory leak.
Why AI can't fix timing bugs well: The AI's thinking is "line-by-line execution"; it's inherently bad at reasoning about "what happens when two things occur simultaneously." Fixing a race condition requires understanding the timing relationships of the entire async flow, not just adding a line of code at one point. Every AI fix is local, but timing problems are fundamentally global.
Fix it yourself: First use the Network panel to clarify the actual request timing. Solutions for race conditions are usually at the architectural level (request cancellation strategy, optimistic updates, version number comparison), not patching inside a single function.
Quick Reference: Should You Fix This Bug Yourself or Let AI Do It?
| Bug Type | Let AI Fix? | Reason |
|---|---|---|
| CSS/Styling | ❌ Fix it yourself | AI can't see the cascade, only stacks overrides |
| Cross-Component State | ❌ Fix it yourself | AI treats symptoms, not causes; data flow gets messier with each fix |
| Environment Differences | ❌ Fix it yourself | AI can't access your environment, can only guess |
| Dependency Conflicts | ❌ Fix it yourself | AI doesn't understand the compatibility matrix |
| Async Timing | ❌ Fix it yourself | AI is bad at reasoning about concurrency |
| Syntax Errors | ✅ Let AI fix | AI's strength, fixes in seconds |
| Type Errors | ✅ Let AI fix | AI is very good at TypeScript type fixes |
| Single-Function Logic | ✅ Let AI fix | Clear inputs and outputs, fixes quickly and well |
| Writing Test Cases | ✅ Let AI write | AI is very good at generating boundary tests |
| Error Message Translation | ✅ Let AI look up | Faster than Google |
Bookmark this table. Glance at it before your next debugging session — some bugs you can fix yourself in 30 minutes, but thrown at AI, they waste half a day and only multiply.
It's Not That AI Is Bad — Debugging Just Isn't Its Strength
What AI is best at is generation — give it a clear requirement, and it writes code quickly and well.
What AI is worst at is diagnosis — give it a vague symptom and ask it to find the root cause, and it can only guess. When it guesses wrong, it keeps fixing in the wrong direction, drifting further and further away.
Slopfix making $10,000 a week cleaning up AI code shows this is no longer an isolated phenomenon — the "after-sales cost" of AI code is becoming a real industry problem.
Rather than letting AI fix something three rounds and make it worse, spend 30 minutes finding the root cause yourself and fix it right the first time.
What's the most absurd "AI made it worse" scenario you've experienced? Tell us in the comments.