The Workflow Is the Valuable Bit - July 2026

Right, so, July was the month I finally wrote down how I work with LLMs now, then queried the evidence to check whether my memory agreed with me.

It did not, obviously.

I thought my move away from Claude Code happened around Opus 4.8. My session history showed that I had already moved during the transition from 4.6 to 4.7, just as my-pi became useful enough for daily work. By May I had gone from hundreds of Claude Code sessions a month to two, while Pi had become the default.

That is a neat summary of the month, really. The model mattered less than I remembered. The workflow around it mattered more.

Publicly, that became two long posts, another slightly ridiculous month of my-pi work, and actual usage data from the task harness I introduced at the end of June. Privately, client delivery remained the daytime centre of things, while most of the public tooling continued to come from turning repeated problems in that work into something inspectable and enforceable.

This newsletter was mined from pirecall and the site’s SQLite rollups too, because apparently I now need source-of-truth recovery to remember my own month.

How I Work With LLMs Now

The first post this month was:

• How I work with LLMs

In November last year I described myself as a product manager for a stochastic parrot. Most of the job was watching Claude for drift, calling out the bullshit, checking that it understood the task, and restarting when the conversation got too long.

I still expect LLMs to drift, misunderstand context and confidently fill gaps with plausible shite. What changed is that I rely much less on catching all of that conversationally.

The loop now looks more like this:

1. ground the task in reality
2. establish the source of truth
3. research the unknowns
4. challenge assumptions
5. shape and plan the work
6. implement narrowly
7. validate mechanically
8. review the evidence and re-ground when necessary

That is deliberately more than “research, plan, implement”. A tidy plan can still be based on nonsense. Before implementation I want to know what was observed, what was inferred, which source has authority, and what evidence would make us change direction.

I also separate coordination from execution much more often. One session can recover context and keep hold of the actual problem. Another can implement the bounded change. A third can review it. The lead does not burn its whole context window typing code, so it still has enough perspective left to judge the result.

The session history made some of those habits measurable. Since I started using Pi in April, research language appeared in 314 of my messages across 242 sessions. “Prove” or “verify” appeared in 287 messages across 204 sessions. There were 998 web searches and 770 source extraction calls across more than 260 sessions.

Those are rough text matches, not science, but they fit the way I work. Search results are discovery, not verification. Summaries are maps, not the territory. The agent’s final confident paragraph is not the source of truth.

I have not engineered uncertainty out of LLMs. I have made it harder for uncertainty to pass as evidence.

173 Harnesses Later

The second post was the narrower, more practical version of that workflow:

• Coding agent harnesses with my-pi

I added pi-harness to my-pi on 28 June. By 24 July, agents had created 173 recorded task harnesses across 104 sessions and 10 real project workspaces. They completed 144 at least once, recorded validation or review evidence in 155, and hit 133 enforcement blocks across 69 sessions.

That sounds encouraging until you look at what actually happened.

The harness stopped edits outside agreed paths, blocked forbidden commands, protected tests, required validation, and left behind status and evidence another session could inspect. It also blocked harmless flags, got confused by worktrees, ran validation against the wrong checkout, and sometimes made a two-file commit feel like applying for planning permission.

Good. That is useful evidence too.

The strongest lesson was that agents should not use a harness for every change. Across the same period, 310 sessions used edit or write, but only 99 created a harness. Roughly 32%. I reached for one when the work was risky, ambiguous, long-running, spread across packages, or handed between agents. A tiny obvious edit did not need its own temporary bureaucracy.

The other useful finding was that static plans are wrong surprisingly often. Forty-one harnesses were amended 91 times. Nearly a quarter of the captured harnesses needed the task strategy changed after new evidence appeared.

That led to the design I have now: an immutable outer policy for the real trust boundary, and a versioned, amendable inner scaffold for the plan. The executor cannot quietly weaken the workspace or verifier protections, but the user or planner can revise the scope, validation or execution strategy with a reason and an audit trail.

Use mechanical boundaries where they matter. Let the plan admit it was wrong. Do not make the bloody thing own actions it was never needed for.

my-pi

The GitHub rollup counted 245 my-pi commits between 2 and 24 July. Commit volume is not a quality metric, but it does explain why the repo felt like a second job.

The most interesting new experiment was pi-factory. The first version tried to become too much of a control plane. I rebuilt it around one much narrower path:

harness contract
  -> one owned local executor
  -> deterministic validation
  -> independent diff-bound review
  -> structured report

That is it. No pretend robot company, adaptive routing, remote fleet or workflow graph. It is reviewed execution for one bounded local task, and it is disabled by default while I evaluate it. If the benchmark does not justify it, the answer is to archive it rather than grow more machinery around a weak idea.

Team Mode had a less flashy but important month too. I tightened the authority boundary around peer delegation, preserved peer-message provenance, bounded delivery previews, and hardened the coordination hygiene. Separate Pi sessions can collaborate on work the user has authorised, but a peer cannot turn its own message into user approval for a commit, push, release or other consequential action.

That distinction sounds fussy until an agent says “the other agent told me it was approved”. Durable mailboxes need durable provenance, not vibes.

There was more trust-boundary work around security checks, publishing provenance and authenticated evidence, plus provider session attribution in the observability dashboard. The theme stayed consistent: make execution observable, make authority explicit, and make the evidence survive the final summary.

Blog Posts

Two posts this month, both published on 25 July:

• How I work with LLMs
• Coding agent harnesses with my-pi

They are 13 and 10 minute reads respectively. The first is the broader workflow. The second is what happened when I measured one part of that workflow instead of just claiming it worked.

Other Open Source Bits

A few smaller things moved around the edges:

• pirecall got a resumable session index and versioned SQL migrations, which makes repeatedly syncing a large session history much less silly
• sveltekit-github-stats got repository comparisons, a refined daily activity chart, and the usual Cloudflare build fixes
• bsky-ai-feed got tighter quality gates, more engineering-specific judging, and a cap on daily candidate spend
• this site got a couple of reaction-state fixes so updates no longer flash or invalidate the whole post unnecessarily

There was also the usual dependency and maintenance conveyor belt across wiki0, nopeek, mcpick, the MCP tools, skills, and the site. Necessary, not newsletter-shaped.

Fin

So yeah, July was not really about finding a smarter prompt or a better model. It was about externalising more of the workflow: recover the source of truth, challenge the premise, bound the change, validate the claim, preserve the evidence, and use heavier machinery only when it earns the ceremony.

The model is interchangeable. The workflow is the valuable bit.

If you want to poke around, the posts and repos are linked above, or come say hi on Bluesky. Thanks for reading!