16 August 2026

From past chats

Fuzz the boundary code, not the whole service

Several of your recent technical threads have concentrated risk at small boundaries: configuration decoding, JSONB inspection, generated schemas, command-line arguments, and message filters. That is a good fit for a deliberately narrow Go fuzzing pass. Choose one pure parser or normaliser, seed it with real examples and previously awkward inputs, and assert invariants such as “never panic”, “reject trailing data”, “round-trips preserve meaning”, and “invalid input cannot allocate without bound”. Run it locally for ten minutes, then keep every minimised failure in the corpus so the ordinary test suite replays it. The useful follow-up question is which boundary accepts the least trustworthy and most structurally varied input; start there rather than chasing broad coverage.

Put an explicit review budget on agent-made changes

Your conversations about short-lived tools and increasingly agent-assisted coding suggest a practical experiment: cap each agent-produced change by review cost rather than lines generated. Ask for one independently testable behaviour per commit, require a short “what changed outside the requested path?” note, and stop or split the task when the diff cannot be understood in one sitting. For the next week, record only three numbers—files changed, review minutes, and defects found after review—to learn where your own comfortable batch size sits. A worthwhile follow-up is whether hand-written and generated changes deserve different limits; machine-produced code can be quick to create while still being expensive to verify.

From the lmika.org front page

Give research spirals a stopping rule and a physical next move

The recurring tension between thinking, reading, asking AI, and actually moving could become a tiny personal protocol rather than another subject to analyse. Before opening a search or chat, write the decision the research is meant to change, allow one 20-minute pass, then finish with either a reversible action or a dated reason to defer. Keep the note to four lines: feeling or uncertainty, decision, evidence threshold, next physical action. Try it on one low-stakes question first. The revealing follow-up is whether the extra thinking is reducing uncertainty, or merely postponing the discomfort of choosing; if it is the latter, the protocol should end in a deliberately small action.

Separate the craft you want to keep from the chores you want AI to absorb

Rather than asking whether AI makes knowledge work worthwhile in the abstract, make a two-column inventory of one representative week: work that expresses judgement or craft, and work that merely transports, reformats, or retrieves information. Automate one item from the second column, then deliberately protect a recurring block for one item from the first—perhaps hand-writing a tricky piece of code, tracing a production behaviour, or shaping a concise technical note. Review after two weeks whether the saved time actually returned to core work. The key follow-up question is which parts of engineering you would still choose to practise even when delegation is faster, because those are probably the capabilities worth protecting from atrophy.