LLMが書いたタスク分解は、誰が検証しているのかThe article argues that having LLMs both decompose and verify tasks in…

A recurring pattern has emerged in how teams run AI coding agents in parallel: a large task is handed to a large language model to break down, and the resulting subtasks are distributed across individual agents that work simultaneously. This blog post from Zenn raises a question that is easy to overlook in that workflow — who, exactly, guarantees that the decomposition itself was correct? The answer matters because an entire fleet of agents can execute flawlessly against a plan that was flawed from the start.

In many orchestrators, the author notes, the answer to that question is the LLM itself. The model decomposes the work, the model reviews the plan, and the model decides what to run next. Every checkpoint in the loop is staffed by the same kind of component. The article's central argument is that using an LLM to verify another LLM's output is close to sampling from the same probability distribution a second time. Because both the generation and the verification draw on the same training data, the same biases, and the same failure modes, errors that are correlated tend to remain correlated. A mistake that the first pass was inclined to make is precisely the kind of mistake the second pass is inclined to wave through.

This is a familiar problem in other contexts. Ensemble methods in machine learning only reduce error effectively when the individual estimators fail independently; if they all fail in the same way, averaging their votes buys little. The same logic appears to apply to what is often called "LLM-as-a-judge," where one model scores or critiques the output of another. The technique is popular because it is cheap, fast, and easy to wire into an agent loop, but it shares the underlying weakness that its judgment is drawn from the same well as the thing it is judging.

The post's proposed direction, building on a previous article, is a deterministic validation layer — a checking stage whose behavior does not depend on a sampled model output and therefore does not share the model's failure distribution. In software engineering, deterministic checks are well established even if they are rarely framed this way in agent design. Compilers reject code that does not type-check, test suites either pass or fail, linters flag defined violations, and schema validators confirm that structured output conforms to an expected shape. None of these tools are creative, and that is precisely the point: their verdicts are reproducible and independent of the model that produced the artifact under review.

Applied to task decomposition specifically, a deterministic layer would aim to confirm properties of the plan rather than trust the planner. That could include checking that subtasks cover the original requirement without gaps, that dependencies between subtasks form a valid ordering, that interfaces the agents will rely on actually exist, or that the combined result can be assembled and tested. The article appears to argue that without some such external anchor, an orchestration system is essentially grading its own homework, and correlated errors will slip through undetected no matter how many review passes are added.

The context here is a broader industry push toward autonomous, multi-agent coding systems. Frameworks such as LangGraph, AutoGen, and CrewAI, along with various orchestrator patterns, have made it straightforward to spin up parallel agents, and vendors increasingly market agents that can plan and execute long-running engineering work with limited supervision. As these systems take on larger tasks, the reliability of the initial decomposition becomes a bottleneck that is easy to ignore because the failure is silent — the plan looks reasonable, the agents look busy, and the defect surfaces only later.

The piece does not claim that deterministic checks can replace LLMs, nor that they can validate every kind of plan; many aspects of a decomposition are genuinely open-ended and resist formal specification. Its narrower and more defensible point is that verification should not come from the same source as generation. Where a property can be checked deterministically, doing so is likely to catch a class of errors that model-on-model review, by its nature, cannot.