Actual developer: Hm, download button's not working. What's the href/onclick doing? Oh, there isn't one. Fixed.
Whatever this shit is: Thing not work, need more AI
(OP) I completely agree! AI is amazing at writing web apps that are full of bugs, but it also gives us what we need to turn that completely around. That's what we're trying to make happen...
The code I have dealt with from AI tends to be rather convoluted for the problems at hand and then become even more difficult to maintain. It has a place but I have been seeing it make code more difficult to understand, not less.
Convoluted code is definitely a problem, I don't think it's unique to AI though. It also becomes more manageable with a time travel debugger as the actual behavior is easy to understand.
Yep. I see it myself, both in other people's code, and our own. The _default_ behavior is a tendency to pile slop on slop, make poor architectural choices, slap bandaids on edge cases without considering the full ramifications, etc. This is more true if there isn't oversight or feedback, and also depending on model quality.
On the flip side: I personally use a strongly human-in-the-loop AI dev workflow [0]. Going back and forth on how much of that code I review myself (and I've found that AI code review frankly does a better job than _I_ do most of the time :) ). But, between staying hands-on, and the ongoing improvements in models, I've seen that the code my own agentic dev sessions produces is actually pretty high quality, and I've been able to clean up a lot of low-quality slop from unmonitored agent sessions. I've also been able to build some pretty major features from scratch and even execute massive migrations with excellent results, again by having me drive the work.
I actually just got done shipping Redux Toolkit 2.14 [1] with a massive set of bug fixes, and almost all of those were found by my agent researching the already-mature RTK codebase, at my direction, and identifying existing logic flaws or weaknesses. Once we knew what those bugs were, we could fix them.
Which, honestly, is the point of the blog post, of Replay QA as an automated testing product, and of Replay as a company in the first place.
Once you know what a bug _is_ and why it happens, fixing it is usually fairly straightforward. _Finding_ it is the hard part.
I've given a conf talk the last few years on "Debugging Software" [2]. One of the main points I make is that no one is _taught_ how to debug - we figure it out on the job as we go, because we have to ship. It's part of the job. But few people like doing it, and most people just want to slap in some console logs and call it a day. Very few people even use existing graphical debuggers (VS Code, Chrome DevTools, etc).
We built a time-travel debugger. The original idea was: make a DVR-style recording of a bug happening once, then you can dive in as deep as you need to investigate. Originally, that was supposed to be a human using the Replay DevTools UI - browser devtools with time travel debugging features built in. It's awesome, I wish I'd had it much earlier in my career :) But we found most people didn't want to spend time doing it themselves.
Earlier this year we shipped Replay MCP, which gives agents the same time-travel debugging capabilities: see hit counts for any line of code, dynamic logpoints and evaluations for every time a line of code ran, see the DOM tree or React component tree at any point in time. I built most of the React analysis features and MCP tools myself, based on my years of experience in the React ecosystem and maintaining Redux.
So, today you _could_ make a Replay recording of your app, point your agent at the MCP, and have it investigate. I've done that, and wrote some blog posts about how that helped my own agent find bugs in React itself and Next.js apps [3] [4]. I've seen my agent nail a bug from a recording on someone else's machine in <10min, starting from scratch.
We've productized that as Replay QA, so that you don't have to do any of the recording or setup - just point Replay QA at your app and repo and we do all the site analysis and recording and bug root cause investigation ourselves. Essentially, encoding our own expertise as debuggers, so you get the benefits [5]
So, back to the original point. Yeah, AI tends to crank out bad code by default, that code is buggy. We can't help your agent choose a better architecture. But we can help identify the bugs proactively, identify the root causes, and suggest solutions, based on the actual runtime behavior of the app. Up to you to get your agents to write _better_ code, but we can give your agent what it needs to fix the bugs it wrote :)
Is this just a promotion post for their "Replay QA™" feature?
It boils down to "other products find the issue and leave the root cause + fix to your agent, our product finds the issue + root cause and leaves the fix to your agent".
Who says I want your agent to root cause? Other products already give me the repro steps, video, trace, network logs, etc, and my agent is in a much better position in terms of context and setup to find the root cause and proper fix.
If you're happy with your agent's performance using surface level o11y to track down issues then that's fine. This is what pretty much the entire industry is doing and it does usually work! QA focuses on root causes because it can look through the app's entire execution and provide evidence so your agent doesn't need to guess when figuring out what the fix is. That guesswork is what we're trying to eliminate, for when the surface level stuff doesn't clearly point at the problem.
Here is my crazy list of ideas for less buggy web apps:
1) care
2) understanding why a change is made/needed before making it
3) deleting code
4) simplifying and removing unneeded features
Makes me smile, seems ai written too. Agents will never fix this mess, it's upon us. But not in the way you're thinking. Asking agents to fix the mess they've been trained on, that they work on and they're made of it's just blindness utopia. We "just" need to part ways with current platforms(talking to you web) and build better abstractions and paradigms. The web plarform as is can't be saved anymore especially from us. It says a lot that many people get excited for a damn dialog html feature that we needed 20 years ago and it's also uncomplete
Agents that are blind to understanding the problem they created will definitely not be able to fix it. Our argument is that we can fix that blindness with better observability. For better or for worse, even if the code is messy, if an agent can see what is going on it can keep things together and get the app into working shape. 100% human written too btw...
I actually think it would go entirely different way, since more and more 'ordinary' users would delegate whatever they need to use app for to 'their' agent instead of using app directly.
Agents have infinite patience, and they would go churn through most horrible buggy UIs out there to eventually achieve the goal, which is even more ironic, given that those UIs would be done by same agents in the first place.
I think AX is just as important in that case though, as even a patient agent will make mistakes and will have a lot more trouble getting things done right when using a buggy app.
There's an opportunity here to bend things towards quality and efficiency moreso than mere volume of code. The agent has to be able to effectively repair and maintain what it has been building though.
AI can fix a bug just from a description and logs. I have never seen replication to be an issue. Replication was more important for human bug fixing as you needed to be able to tinker with it.
Depends on the harness and the requirements right? It will infer meaning that regresses to the mean but you can likely feed it the requirements if you built the harness right and thought things through.
Nothing about intent. A lot of bugs are correctly implemented but do the wrong thing. Actually in my experience these far outweigh the classic code bugs when it comes to web apps.
I think that is the interesting problem to solve (and would have the highest user impact)
What sort of bugs do you have in mind? From our perspective there are many kinds of bugs that inhibit UX (and AX) but they can be subtle issues like poorly designed flows. It's hard for an agent to notice or understand these but they are serious problems and we're trying to surface these more readily.
Actual developer: Hm, download button's not working. What's the href/onclick doing? Oh, there isn't one. Fixed. Whatever this shit is: Thing not work, need more AI
This is really funny to read, as I have encountered way more bugs in software in the past year than ever.
Yep, and web apps seem to be the worst offenders.
(OP) I completely agree! AI is amazing at writing web apps that are full of bugs, but it also gives us what we need to turn that completely around. That's what we're trying to make happen...
Great, the thing that caused so many massive new problems for us all is now being sold to us as the solution to the problems it itself created.
The code I have dealt with from AI tends to be rather convoluted for the problems at hand and then become even more difficult to maintain. It has a place but I have been seeing it make code more difficult to understand, not less.
I'm sure all commercial agents have a system instruction that says "make the code hard to follow" to make sure you keep sending those token$$$
Convoluted code is definitely a problem, I don't think it's unique to AI though. It also becomes more manageable with a time travel debugger as the actual behavior is easy to understand.
(Replay engineer and Redux OSS maintainer)
Yep. I see it myself, both in other people's code, and our own. The _default_ behavior is a tendency to pile slop on slop, make poor architectural choices, slap bandaids on edge cases without considering the full ramifications, etc. This is more true if there isn't oversight or feedback, and also depending on model quality.
On the flip side: I personally use a strongly human-in-the-loop AI dev workflow [0]. Going back and forth on how much of that code I review myself (and I've found that AI code review frankly does a better job than _I_ do most of the time :) ). But, between staying hands-on, and the ongoing improvements in models, I've seen that the code my own agentic dev sessions produces is actually pretty high quality, and I've been able to clean up a lot of low-quality slop from unmonitored agent sessions. I've also been able to build some pretty major features from scratch and even execute massive migrations with excellent results, again by having me drive the work.
I actually just got done shipping Redux Toolkit 2.14 [1] with a massive set of bug fixes, and almost all of those were found by my agent researching the already-mature RTK codebase, at my direction, and identifying existing logic flaws or weaknesses. Once we knew what those bugs were, we could fix them.
Which, honestly, is the point of the blog post, of Replay QA as an automated testing product, and of Replay as a company in the first place.
Once you know what a bug _is_ and why it happens, fixing it is usually fairly straightforward. _Finding_ it is the hard part.
I've given a conf talk the last few years on "Debugging Software" [2]. One of the main points I make is that no one is _taught_ how to debug - we figure it out on the job as we go, because we have to ship. It's part of the job. But few people like doing it, and most people just want to slap in some console logs and call it a day. Very few people even use existing graphical debuggers (VS Code, Chrome DevTools, etc).
We built a time-travel debugger. The original idea was: make a DVR-style recording of a bug happening once, then you can dive in as deep as you need to investigate. Originally, that was supposed to be a human using the Replay DevTools UI - browser devtools with time travel debugging features built in. It's awesome, I wish I'd had it much earlier in my career :) But we found most people didn't want to spend time doing it themselves.
Earlier this year we shipped Replay MCP, which gives agents the same time-travel debugging capabilities: see hit counts for any line of code, dynamic logpoints and evaluations for every time a line of code ran, see the DOM tree or React component tree at any point in time. I built most of the React analysis features and MCP tools myself, based on my years of experience in the React ecosystem and maintaining Redux.
So, today you _could_ make a Replay recording of your app, point your agent at the MCP, and have it investigate. I've done that, and wrote some blog posts about how that helped my own agent find bugs in React itself and Next.js apps [3] [4]. I've seen my agent nail a bug from a recording on someone else's machine in <10min, starting from scratch.
We've productized that as Replay QA, so that you don't have to do any of the recording or setup - just point Replay QA at your app and repo and we do all the site analysis and recording and bug root cause investigation ourselves. Essentially, encoding our own expertise as debuggers, so you get the benefits [5]
So, back to the original point. Yeah, AI tends to crank out bad code by default, that code is buggy. We can't help your agent choose a better architecture. But we can help identify the bugs proactively, identify the root causes, and suggest solutions, based on the actual runtime behavior of the app. Up to you to get your agents to write _better_ code, but we can give your agent what it needs to fix the bugs it wrote :)
- [0]: https://blog.isquaredsoftware.com/2026/05/ai-thoughts-part-2...
- [1]: https://github.com/reduxjs/redux-toolkit/releases/tag/v2.14....
- [2]: https://blog.isquaredsoftware.com/2023/06/presentations-debu...
- [3]: https://replay.io/blog/replay-time-travelogue-how-replay-mcp...
- [4]: https://replay.io/blog/replay-time-travelogue-improving-nadi...
- [5]: https://replay.io/blog/mark-erikson-on-replay-qa-from-time-t...
Do you have anything to contribute to this community that isn't self promotion spam?
I can even recognise the AI bugs now - like randomly broken buttons and wierd unreadable text that no normal developer would release.
Is this just a promotion post for their "Replay QA™" feature?
It boils down to "other products find the issue and leave the root cause + fix to your agent, our product finds the issue + root cause and leaves the fix to your agent".
Who says I want your agent to root cause? Other products already give me the repro steps, video, trace, network logs, etc, and my agent is in a much better position in terms of context and setup to find the root cause and proper fix.
If you're happy with your agent's performance using surface level o11y to track down issues then that's fine. This is what pretty much the entire industry is doing and it does usually work! QA focuses on root causes because it can look through the app's entire execution and provide evidence so your agent doesn't need to guess when figuring out what the fix is. That guesswork is what we're trying to eliminate, for when the surface level stuff doesn't clearly point at the problem.
Here is my crazy list of ideas for less buggy web apps: 1) care 2) understanding why a change is made/needed before making it 3) deleting code 4) simplifying and removing unneeded features
Interesting. What harness could I use for 1? Be concise please, I don't have a lot of time.
Makes me smile, seems ai written too. Agents will never fix this mess, it's upon us. But not in the way you're thinking. Asking agents to fix the mess they've been trained on, that they work on and they're made of it's just blindness utopia. We "just" need to part ways with current platforms(talking to you web) and build better abstractions and paradigms. The web plarform as is can't be saved anymore especially from us. It says a lot that many people get excited for a damn dialog html feature that we needed 20 years ago and it's also uncomplete
Agents that are blind to understanding the problem they created will definitely not be able to fix it. Our argument is that we can fix that blindness with better observability. For better or for worse, even if the code is messy, if an agent can see what is going on it can keep things together and get the app into working shape. 100% human written too btw...
I actually think it would go entirely different way, since more and more 'ordinary' users would delegate whatever they need to use app for to 'their' agent instead of using app directly.
Agents have infinite patience, and they would go churn through most horrible buggy UIs out there to eventually achieve the goal, which is even more ironic, given that those UIs would be done by same agents in the first place.
For humans UX is already dead.
I think AX is just as important in that case though, as even a patient agent will make mistakes and will have a lot more trouble getting things done right when using a buggy app.
There's an opportunity here to bend things towards quality and efficiency moreso than mere volume of code. The agent has to be able to effectively repair and maintain what it has been building though.
And it will all be manipulated to increase token consumption as far as possible, to the provider’s benefit.
Vibe coder sounds more legitimate than bug breeder.
AI can fix a bug just from a description and logs. I have never seen replication to be an issue. Replication was more important for human bug fixing as you needed to be able to tinker with it.
“Observability” is one of my least favorite buzzwords of the past year. It describes nothing new, aside from a general sense of AI-ness.
But can it read the minds of developed to know what the intended behavior is, or even if a bug, what the desired fix is?
Depends on the harness and the requirements right? It will infer meaning that regresses to the mean but you can likely feed it the requirements if you built the harness right and thought things through.
And now we are going to have to deal with this animal.
The "AI Bugfixer Extraordinaire"..
Sigh, do us all a favor and go back into whatever crack you crawled out of.
Nothing about intent. A lot of bugs are correctly implemented but do the wrong thing. Actually in my experience these far outweigh the classic code bugs when it comes to web apps. I think that is the interesting problem to solve (and would have the highest user impact)
What sort of bugs do you have in mind? From our perspective there are many kinds of bugs that inhibit UX (and AX) but they can be subtle issues like poorly designed flows. It's hard for an agent to notice or understand these but they are serious problems and we're trying to surface these more readily.