(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...

An end to buggy web apps