I am starting to use Pi as the place where my coding-agent workflow comes together: the model, the terminal, memory, subagents, web research, and the rules I want the agent to follow while it works inside a real repo.
Why Pi is interesting to me
The thing I like about Pi is that it feels less like a single chat window and more like a proper workbench for coding agents. It can read the repo, run commands, edit files, remember durable context, delegate work to subagents, and pull in web or source-code research when the local project is not enough.
That matters because most agent work fails for boring reasons: it guesses before reading, changes too much, skips verification, or loses context between sessions. My setup is mostly about reducing those failure modes.
The point: I want Pi to make the useful path the default path: read context, make the smallest safe change, and prove the result.
The current shape of my setup
dotfiles-pihttps://github.com/francanete/dotfiles-piRight now my Pi setup is mostly global. This site has a local .pi/ directory,
but the important defaults live in my Pi settings repo at dotfiles-pi. I like
that split: global behavior for how I work, project memory for what Pi learns
about a specific repo.
I also changed the TUI newline binding so writing longer prompts feels natural:
shift+enter or ctrl+j inserts a new line.
The packages I care about
- 01
Subagents. I use Pi with focused helpers for scouting, planning, reviewing, researching, and implementation work. This is useful when I want one agent to stay in control while another agent gathers context or checks a plan.
- 02
Hermes memory. Pi can keep durable notes about me, the project, conventions, and known tool quirks. That makes repeated work less wasteful without turning every session into a giant prompt.
- 03
Web access. For library questions or current docs, Pi can search the web, fetch pages, inspect GitHub repos, and bring back source-backed answers instead of guessing from memory.
How I want to use subagents
The subagents are the part that makes Pi feel different from a normal coding chat. I do not want to delegate everything. I want to use them when splitting the work creates better judgment.
agentsscout -> quickly map the repo or feature area
planner -> turn context into a small implementation plan
reviewer -> check diffs, plans, and assumptions
researcher -> gather external context
worker -> implement an approved change
oracle -> sanity-check high-context decisionsFor small edits, one agent is enough. For bigger work, I like the idea of a loop: scout the context, plan the smallest change, implement surgically, then review the diff before calling it done.
The workflow I am trying to make default
- 01
Start with context. Read the files, imports, callers, tests, and config that actually affect the change.
- 02
Use the right mode. Simple tasks can go straight to implementation. Non-trivial tasks should get a short plan or a second opinion from a subagent.
- 03
Keep the diff small. Pi is powerful, but I still want every changed line to trace back to the request.
- 04
Verify with evidence. A build, test, screenshot, or clear manual check matters more than the agent saying it is confident.
What memory is for
I do not want memory to become a junk drawer. The useful memories are the ones that survive across sessions: project conventions, commands, known failures, preferences, and workflow rules.
For this site, Pi already knows that notes live in src/content/notes/*.mdx,
that they should feel like static notes instead of blog posts, and that I verify
content changes with npm run build.
Good memory is boring: where things live, how to verify them, what not to repeat, and which conventions matter in this repo.
The habits that matter most
What I love so far is not one feature in isolation. It is the way Pi makes the whole agent loop feel more deliberate. The agent can move fast, but the setup is there to slow down the parts that should be slow: understanding the code, choosing the smallest change, and checking the result before I trust it.