When to reach for Pi

Some orientation before the verdict: Pi is a terminal coding agent with a deliberately minimal core and few built-in guardrails, and across this course you assembled a harness of your own extension and rule files around it, working on stash, a small inherited FastAPI and SQLite feed reader. That puts you in a better position than most people evaluating a tool: you’re not guessing what Pi is good for, you watched yourself do it. So use that. Here’s the honest accounting - where it won, where it cost you, and where it actually sits next to the other tools you use. The four principles this course opened with - capability, context, control, and cost - are still the sorting, under the grounds’ own names: observability is the context principle paid out in full view, control and cost keep their names, learning is the capability dividend of having built the moves yourself, and maintenance - priced in its own section below - is the bill the control you took on quietly adds.

The claim to check as you read this: Pi wins clearly on three of the four grounds below - observability, control, and cost (real, and bounded by how much you actually run it) - and wins quietly on a fourth, learning, that never shows up on a bill. The one thing it never wins is maintenance: that cost is yours and unbounded, priced in its own section below.

Module 4’s toy sweep backs the cost line. Declared illustrative there, not a measurement, it priced four mechanical re-sync rows at 15x on the frontier model at high thinking against the cheap model at low - and in that sweep the extra spend bought nothing measurable, because fetch-parse-upsert rows have nothing to reason about. The ratio is deliberately coarse and that module says so. What survives the coarseness is the shape of the gap, on exactly the kind of work stash’s backlog is full of.

Where Pi wins

Observability. From module 2 onward, nothing was hidden: the literal, as-sent system prompt via ctx.getSystemPrompt(), every tool call’s exact arguments, tokens and dollars accruing in the footer as the loop ran, and the full uncompacted log on disk. That’s not a minor convenience - it’s the difference between trusting a fix because you watched it happen and trusting it because the tool told you to. Most agents make you take that on faith; Pi never asked you to.

Control. Every “missing” feature you rebuilt in module 6 and module 8 - the damage-control gate, the plan injector, the verifier - you built with a full view of the mechanism underneath, not a config toggle whose internals you have to trust. When damage-control blocks a delete aimed at stash.db, you know exactly why: you wrote the rule file, and you traced its matcher character by character. Every gate in this harness is one you can read, diff, and turn off.

Cheap, and cheap locally. The routing from module 4 - cheap model for the mechanical sweep, strong model only where it earns its keep - is a habit Pi’s easy model-switching makes natural rather than exceptional, and the 15x gap above is what that habit is worth on mechanical work. When a local model made sense for throwaway jobs, you already knew its honest context ceiling going in, instead of discovering it mid-job. On metered billing: same tokens, different price, and for the first time you actually control which price you pay. (On a flat subscription the same routing choice changes quota and speed rather than the invoice.)

Learning. This is the one that’s easy to undersell. Building a permission gate, a plan injector, and a read-only verifier from scratch taught you what those features actually do in any agent, including the ones that ship them by default. You now know what a “permission mode” is checking, not just that it exists.

Where it costs you

There’s a cost that runs under every one of those wins, and it doesn’t go away with practice: you own the maintenance. A minimal core with no built-in guardrails means every guardrail is a file you wrote, and every file you wrote is a file only you - or whoever reads your .pi/ directory - can fix when it breaks, when Pi’s extension API shifts under it, or when stash grows in a direction the rule didn’t anticipate.

Here’s that cost, made concrete instead of asserted: the last lesson counted your harness at 18 files, and 2 of them - tilldone.ts and resync-chain.yaml - are still exactly where their own lessons left them, flagged as unfinished and never picked back up. That’s not a hypothetical maintenance burden. It’s two specific, named files, sitting in your own directory right now, that nobody but you is going to finish.

Pi’s own creator names the incumbent shape of this trade: the big agents have “turned into a spaceship with 80% of functionality I have no use for” - so feature-bloated that nobody outside the vendor can keep them flying. Pi removes the bloat - and with it, the vendor’s maintenance crew. The enemy this course has been naming since module 1 - defaults quietly spending your context window, and more broadly handing you machinery you never chose - arrives here at its final bill: every default you didn’t accept, you rebuilt yourself, and a thing you built is a thing only you maintain.

You get full control and full agency; you also get the pager, and the pager already has two open tickets. That trade is fine, and often worth it - but worth naming plainly rather than dressing up as pure upside. A tool that ships permission prompts by default and a tool that makes you build your own aren’t at different points on a quality scale; they’re making a different bet about who carries the ongoing cost.

The YOLO-by-default posture from module 1 and the gate you built in module 6 are the sharpest version of the trade: nothing stops a destructive command until you write the rule that does, and no rule you write is finished the day you write it - it only stays adequate until stash does something the rule didn’t anticipate. Full agency and full liability arrive in the same file, every time.

Primary tool, or the one you keep in reserve?

The honest answer isn’t “graduate to Pi as your main driver.” It’s closer to where this course itself landed after building every layer: Pi tends to earn a place as one tool in a stack, reached for on specific merits, not the only agent open all day.

A harness this legible is genuinely valuable for a side project you want to understand completely, for cost-sensitive bulk work where a cheap model and full routing control save real money, and for exactly the kind of learning this course just put you through. It’s a harder sell as the thing you reach for when you just need a feature-complete assistant now and don’t want to think about the plumbing underneath it - that’s a legitimate use case, and it’s not the one Pi was built to serve.

So the test isn’t “is Pi good.” It’s: for this job, do you want the harness someone else already assembled, or do you want the one only you can read? stash was the right project to answer that question on, because you got to watch the harness earn its keep, piece by piece, against a real codebase with real rough edges. Carry the question, not a verdict, into the next tool you pick up.

Reconcile that against the opening claim: observability (the context principle, made visible), control, and cost all held up under a real accounting - none of them were oversold. Learning (the capability dividend) held up too, in its quiet way: you now know what a “permission mode” checks in any agent that ships one, and no bill line item captures that. Maintenance didn’t hold up as a win, and it was never claimed as one; it’s the one line item on this balance sheet with no ceiling, which is exactly why the closing lesson prices every layer separately instead of netting the maintenance against the wins.

Next: close the course.