Where This Approach Does Not Work

Three kinds of tasks the method does not cover, and the price of splitting. 👋 I'm Anton — a backend engineer working in PHP/Symfony and Go, currently carving a live PHP monolith into Go services. The last eight parts of this series described one way of handing work to an agent, and every one of them was written from the inside, where it works. This part is the opposite view: the three places I stopped using it, and why. Notes and code: github.com/brilliant-almazov . Maybe you draw the line somewhere else. That's the more interesting conversation, so I'd rather publish my line than pretend there isn't one. The whole method has one foundation Strip away the folder layout, the batches, the waves, the per-package acceptance command, the list of banned phrases — everything I described in the previous eight parts — and one assumption is holding all of it up: The facts are known before the task text is written. Paths. Full type signatures. Names of the primitives that must be reused. Values — error names, queue names, metric names, table names. One acceptance command that runs with no substitution. That's not a nice-to-have; it's the load-bearing wall. The reason an executor is allowed to read at most three named files and forbidden to search the tree is that it doesn't need to: everything it needs is already in the text. Remove the assumption and the whole thing inverts — the executor has to go find things, which is the single most expensive thing it can do, and it pays that cost again on every executor, every time. So the honest question isn't "does this method work?" It's "when is the assumption false?" I know three answers, and they're not edge cases — they're most of what a normal week contains. Case 1 — research tasks The shape: I don't know what needs to be built yet. Not "I know roughly and need to fill in details" — that's a normal task with missing facts, and the fix is to go get the facts. I mean the case where the deliverable itself is the unknown. Which of thr