Two of today's tools check the agent's work, and two help you follow it.

Whiteboard (MIT, TypeScript and Rust, 923 stars, 34 forks, 439 commits, five human contributors, created August 18, v0.1.2 released September 24) is a desktop app built on a vendored copy of Code OSS, with an SDK and MCP server that let Claude Code, Codex or another agent draw on a canvas while it works. The quickstart is a single request: ask your agent to review the current branch against main and open the result in Whiteboard. What you get is a sequence diagram, an entity-relationship diagram or a quote from the agent's trace, and clicking any part of it opens the code behind it, with VS Code keybindings and LSP. The diff viewer is a separate piece, written in Rust and AST-aware. By default it summarizes large added functions as pseudocode and collapses tests and docs, and a WASM plugin system lets you change those rules. A decision log links the agent's own traces to the requirements you set, so the choices it made without asking are listed in one place.

The Show HN reached about 330 points. The founders said the common workflow is plan, approve, let the agent code, then use Whiteboard to have the code explained. One commenter argued that humans will stop reading implementation-level code soon and that planning is the surface to build for. The founders' answer was that key tradeoffs only show up once there is an implementation, so a plan with no code is hard to review. Another commenter noted the macOS download is 736 MB. The founders agreed and put it down to building on VS Code, with a native rewrite planned. The README lists what does not work yet: you cannot edit files, one review cannot span several repos, and a shared review does not update after it is shared.

Reach for it if you keep approving agent branches you could not explain to a teammate; it replaces the explainer markdown file you ask the agent to write and then read in a plain editor. Delete the habit of reviewing a 2,000-line agent diff line by line in the order the files happen to sort. Tradeoffs: macOS and Fedora builds only; anonymous telemetry is on by default, though the telemetry doc says it excludes code, diffs, paths and prompts and can be turned off; it is a 736 MB fork of an editor you cannot type in yet; and the diagrams are drawn by the same agent whose work they describe.

Critic (hosted, free, from Feyn, launched on Show HN on September 24) is a change-review site plus a plugin for Claude Code and Codex. At set points during the agent's turn, the plugin's hooks ask it to write a narrative of the change: what was true before, what is true after, and the assumptions, decisions and complex blocks a reviewer should look at, along with screenshots and local run instructions. The change shows up at critic.run and through a bundled MCP server, so a reviewer's agent can read the same context. The unusual part is that a reviewer can ask the authoring agent a question. Critic forks the original session to answer it, so the main thread keeps working, and the fork has its write tools stripped: it can answer questions about the change, but it cannot act on the author's computer. The demo change on the homepage is one of Critic's own PRs, and it shows questions waiting for an author device to come online, because session transcripts stay on the machine that created them.

The HN thread was small (8 points), but its first question is the important one. A commenter asked what stops the narrative from having the same problems as the code, since the same agent writes both. The founder said the plugin only nudges the agent at boundaries and ships skills for writing a concise narrative. A second commenter pointed out that format and word-count checks measure the shape of a narrative, not whether it matches the diff, and suggested a separate session that lists the claims it cannot verify from the code. That question had no answer in the thread when this edition was composed. The founder says the most common catch has been the agent not reusing existing styles, components or functions.

Reach for it if your PRs are mostly agent-written and reviewers keep asking the author "why did it do this" when the author does not know either; it replaces pasting a reviewer's question back into your own terminal and relaying the answer. Delete the PR description the agent wrote after the fact from memory. Tradeoffs: it is hosted, and pushed changes are mirrored to Critic and visible to anyone who can see them on GitHub; answers need the author's machine online; there is no published pricing beyond "free to use"; and the narrative is the authoring agent's self-report, with no check against the diff.

Canary (YC, hosted, CLI @runcanary/cli under Apache-2.0 at v0.1.13, first published to npm September 4, 13 versions since) is independent testing for code an agent wrote. Setup is one line pasted into Claude Code or Codex: install the CLI, run canary skills, and let the agent onboard the repo. After that, canary verify snapshots the working tree, with nothing committed, boots it in a clean remote sandbox, and runs tests there. It also runs on every PR. The Show HN describes the method: read the diff and trace its reach through callers, dependencies and state; turn each suspected failure into a scenario with an actor, a state and a trigger; then pick runtime tests, static analysis or unit and integration tests to settle it, seeding data and mocking third-party services as needed. Failures go back to the coding agent, which fixes them and asks for a re-run of the failed scenarios. It can pull context from Linear, Notion, Sentry and Datadog. The homepage's lead example is a cross-org file read: swap one storageId for another org's and the resolver returns the file, because it never checks ownership.

The argument for Canary is on its own homepage: "The tests pass. The same agent wrote them, and nobody on your team reads them." A separate verifier with a different harness is the fix for that, and the company's QA-Bench v0 (35 PRs across four repos, published in March) scores Canary 83.1 against 80.2 for GPT-5.4 and 78 for Claude Code. That benchmark was written and run by the vendor, and the gap is three points. The HN post got 6 points and no comments, so there is no outside report yet.

Reach for it if agent PRs outnumber your reviewers and the bugs that get through are behavioral, like auth scoping, double submits or fetch-anything URLs, not typos a linter would catch; it replaces "the tests are green" as your merge signal when the same agent wrote the tests. Delete the manual staging click-through you do before merging an agent's change to permission logic. Tradeoffs: your code runs in Canary's sandboxes, and SOC 2 is listed as in progress; pricing is not published and the site sends you to book a call; the only accuracy number is the vendor's own benchmark; and it is weeks old.

Jango (macOS on Apple silicon and Intel, free tier, Pro at $9 a month, launched on Product Hunt today) tests the parts of an app that need more than one person. You add a dev URL and some test accounts, give each AI participant a role and a goal (a buyer places a limit order, a seller offers at $99, a teammate updates a shared task), and each one acts in its own isolated local browser while you watch. You can pause, redirect one ("Maya, invite Alex to the group"), take over any participant's screen, or join as yourself. Each run ends with a report of actions, errors and screenshots. The app keeps memory between runs: known identities with encrypted login state, observed controls with their execution history, and evidence from earlier checks. The same cast can be driven from a CLI or exposed to your coding agent over MCP.

The pricing is plain. Every plan runs on your Mac with your own AI key and no platform charge. Free gives three participants per session and one project. Pro gives twelve participants, unlimited projects, multi-user checks and saved checkpoints, and managed AI credits at cost plus 10% (plus 20% on the free tier). There was no HN thread and the Product Hunt page had no substantive discussion at composition, so everything here is from the product's own site.

Reach for it if you build chat, marketplaces, collaboration or anything where a bug only shows up when two accounts act at once; it replaces signing into three browser profiles yourself and switching windows to fake a conversation. Delete the "we'll test real-time sync once we have beta users" line from the plan. Tradeoffs: Mac only; AI users find what they are told to look for and are not a load test; the multi-user checks you actually want are on the paid tier; and it launched today, with no outside reports yet.

langextract (Apache-2.0, Python, 38,827 stars, 2,716 forks, 182 commits, created July 2025, v1.7.0 released September 13, "not an officially supported Google product") is the verify side of today's split applied outside code. It pulls structured records out of long unstructured text using a prompt and a few examples, and it maps each extraction back to its character span in the source. When a model copies something from the few-shot examples instead of the input, which the README says happens, the extraction comes back with char_interval = None, and you can filter those out in one line. It chunks long documents, runs chunks in parallel with multiple passes for recall, and writes a self-contained HTML file that highlights every extraction in context for review. Providers are Gemini, OpenAI and local models through Ollama, plus community plugins.

v1.7.0 improves source alignment for repeated mentions, which is the hard case: the same name appearing ten times in one document. It also surfaces blocked, refused or empty Gemini and OpenAI responses as inference errors. It was on the GitHub Python trending list this morning with 154 stars in the day.

Reach for it if you run an LLM over contracts, clinical notes or support tickets and someone downstream has to trust the fields; it replaces a JSON-mode prompt whose output you cannot trace to a sentence. Delete the spot-check spreadsheet where someone searches each extracted value in the PDF by hand. Tradeoffs: grounding proves the text exists in the source, not that the model classified it correctly; v1.7.0 changes repeated-mention spans, and the release notes give a resolver_params flag to keep the old difflib alignment; the recommended default model is Gemini Flash, so the smoothest path is a Google API key; and Google does not officially support it.

Also on the desk. Fearless SIMD 1.0 (Rust, Apache-2.0, from the Linebender project) reached 272 points on HN on Tuesday and is off-theme but worth a look if you write hot loops in Rust. And the low-FPS spinners page makes a small, correct case that a loading indicator on otherwise static content should not keep your laptop's GPU busy.

Verification notes: star, fork, commit, contributor and release data are from the GitHub API on 2026-09-25. Commit totals use the per_page=1 Link-header last-page trick, and Whiteboard's contributor count excludes three bot accounts. Whiteboard's limitations, telemetry defaults and Code OSS vendoring are from its README and docs/telemetry.md. Critic's fork-and-strip behavior is from the founder's Show HN post, and the offline-device queue is from the demo change on critic.run. Canary's method is from the Show HN post, and its benchmark numbers, sandbox claims and SOC 2 status are from runcanary.ai. The CLI's license and version history are from the npm registry. Jango's participant limits and pricing are from usejango.com and its launch description from Product Hunt. langextract's grounding behavior is from the README, and the v1.7.0 changes are from the release notes. HN points and thread quotes are from the Algolia API (items 49833867, 49834098, 49836632, 49800085). Pipeline health: today's pool held 111 rows, up from 79 yesterday, against the ~280 the compose prompt assumes. Reddit returned zero rows again, 139 days since the last nonzero day on May 9. github:trending returned 14 rows across four feeds (all 4, python 3, rust 4, typescript 3), with go empty.