Build1 distinct publisher3 min readPublished
One developer's log of a three-day build: an approval gate that printed a confirmation and ran anyway, and a "parallel" executor whose wall clock equalled the sum of its branches.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
`futures::join_all` polls a set of futures on one task, and that is fine until one of them blocks. In Vodou's fan the tool client underneath was not async at all: a blocking stdio write followed by a blocking read, so the first branch held the poll loop and the other two queued behind it [5][6]. Nothing in the type signature objects to that arrangement, which is the developer's own stated lesson: a blocking call inside a future is still a blocking call [15].
The transferable artefact here is not the fix, it is the assertion. Report two numbers for every fan-out: wall clock, and the sum of the branch durations. Three read-only tools on three MCP servers came back at 412ms, 268ms and 83ms, for a wall clock of 770ms against a branch sum of 763ms [8]. Those three branch times add to exactly the reported sum, and the wall clock sat 358ms past the slowest branch, 1.87 times the 412ms it should have tracked [17][18]. A real fan tracks the max [9]. A fake one tracks the sum, and this one had been quietly charging the sum on the multi-intent path since that path shipped [10].
The post-fix run is worth reading carefully, because it is not a speed claim. After each branch got a real thread, wall clock was 633ms against a 1398ms sum, on deliberately heavier branches [11][12]. That is 45 percent of the sum, roughly 2.2 branches' worth of work per unit of wall clock [19]. The bars moved apart. That separation, not the millisecond figures, is what passes or fails.
The approval gate needs the same discipline for the same reason. Its output is not a card, it is the absence of a write somewhere else, and a card that asks and a card that asks and then posts anyway render identical pixels [2]. Whatever screenshot you take, the state you care about lives in the executor, and the assertion has to run against Slack. According to the source, most frameworks will print something before a dangerous call and far fewer actually stop [1] - which means "it showed a confirmation" is a UI observation being sold as a safety property.
Two of the thirty commits in this three-day, fifty-nine-file push exist purely to correct features that had been reporting themselves as working [3][4]. The structural half of the answer is the compiler: one implementation, called by chat, the CLI, the setup wizard and the skill proposer, chosen over the obvious alternative of a TypeScript parser for the interface and a Rust one for the runtime, which is how a plan card ends up disagreeing with the run [14]. The plan card also prints the resolved server and tool on every row, so a mis-resolution is caught while it is still free rather than by a Slack message that should not have been sent [13].
This is one developer's log on one framework, and the gate fix is asserted rather than demonstrated. The two-number test is cheap enough that nobody has an excuse for taking a fan's word for it.
Ranked by verification strength, evidence, and original report placement.
After the fix, wall clock was 633ms against a 1398ms sum of branches, and the second run had heavier branches; before the fix the wall clock tracked the sum, after it tracked the slowest branch.
A card that says "this will post to Slack, approve?" and a card that says the same thing and then posts anyway render the same pixels; the difference only shows up in the executor, which is the part nobody screenshots.
The author spent three days building graph execution into Vodou (a readable recipe format, a plan shown before anything runs, real parallel tool calls, and an approval gate), amounting to thirty commits across fifty-nine files.
If the fan were real, the wall clock would sit near 412ms, the slowest branch.
The plan card carries the resolved server and tool on every row, so a wrong tool resolution is visible while it is still free to fix instead of being discovered by a Slack message that should not have been sent.
The author's stated lesson: async fn in the signature is not the thing that makes code concurrent, and a blocking call inside a future is a blocking call.
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.
Specific self-reported numbers, single unverified source
The mechanism is explained precisely enough to be checkable in principle (join_all polling all branches on one task behind a blocking stdio client) and the post publishes per-branch timings whose arithmetic is internally consistent (412 + 268 + 83 = 763). But everything comes from one first-person dev.to post by the project's own author: no repository, commit range, code excerpt, harness, or second observer. The before and after runs also use different workloads, so the improvement is a change in the wall-clock-to-sum relationship rather than a controlled measurement.
No usage data beyond the author
The supplied source documents one developer shipping code into his own project and measuring it himself. There are no installs, users, downloads, third-party deployments, integrations by other parties, or any external adoption of Vodou or of the compiled-approval-node pattern. The self-reported release and benchmark observations describe the author's own work only, which is not adoption evidence, and nothing in the material supports inferring uptake.
Slightly understated, with one overreaching lede
The body of the post claims less than its evidence would allow: it is a self-incriminating account that names its own shipped defects, publishes numbers that make the author look bad, and explicitly warns that the absolute latencies matter less than the wall-versus-sum relationship. That pulls the gap negative. Pulling back toward zero is the unsupported opening generalization that most agent frameworks warn without stopping, and the absence of any repository or harness to back the commit counts and timings. Net: mildly understated relative to the evidence actually presented.
Author-authored post about the author's own project
The sole source is written by the maintainer of Vodou on a developer-marketing platform, and the post showcases his own recipe format, plan card, single compiler and approval gate — a clear promotional incentive with no editorial layer, fact-check, or opposing voice. The incentive is partly offset because the content's main move is admitting that two shipped subsystems did not work, which is costly to the author's own credibility, so distortion pressure is moderate rather than severe.
Mechanism credible, corroboration absent
Confidence is moderate-low. The engineering diagnosis is internally coherent and consistent with well-known Rust async behaviour, and the published numbers are arithmetically self-consistent, so the technical core is plausible. But the cluster has exactly one publisher and one author who is also the subject, no adoption data at all, and no way to verify commit counts, code, or benchmark conditions. Claims about Vodou's internals are as reliable as its author; the generalization about other frameworks is not reliable at all.
build
TypeScript 7.0 is a build-infrastructure release: re-budget CI, then check your toolchain1 distinct publisher
build
The Slack CLI that skips admin approval keeps live tokens in a file your agent can read1 distinct publisher
build
The only way to prove a contract test can fail is to ship a server that lies1 distinct publisher
security
Sophos: Fake AI Installers Drove 30 of 38 AI-Linked MDR Cases, With Claude the Favourite Costume1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 26, 2026