Build1 distinct publisher2 min readPublished
A logging migration split ten ways broke on the one decision that has to be made once: which channel each script writes to. The repair was a JSON index, not more agents.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
The five instructions handed to each agent are worth reading item by item: find the legacy logging, replace it with the structured logger, use the correct channel, preserve the business logic, finish your assigned files [5]. By the author's own later accounting, most of that is not judgment. Finding legacy calls is a command that prints file and line number [10]. The channel is a pure function of the file path, produced by a generator and validated once into a map [11]. Knowing which files are done is a status field, which is what a JSON file, a database or a task queue exists to hold and what an LLM context is not built for [9]. Preserving business logic is genuine work, but it is local to one file and needs no coordination. Mapped against the mechanisms the author eventually assigns them, none of the five items needs a per-batch opinion [4]. One of them needs there to be exactly one opinion.
That one is the channel. Every script required its own [2]. Uniqueness is a property of the whole set, not of a batch, and an agent holding fifty files [4] can only check those fifty. Two agents can each be locally correct and jointly wrong, and that defect is invisible in any single diff, because it does not exist in a file. It exists in the collection. What the post describes is a model being asked to reconsider naming conventions and uniqueness for every file [11], which is the same authority instantiated ten times over, each copy unable to see what the others decided.
Workflow state fails the same way. Pending, processing, completed, failed, skipped [9] only mean something when one writer owns them. Ten contexts each maintaining their own copy produce ten partial views and no arbiter, and there is nobody to ask which view is current.
Worth saying plainly: the post reports no token counts, no wall-clock comparison and no defect rate from the ten-agent attempt [dx]. The case is structural, not measured. What survives the restructure is that the concurrency did not vanish, it moved. The preprocessing stage still builds an inventory, a set of log locations and a channel map [17], and those are deterministic jobs that can run alongside each other without disagreeing about anything. The logging engine was already written and reachable through a common include path before the migration began [3]. The remaining work was clerical, and clerical work at that volume wants a registry, not a committee.
Ranked by verification strength, evidence, and original report placement.
The author of a dev.to post describes a migration involving roughly 500 scripts, moving legacy logging calls to a newly implemented structured logging engine.
The migration required unique logging channels per script, for tracing and observability through Grafana, Loki, Tempo and Alloy; the example given is ExampleScript.py mapping to example_channel.
The new structured logging engine was already implemented and available through a common include path before the migration work started.
The first plan was to divide the files into batches and give each batch to a mini-model, using ten sub-agents; the diagram in the post shows 50 files per agent.
Each agent received essentially the same instructions: find legacy logging, replace it with the new structured logger, use the correct channel, preserve business logic, and complete its assigned files.
Each agent was also rediscovering the repository, figuring out what needed changing, deciding channel names and tracking its own progress; the author says that repeated work became the real cost.
Follow any of these and your For You feed starts watching them — no settings page required.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
One first-person account, structurally argued, unmeasured
All claims rest on a single dev.to post by one practitioner about one unnamed repository. The internal detail is specific and self-consistent - file counts, agent counts, the five instructions, the index record shape, the preprocessing outputs - which supports the narrative as reported. But nothing is corroborated by a second publisher, no artifact (generator, index, diff) is shown, and the post itself supplies no token, timing or defect data, so the case against fan-out is structural inference rather than measurement.
One self-reported workflow change
The only adoption signal is the author's own disclosure that he replaced the ten-agent fan-out with preprocessing plus a single Claude Code session for this migration. That is a genuine usage datapoint but covers one person and one repository, with no organizational rollout, no user counts, and no indication the pattern was picked up elsewhere. Nothing in the supplied material speaks to broader uptake of either the fan-out or the index.json approach.
Modest tone, generalized from one case
The post makes no product, performance or market claim and is unusually restrained - it explicitly says the single-agent design 'isn't less sophisticated', and it names where sub-agents do pay off. The mild overstatement is scope: the title generalizes to 'How not to use sub-agents' and the argument is framed as a rule for choosing parallelism, while the underlying evidence is one unmeasured migration in which the fan-out's predicted failures are inferred rather than observed. Hence slightly positive rather than aligned.
Individual blog post, no disclosed commercial tie
The source is a personal dev.to post with no vendor sponsorship, product being sold, pricing, or competitive comparison visible in the supplied material. The residual incentive is ordinary practitioner-audience reward - a contrarian 'how not to' framing and a tidy before/after narrative attract engagement, which can favour a clean structural story over reporting messy measurements. No incentive is disclosed either way, so this is scored from what the text shows rather than from any stated interest.
Internally coherent, single-source, unverified
Confidence is limited by the one-publisher, one-author basis and the absence of any measurement, but is not minimal: the mechanics described are technically ordinary and mutually consistent, the reasoning about workflow state and deterministic channel generation is checkable on its face, and the ledger's derived claims follow from the stated design. Treat the pattern as a credible hypothesis about task boundaries, not an established result.
build
An empty Detected fields panel is a Loki capacity incident that has not billed yet1 distinct publisher
build
A Prometheus that had written nothing for hours passed every health check1 distinct publisher
build
OpenTelemetry's maintainers say the helper class you are about to write is the bug1 distinct publisher
build
The prompt never arrived: a Windows batch shim was worth 15 of 24 runs in an agent eval1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 25, 2026