You've reached the end: the week on stash, and where to go next

That’s the course. Before you close it, look back at the week you just walked, because the shape of it is the actual lesson.

The arc, in one breath

You started with a repo you didn’t write. stash came to you as a friend’s read-it-later service - FastAPI and SQLite, lightly documented, working well enough to trust with saved links but not quite well enough to trust with everything you’d want to throw at it. Across ten modules you turned it into something better, and in the same motion you built the thing that did the turning.

You installed Pi, authenticated with an API key, and shipped a first real fix - before you’d customized anything, just four default tools and a compact system prompt closing on a real bug. That fix worked, but it felt like a black box, so next you opened the box: the exact behavior of read/write/edit/bash, the loop with no step limit, and the full live context - the thing most agents hide and Pi hands you outright. Once you could see the context, you learned to shape it: forking sessions instead of dragging a wrong turn forward, understanding how compaction actually summarizes, and writing stash’s conventions into .pi/APPEND_SYSTEM.md so you stopped re-explaining the readability extractor’s quirks every session.

With the rules captured, you turned to spend: routing cheap models to bulk work and strong ones to careful work, and finding local models’ honest context ceiling rather than trusting the number on the box. Config only gets you so far, though - stash needed a move Pi didn’t ship, so you wrote your first extension: a /stash command, a real tool, a lifecycle hook. That same power meant you could rebuild, on purpose, the guardrails Pi omits by default - a damage-control gate over the database and .env, task discipline enforced instead of advisory, a PLAN.md habit standing in for the plan mode Pi doesn’t have.

Not every recurring chore was worth a TypeScript file. Onboarding a new content source was a procedure, not a tool, so you packaged it as a skill - no code, shareable, invoked on demand. Then the jobs got bigger than one context could hold: you built subagents from first principles, fanning a large re-extraction job out in parallel and standing up a verifier that reads the builder’s session log instead of taking its word for it. And for a migration too big even for that, you assembled a small orchestrator-lead-worker team - and learned the honest test for when a team is worth the coordination cost and when it’s just theater.

This module didn’t add an eleventh piece. It pulled the other nine into one .pi/ directory you could actually hand someone, and then asked you to judge, clear-eyed, where that harness wins and where it quietly becomes your job to maintain.

Two places to go from here

For the spec-level other half - Foundations. This course was a story: one project, one harness built piece by piece, each primitive introduced exactly when stash demanded it. That’s the right way to learn the moves, but it deliberately stayed light on the exhaustive “every option this primitive takes” view. Foundations is that view - lookup-shaped, authoritative, the place to go when you need the complete list of extension lifecycle events or the precise config-merge order rather than the slice this course’s story needed. Same picture, other side: this course taught you the practice, Foundations is the reference.

For the other tools you work across - the sibling courses. Almost nobody lives in one agent all day, and the instincts you just built transfer directly, even though every tool spells them differently. The site’s other courses - Claude Code, Codex, opencode, GitHub Copilot, and Cursor - run on the same teach-by-doing spine: one repo, one week, primitives introduced as the work needs them. If any of those are in your rotation, the discipline you just practiced on stash - closing the gap between what you know and what the agent knows - is the same discipline, told in a different tool’s idiom.

The question this course opened with

Go back to the very first page. Before you’d typed a single Pi command, the question on the table was: how is the tool you have right now shaping what you believe is possible?

You couldn’t really answer that at the start, because you’d only ever driven agents that hid their own wiring - a system prompt you never saw, tool calls that scrolled past, guardrails that existed but whose exact shape you never had to learn. It’s hard to know what a closed box is shaping in you, because the shaping happens exactly where you can’t see it.

Now you can answer it, because you spent ten modules with a tool that hid nothing. You saw what a permission gate actually checks, because you wrote one. You saw what “no subagents” means in practice, because you spawned your own and built a verifier that doesn’t trust the builder. You saw the full cost of a harness that ships nothing pre-built, because you paid it, piece by piece, on a project small enough to feel every seam. That’s the trade this whole course was demonstrating, not just describing: a closed harness shapes what you believe is possible by deciding, invisibly, what’s worth showing you. An open one shapes it too - just in the other direction, by making you build the thing before you can lean on it.

Neither is free. But only one of them lets you find out which parts of “what’s possible” were the model’s ceiling and which were just the harness you happened to be handed. Carry that test into whatever you build next, on whatever tool you pick up - the model is the constant across all of them; the harness was always the variable, and now you know how to hold it.