In my startup, I am currently in consideration for doing this exact thing. The interesting part is it's not really the AI that's causing the issue. It's the ease of my developer to make a mess, either with messy code or feature bloat.
After figuring out the exact product we need with some very quick development cycles with AI, we now have some problems that I can't keep under control because of AI. So, currently under consideration to rewrite the core functionality without AI so we can keep it simple, understandable and slower to change.
The interesting part is that AI could do this, but managing developers with AI has become very difficult to get them to slow down and build stable simple things.
EDIT: I found it interesting how negative the comments were and I thought it would be easier to add context to the root.
My developers wanted to use AI. I was a skeptic for several reasons. But I agreed that it was worth committing to and seeing what came of it. And all in all, the rapid prototyping is excellent.
However, as parts of the software are past the point of rapid prototyping, I talked with my team and everyone agreed that the core piece deserved a re-factor/re-write because of the mess it was. Classic tech debt of deprecated code hanging around and prototype features with patchwork additions that now are a poor way of executing the intended function.
So, we agreed to do a significant re-factor and did. However, quickly it got incredibly messy again. Partially due to AI using git to look at prior commits and add things back.
And so, it was essentially an unsuccessful refactor and we find ourselves with the same issue. They also agree that using AI is the problem here because it's very easy to get new things. And the temptation to solve a problem quickly is high (I am stressing the opposite, to go slow), but it can be hard to say no to a co-worker who isn't dealing with the technical issues.
So, both myself and my developers agree that AI is the issue in creating a messy that has resulted in unstable code. The reason I say that I am considering this choice is because while they acknowledge the issues it's causing, they aren't excited about returning to coding without them. Which is also why I'm considering the right move here, since the goal is both a happy team and well functioning software.