Loading today’s stories
Build1 distinct publisher3 min readUpdated
A new tool diffs a Git checkpoint instead of trusting a coding agent's summary, with no LLM in the analysis path. The baseline is the clever part; the risk weights are the part still unpublished.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
The checklist is the advertised part. The baseline is the part doing the work. AgentCheck builds its checkpoint by writing the current state into a temporary alternate Git index and calling `git write-tree`, which leaves the developer's real index, working tree and history untouched [14]. According to its author, writing on dev.to, that design exists so pre-existing mess in the tree - staged edits, unstaged edits, tracked deletions, untracked files that are not ignored - becomes part of the baseline rather than being charged to the agent [15]. Attribution, not safety, is the win there.
The scoring is where the published detail runs out. In the example output, a single dependency-change finding produces a score of 3 [8], and the bands are 0-2 LOW, 3-6 MEDIUM, 7+ HIGH [12]. So one dependency change is worth at least three points and lands one step inside MEDIUM, which is enough to return REVIEW RECOMMENDED [18]. Eight signal categories are listed [19], but the post gives the band thresholds without the per-signal weights [20]. For a tool whose entire pitch is that the same repository state yields the same result [9], the weights are the interesting number, because they decide whether a migration plus a deleted file clears the HIGH line or sits comfortably in the middle.
The scope boundary follows from the mechanism. The comparison runs against Git-visible, non-ignored state [5][15], so a credential written into an ignored `.env`, or anything the agent did outside the repository, never enters the diff [17]. That caps the possible-secrets check at secrets that made it into files Git can already see.
What the tool refuses to claim is the honest part. Its author says it cannot know whether the code is correct, and the aim is only to point at the parts of a change set that deserve attention before a commit [13]. He also says he still runs `git status`, `git diff` and `git diff --stat` by hand [4]. So this is a structured version of a checklist he was already running after every agent task [3], and the reason it exists is that the agent's own "done, implemented the requested changes, updated the tests" message is an account rather than an artefact [2]. The author considered the obvious alternative, a second model reviewing the first, and deliberately rejected it in favour of deterministic checks between the agent and the human [10].
That is the transferable idea for anyone handing repo-wide work to Codex, Claude Code or Cursor [6]: the review layer's value comes from having a different provenance than the thing it reviews. A summary is generated by the same process that made the changes. A tree comparison is not.
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
AgentCheck does not use an LLM for its analysis; the checks are deterministic and, given the same repository state, it should produce the same result.
The author says he did not want the verification layer to be one LLM reviewing another, and wanted a smaller predictable chain: coding agent, actual Git-visible changes, deterministic checks, human review, commit.
AI coding agents now handle large tasks including refactoring, adding features, updating dependencies, modifying configuration, creating migrations and touching files across an entire repository, according to the author of AgentCheck.
The author writes that a coding agent typically returns a reasonable summary such as "Done. Implemented the requested changes, updated the tests, and cleaned up the affected code", which he considers useful but not enough to commit without checking.
After an agent finishes, the author says he manually checks which files changed, whether files were deleted, whether configuration changed, whether dependencies were added or updated, whether a migration was introduced, whether anything resembling a secret appeared, whether related tests changed, and whether the change set is larger or riskier than expected.
The author notes Git already supplies the raw information via git status, git diff and git diff --stat plus inspection of individual files, and says he still does that.
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.
Mechanism described in detail, verified by no one but the author
The cluster is one self-published launch post by the tool's creator. Its strength is specificity: the checkpoint is described down to the temporary alternate index and git write-tree, the baseline semantics for pre-existing staged/unstaged/deleted/untracked state are stated, the eight signal categories and the 0-2/3-6/7+ bands are published, and a worked sample output is shown. Its weakness is that nothing is independently reproduced: determinism is asserted rather than demonstrated, no false-positive or false-negative measurement exists, per-signal weights are undocumented, and the Git-visible-only scope leaves ignored files outside the secrets check without the post acknowledging it.
Shipped and installable, no usage signal at all
Adoption evidence stops at availability. The tool exists as a published npm CLI and a VS Code Marketplace extension under Apache-2.0, which is more than a blog-post prototype, but the only disclosed user is the author, and the deliberate absence of any backend or telemetry means no usage figure exists to cite. No installs, downloads, stars, teams or external deployments appear in the cluster.
Mostly restrained, with a transparency claim that outruns the documentation
The post is unusually disciplined for a launch story: it explicitly refuses to claim correctness, states that scope is intentionally limited, and positions the output as an attention pointer before a commit. Two things still lean ahead of the evidence. The risk score is called transparent while the per-signal weights that produce it are unpublished, and the deterministic verification framing sits on top of a diff that structurally cannot see ignored files such as .env or anything changed outside the repository - so the possible-secrets signal covers less than the language implies. The verdict language is also easy to over-trust when a single dependency bump alone reaches MEDIUM / REVIEW RECOMMENDED.
Creator marketing his own launch, but low extractive incentive
Every claim in this cluster comes from the person who built and distributes the tool, in a post whose function is to drive installs of his npm package and VS Code extension - a clear promotional incentive, and the reason the favourable framing of determinism and transparency should be discounted. Offsetting factors are real: the project is Apache-2.0 open source, there is no paid tier, account, backend or telemetry disclosed, and the post volunteers scope limits and an explicit non-correctness disclaimer, which are not the moves of a maximally promotional launch.
Single self-reported source, specific enough to be falsifiable later
One publisher, one author, no corroboration - which caps confidence regardless of how detailed the account is. What the claims describe is internally consistent and technically plausible for anyone familiar with Git's index and write-tree behaviour, and the numbers quoted (file counts, score 3, band thresholds, eight categories) are precise rather than hand-waved, so the descriptive claims about what the tool reports are reasonably safe. Confidence in the operational claims - determinism in practice, useful signal-to-noise, real-world coverage of secrets - is materially lower until someone other than the author runs it.
build
Resend is selling to the agent and handing the humans free templates1 distinct publisher
build
Waku 0.1.0 bets the product is the control plane, not another coding agent1 distinct publisher
build
Spline V2 turns the 3D editor into an endpoint, with the desktop app as the only door1 distinct publisher
build
Your Coding Agent Reads .env, And .gitignore Was Never The Control1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 23, 2026