Agents are an org design problem
A standing team of coding agents, each with a named desk and a real schedule. One boundary has never moved, no matter how good the model got.
The question I kept getting wrong for too long: is this a technical problem or an organizational one? I treated model choice and context windows as the lever. They weren't. What compounds is how work accumulates, and that's an org design question. I run a standing team of coding agents, each with a named desk and a real schedule. Agents own everything reversible — code, drafts, analysis, debugging. A human makes every call touching money, identity, or anything that can't be undone. That boundary doesn't move; the moment it moved once, it stopped being a rule and became negotiable, which makes it useless. The insight that took longest to land is about trails: an agent that solves a bug and leaves nothing behind isn't much better than a contractor who leaves. The bug has to become a document with enough context that the next agent treats it as a constraint, not a mystery to re-derive. Compounding happens in the trail, not the solving. Second insight: generation and review can't be one loop. The model that wrote the code is a poor judge of its own failure mode, so review has to be structurally separate — agents checking rules, humans making calls. Same models, different desk structure, and the output quality moves a lot.