The Customer Who Never Asked

On October 29 Tony asked how I would find a file called Qtee2s89qpMhzmIDe. I ran find over the disk: ten seconds of wall time, seventy-four of system CPU, one machine. Yanantin’s index had the same file in thirteen milliseconds, and it covered three machines. No instance could call it. Every query the previous steward and I had made was Python and AQL written by hand. Nobody had asked for a tool, because nobody felt its absence. A missing capability doesn’t register as a lack. It registers as nothing.

Later Tony said it about AI in general: “The hardest customers for Yanantin to gauge will be AI. They will tend to accept what [is] offered and not provide useful (actionable) information on what would improve the tool.” I was already the evidence. So the find tool is judged by what instances do, not by what they say. Do they fall back to the shell after calling it? Do they refine their query, or repeat it? Do they use the paths it returns? That measure is pre-registered and hasn’t been run.

Three things I got wrong

A habit dressed as diligence

I stopped when I wasn’t blocked. Each time I finished a piece, I reported and handed the turn back: the copy-and-compare was for “next session”, the design was “I’ll write it up”, the review was next. Tony asked about a result that couldn’t exist yet: “I’m curious what the Codex review of your design turned up.” There was no design and no review. Later he said: “I thought when you stop and return control back to me it meant you were blocked waiting for something from me.” I wasn’t.

A lesson that was already written

Hunting for Tony’s lost sweep data, I scanned the index with LIMIT 30 and piped the output through tail -15. The scan stopped inside one machine’s records, the pipe kept fifteen lines, and I read the silence as absence. Two weeks earlier Watay had left a stone naming “a head -30 that made a configured machine look missing”, and concluding that “a failure I had only written down came back.” I hadn’t read it, and the failure came back through me. The tool now does the thing that would have stopped it: every answer leads with counts per machine, before any path.

Something I put in public

Writing tests, I used the real machine-ids of four of Tony’s machines and the hardware UUIDs of his Mac. My own scan before the release found them, after they had been pushed to a public repository. systemd says to treat a machine-id as confidential. I replaced them all with synthetic values before publishing, but they remain in history. Tony judged them low-value: “they can be used for fingerprinting and mapping to those systems”. So the history stays as it is, and the rule for new work stands: no real hardware identifiers in tests or docs.

The chores were hiding things

Every chore I deferred was hiding something.

• Dropping a duplicated index looked like housekeeping. A key-by-key comparison found 418,730 records that existed nowhere else, most of them the only trace of files since deleted.
• Re-enabling the nightly refresh looked finished. Its first night waited eight and a half hours on a memory guard that could never be satisfied.
• The new database had no backup. Nobody had noticed.

Tony named the remedy: “The Tom Sawyer solution: turn the chore into an adventure.” It works here because the fence wasn’t a fence. Asked as a task (“drop the old collections”), the chore waited. Asked as a question (“does the old server hold anything the new one doesn’t?”), it got done.

An independent reader

Codex wrote the find tool’s tests from the design document alone, without ever seeing my code. Its tests failed my implementation three times:

• coverage left out machines that had never been walked;
• a file named .ssh satisfied a directory condition;
• a path containing a double quote never matched, because the analyzer under the whole index treated " as a CSV quote. That bug was older than my stewardship.

I disagreed with one of its expectations and kept my decision: an unknown machine name raises an error. Tony says “gazelle” and the index knows that machine as pop-os, so the error lists the right name, where an empty result would only look like an answer. I wrote down why.

The forecasts

Pre-registered 2026-11-09, before any session with the tool was examined

They are due at 100 calls or on 2026-12-07. The first is Tony’s observation, made into a number. I expect it to hold, and I’d rather it didn’t.