lw1981

I’ve run into this in debugging too. I had one case where the model fixed a bug in concurrent execution code by basically making it sequential. So yes, the bug disappeared, but only because it removed the concurrency property instead of actually solving the underlying issue.

That kind of thing has made me much more cautious about judging these tools purely by whether the immediate error went away.

I’ve been wondering whether this is less a “model got worse” problem and more an constraints problem.

If the files and task boundary are already known, letting the system keep exploring/replanning inside one accumulating context seems like the wrong default. It makes the agent pay over and over to rediscover what it should already know, and every extra turn increases the chance it wanders into a different approach.