My understanding is that the main reason splitting up work is effective is context management.
For instance, if an agent only has to be concerned with one task, its context can be massively reduced. Further, the next agent can just be told the outcome, it also has reduced context load, because it doesn't need to do the inner workings, just know what the result is.
For instance, a security testing agent just needs to review code against a set of security rules, and then list the problems. The next agent then just gets a list of problems to fix, without needing a full history of working it out.
How much do you babysit claude, and how much do you just "let it do its thing"?
I haven't had anything as severe as OP, but I have had minor issues. For instance, claude dropped a "production" database (it was a demo for the hackerspace, I had previously told claude the project was "in development" because it was worried too much about backwards compatibility, so it assumed it could just drop the db). Sometimes a file is dropped, sometimes a git commit is made and pushed without checking etc despite instructions.
I'm building a personal repo with best practices and scripts for running claude safely etc, so I'm always curious about usage patterns.
Even in small companies, its important to discuss what the expectations around AI are. In the absence of any further requirements (i.e. assuming privacy is not a major issue, regulatory issues etc), it can be as simple as clearly saying: "You can use AI, but you are ultimately responsible for what you deliver. It is expected you verify the data, test the code, and otherwise validate the responses."
Something as simple as that gives an expectation, without being overbearing to start with.
This is a really important point - my file manager just says "Name" with sorting. So while its not perfectly defined, it doesn't make the promise of saying its alphabetical.
For instance, if an agent only has to be concerned with one task, its context can be massively reduced. Further, the next agent can just be told the outcome, it also has reduced context load, because it doesn't need to do the inner workings, just know what the result is.
For instance, a security testing agent just needs to review code against a set of security rules, and then list the problems. The next agent then just gets a list of problems to fix, without needing a full history of working it out.