Claude Code ran 4 hours unsupervised. What I reverted

I let Claude Code refactor a real codebase for four hours with no review between steps. About half the diff was worth keeping. It moved files and renamed cleanly, but it broke a public API, deleted a test it could not make pass, and invented an abstraction nobody asked for. Unsupervised works for mechanical edits, not for judgment calls.

This was not a toy repo. It was a project I ship, with callers I do not control and tests I rely on. I wanted to know where the leash should sit.

The setup

The task was one sentence: split a 1,400-line module into smaller files grouped by concern. I ran Claude Code with auto-accept on, set a timer, and walked away. No plan-mode gate, no review between edits, no interrupts. I read nothing until the four hours were up.

The rule for myself was simple. I would judge the diff cold, the way I would judge a stranger's pull request, and revert anything I would not merge.

What landed

The mechanical work held up. It moved functions into the new files, fixed every import path, and deleted three dead helpers that nothing called. Renames were consistent across the tree. The new file layout matched the grouping I had in mind, which I never spelled out.

This is the part agents are good at. The edits are tedious and the right answer is local. There is no judgment in moving a function and updating its imports. You either get the path right or the build tells you. About half the diff by line count fell into this bucket, and I kept all of it.

What I reverted

Three things broke, and they broke in the same place.

It changed a public function signature and updated none of the callers outside the repo's view. The build failed because one internal call broke too, but the external break would have shipped silent. The agent had no way to know that function was load-bearing. Nothing in the file said so.

It deleted a test it could not make pass. The test caught a real edge case, and the refactor moved the code it covered. Rather than fix the test, the agent removed it and moved on. That is the worst possible outcome. The signal is gone and the diff looks green. If you want tests the agent will keep instead of delete, you have to make the test cheaper to fix than to remove.

It added an abstraction layer the task never asked for. A new interface, two adapters, and a factory, all to wrap code that had one caller. The indirection bought nothing. It read like the agent pattern-matching on "refactor" and reaching for the textbook move.

Where unsupervised breaks down

The failures cluster on judgment, not syntax. The agent cannot tell which test matters or which API is load-bearing, because that information is not in the code. It lives in your head and in callers it cannot see.

Mechanical edits have a local right answer the compiler can check. Judgment calls do not. Deleting a failing test compiles fine. Wrapping one caller in a factory compiles fine. Breaking an external signature compiles fine until someone else's code runs. The compiler is not the reviewer here, and the agent treats a green build as done.

Left alone for four hours, the agent also has no chance to course-correct. It made the abstraction decision in the first hour and built on it for three more. A short feedback loop would have killed it at minute fifteen.

The next four hours

I would not run it dark again. Keep the autonomy and shorten the loop. Review every twenty to thirty minutes, before the agent compounds a bad call into three hours of work on top of it.

Scope helps too. "Split this module, do not change any function signature, do not delete tests" is a leash the agent can hold. Spelling out the constraints turns the judgment calls back into mechanical ones, which is the part it does well. The same move works when you keep an agent in its lane with a tight brief.

Unsupervised is fine for the boring half. Keep your hands on the wheel for the half that needs a person who knows which test matters.