Loading today’s stories
Build1 distinct publisher3 min readPublished
The post names left-pad at 2fca615, 11 tracked files and 44,229 bytes, and lists the four outcomes that would sink the claim, which is a harder standard than most tool demos set for themselves.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Two substrates are not two routes to the same outcome, which is the reason to run both. On the git adapter, a commit writes a new blob into the object database and moves HEAD, in run 1 from 2fca615 to ef062db, and leaves the bytes of README.md on disk alone [8][9]. `git status` then prints `M README.md`, because it diffs the worktree against the new HEAD rather than the old one [9]. So the falsifier inverts the assertion most demos make: if the git walk changes README.md's worktree bytes, the post is wrong [3]. The fs adapter has no concept of a repo, so it rewrites the working file and the sha256 moves from 662703d6 to 5491b8f2 [10]. Undo therefore has two definitions checked by two invariants, HEAD back at 2fca615 with a clean status on one side, the sha256 back at 662703d6 on the other [11]. An in-process mock server, which is all the walk had been run against until now, cannot produce that distinction [14].
The stage timers do not quite add up, in a good way. The four git stages report 1.247, 0.362, 0.490 and 0.535 seconds, summing to 2.634 against a reported total of 2.662 [5][17]. The fs stages sum to 2.416 against 2.441 [6][18]. Something outside the stage timers costs 28 and 25 milliseconds, which is what measured totals look like. The two substrate totals come to 5.103 against 6.057 including the clone, leaving about 0.95 seconds for fetching left-pad and starting up [21].
The wall-clock bound is the weakest assertion in the set. Thirty seconds against a measured 2.662 is roughly 11x of headroom [19], so it catches a hang and nothing finer. Nothing in the measurement scales with the target, either. The payload is 44,229 bytes across 11 tracked files, about 4KB per file [2][20], and the break stage still costs 1.247s on git and 1.172s on fs [5][6]. A 4KB rewrite does not take a second. That second is process and receipt work: each prove stage checks a commit receipt against a merkle checkpoint, and each verify stage re-checks both receipts in a separate process with no network [23][12]. For the timings to transfer you would need a target of comparable size, comparable hardware, and a build profile you can name; the post identifies the binary only as `target/debug/gx` [13].
The limits are stated where a reader can act on them. The log is translated from a Japanese-language run with timings, hashes and commit IDs unchanged, and only run 1 of 3 is reproduced in full [16][4]. Both break stages record `permit-default=Allow`, so the walk exercises the permitted path and no denial [24]. And the authors write that they did not confirm the local debug binary matches what is currently checked out in the public repo they point at [13]. That is the rare limits section that costs its author something. It also marks the seam in the format: the target is pinned to a commit, the tool is pinned to a path [2][13].
Ranked by verification strength, evidence, and original report placement.
The stated falsification procedure is to clone github.com/stevemao/left-pad at commit 2fca615 (11 tracked files, 44,229 bytes) and run the four-stage walk against it on the git substrate and again on the fs substrate.
The post says it is wrong if any stage fails, if wall-clock for either substrate's four stages exceeds 30 seconds, if the git walk changes the worktree bytes of README.md, or if undo does not restore the exact pre-change sha256 or HEAD.
The authors ran the walk three times; run 1 is reproduced in full and the other two runs' numbers appear only in a table later in the post.
Run 1, git substrate: break 1.247s, prove 0.362s, restore 0.490s, verify 0.535s, with T_git_four_stages=2.662.
Run 1, fs substrate: break 1.172s, prove 0.377s, restore 0.384s, verify 0.483s, with T_fs_four_stages=2.441.
Run 1 reported T_total_incl_clone=6.057, FAILURES=0 and P4_RESULT=PASS.
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 30, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
build
Your meter now runs on someone else's machine: signed receipts, fsync, and failing open1 distinct publisher
build
Once the question needs a cube, you own the parser1 distinct publisher
build
Given one full stop as input, a coding agent mined the shared run record for work1 distinct publisher
build
Five coding agents on one repo is a staffing problem, and worktrees only fix the filesystem1 distinct publisher
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.
Checkable but unchecked
Everything rests on one dev.to post written by the tool's own authors, which is the weakest possible sourcing and simultaneously among the more honest write-ups of its kind: the target commit is pinned, the failure conditions are named in advance, and the untested gap between the debug binary and the public checkout is disclosed by the authors themselves. The commit IDs and sha256 prefixes are third-party checkable; the receipt validity verdicts are not, since no receipt or checkpoint is published. Add the two runs shown only as table rows and the millisecond mismatch between the printed stage times and their totals, and you have a claim built to be verified that nobody has yet verified.
First run off the fixture
By the authors' own account this walk had, until now, only ever met a mock server written for the demo command. One clone of a 44kB repository, run three times on one machine by the people who wrote the tool, is the entire adoption record. No third party, no deployment, no dependent project appears anywhere in this reporting.
Understated by design
The 30-second bar sits over eleven times above the 2.662 seconds actually measured, so the post declares victory against a threshold it was never near — and then spends its longest section on a semantic error it almost made rather than on the speed it beat. Where most tool demos would headline 'sub-three-second verifiable undo', this one leads with instructions for breaking the claim and a confession about the binary. The framing runs behind the demonstration, not ahead of it.
Own tool, own bench
This is a vendor demo in the literal sense: the authors built gx, chose the target, wrote the log format, translated it, and decided which of three runs a reader gets to see. left-pad was picked precisely because it is instantly recognizable, which is a presentational choice as much as a technical one. The disclosures pull the other way and deserve credit — but the incentive to look good is undiluted by any outside voice in this reporting.
Detailed, unaudited
Confidence here is limited by arithmetic, not by suspicion. A single self-published account carries every number; the parts a reader could independently confirm — commit 2fca615 to ef062db and back, sha256 662703d6 to 5491b8f2 and back — are stated crisply enough to trust as reporting, while the receipt verdicts and the two unshown runs sit outside anyone's reach. Nothing contradicts the account; nothing corroborates it either.