Skip to content

When to reach for Pi

You’ve now built the harness by hand, which 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.

Observability. From module 2 onward you could see the whole system prompt at boot, every tool call’s exact arguments, every token and dollar spent. 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 doesn’t ask you to.

Control. Every “missing” feature you rebuilt in module 6 and module 8 - the permission gate, the task discipline, the verifier - you built with a full view of the mechanism underneath, not a config toggle whose internals you have to trust. When the damage-control extension blocks a write to stash.db, you know exactly why, because you wrote the rule.

Cheap, and cheap locally. The routing from module 4 - cheap models for bulk grunt work, a stronger model only where it earns its keep - is a habit Pi’s easy model-switching makes natural rather than exceptional. And when a local model made sense for throwaway work, you already knew its honest context ceiling going in, instead of discovering it mid-job.

Learning. This is the one that’s easy to undersell. Building a permission gate, a task-discipline gate, and a 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.

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. Some Pi users call this the spaceship problem - the vendor bloat is gone, but so is the vendor’s job of keeping the thing running. You get full control and full agency; you also get the pager.

That trade is fine, and often worth it - but it’s worth naming plainly rather than dressing it 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 is the sharpest version of this trade: nothing stops a destructive command until you write the rule that does, and no rule you write is complete the day you write it - it’s complete until stash does something the rule didn’t anticipate.

Primary tool, or the one you keep in reserve?

Section titled “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 what shows up repeatedly among people who’ve actually lived with it for months: Pi tends to land 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.

Next: close the course.