Build1 distinct publisher3 min readUpdated
A developer grepped pi for the five features it refuses and got two hits, both false. The audit that survives is one line of default tool names, not the size of the repo.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Half of pi's shipped tools are switched off when a session starts [7][1]. That is the audit worth running: `ls`, `grep`, `find` and `truncate` are in the repo and never reach the model unless someone opts in [7], so the surface an ordinary run puts in front of the model is the same four it began with [8]. Repo size tells you what a maintainer agreed to support. It does not tell you what the agent can reach in a session nobody configured.
The 443-line edit tool is the case against counting lines at all [3]. It is long because it applies multiple disjoint edits in one call, matches each against the original file rather than incrementally, detects and restores line endings, and serialises concurrent mutations [9]. That is one tool with four behaviours a shorter implementation does not have, not four tools. Compaction is in the codebase on the same logic, because long sessions need it, and the eval package because a harness you cannot measure is one you cannot improve [10].
The most portable thing in the writeup is smaller than any of that. pi checks whether the model's output was cut off by the token limit, and if it was, refuses every tool call in that message, on the grounds that a truncated argument list still parses sometimes [11]. The author reports his own harness records that same stop reason in three places and branches on it in none, a bug from a family that had already caught him twice [12].
He nearly filed the opposite story. The first note was that the minimalism thesis had eroded, and there was a paragraph half-written arguing the refusals had lapsed [18]; both grep matches dissolved when he read what they actually matched [6]. By his own count he has now been wrong that way six times on one project, including a metric that reported zero problems twice and a regex that silently matched nothing [13].
The evaluation side is the one place where the piece has corroboration rather than assertion. pi's eval package and the author's, built independently, landed on the same five primitives: isolate each run in a temp directory, persist the session as an artifact, index runs in a JSONL file, compare configurations against each other, and pin provider and model into the results [14]. The divergence is instructive too: pi's graders assert on tool calls by name, arguments, status and return value, while his grade the end state, which can report that a task succeeded without saying whether the agent got there acceptably [16].
So the label is carried by the refusal list, not the file count, and that list has not moved in a year [17]. Background bash was left out because it means managing processes an operator cannot see, subagents because they put decisions where nobody can inspect them [5]. An agent with four shallow tools is not minimal in that sense. It is just early.
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
The author picked pi as a reference for building his own coding agent because it was described as the smallest serious harness: four packages, four tools, a system prompt under a thousand tokens, and competitive benchmark scores anyway.
The author's rule was build first, then read: build each piece himself, then open pi's version and diff the decisions.
pi also contains a compaction subsystem, session branching, an extension system and its own eval suite.
pi is known for what it leaves out: no MCP, no subagents, no to-do tool, no plan mode, no background bash. The stated reasoning is that background bash means managing processes you cannot see, and subagents mean decisions made where you cannot inspect them.
Grepping for all five omitted features returned two matches, both inside a vendored highlight.min.js: the MCP hits were the string 'mcpy' in a language list, and the TODOs were comments in third-party source. All five refusals hold.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Specific but single-source and unverified
The claims are unusually concrete for a blog post — a quoted defaultActiveToolNames line, a 443-line edit tool, a named createJudge() function, five enumerated eval primitives, and a grep whose two hits are traced to a vendored highlight.min.js. But every observation comes from one author's private reading of a repository, with no commit references, no independent inspection, and no data behind the 'competitive benchmark scores' framing the whole premise rests on.
No adoption data supplied
The cluster contains no release, deployment, download, star-count, user-count or usage-disclosure evidence for pi or for the author's harness. The only adoption-adjacent statement is an unquantified secondhand reference to competitive benchmark scores, which does not establish who runs either project or at what scale.
Mildly overstated generalisation
The article is itself a correction of overstatement — it retracts the author's own 'minimalism has eroded' note and shows the grep hits were false — which pulls the gap toward zero. What pushes it slightly positive is that a broad design principle ('do less, and do more of what's left'; small was the side effect) and a claim about correct design being validated by convergence are generalised from one repository read by one person, and the underlying 'smallest serious harness with competitive benchmarks' premise is asserted without numbers.
Disclosed self-promotional learning project
The author is publicly building a competing harness and closes by pointing readers to zachzwy/agentloop plus his GitHub and LinkedIn, on a platform where engineering write-ups build personal reputation. That creates an incentive to frame the comparison as a learning triumph. Offsetting it, the disclosure is explicit and the post repeatedly reports findings that make the author look worse — an unhandled truncation bug, weaker end-state-only graders, and six occasions of trusting a wrong measurement.
Internally coherent, externally uncorroborated
Confidence is limited mainly by structure rather than by content: one publisher, one author, one repository reading, and no adoption or third-party verification anywhere in the cluster. Within those limits the account is internally consistent, quotes code directly, and explicitly distinguishes verified findings from the impression it retracted, so the specific code-level claims are more trustworthy than the general design conclusions.
build
Rate limit your MCP servers, because a retrying agent turns one error into a billing incident1 distinct publisher
build
Thirty minutes a day, and none of it from letting the agent write Swift1 distinct publisher
build
The MCP transport your search results teach has been deprecated since March1 distinct publisher
build
MCP 2026-07-28 drops the `result` wrapper, and your unit tests will not notice1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 23, 2026