Pi agent lessons from Dillon's shared session
I spent some time reading Dillon Mulroy's shared Pi session, and honestly, I learned more from the workflow than the docs.
The main thing I noticed is that he doesn't use Pi like a quick code generator. He uses it more like a supervised senior implementation partner. The agent is not just asked to "build this thing". It is given specs, constraints, examples, review notes, and a clear process.
A few things I want to copy in my own Pi workflow.
1. Write the spec first
Before asking Pi to implement a large feature, create a small but clear tech spec with goals, constraints, routes, data model, edge cases, and test plan.
2. Add working-style rules to AGENTS.md
My current AGENTS.md has tool preferences and writing style rules. I should also add how I want to work – something like "prefer 3–5 small focused prompts over one large prompt", or "never rewrite a file without showing me the diff first".
3. Do architecture review before coding
Instead of directly saying "rebuild this", first ask Pi to inspect the existing files and explain where the design is weak, where cohesion breaks, and what should be changed.
4. Ask for call graphs and seams
Before implementation, ask Pi to sketch the public API, call graph, injected seams, and production vs test adapters. This makes bad design visible before code is written.
5. Use skills for methodology
A simple prompt like "use TDD" is weaker than a full TDD skill. Dillon injects an inline <skill> block that defines the philosophy, anti-patterns, and step-by-step workflow. I should create or reuse small skills for TDD, review, UI polish, refactors, and audits.
6. Use vertical slices
One failing test, one small implementation, one passing check. Don't ask the model to build the whole dashboard or whole feature in one go.
7. Give hard constraints
Prompts should include rules like: no new package, no mock data, no broad rewrite, no nullable return, no touching unrelated files. This keeps the agent on a tighter leash.
8. Use markdown annotations for review
Instead of explaining everything again, paste notes like this and ask Pi to apply only those changes:
## Markdown Annotations
- Section 4.1: update status to "implemented"
- Line 42: rename `fetchUrl` to `resolveShortLink`
- Section 3: remove the assumption about Cloudflare D1 – it's now R2
9. Codify mistakes permanently
When Pi makes the same kind of mistake, don't just fix it once. Add the rule to AGENTS.md so future sessions inherit it.
10. Use reference repos
For framework-specific work, keep local clones or examples and ask Pi to read those first. Real examples are better than model memory.
11. Use the session tree properly
If a design exploration is risky, fork the session. If it goes wrong, abandon that branch instead of trying to repair a messy conversation.
12. End with a handoff
At the end of a longer task, ask Pi for what changed, tests run, files modified, open issues, and the next 5 todos.
This is probably the biggest takeaway for me:
Better agent results come less from one perfect prompt and more from a better engineering loop.
The loop should be something like:
review the existing design
→ sketch options
→ agree on the shape
→ write or update the spec
→ implement one vertical slice
→ run checks
→ review with annotations
→ save new rules in AGENTS.md
→ hand off clearly
I already use Pi with DeepSeek, web access, goal tracking, and vision proxy, and I wrote about that setup in my Pi coding agent setup post. That setup is working nicely, but Dillon's session made me realize that it is still mostly tool-focused.
The next improvement is process-focused – better specs, better review loops, better constraints, and better handoffs.
