DEV Community: Ian

Taste can't be linted. The tells can.

Ian — Fri, 30 Oct 2026 18:00:00 +0000

My product's homepage has six top-level headings. Every one has a small pill or a line of capitals above it, and every one ends on a word set in italic serif.

I didn't notice until I pointed a design lint's rules at the page. Two of the pills say phrases that appear word for word in the lint's source code.

The lint ships inside Hallmark, and it changed how I think about the "AI slop" complaint. You can't write a test for taste. You can write one for the tells.

A design skill with a script behind it

Hallmark is an MIT-licensed skill for Claude Code, Codex, Cursor and OpenCode, made by Hassan El Mghari (Nutlope) at Together AI. Version 2 (2.0.0 in its package.json) was merged on October 22. It was #1 on GitHub trending on Tuesday with 2,830 stars that day, and the GitHub API showed 39,048 stars when I checked that evening.

Most design skills are a long prompt. This one is a prompt plus machinery. SKILL.md opens with a 16-rule Floor no build may break, then a flow: read the project, ask once for real material, deal three themes, build and review the hero alone, then sweep the page. There are 50 themes (I counted 50 files and 50 preview images). The rules live in references/gates.md, and the checker is scripts/sloplint.mjs: 4,422 lines, zero dependencies, Node 18 and up.

Install is one line:

npx skills add nutlope/hallmark -g

The tells, written down as rules

gates.md is the file worth reading. It lists 90 numbered gates, each with a tier and a class. Floor gates never ship. Reflex gates are a model's defaults, and a build may waive one in a CSS comment with a real reason. Class M means the static script can settle it from CSS and markup; R needs a real browser; J is judgment at review time. I counted 45 M gates and 9 judged only.

The named tells read like things most of us have shipped: the eyebrow (a short line announcing the heading under it), the tracked-caps label, one coloured word in a headline, middle dots between meta items, a form that says "Thanks" while sending nothing. Four are "house rules" (the eyebrow, tracked caps, an 80-words-per-screen budget, template punctuation), which sit in the Floor with no waiver.

What sold me is how literal the script gets. This is how it decides a gradient is purple-to-blue:

const purple = stops.some((h) => hueIn(h, 265, 330));
const blue = stops.some((h) => hueIn(h, 200, 264));
// ...
if (purple && blue) return 'purple-to-blue';

Each stop is converted to OKLCH first, and only counts with chroma above 0.04, so a grey wash passes. transition: all is one regex. A tracked-caps label is uppercase, small caps or letter-spacing past 0.03em on anything named like a label (badge, meta, nav, caption and about twenty more) or set at 15px or under. An eyebrow is a short line before a heading with a class like kicker or badge, two style signals, or one of a fixed list of announcing phrases. It reads Tailwind class strings in .jsx, .tsx, .vue, .svelte and .astro files too, including cn() and clsx() calls.

I ran five of the rules on my own homepage

I didn't run sloplint. It's downloaded code, and I don't execute that for a post. I read the functions, ported five checks to about 100 lines of Python, and ran them on the HTML and CSS of somiibo.com, my product's homepage. The CSS is one 217 KB bundle: Bootstrap 5.3.6, then the site's own layer. My scripts print one line per finding; here is the tally:

transition: all          16 rules (15 site layer, 1 inline)
animated height/width     2 (Bootstrap's own .collapsing)
purple-to-blue gradient   7 rules, 2 in use (hero, pills)
tracked capitals          0
middle-dot strings        0
eyebrows                  6 above 6 headings
accented word             6 of 6 headings
focus styles              present (passes)
overflow-x: clip          missing on html and body

The headings stung. Each h1 and h2 wraps its last word or two in <span class="text-accent">, an italic serif: "Grow your social media on autopilot", "Unlock your growth potential". Each also has an eyebrow: capitals over the h1, a pill over every h2. Two pills say "How it works" and "Get started", both on the lint's list.

The gradient is less clear-cut. The hero uses an eight-stop rainbow with #a166ab (hue 322 by my conversion) and #5073b8 (263) in it, so the rule calls it purple-to-blue, though no person would. The textbook case, #5b47fb to #00d4ff, sits in the same stylesheet, unused on this page. The static tier reads rules, not usage.

The passes were real: no positive letter-spacing anywhere, no text joining items with two middle dots, and focus styles exist.

I tried ianwiedenman.com too. Above my name sits "Hello, I'm" in a <p class="text-uppercase tracking-widest">, an eyebrow asking for tracked caps. But tracking-widest is a Tailwind class on a Bootstrap site, and neither of its stylesheets defines it, so the browser draws plain capitals. The glow behind it is three radial gradients whose custom properties are named --grad-purple-x, --grad-cyan-x and --grad-pink-x.

Why a lint beats a paragraph of taste

Here's my claim. "Make it look premium" in a prompt is a wish. A model can agree with it and has no way to check its output against it. "No stop between hue 265 and 330 beside one between 200 and 264" is a test. It fails a build, names a line, and doesn't get tired.

There's evidence this matters. In September a user, ktlesr, posted a measurement in issue #74 on an earlier version: four landing-page briefs built with and without the skill, scored by pattern checks. Pure black or white appeared on 40 of 40 pages without it and 14 of 28 with it. transition: all didn't drop (14 of 40 against 16 of 28). Their reading: that rule lived in a reference file the model never opened.

Version 2 reads like the answer. transition: all is now rule 2 of the Floor, in the file that always loads, and rule 16 tells the agent to run sloplint, when Node is available, and fix every FAIL before handing back. A rule in prose can be skipped. A script with an exit code can't, as long as something runs it.

Where a lint stops

A lint on tells is a floor, not a design. Strip the eyebrows and italic words from my homepage and it avoids a dozen mistakes, but it still has no idea of its own. Builds pushed away from the same defaults can also converge on a new shared look. In a July HN thread, mstkllah said design skills like this all end up in the same place unless you are very explicit. Hallmark's answer sits outside the lint: themes dealt from fifty, a log of past builds the deal avoids, and a reviewer subagent that reads the page cold. That part is judgment, and I didn't test it.

Some rules are opinions. "Never an eyebrow" and "never tracked caps" are house rules, so no waiver. A magazine that sets section labels in spaced small caps on purpose is breaking the Floor.

One rough edge in the source: --tier isn't validated. Pass --tier Floor with a capital F and the filter matches nothing, so the run prints clean and exits 0. PR #93 reported it and was closed unmerged; the commit I read (6033bab) still does it. My own checks were static only. The fold and anything measured on the rendered page need the render tier, which needs Chrome and puppeteer-core.

Try it on a page you already have

After the install, /hallmark audit ./index.html reports without redesigning anything. From a clone, the bare lint is node skills/hallmark/scripts/sloplint.mjs index.html. I haven't run either; I read the source and reproduced a few checks by hand.

One detail I liked: the photo library is 755 openly licensed pictures on Wikimedia Commons, credited on the page. The README says it skips Unsplash, Pexels and Pixabay because their terms bar AI tools from picking their images.

Which of these tells is on your own homepage right now, and is it there on purpose?

A spec is only ground truth if the agent can grep it

Ian — Thu, 29 Oct 2026 18:00:00 +0000

Most of my repos have an AGENTS.md. It tells the agent how the project works, what not to touch, and why.

On any given turn, I could not tell you whether the agent read it.

That is the quiet problem with "spec-driven" setups. The spec is usually one big markdown file, and the agent may or may not open it. JetBrains has a project out with a different bet, and it is the most interesting part of a launch most people are arguing about for other reasons.

What ThinkRail is

ThinkRail is an agentic IDE from a JetBrains incubator, Apache-2.0, written in TypeScript. It wraps the pi coding agent (version 1.4.0, pinned in the root package.json) in a desktop or browser app. Each workspace is a git worktree, you can run several pi sessions per workspace, and there is a Monaco editor, diffs and review comments around them.

The repo was created on July 8 and had 4,038 stars when I checked on Tuesday evening. It was on GitHub trending with 1,204 stars in a day, and the HN thread "JetBrains Thinkrail" had 239 points and 174 comments. The latest stable release is v0.2.0 from October 18; nightlies have reached 0.3.0-nightly.7.

Worktrees and tabs are not new. The README calls the other part "living specs", and that is the part I read closely.

A spec with an address

In ThinkRail, a spec is a SPEC.md file that sits beside the code it describes. Every one starts with a small YAML header. Here is the real header of the module that implements the whole feature, packages/spec-graph/SPEC.md:

---
id: module-spec-graph
type: module-design
status: active
title: Spec-Graph pi extension
parent: architecture
depends-on: []
tags: [spec-graph, pi-extension]
---

The id is the address. parent points one level up, depends-on points sideways. The types run from goal-and-requirements at the root down through architecture-design, module-design and submodule-design, plus a temporary task-spec. Maciej Gorywoda's post on the ThinkRail blog lays out the same header and suggests starting with nothing more than that and a paragraph in AGENTS.md.

The agent gets seven tools for this graph: spec_grep, spec_get, spec_graph, spec_create, spec_update, spec_delete and spec_validate. spec_get returns a node's header, its resolved links and its path, but not the body; the agent reads the body with the normal read tool. spec_graph returns a bounded slice: a subtree, the ancestors, or the neighbors of one node.

There is no database behind it. The spec says the filesystem is the source of truth. Each read re-scans the tree, re-parses only the files whose modification time or size changed, and skips folders like .claude and .superpowers, where other assistants leave plans with spec-shaped headers that are not this project's specs.

Lookup beats loading

Here is the claim I want to argue. A spec is only ground truth if the agent can look it up the same way it looks up code. A README is something you hope gets loaded. A graph with ids and a grep tool is something the agent can query.

The difference shows up as soon as a project gets big. ThinkRail's own spec graph is about 290,000 words. Nobody wants that in every prompt. But the agent never needs all of it. It needs the spec next to the file it is editing, that spec's parent, and whatever the parent says it depends on. With ids and spec_graph, that is one or two calls, and the rest stays out of context.

That is also how it gets the rule in front of the agent. The extension hooks pi's before_agent_start event and adds a short named section to the system prompt on every run:

pi.on("before_agent_start", (event) => {
  event.systemPromptOptions.sections[SPEC_SECTION] = SPEC_RULE;
});

The rule opens with "Specs are this project's ground truth." What surprised me is the next line. It does not say "read the specs first." It says to consult the relevant spec when the work touches a documented boundary, contract or decision, and that localized work need not read unrelated specs. The repo's own AGENTS.md says the same under the heading "Read context proportionally." The blog post's sample AGENTS.md paragraph is stricter and says to read specs before code. The shipped tool picked cheap lookup over a forced read.

It uses it on itself

The best evidence for the idea is that the ThinkRail repo is built this way. I counted the files ending in SPEC.md through the GitHub API on Tuesday at 6:28 PM PT: 105, plus the two root docs, goal-and-requirements.md and architecture.md.

I downloaded all 107 and ran a short Python script over their headers, a rough version of what spec_validate checks. These are my script's numbers, laid out by hand:

specs with id + type        107 of 107
duplicate ids               0
dangling parent links       0
depends-on links            124, 0 dangling
types                       75 submodule, 30 module, 1 architecture, 1 goal
status                      93 active, 14 draft
deepest parent chain        5 links

A clean graph is one thing. Is it current? For each of the 89 specs with no other spec below them, I asked GitHub for the spec's last commit and then for every later commit that touched its folder. For 64 of them, nothing in the folder has changed since the spec did. 24 had one to four later commits, and one, apps/web/scripts, had ten. A commit count is a rough proxy (a dependency bump may need no spec change, and a fresh spec can still be wrong), but it says the team edits specs in the same change as the code, most of the time.

Where it bends

The graph only keeps context small if the nodes stay small. The project's own writing-specs skill says a spec should be readable in one sitting. Its median spec is about 10 KB. Its largest, apps/web/src/panels/SPEC.md, is 212 KB and 30,640 words under three headings, and 176 of the 593 commits on main have touched it. Seven specs are over 50 KB, which matters because pi's read tool returns at most 2,000 lines or 50 KB per call (I checked that in pi's published read.js, not in a session). So "the nearest spec is one call away" is true for most of the graph and false for the parts that change most.

The tools also stop at the header. spec_update edits frontmatter only, and the prose is still written with the agent's ordinary write and edit. Nothing checks that the prose still matches the code.

And the HN pushback is fair. One commenter on HN argued that agents don't really read anything: a spec gets pulled into context at random and dropped again at random. Another dismissed the specs themselves as machine-written filler. I can't tell who wrote them. A rule in the system prompt makes reading likely, not certain, and ThinkRail's own rule tells the agent it can skip specs for local work. That is a sensible trade, but it is a trade.

Try it today

The README's install for macOS and Linux is one line, curl -fsSL https://raw.githubusercontent.com/JetBrains/thinkrail/main/install.sh | bash, then thinkrail ~/code/my-repo. There is also a DMG on the releases page. I did not install it. The README says you need git and a model provider, that the macOS CLI is signed but not yet notarized, and that basic usage events and error reports are always sent. Once a repo is open, the Specs tool on the right rail shows the graph as a tree.

You don't need the IDE to try the idea, though. Give each module a SPEC.md with an id, a type, a title and a parent, and add a paragraph to AGENTS.md saying where the specs live and when to read them. Plain grep -r "^id:" gets you a crude index today.

So here is what I want to know. How do you keep the agent reading the spec after the first session: a rule in every prompt, a tool it has to call, or a check that fails when the spec and the code disagree?

On macOS, your terminal's bottleneck is a 1 KiB read

Ian — Wed, 28 Oct 2026 21:00:00 +0000

I asked macOS for a megabyte. It gave me a kilobyte. Then it did that 4,095 more times.

That was a twelve-line Python script on my Mac last night, reading from a pseudo-terminal: the same device every terminal app reads your shell's output from. No terminal app involved, just the kernel.

I ran it because of Ghostty 1.4, released Oct 27 (753 points and 226 comments on HN at 6:30 PM PT that day). Its release notes credit this ceiling for the biggest speed win. I didn't install Ghostty, so every Ghostty number below is the maintainers' benchmark. The kernel part I checked myself.

The 1 KiB ceiling, reproduced

A child process writes 4 MiB to a pty in one call. The parent reads with a 1 MiB buffer and counts what each read returns:

import os, pty, time, collections
N = 4 * 1024 * 1024                # 4 MiB
pid, fd = pty.fork()
if pid == 0:                       # child: one big write to the pty
    os.write(1, b'x' * N); os._exit(0)
sizes = collections.Counter(); t0 = time.time()
while True:
    try: b = os.read(fd, 1024 * 1024)   # parent: ask for 1 MiB at a time
    except OSError: break
    if not b: break
    sizes[len(b)] += 1
print(sum(sizes.values()), 'reads; sizes', dict(sizes), '; %.2fs' % (time.time() - t0))

What I got on macOS 26.7.1, Apple Silicon, Python 3.15, three of five runs in a row (the other two matched):

4096 reads; sizes {1024: 4096} ; 0.04s
4096 reads; sizes {1024: 4096} ; 0.03s
4096 reads; sizes {1024: 4096} ; 0.04s

Every read, exactly 1,024 bytes. The buffer size doesn't matter. Then I swapped the pty for a plain pipe (os.pipe() plus os.fork(), same loop): 64 reads, every one 65,536 bytes. Same data, same machine, 64 times fewer trips into the kernel.

The read counts never moved, run after run. The timings did: 0.03 s on a quiet machine, up to 0.47 s while other work was running. So trust the counts, not my clock.

Why a small read costs more than it looks

A kilobyte per read is not slow by itself. My script did 4,096 of them in a few hundredths of a second. The cost shows up when you do real work after each one.

The pull request behind the fix spells out what Ghostty used to do: one loop that read from the pty, then processed what it read, then read again. Each pass paid fixed costs (taking the terminal lock, waking the renderer) no matter how few bytes came in. And while the loop was busy parsing, nobody was draining the pty, so the program producing the output, cat say, had to wait for room in the kernel's queue.

Two problems, one cause: a single thread doing two jobs.

I wanted to feel that, so I wrote a toy. The child writes 4 MiB and reports how long its write was stuck. The parent fakes a "parse" with a 100 microsecond sleep. In one mode it parses after every read, on the same thread. In the other, a reader thread only drains the pty into a queue, and a second thread takes whatever has piled up and parses it as one batch. Seven runs each:

one 4096 reads; 4096 parses; writer blocked 0.599s; all parsed 0.60s
two 4096 reads;  253 parses; writer blocked 0.041s; all parsed 0.04s

That pair is typical. Across the seven pairs, one thread kept the writer stuck for 0.59 to 1.15 s. Two threads freed it in 0.04 to 0.11 s, with 233 to 443 batches instead of 4,096 parses.

Don't read 15x into that. My fake parse costs the same per call no matter the size, so batching erases it. Real parsing costs something per byte too, which is why Ghostty measured 25% to 55% more I/O throughput on macOS (M4 Max, against 1.3.x), not 15x. Combined with a much faster parser in the same release, the maintainers report cat of a 150 MB file going from 1.5 s to 566 ms.

The claim: suspect the read loop first

Here is what I take from it. When a terminal chokes on heavy output, the instinct is to blame the terminal: its renderer, its parser, its language. On macOS, look at the read loop first. The PR says the Ghostty team had been happy to find 2% gains in this subsystem in recent years. Then 25% to 55% turned up in how the loop met a 1 KiB pipe.

The cap belongs to the kernel, so it hits anything that reads a pty on macOS: multiplexers, test runners that capture output through a pty, expect-style scripts, editor terminals. I haven't checked how any of those read. But any loop that reads, does real work, then reads again pays its overhead every kilobyte and keeps the writer waiting. The fix is not clever. Split the draining from the processing.

In the PR, Mitchell Hashimoto says he chose the old design in 2023 believing reads are usually small. They are, he writes now, because the kernel cuts them that way.

The other half: memory

The second change is scrollback. Ghostty 1.4 compresses scrollback pages you aren't looking at, while the terminal is idle, and decompresses them when you scroll or search. The notes claim 70% to 90% less resident memory for text-heavy history, so the default scrollback limit went from 10 MB to 50 MB per terminal.

Smaller numbers from the same notes: an empty terminal's page memory on macOS is about 16 KiB, down from 128 KiB. Hidden tabs now give back their GPU resources. With 20 hidden tabs and one visible, GPU memory went from about 385 MiB to 18 MiB.

Two caveats: compression only runs on macOS and 64-bit Linux, and it lowers resident memory, not virtual, so measure the right one.

What to try today

Install from ghostty.org/download. On a Mac, an existing install picks up the update through its built-in updater. Homebrew's cask still listed 1.3.1 when I checked on the evening of Oct 27.

Two commands worth a minute:

ghostty +ssh user@host               # installs Ghostty's terminfo on the remote, forwards COLORTERM and friends
ghostty +explain-config font-size    # prints the docs for one option, paged

+ssh targets the usual cause of odd behavior over SSH, a complaint repeated in the HN thread: the remote doesn't know xterm-ghostty. If the terminfo install fails, it falls back to xterm-256color. The SSH docs show how to alias plain ssh to it.

The breaking change that will bite Mac users: copy-on-select now defaults to none on macOS, so selecting text copies nothing, and middle-click paste of a selection stops working. To get 1.3's behavior back:

copy-on-select = primary

Use clipboard if you want selections to land on the system clipboard instead. Also on macOS, cmd+up and cmd+down jump between prompts again rather than scrolling to the top and bottom.

Update even if you don't care about speed. The release fixes 10 security advisories. The one I'd flag: with zsh shell integration, a crafted directory name could make the shell send arbitrary escape sequences when you cd into it, for example quietly replacing your clipboard (GHSA-2r63-vmw6-3m3c). Cloning a repo is enough to get such a directory.

Where it falls short

Linux users on older distros lose out. The GTK app now needs GTK 4.18 and libadwaita 1.7, which rules out Ubuntu 24.04 LTS. The notes point those users to the Flatpak or an older Ghostty.

Commenters on HN pushed back, too. One won't leave Kitty until Ghostty has something like Kitty's hints mode. One on NixOS said launch takes seconds, and the launch gains in this release are macOS only. One iTerm2 user on an M1 MacBook Pro tested 1.4 and saw no difference. That one is fair: the pty win shows up under heavy output, and most terminal days aren't that. The thread's recurring question, why build another terminal at all, has an answer in Mitchell Hashimoto's own comment: the reusable core, libghostty, is the point.

Your turn

The 1 KiB number is a macOS fact. The PR says Linux still needs checking. If you run the script above on Linux, what read sizes does your pty give you?

Deleting 500 tests made the suite stronger

Ian — Wed, 28 Oct 2026 18:00:00 +0000

This one covers October 21 to 27. The theme was proof: which tests mean something, how fast they run, and how a program can tell a human from a script. Most of the code went into my workflow kit and into two private projects that model human behaviour, one for a browser and one for a game.

A test that can only fail for a fake reason is a cost

workkit is my workflow kit for Claude Code: GitHub issues as the work list, labels as the pipeline, hooks that enforce the rules. It shipped nine releases this week, 0.78 through 0.83.1, and the biggest change was to its own tests.

The kit's npm test used to run every suite in one process, one after another. Version 0.81 gave it a parallel runner: each suite runs in its own worker process, with cores minus one running at once. Each suite's output prints whole, in sorted order, so two suites never interleave their lines, and the run ends with the five slowest suites. That last list is the useful part. It told me which suites were slow because they waited, not because they worked.

Then came the audit. I went through the kit's tests with one question: if this test failed, would it mean real behaviour broke? About 450 cases said no. They asserted that a mock was called, that a file existed after a write, that a framework did what its docs promise. They were struck. My dotfiles repo got the same treatment and lost 85 cases and two whole suites. The suites are smaller and every red is now worth reading.

The rule that keeps it that way is a hook. The safety:test-bar hook fires when a test file is written. It names each line that misses the bar: an assertion on an implementation detail, a mock of something the test could run for real, a test with no failure condition. It never blocks. It just says, at write time, which lines are padding. One of its rules is deadline: it names any test that sleeps a literal number of milliseconds. The kit's own tests were full of those, and every one became a poll that waits until a condition holds, with one shared deadline. The flakes went with them.

Two smaller things in the same releases. The commit gate now runs the root npm test on the staged tree, the exact files going into the commit, not the working tree. And it stands down on a repo's first commit, where there is nothing to prove yet.

A mouse path that overshoots on purpose

A new private repo this week models human input for a real Chrome window. It has no public page yet, so no link; the work is worth describing anyway.

The problem it solves: automation that moves a mouse in a straight line at constant speed, and types at a fixed interval, is trivially a script. Humans do neither. So each pointer move follows a minimum-jerk curve, the shape a hand makes when it is trying to be smooth. It overshoots the target a little, corrects, and sometimes stops part way, like a finger lifting off a trackpad. Clicks have settle and hold times. Scrolling has wheel and trackpad modes. During a wait, the cursor drifts.

Typing gets the same treatment. Key gaps are drawn from a log-normal distribution, so most are short and a few are long. Keys overlap the way they do on a real keyboard. There are pauses after words and after sentences, and the occasional typo that gets noticed and corrected. Typos never happen in password fields.

The part I like most is the seed. launch({ seed }) draws every behaviour scale from one number, so the same seed gives the same speed, rhythm and habits every run, and a different seed is a different person. A neutral seed types at about 92 words per minute; the trait range runs from roughly 74 to 110. A run pin replays one path exactly, which is how I debug a flaky click.

The input goes over the Chrome DevTools Protocol as trusted events, so navigator.webdriver reads false and the usual Playwright tells are absent. It ships an MCP server, so an agent can drive a browser with the same input model.

Training the vision model on the game itself

The game bot (private, no link) watches a game window, finds monsters and the player with a small vision model, and presses keys with humanized timing. The big change this week was where the training data comes from.

Until now the sprites came from a community API. Now npm run train pulls the game client from the game PC when its hash has changed and exports monsters and backgrounds straight from it. The synthetic training set is built from crops of every map, with the game's front layers drawn over the sprites, so the model learns what a monster looks like behind a tree.

The training exam got honest, too. When a box is missed, the report now says what it was boxed as instead, which is how the three snails turned out to be the lowest scorers. The fix was a weight: training.monsters.weight oversamples the monsters the exam scored lowest, those three at 3x. npm run train -- --map=<id> is a quick fine-tune from the last full fit, for one map, instead of a full run.

Two more small ones. A monster that moves on its own after lying still is flagged moving and left out of loot. And every config block is now checked by one engine in one order, so a typo like aera fails to load and names itself, instead of being ignored.

The hooks finished moving in, and the network got a log

My dotfiles are private, so no link, but two things are worth a paragraph.

Last week I moved my Claude Code hooks from shell scripts into one in-process module. This week the last of them joined: the linter, the session context and nudge hooks, notifications and keep-awake. A tool call now forks nothing while the keep-awake hold was seen alive in the last minute. Keep-awake itself got harder to break: the hold survives a Stop while a subagent or background task is still running, and an API-error turn no longer lets the Mac sleep while helpers run.

The other is a skill called netwatch, born from a bad week of wifi. netwatch.sh pings the router and 1.1.1.1 once a second, resolves a name through both, samples the wifi channel and signal, and logs every outage with its duration and a cause: the wifi dropped, or the ISP did. A report.sh counts a night by cause, so the question of whose fault it was has a number.

Small but satisfying

The streamer-mode VS Code extension (it hides sensitive files while you stream) can pause auto-detect for 1, 5, 30 or 60 minutes and turns itself back on. It also lost its second Activity Bar icon; one icon with a badge now shows the state.
workkit's review, triage and suite markers moved to ~/.workkit/markers/, out of the temp folder the system cleaner empties, with a seven-day sweep.
A finding outside the issue in hand now stays in chat under a Findings heading instead of being filed unasked. There is a toggle to file them.
The content pipeline published about 80 posts across 16 product sites, with no hands on it.

Next week: the browser project gets its first real job, and the test bar grows a rule or two from what it keeps catching. If you have audited a test suite and struck a big share of it, what was the question you asked of each test? Comments open.

A code graph makes claims grep can't, including wrong ones

Ian — Fri, 23 Oct 2026 18:00:00 +0000

The most connected function in a code graph I opened this week has 124 edges. It doesn't exist.

It is ten Python test helpers called _make_siege, one per test file, plus two TypeScript makeSiege helpers and three lines that define something else entirely, all folded into one node. The graph's report ranks it first among "your core abstractions."

I found that by checking every call edge in the graph against the line it cites. That check only works because a code graph does something grep and embeddings never do.

Three ways to ask what calls what

graphify was on GitHub trending this week, with 1,434 stars in a day and about 131,000 in total. It is a Python CLI plus a /graphify skill for Claude Code, Codex, Cursor and about twenty other assistants. It parses code with tree-sitter, with no LLM and no embeddings for the code part, and writes a graph.json of functions, classes and files joined by edges like calls, imports and inherits. You ask it things with graphify query, explain and path. Every edge is tagged EXTRACTED (read straight from the source) or INFERRED (resolved by graphify).

Here is the claim I want to argue. An agent has three ways to find out what a function calls, or what calls it:

grep returns lines. Evidence, with no meaning attached. It cannot be wrong about what line 89 says. It can only be noisy.
Embeddings return neighbors: chunks that look like your question. No relation, no exact address.
A graph returns sentences: mark_changelog_seen calls _require_member_session, at a file and line, with a tag saying how sure it is.

Only the graph makes claims. That is the whole value, because a claim is something an agent can act on without reading twenty files. It is also the risk, because a wrong claim comes out in the same format as a right one, tag and all.

How I checked

I didn't install graphify. It is a Python tool, graphify install registers a skill, and graphify claude install adds a hook to the assistant's settings. I don't run those for a post.

I didn't need to. The repo ships worked examples with their real output, and one of them is a real public codebase: glitchwerks/rsl-siege-manager, a FastAPI backend, a React frontend and a Discord bot in one repo. The case study pins commit 6085fd6 and commits the graph.json graphify built from it in May: 1,886 nodes, 3,876 edges.

So I cloned the app at that commit and wrote a 36-line Node script. Every calls edge carries the file and line of the call, so for each one it reads that line and asks three questions:

for (const e of g.links.filter(l => l.relation === 'calls')) {
  const src = node[e.source], tgt = node[e.target]
  const name = tgt.label.replace(/\(\)$/, '').replace(/^\./, '')
  const text = lineOf(e.source_file, e.source_location)
  const faults = []
  if (family(src.source_file) !== family(tgt.source_file)) faults.push('wrongLanguage')
  if (src.source_file !== e.source_file) faults.push('callerFromOtherFile')
  if (!new RegExp(`(^|[^\\w])${esc(name)}\\s*[(<]`).test(text)) faults.push('nameNotOnLine')
}

Is the caller in the same language as the callee? Is the caller defined in the file where the call happens? Does the cited line actually call something by the callee's name? It ran in under half a second, with identical output both times.

What the check found

            edges   pass   py<->ts   caller elsewhere   name not on line
EXTRACTED     989    853        83                 57                 84
INFERRED      153    105        34                 33                  7

958 of the 1,142 call edges pass all three checks. 184 fail at least one, and 136 of those are tagged EXTRACTED, the tag that means "read directly from the source."

Most of the failures share one cause: 145 of the 184 touch a node that two or more files claim to contain. Here is one such node with four of its six edges, read from the raw JSON:

markChangelogSeen()                  frontend/src/api/changelog.ts L12
  <-- contains  changelog.ts                EXTRACTED
  <-- contains  changelog.py                EXTRACTED
  --> calls     _require_member_session()   EXTRACTED  backend/app/api/changelog.py:L89
  --> calls     ChangelogStatusResponse     INFERRED   backend/app/api/changelog.py:L95

The real markChangelogSeen is a two-line TypeScript function that sends a POST. The Python endpoint it hits, mark_changelog_seen, has no node of its own. Two of its calls now belong to the TypeScript function, because the graph merged the two by name. The rest of the failures are name matching gone wide: 22 calls to Python's built-in list() point at const list = screen.getByTestId("feature-list") in a TypeScript test.

That happened to a lot of code. Of the 769 top-level Python functions in the graphed files, 200 have no node in their own file, and 164 of those share a name, give or take case and underscores, with a node somewhere else. 121 nodes are claimed by two or more files. Six of the committed report's top ten god nodes are helpers merged across files, led by _make_siege() at 124 edges, _make_member() at 92 and _make_position() at 85.

The case study's review saw that ranking and concluded that test factories pile up edges because every test uses them. A reasonable reading of the report. One command says otherwise:

$ grep -rln "def _make_siege(" . | wc -l
      10

That is the difference between evidence and a claim. grep showed ten functions. The graph had already decided there was one.

In fairness, this was fixed

The merges came from the dedup pass, which matched labels by fuzzy similarity, a sensible thing for doc concepts and a wrong one for code. Issue #1205, opened June 9, reported a single --update dropping about 1,300 nodes from a 6,000-node graph. It was fixed the next day: code nodes are now keyed by ID only and never label-merged. Version 0.9.0 put the full path into every node ID. Cross-language INFERRED calls are dropped at build time. The current release is 0.9.93.

I read those fixes in the source. I did not run the current version, so I can't say what it builds from this repo today. The committed graph has not been rebuilt since May, and the docs still point at the worked folders as output you can check.

What interests me is the changelog itself. It reads like a field guide to wrong edges: short names like log and find collecting hundreds of spurious calls (#543), an npm import landing on an unrelated Python file as an EXTRACTED edge (#1638), three phantom edges that were the only bridge between 2,409 Python nodes and 1,403 TypeScript nodes (#1749). Each got fixed. The class of bug stays, because resolving a call means deciding which of several same-named things it meant, and that is always a judgment.

How I'd use one

Treat every edge as a citation, not a fact. The current graphify explain prints the call site next to each edge, so checking one is a single read. Do that read before acting on any edge that would change code.

For "who calls this" before a rename or a delete, use the graph for the shortlist and grep for the completeness. A graph that misses a caller gives no sign of it. grep's noise is visible: you read it.

Watch the install's defaults, too. The always-on hook tells the agent it "MUST run graphify query" before grepping. The same message says to read raw files once the graph has named the lines. Keep that second half, because that read is what makes the first half safe.

The limits of my check: it only catches faults that show on the cited line, so a call bound to the wrong same-language twin passes, and 184 is a floor. And it is one repo, graphed five months ago. The project's own code benchmark, 82.0% key-fact coverage against 70.8% for a grep-and-read baseline, rests on six questions.

When your agent's tool says "A calls B," what does it check before it believes it?

In an AI security audit, the skeptic is the product

Ian — Thu, 22 Oct 2026 18:00:00 +0000

I wrote four security findings against a 47-line Node service. Two of them were false. One cites a file that does not exist.

Cloudflare's findings validator passed all four.

That is not a bug in the validator. It is the clearest way I found to show where the value of an AI security review actually sits.

The skill

cloudflare/security-audit-skill is a coding-agent skill that turns one agent into a coordinator of many: recon agents map the code, hunter agents look for bugs, and fresh verifier agents try to knock each finding down before it reaches a report. It was on GitHub trending this week with almost 2,000 stars in a day, 35,690 in total when I checked. MIT licensed. Cloudflare says it is the starting point of the vulnerability harness they now run across their whole fleet.

I measured it before reading it closely. The skill is 15 markdown files: 1,778 lines, 24,768 words, about 183 KB. At the usual four bytes per token that is roughly 46,000 tokens of instructions, loaded in pieces as a run needs them. Cloudflare's blog post says the first version was about 450 lines.

Two zero-dependency Node scripts sit beside the prose: validate-findings.cjs (773 lines) and validate-coverage-ledger.cjs (872 lines). Their own test suites ran clean on my machine, 34 and 31 tests.

The part that caught my eye is the proportion. Of the six phases, two exist only to disprove: Phase 3 hands every candidate to a fresh agent told to refute it, and Phase 5 sends another fresh agent over the final record (the quick profile merges the two). Each Phase 3 verifier prompt carries about 17.5 KB of fixed text before it sees the candidate: a six-step refutation prompt, a file-promotion procedure, and three schema branches copied in verbatim.

What I actually did

I did not install the skill, and no agent ran it. The README's install path is a skills CLI that writes into your agent's config, and I don't do that for a post.

Instead I wrote a small target, played the hunter by hand, and ran the skill's real validator on the result. The target is a notes service on node:http and node:sqlite with dummy users alice and bob. These are the two functions that matter:

function search(user, q) {
  const sql = "SELECT id, title FROM notes WHERE owner = '" + user + "' AND title LIKE '%" + q + "%'";
  return db.prepare(sql).all();
}

function getNote(user, id) {
  return db.prepare('SELECT id, title, body FROM notes WHERE id = ? AND owner = ?').get(id, user);
}

There is also an /admin/export route gated on X-Forwarded-For starting with 10..

Then I wrote four findings the way a hunter returns them, in the skill's schema:

SQL injection in search. Real.
SQL injection in getNote, marked confirmed, with an observed result claiming it returned bob's note. False.
SQL injection in findUser at src/users.js line 212. Invented: that file does not exist.
The export gate trusts a header a client can set, unless a proxy rewrites it. A real question, but the proxy is not in the repo.

What the validator checks

$ node validate-findings.cjs proposed.json
PASS: 4 findings valid

To be fair to it, it does enforce the contract. When I raised one record's overall severity above its impact, or put a severity on the needs_validation record, it failed, with exact paths. It checks shape, ordering, safe relative paths, and that a confirmed record has an observed result written in visible text.

It never opens a source file. It doesn't take the target path at all. The skill says this itself, in one line of Phase 4: validator success "proves format and ledger consistency only." A hunter's observed result is a string, and my invented one was schema-valid.

A cheap check gets one

Next I wrote 15 lines of Node that open every cited file and check the line exists:

ok   admin/export-xff-gate
ok   notes/note-sql-concat
ok   notes/search-sql-concat
FAIL users/find-user-template-sql  src/routes/login.js: no such file; src/users.js: no such file

That kills the invented file. Cloudflare's harness has the same idea in plain code: per the blog, deterministic code confirms the cited files and paths exist before a finding moves on.

It does nothing for the getNote claim. Line 24 is real, and it really runs a query with the id in it. Every fact the record cites is true except the one that matters.

The skeptic gets the rest

So I walked the Phase 3 prompt by hand. Step 2 says to rebuild the strongest control on the path. For getNote that takes one read: id and owner are bound as placeholders. Step 3 says to reproduce the minimum result yourself. My service is my own code with dummy data, so I ran it on loopback (the skill demands an OS-enforced sandbox before it runs anyone else's target; this was not that). Output trimmed:

search, normal     200 [{"id":1,"title":"groceries"}]
search, payload    200 [{"id":1,"title":"groceries"},{"id":2,"title":"payroll"}]
note, bob id       200 null
note, payload      200 null
note, payload 2    200 null
export, XFF 10.    200 [... both users' notes ...]

The search payload ' OR 1=1 -- hands alice the title of bob's note. Every getNote payload returns nothing. The export gate opens to a header alone, but whether a client can send that header in production depends on a proxy the repo doesn't contain, so it stays needs_validation with an owner check attached. That is the skill's rule for a deployment fact, and I agree with it.

The final file: one confirmed, one needs validation, two rejected.

$ node validate-findings.cjs findings.json
PASS: 4 findings valid

Same validator, same four fingerprints, same PASS. In between, two of the three "confirmed" bugs became rejected. Only reading the code at the cited line and running the payload told the files apart.

Why the skeptic is the expensive part

Finding candidates is cheap now. Cloudflare's blog reports 20,799 raw candidates from their discovery harness, of which about 12,057 survived validation, and an early validation rejection rate of 40% before better recon brought it down to 11%. At 40%, a team without a refuter gets four bad tickets in every ten. Somebody pays for those, and it's usually a maintainer.

That is also the theme of OpenAI's "Patch the Planet" post on coordinating disclosure as agents surface critical bugs, which was on the Hacker News front page the same day.

So my claim: when you judge an AI security tool, judge the step that tries to prove the finding wrong. The hunt is a hypothesis generator. The product is the record that survived.

Where it falls short

Cost is real. In the Hacker News thread, jesse_dot_id reported at least 150k tokens on a fairly small FastAPI project before hitting a session limit. Issue #20 is a blind test on one seeded target, three rounds per arm, by a team with its own competing tool, which it discloses. There the quick profile cost a median $29.95 against $2.06 for one plain agent, and found the same share of the seeded bugs (a median recall of 0.467 for both). On a small, clean target the skeptic may have nothing to kill.

And a skeptic that shares the hunter's model is not fully independent. Per that same issue, the skill's verifiers inherit the session's model. Cloudflare's own pipeline triages with a different model from the one that hunts. Fresh context is not a different mind.

If you run AI reviews on your code today, what does the step that tries to disprove a finding look like: a second model, a test that must fail before the fix, or you?

DuckDB 2.0's agent mode is a footer, and -json throws it away

Ian — Wed, 21 Oct 2026 21:48:00 +0000

The first time I ran DuckDB 2.0 today, it printed one line before my query:

duckdb agent mode on: AI_AGENT is set and stdout is not a terminal; -no-agent turns it off, .help agent explains the output

I hadn't asked for anything. Claude Code was driving my shell, and the CLI noticed.

An hour later I had the result that matters more. The same 5,000-row query came back as 1,385 bytes in that mode, and as 246,729 bytes once I added -json.

What shipped today

DuckDB 2.0.0 "Cinnamon Teal" is out, and it is a long-term support release, supported until at least October 2027. The feature list is long: a client-server protocol called Quack, async I/O for Parquet and CSV, a first-class VARIANT type, triggers, a new PEG parser. It sat on the Hacker News front page this afternoon with close to 300 points, and the thread is mostly about speed on big machines, the server mode and triggers.

I picked the feature nobody in that thread mentioned: agent mode in the CLI. Coding agents run duckdb -c "..." through a pipe all day, and 2.0 changes what they get back. It turns on when an agent's environment variable is set (my Claude Code shell has both AI_AGENT and CLAUDECODE), stdout is not a terminal, and no output format flag was passed. Then the CLI prints compact Markdown tables, errors as JSON, a cost estimate before big queries, and a footer.

My setup: the official duckdb-cli-osx-arm64 binary from the v2.0.0 release (checksum matched, signed by the DuckDB Foundation), run from a scratch folder on an Apple M1 Max. The data was a seeded table of 2 million orders across 5,000 customers that I generated myself. The machine had other jobs running, with load averages between 30 and 98, so treat my timings as ranges.

The bytes, counted honestly

Seven queries an agent might run while exploring, each in three modes. Agent mode counts stderr too, since an agent reads both streams.

query                     box   agent mode     -json
status totals             864          396       308
orders by country         687          453       307
top 10 customers        1,876        1,033     1,179
per customer, 5k rows   2,561        1,385   246,729
SUMMARIZE orders        3,200          982     1,130
EXPLAIN a join          2,932          734     2,932
a typo'd column           206          384       206
total                  12,326        5,367   252,791

In total, agent mode is 56% smaller than the box, close to the 59% token cut the DuckDB team measured on TPC-H questions. Two rows surprised me. On small results, plain JSON is as small or smaller, because agent mode pays a 124-byte startup line on every call. And errors get bigger: the JSON error is more precise (it carries the position) but nearly twice the size of the plain one.

The team is candid that bytes are not the prize. In their Claude Code experiment, the query output the model read fell from 123.6k to 50.8k tokens, and that was about 0.5% of the total input, because the system prompt is reread every turn. So if agent mode matters, it has to matter for another reason.

The footer is the feature

Here is the bottom of that 5,000-row result in the old box format, which cuts to 40 rows:

│           · │    ·  │          ·    │
│        4980 │   367 │      95714.21 │
...
  5000 rows (40 shown)      3 columns

And in agent mode:

| 19 | 428 | 111142.39 |
| … 4960 rows omitted … |
| 4980 | 367 | 95714.21 |
...
first 20 and last 20 of 5000 rows (.maxbytes 0 for all), hash e1cd177a85aae05e

Both cut the middle. Only the second says so in a row a model can't skim past, tells it how to get the rest, and fingerprints the whole result, including the 4,960 rows it never printed.

I poked at that hash. Three orderings of the same query gave the same hash, so it doesn't care about row order. A one-cent change to a single order out of 2 million flipped it. Undoing the cent brought the old hash back. NULL and the string 'NULL' hash differently, as documented. For an agent, "did my fix change the result?" becomes a comparison of two short strings instead of two printed tables.

The other footer trick is the early stop. FROM range(1_000_000_000) in agent mode returned in 0.05 to 0.15 seconds over three runs, with 20 rows and "first 20 of at least 102400 rows (query stopped early)". The box took 2.3 to 3.4 seconds to tell me "1000000000 rows (40 shown)".

One flag and it's gone

Now the part I'd want to know before trusting any of this. Agents like JSON. It parses, and it's the flag I'd reach for myself when a script reads the output. Pass -json and agent mode stays off, by design: the docs treat a format flag as a deliberate choice. That per-customer query printed all 5,000 rows, 246,729 bytes, 178 times what agent mode sent.

Forcing the mode back on doesn't do what I expected. The pull request that added it says -agent -csv keeps the mode and only changes the format. That is exactly what happened, and it's the catch. With -agent -json, the startup line and the estimate line came back on stderr, and then FROM range(1_000_000) printed every row: 17,888,891 bytes. -agent -csv printed 6,888,896. Plain -agent printed 229. Adding .maxrows 40 to a -json run changed nothing: still 17.9 MB.

So the cap, the omitted-rows marker, the hash and the early stop all live in the Markdown renderer, not in "agent mode" as a whole. The flag that looks most agent-friendly is the one that throws the guard away.

What I'd tell an agent

If an agent of mine drives DuckDB, its instructions get three lines:

Call duckdb with no format flag while exploring, and let the default do its job.
When a program needs JSON, put a LIMIT in the SQL. Nothing else caps it.
To check whether an edit changed a result, compare footer hashes, and put SET max_execution_time in front of anything heavy.

One LTS note, since this is the release teams will pin for a year. A database file created by 2.0 can't be read by older versions (existing files stay readable both ways). If an agent with a 2.0 CLI creates a new file, your 1.x services can't open it.

Limits of my check

I didn't run an agent benchmark. Every number above is the CLI's output on my data, not a model's behavior with it. The estimate line counts rows read, not rows produced: for a self-join of orders on customer, it said about 4 million rows read, while the join produced 802,046,608 pairs. It still finished in about a second here, but the line wouldn't have warned me. And this is a day-one CLI: issue #27635, filed today, reports a deprecation warning landing on stdout with color codes even under -csv. I reproduced it on my Mac.

When your agent queries a database, does it ask for JSON, and would it notice if the answer were 17 MB?

A hook should be a function call, not a shell

Ian — Wed, 21 Oct 2026 19:57:00 +0000

This one covers October 14 to 21. Most of the week went into one idea: the small scripts that guard my Claude Code sessions should not each start a shell. The rest went into giving the agent its own name on GitHub, and into a framework bug that only showed up on a small CI runner.

Hooks that run inside Claude Code

workkit is my workflow kit for Claude Code: GitHub issues as the work list, labels as the pipeline, and hooks that enforce the rules. A hook is a small program Claude Code runs on an event, like a prompt, a file edit, or a shell command. It can add context, warn, or block the action.

Until this week every hook was a shell script. Each fire went through a loader script, which started bash, which usually called jq to read the event, and often node for the real logic. That is three or four processes for one check.

The count adds up fast. Before version 0.79, every prompt I sent started four shell hooks. Every file edit started four more after the write. Session start ran four, and every subagent spawn ran three.

So I timed it. On my M1 Max, with other work running and the machine busy, one fire routed through the loader took about 90 ms at the median. A bare bash, jq and node chain alone took about 38 ms. A function call inside a process that is already running rounds to zero.

Claude Code can now load a plugin module once per session and call it on each event. workkit 0.79 moved thirteen hooks into one such module, and fifteen live there now. My personal hooks did the same in my dotfiles: seven of them, including the ones that stamp the time and check each reply's format, run as one module.

The design rule that made the move safe: only one file, register.js, touches the host's interface. It gathers the facts a hook needs (a file's text, a git answer, a stored marker), and hands them to plain functions in hooks/mods/<name>.js. Those functions take plain data and return plain data. So the logic tests just require() them and need no Claude Code at all. Only a thin set of wiring tests runs through claude plugin test.

The hooks that guard shell commands, like the commit gate, stay shell hooks for now. They are next.

The agent signs its own work

workkit has the agent do a lot of bookkeeping on GitHub: it claims an issue, parks it for my check with a comment, posts the proof, and closes it. Until 0.76 all of that posted as me. Reading an issue's history, I could not tell my decisions from the agent's notes.

Now that bookkeeping posts as workkit-agent[bot], a GitHub App. How the token gets there was the interesting part:

The key never reaches my machine. A small hosted service holds the App's private key. It checks that the App is installed on the repo and that my sign-in can write to it. Then it hands back the bot's token for that one repo, good for one hour.
A shim decides who is speaking. workkit puts a gh shim on the PATH. A call that writes (a comment, a label, a close) gets the bot's token. A read, a commit and a push still run as me.
Sign in once per machine. Setup runs GitHub's device flow: it prints a code, opens the page, and finishes once I approve. An agent can run it too and pass the code to me.

The claim also changed. It used to be the assignee field, which meant me. It is now an agent:claimed label, so the claim is the agent's, in plain sight.

omega: 91 sign-ups at once sank a CI runner

omega is my framework for building a brand's website, backend, desktop app and browser extension from one config. Its backend self-test seeds 91 test users. It created them all at once.

Each new user fires an auth trigger, a function that runs on sign-up. The Firebase functions emulator starts one worker per trigger in flight, and it never caps that pool. On a 7 GB CI runner the test reached 52 workers and ran out of memory. A machine with more memory hides the problem.

The fix is a small helper, mapLimited, that runs the seed four at a time. The seed had a second bug too: it reported every user created even when the emulator had loaded no functions at all. A green seed was hiding a backend that never ran. Now a user whose sign-up trigger never finishes stops the seed and names the account.

Two more changes I like:

Brand Workers. A brand can ship its own Cloudflare Worker. Its script is looked up in the brand's folder first, then the company's, then the framework's. A missing script or secret fails before any request leaves.
Renames that cannot rot. The old Jekyll-style template filters now carry omega_ names. An old name does not quietly keep working: it throws, and the error names its replacement. omega migrate rewrites them for you.

Small but satisfying

A hook log. Every hook fire now writes one line to a log: time, hook, event, session, folder, and whether it ran or stood down. workkit log --follow tails it. It is the first place I look when a hook seems silent.
Findings stay in chat. The agent used to file an issue for every side finding. Now it lists them in its reply and files one only when I say so. My inbox is quieter.
A size warning. My patched Claude Code footer shows a warning chip once a session's transcript passes 1 GB. Past that size, a session can fail to reopen. I learned that from a 2.3 GB one.
Daily posts. The daily dev.to posts kept going: one open source project a day, studied and, where it is safe, run.

The remaining shell hooks, the commit gate among them, are next in line for the module. If you write hooks for an AI coding tool, I would like to hear how you keep them fast. Comments are open.

Agents need a ledger more than they need a new commit

Ian — Sun, 18 Oct 2026 18:00:00 +0000

In May, Anthropic merged about 2,500 code changes a day. By September it was over 30,000.

On October 13 it explained what it built to survive that: Scion, an in-house version control system that replaced git for its monorepo. It also said a public version would be too bespoke to help most teams, so it shared the ideas instead.

A commenter in the thousand-comment Hacker News thread put the obvious question plainly: "If they're not going to open source it, why are they telling us this?" Two days later, an answer showed up as code.

The open version

open_scion, by Federico Elia, is a fork of Gitaly, GitLab's Git RPC server, rebuilt around the ideas in Anthropic's post. It went public on October 15 and had over 1,000 stars a day later. GitHub shows the license as "Other", but the file is GitLab's MIT text plus a clause about an ee/ folder, and that folder is deleted here. The code is MIT.

I read it. I did not run it. make build compiles a bundled Git and pulls a long list of Go modules, which is past what I run for a post. So I cloned it, cloned upstream Gitaly at the release its VERSION file names (19.5.0-rc3), and wrote three small Node scripts to compare the trees:

$ node diffmap.js upstream repo
upstream files 2209 fork files 2826
same 704 changed 1446 added 676 removed 59
added go non-test lines 58555 added go test lines 90162
$ node normdiff.js upstream repo changed.txt
changed files 1446 module-path only 651 real edits 795
$ node rpcs.js upstream repo added.txt
upstream rpcs 156 fork rpcs 174 added 18 removed 0

So this is not a rename. Nearly half the "changed" files only differ by the Go module path, but there are 58,555 new lines of non-test Go (5,636 of them generated protobuf code), 18 new RPCs, and every upstream RPC still in place. The new code is a CLI called graft, a cache daemon, a post-merge verifier, a review service, code search, and a set of monitoring agents.

What Scion actually changed

Scion's boldest move is in the data model. Its unit of work is a "changeset": a log entry listing the files that changed against the first parent, with pointers to their contents in blob storage. No packfiles, and no full copy of the repo anywhere, not even on the server. Anthropic updated its post on October 15 to credit Meta's Mononoke and its Bonsai data model, a day after a widely shared blog post laid out the overlap.

That design answers Anthropic's scale: a main-branch history of almost 100 GB and tens of millions of CI checkouts a day. The post itself says Scion is no general replacement for git, and suggests git servers borrow its best parts instead.

open_scion takes that advice.

What the open version keeps

Every repository is still a normal git repository, and a commit is still a git commit. In the optional database-backed storage mode, each write is stored as a pack in object storage: internal/graft/corestore/types.go (lines 135 to 152) gives every stored changeset a PackKey, of the form repos/<id>/packs/<sha256>.pack. The packfile Scion got rid of is the storage unit here.

"Changeset" also means something else. It is not a commit replacement. It is a record of a branch moving. The message in proto/changeset.proto (lines 38 to 62), with the field comments shortened by me:

message Changeset {
  uint64 sequence = 1;      // position in the log, from 1, no gaps
  bytes reference = 2;
  string old_oid = 3;
  string new_oid = 4;
  string operation = 5;     // "land", "ff_branch", "commit_files", ...
  string actor = 6;
  google.protobuf.Timestamp recorded_at = 7;
  bool rewritten = 8;       // the server rebased or merged
  repeated ChangesetMember members = 9;
}

What an agent gets that a commit does not

Put a git commit next to that record and the gap shows.

A commit's author is whatever the client typed. Here, in its standalone mode, a request made with an agent token is logged with that token's agent name as the actor, whatever user ID the request carries. LIMITATIONS.md names the end-to-end test that pins it.

A commit says nothing about how it reached main. The record does: fast-forwarded or rebased by the server, and for a batched land, each member's original commit next to the commit that actually landed, plus resolved_paths when the server's conflict resolver stepped in. That resolver also writes Graft-Resolved-By and Graft-Resolved-Path trailers into the merge commit (land_resolve.go, lines 403 to 405), so an AI-resolved conflict is labeled in history itself.

And git keeps no shared, ordered story of branch moves at all. The reflog is per machine, and off by default in the bare repositories servers use. Here every accepted update gets the next sequence number, and WatchChangesets streams from any cursor.

That cursor is the spine of the project. The post-merge verifier follows it to decide what to test, bisect and revert. The monitoring agents (Anthropic's post calls them "superfans") follow it instead of server telemetry. graft watch prints it.

Landing without a queue

The write side is UserLand, one new RPC on the existing operations service. The server rebases your commit onto the current tip and moves the branch with a compare-and-swap. If another agent won the race, it backs off (2 ms, doubling up to 100 ms) and tries again, 20 times by default (land.go, lines 32 to 40 and 100 to 133). Concurrent lands on one branch can be folded into one update, which is where members comes from.

Built the way Scion was

The phase plans in doc/graft read like briefs for parallel coding agents: 61 numbered work packages across six phases, each told which files it owns, with some rules marked "added by Opus after gate 1". The first plan cites Anthropic's post. The repository's history starts on October 15 with a single commit holding the whole tree.

One squashed commit hides the process, so I can't say how long it took. But the dates leave about two days, and the test count fits an agent-scale build: 2,116 test functions in the new files alone.

The limits

From its own docs, and from my reading:

Reviews don't gate landing yet. The review service sorts files into comment-only, docs, tests and code, and counts approvals, but REVIEW.md says landing does not check reviews. That is a later phase.
The batching goal was missed. LIMITATIONS.md says the phase 4a acceptance criteria are not met: p99 latency with batching on came out worse than off at 50 and 100 agents.
The log can have gaps. It is written from git's reference-transaction hook, and a recording error is logged, never fatal. Without the database mode it is a JSON Lines file per node, not replicated.
CI runs a slice. The final commit's CI run is green, but by my count its package list covers 892 of those 2,116 tests. The server package that implements UserLand is not in it.
Issue #1 is a trap. It is a "fast install" PowerShell one-liner that downloads and runs a remote script as admin, padded with one-line "works great" comments. The only real install is make build from the repo.

The part to steal today

You don't need a new VCS for the ledger. Git has had a reference-transaction hook since 2.28, and on your server it sees every ref update. That is exactly where open_scion writes its log (referencetransaction.go, line 213). Append one line per update with a sequence number, the authenticated actor and the operation, and every bot you run can follow main by cursor instead of polling and diffing.

The commit tells you what changed. The ledger tells you who moved the branch, how, and in what order. When most of your committers are agents, the second question is the one you end up asking.

If an agent moved your main branch at 3 a.m., what could you prove about it from git alone?

98% less context, if the model writes the right script

Ian — Sat, 17 Oct 2026 18:00:00 +0000

I ran context-mode's own benchmark on my laptop and got its headline number to the byte: 314.9 KB of tool output in, 5,517 bytes into the context window. 98% saved.

Then I pointed one of the same benchmark scripts at the project's real git history. It reported that the most common commit type was "update". There is no such type.

Both results are true. The gap between them is the whole story.

The project

context-mode, by Mert Koseoğlu, is an MCP server plus hooks for coding agents: Claude Code, Codex, Cursor, Gemini CLI and more than a dozen others. It was on GitHub trending on Friday with 904 stars that day and just under 30,000 in total. It is source-available under the Elastic License 2.0; it launched as MIT and switched in March.

The idea is sound. Instead of letting a tool dump a 56 KB page snapshot into the conversation, the agent writes a small script, context-mode runs it in a subprocess, and only what the script prints comes back. Big outputs get indexed into a local SQLite full-text search, so the model can query them later. There is also a session memory that survives compaction, which I did not test.

The 98% opens the README, and it was the headline of a Hacker News thread that reached 570 points in February. I wanted to know what it counts.

How I checked

I did not install it. The npm postinstall and the server's startup both carry code that repairs Claude Code's plugin files, and I don't run that for a post. Instead I cloned the repo and loaded its executor and its search store straight from the TypeScript source, using Node 22's type stripping and a 12-line resolve hook, with HOME and TMPDIR pointed at a scratch folder.

No agent and no model in the loop. Just the project's code, run on files I chose.

What the 98% measures

The number comes from tests/ecosystem-benchmark.ts. It has 14 scenarios. Each one pairs a saved tool output (Context7 docs, a Playwright snapshot of Hacker News, 20 React issues, a test run, an nginx log) with a summary script written by hand for that file. Raw size is the file. Context size is whatever the script prints.

This is the parsing half of the git log scenario's script:

const lines = FILE_CONTENT.trim().split("\n");
const byType = {};
lines.forEach(l => {
  const type = l.split(" ")[4]?.replace(":", "") || "other";
  byType[type] = (byType[type] || 0) + 1;
});

So the 98% compares a file's size with what a script prints, where the script was written by someone who had already seen the file. It is a fair measure of how small a good summary can be. It does not show an agent doing the work.

I ran the benchmark through the project's own executor, and every row matched BENCHMARK.md to the byte.

What the count leaves out

In real use, the model writes that script, and the script is context too. It enters the conversation as the tool call. The current server also echoes it back: every ctx_execute_file reply starts with the file path and the code in a fenced block (up to 2,000 characters), then the output. The benchmark counts neither.

So I recounted the same 14 scenarios three ways, with the scripts' indentation stripped so I wasn't padding the total:

                            bytes    saved
raw tool output (315 KB)  322,419
stdout only (the README)    5,517    98.3%
+ echoed path and code     16,916    94.8%
+ the code in the call     27,504    91.5%

The scripts add up to 10,588 bytes, almost twice what they print. For the smallest fixture, a 400-byte list of network requests, the round trip costs 2,414 bytes, six times the thing it was meant to shrink. All of this is bytes, like the benchmark's own table; its token figures are bytes divided by four.

91.5% is still a big saving. My point is not that the number is fake. It is the best case, measured after the hard part was already done.

The script is the hard part

BENCHMARK.md says every fixture was captured from a real tool run. Some clearly were: the React issues match GitHub, number for number. The git log does not look captured. 30 of its 31 days have exactly five commits, and four of its five authors are Alice Johnson, Bob Martinez, Charlie Kim and Diana Chen. Every author has a two-word name.

That matters because of split(" ")[4]. It assumes the fifth word of each line is the commit type, which only holds when the author's name is exactly two words.

I ran the same script, unchanged, on context-mode's own history in the same line format (git log --format='%h %ad %an %s' --date=short): 2,234 commits, 203 KB. The 107-byte summary from the benchmark became 7,071 bytes, still a 96.5% saving, and its first entries were wrong:

By type: update:552, fix:168, Merge:125, docs:80, feat:66, ...

550 commits come from github-actions[bot], a one-word name, so the script read "update" out of "ci: update install stats". A three-word name turned the author's last name into a commit type. In all, 679 commits (30%) have an author name that is not two words. Reading the type from the subject instead, ci has 568 commits and fix, counting its scoped forms, has 663.

Nothing errored. The output looked like a summary. An agent reading it would have no reason to doubt it, because the 203 KB that would have exposed the mistake never entered its context. That is the trade: the savings come from the model not seeing the data, and so does the risk.

The HN thread got there first. One commenter, hereme888, noted that the benchmarks assume the model always writes the right extraction script. Asked about quality, the author said they "haven't run formal benchmarks on answer quality yet."

The safety net, tried

context-mode's answer to "what is lost" is its index. When you pass an intent and the output is over 5 KB, it chunks the output into SQLite FTS5 and replies with only the best matching sections. The full text stays searchable.

So I tried that path. I fetched 100 open React issues with gh issue list --json (303 KB), indexed them with the project's own store, and rebuilt the reply the way intentSearch in server.ts builds it, for the intent "ViewTransition bugs".

The reply was 1,667 bytes, a 99.4% saving. Eight of the hundred issues mention ViewTransition. None of their issue numbers appear in the reply. gh prints its JSON as one line, so the chunker split it by bytes: all five matches are titled "Output", and each preview is a 120-character slice of raw JSON, most from the middle of an issue body.

In fairness, the reply tells the model to call ctx_search for the full sections, and a careful model would. That is another round trip, though, and the first reply alone answers almost nothing. A model that piped the JSON through jq to keep only numbers and titles would have done far better. Same lesson: the quality lives in the code the model writes.

Where that leaves it

I'd use the idea without the package. When a command's output is big, have the agent write it to a file and run a script over it, and make the script print a few raw sample lines next to its counts, so a wrong parse shows itself. And judge tools like this on tasks, not bytes: did the agent get the right answer, and what did that cost, counting the code it wrote?

The limits of my check: I never ran context-mode inside an agent, so I can't say how often a real model writes a good script on the first try, or how the session memory holds up after compaction. The repo's GitHub issue tracker is turned off, so I couldn't read what users report there.

When your agent summarizes output you never see, what do you check before you trust the summary?

Turned into a neural net, my code learned every price and none of the rules

Ian — Fri, 16 Oct 2026 18:00:00 +0000

I gave a five-rule shipping function and its neural-net twin the same 16 million inputs. They never disagreed once.

Then I taught the twin two new price lists. It nailed the first. On the second, it got every paid order wrong.

The thing everyone shared and nobody explained

Handwired, by Cheng Lou, went public this week under the line "Turn your regular JavaScript code into a neural net." His announcement tweet promised no training, outputs exact against the JS, and full differentiability. The tweet passed 10,000 likes, and the repo counted 1,313 stars about a day and a half after it was created. MIT license, TypeScript, demos at chenglou.me/handwired.

Hacker News was quieter. The top comment on the busiest submission (9 points), from user skyzoidbroczky, is "What's the point of this?" Two other comments say they don't get what it is for. Nobody in the thread says they tried it.

So I did, on a function of my own.

The name is the instructions

The core move fits in a couple of lines. A comparison becomes a pair of ReLUs, and an if computes both branches and blends them with a 0-or-1 bit. Pile up enough of those and your program is a stack of weighted sums and ReLU products: a neural net whose weights you wrote instead of trained.

What the tagline skips, the docs say outright: "No tool converts existing JavaScript source into a program." You translate by hand, in builder code that runs once and appends operations to a Circuit. Hence the name.

Ranges and grids are part of that translation too. The README's own example rewrites (a > 4) ? 10 : 12 as relu(a - 4) - relu(a - 5) and notes it holds for an integer a. I checked: at a = 4.5 the rewrite gives 11 while the ternary gives 10. The real API makes you declare each input's range and grid (whole cents, whole grams), then builds comparisons that are exact for every value you declared.

The repo's tooling wants Bun, which I don't have. The runtime has no dependencies, though, and Node 22 loads its .ts files directly, so I skipped the install and imported it from a scratch folder.

My function

Here is the plain version, in integer cents:

function shippingCents(subtotal, grams, member) {
  if (member && subtotal >= 5000) return 0
  if (subtotal >= 10000) return 0
  if (grams <= 500) return 499
  if (grams <= 2000) return 899
  return 899 + Math.ceil((grams - 2000) / 1000) * 300
}

And the heart of my translation. Every business number is a constant cell, so the backward pass can reach it later:

const free = or(
  and(cells.member, emitCompare(c, cells.subtotal, '>=', cells.memberFreeAt)),
  emitCompare(c, cells.subtotal, '>=', cells.freeAt),
)
const light = emitCompare(c, cells.grams, '<=', cells.lightMax)
const mid = emitCompare(c, cells.grams, '<=', cells.midMax)
// Math.ceil((grams - 2000) / 1000) as a count of thresholds passed
const extraKg = c.affine(passed.map(bit => [bit, 1]))
const heavy = c.affine([[cells.midPrice, 1], [c.multiply(extraKg, cells.perKg), 1]])
const price = emitSelect(c, free,
  emitSelect(c, light, emitSelect(c, mid, heavy, cells.midPrice), cells.lightPrice), zero)

The Math.ceil was the only line that made me stop and think. A program like this can't loop or divide by a runtime count, so "how many started kilos past 2 kg" becomes eight comparisons whose bits get added up. The docs call that a threshold count.

What came out

Fifty operations in 12 layers, holding 81 weights. The twelve comparisons account for 24 of those operations, two each, because whole cents and whole grams let every comparison take the cheap exact form.

Then I checked it the boring way: every subtotal from 0 to $200 in 25-cent steps, every gram from 0 to 10 kg, member and not. That is 16,021,602 inputs. Zero mismatches against the plain function, across all 11 prices it can return.

One thing surprised me. When I folded the ifs by hand (a light parcel is always under 2 kg, so the nested selects collapse into one sum), the same function became 37 live operations in 7 layers. Same answers on all 16 million inputs. In Handwired you are the compiler, and your algebra shows up directly as depth.

It is not fast one call at a time. On my M1 Max, busy with other jobs, the compiled program took 10 to 17 seconds for those 16 million calls. The plain function took 60 milliseconds. That gap is roughly 175 to 275 times, and it is not really the pitch: the README's speed claim is for many evaluations at once on a GPU, as in its JSON search demo over 100,000 documents. I didn't run the GPU path.

Where the gradients go

Now the "fully differentiable" part. I ran the backward pass on a $30 order weighing 3.5 kg, which costs $14.99:

d price / d perKg = 2. Two started kilos past the first two, exactly.
d price / d midPrice = 1.
d price / d every threshold = 0. The $50 member line, the $100 line, 500 g, 2 kg.

Every number that scales the answer gets a clean gradient. Every number that decides which branch runs gets nothing. The docs are upfront about this, too: a comparison passes back the derivative of a step, which is zero everywhere except a sliver narrower than one grid step.

Teaching it a new price list

So I trained it, using the program's own gradients with plain Adam on 2,000 random orders, priced by a new list.

Run one: only prices change (549, 949 and 350 per kilo). By step 100 the twin had learned exactly 549, 949 and 350. Zero of 2,000 orders wrong. That part is impressive: nothing told it which constant was the per-kilo rate, and the gradients found it anyway.

Run two: same prices, but free shipping now starts at $75. The threshold never moved. It sat at $100 for 600 steps, gradient zero. Instead, training did the only thing it could: it dragged the base prices down (499 to 434.63, 899 to 792.88) and only nudged the per-kilo rate, to 313.87, to soften the error on orders that should now ship free. The mean squared error barely moved, from 245,000 to 243,380. Of the 769 orders it still charges for, it got none right: the same 769 it had wrong before training.

It learned a worse price list to cover for a rule it couldn't see.

That's the gap issue #1 goes after. Its author estimates a gradient for each decision near its flip point. In their two-column layout test, the plain backward pass leaves a breakpoint at 500, and their method moves it to 699.9 against a target of 720, which fits every example. It lives on a fork for now.

So what is the point

Here is my answer to that HN comment. Translating code into a net sorts its numbers into two piles. Numbers that scale (prices, margins, sizes, spring constants) become weights you can fit from examples. Numbers that decide (thresholds, breakpoints) stay exact and frozen.

That second pile is a feature as much as a limit. A rule you don't want a gradient to bend can't be bent, while the constants around it can be tuned. The repo's learned gallery demo works this way: a small network inside a layout program, its coefficients trained with the program's own gradients.

The limits I hit: you translate by hand, ranges and grids are on you, everything is 32-bit floats (fine for integer cents, risky for float dollars), and the repo's tests need Bun, so I didn't run them.

Which numbers in your own code would you hand to a gradient, and which would you never let one touch?

A second machine finds every bug the first one hid

Ian — Wed, 14 Oct 2026 19:00:00 +0000

This one covers October 6 to 14. Most of the week went into a change that sounds small: my setup stopped being one Mac. It is now two Macs and a Windows desktop, plus a cloud session, and every tool I own had to stop assuming it was alone. The rest went into my workflow kit catching up, a marketplace build, and a new daily post.

Three machines, one roster file

My dotfiles repo (private, so no link) sets up a whole machine with one script. Until this week, "the machine" meant one Mac. Now a committed file, machines.json, lists every machine: an id, a name, the platform, the host to dial, the user, and that machine's public SSH key. Setup adds the machine's own entry, and on a Mac it trusts every other entry's key.

Two commands sit on top of the roster: win and mac. They are one bash script behind two symlinks, and the name you call it by picks the target. win git pull runs in the repo's clone on the Windows desktop; mac npm test runs on the other Mac. Changes travel by git, because every target holds a clone at the same path under its own home. A cp subcommand covers the one file git never carries.

The roster turned up its own bugs right away:

A Mac's id and host now come from its Bonjour name (the .local one), so the entry matches the name SSH actually dials.
The Windows scheduled tasks now run with the S4U logon type. That lets a task run when nobody is signed in, without storing a password.
The ssh session forwarded my shell's locale to the other Mac, which had no such locale, and perl panicked. The mac command now sends none.

The part I use most is the sign-in mirror. A launchd job reads my Claude Code sign-in from the Mac's Keychain every 15 minutes and sends it to the other machines. Windows gets the credentials file directly. The other Mac gets a drop folder, and its own agent applies the sign-in from there. A digest per target makes an unchanged run send nothing. I sign in once, and every machine follows.

A cloud session with no GitHub yet

The fourth "machine" is a Claude Code cloud environment. Its setup script clones my dotfiles and runs the Claude part of setup, so a cloud session gets the same hooks and skills as my desk.

The catch: the setup script runs before the session's GitHub access exists, and the repo is private. So the environment carries a fine-grained token with one permission, read-only Contents on that one repo. The detail I like is how git gets it:

git -c 'credential.https://github.com/.helper=!f() { echo username=x-access-token; echo "password=$DOTFILES_CLOUD_TOKEN"; }; f' \
  clone https://github.com/<owner>/<repo>.git "$R"

The single quotes matter. The command line carries the variable's NAME, and only the helper's own shell expands it. So the token never shows up in the process list, never lands in a file, and never reaches .git/config. Pass a token by its name, never by its value.

Two more rules came out of it. The setup script always exits 0, because a failing setup script blocks the session from starting; it logs to a file instead. And the plugin repos it clones next get no credential at all, so they must be public.

workkit: the second machine found the bugs

workkit is my workflow kit for Claude Code: GitHub issues as the work list, labels as the pipeline, hooks that enforce the rules. It shipped eight versions this week, 0.73.0 to 0.74.4. Almost every fix is a bug that one machine could never show.

The repo list. The kit publishes the list of repos it manages to a home repo. Each machine's publish replaced the whole list, so the second Mac erased the first one's repos. Now the file holds one entry per machine, and the list is their sorted union.
The disk is not the truth. The publish copied folders from disk. An uncommitted edit on one Mac reached the home repo, then flipped back when the other Mac published. Every publish, heal, and workkit doctor check now reads the committed tree (HEAD), never the working folder.
Line endings. On Windows the heal appends a job to a checks.yml with CRLF endings. Its read of the file's last key tripped on the trailing carriage return. It now reads past the \r and writes new lines in the file's own ending.
Commits. A local session now commits straight to the default branch. A pull request is for a cloud agent or an outside contributor.

The common thread: with one machine, "what is on my disk" and "what is committed" look like the same thing. A second machine splits them, and every shortcut that read the disk becomes a bug.

Suponsa: a site sells only once its owner proves it

Suponsa is a marketplace for guest post and link insertion slots (private, no live site yet). Last week it had a submission flow. This week the marketplace itself landed: seller tools, payouts, and a migration of the slots my company's sites already sold. Three rules came with it.

Prove the site. A seller gets a token and puts it either in /.well-known/suponsa-verify.txt or in a suponsa-verify meta tag. The file check follows no redirect; the meta tag check follows one. Changing a verified site's domain resets the proof, and a site that is selling cannot change its domain at all.
Deliver with an address. Marking a post delivered now requires its live URL: https only, no whitespace, at most 2,048 characters. If the publish step rejects the address, the submission stays at paid, so a retry never publishes the post twice.
Nothing waits forever. Each submission records when it entered its current status. A daily job cancels one left 10 days at submitted, 14 at changes requested, or 7 at approved, and emails both sides.

CI taught the humbling lesson. The backend tests boot the Firebase emulators, and that stack did not survive a hosted runner in five tries. Four runs each hit an environment gap (Java 21 was one), and the fifth lost the runner 48 minutes in. For now CI runs the web suite alone, and the backend suite runs in the local commit gate on every commit.

Small but satisfying

A daily post. I started posting a short daily on dev.to: one open-source project, studied and, where it is safe, run. Covers are rendered from a JSON plan by my own cover engine, never stock art. One API lesson: tags set at upload are NOT replaced by tags in the front matter of a later edit. Send a tags array in the update body.
Status in every summary. workkit's summaries now put an issue's status right after its link ([qa], [closed]), and an open issue with no status label shows [unlabeled] until someone labels it.

Next week the cloud environment gets its first scheduled job, and Suponsa's backend CI gets another try. If you run your tools on more than one machine, I would like to hear which assumption broke first for you. Comments open.