After requirements and screens, I pushed myWiki with almost no review. then the codebase was already fat
B1 through B16 landed in a few days. The E, R, and G series went green through /goal and unmanned dispatch loops. The build worked. It did not feel like code I had typed line by line.
This was roughly last week. I did not put a date on the calendar. I was deep in second-wiki cleanup, and myWiki. after requirements and screen layout. was pushed almost entirely unmanned. Only after someone said it was “done” did I open it properly.
There was too much to fix.
Green, but my hands would not move
Unmanned code can pass tests and still feel thin as “mine.” In a 2026-07-04 myWiki session I said that out loud. A lot of the rewrite urge is really the urge to understand.
The problem was timing. By the time I tried to understand it, the project was already large. Requirements had shifted midstream. Changing one line was no longer one line of work.
So more time went into review and reordering requirements than into coding. Wiki cleanup piled up too. The context I had to hold got so big that progress stalled. not because I could not implement, but because I could not decide where to start.
When I wrote about splitting large work into segments, I listed three problems with handing everything over at once: context limits, error inheritance, and the person disappearing from the loop. I had hit the third one myself. discovering “this is not what I wanted” only after the end.
The bottleneck was not generation speed
Dispatch generates fast. Green comes fast. Without mid checks, the next feature stacks on a slightly wrong assumption. Even a small early miss infects everything above it. In the build-plan post I wrote that a wrong contract layer flowing into implementation can cost more to fix than starting over. This time it showed up at product scale.
Fluid requirements make it worse. Every session re-grounds. The same facts get serialized into many documents, and reading cost climbs. That myWiki line about “re-investigating context I already paid for” is the same axis as a long review backlog. The physics of reading a hundred tokens to write one shows up as thrash.
I stopped reading a long review queue as laziness. It is closer to a signal that held state is already past the limit. Then you do not add more implementation. You add a mid-course gate.
Mid-flight review is the gate
I am not throwing away unmanned completion. Requirements and screens, then auto for the rest, still works. Without a human look at segment boundaries, the cost of change later exceeds the cost of making it the first time.
Wiki cleanup is not finished either. After a lot of fiddling I still wonder if the structure needs a rebuild. That is another story. This post only needs one takeaway: without mid review and mid adjustment, unmanned finish becomes debt.
The bottleneck was never a slow model. It was rewinding a codebase that grew without checks.