Self-upgradable software: A Pi setup
Before I tell you about my customized Pi coding agent setup, I want to briefly mention how any vanilla coding agent is more than enough. I built most of Tuna on a completely stock codex, high reasoning.
You absolutely should not feel that this is necessary. It might not even be a good idea. So many grifters claim you're behind but nobody really knows.
With that out of the way, welcome to the deep end…

The lifestyle
I've gone back and forth through the years on customization.
In my teens, I built my own PC with money earned from my very first job. Picked every part. Put them together. What an adventure!
I hopped on customize.org (RIP) every day. It was a forum dedicated to changing the looks of the windows, the icons and everything else on your system. I spent hours and hours on customizing my Windows XP installation.
My computer and its setup became a project onto itself. I reinstalled Windows so often I could recite the pirated Windows XP key from memory. FCKGW. If those 5 first characters don't bring a millennial nerd rush of nostalgia to your heart, you just weren't there.
And then I fell in love with Macs. At first, by stealing glances at the 2 (total!) guys with iBooks at my highschool. The rebels, the troublemakers. Later by touching and staring at the shiny machines in stores.
After what felt like ages, I had finally saved enough for a white, plastic first-generation Intel Macbook.
I fell in love. The beautiful, fast, powerful UI on top of the solid, ancient, proven unix underpinnings. Quicksilver, TextMate, TextExpander. Apps that tied themselves tightly into the user experience expanded what was possible. I dug in.
Soon, using anyone else's computer felt strange. Like walking in quicksand.
And then I found vim.
Its learning curve was steeper than anything I'd tried before. But the power? And the possibilities? I was determined to become the kind of guy who uses vim. And I was. My dotfiles traveled with me from install to install, from Macbook to new Macbook, never at rest, always open for some new idea. Expanding and contracting but always mine.
Using vim to customize vim had its own sort of self-referential magic to it.
And I still am a vim guy. But more and more seldomly do I pull out the ol' $EDITOR. Coding agents are so good, so precise now, that there's rarely a reason.
First Claude Code crawled then Amp walked and I grew more ambitious and excited than ever. Codex ran and I gave in completely.
The Codex CLI wasn't as fancy as the other two but the models were good. Like, really good. This wasn't just speeding up light, monotonous tasks here and there. Around GPT 5.1 or 5.2, I don't remember, it's all a blur, they became capable of engineering that I was barely capable of myself without it. So I stayed for the model and lived with the CLI.
And then I found Pi.
The Shitty Coding Agent
Pi is like vim. Small, focused core. Clean fundamentals. Just enough.
But this foundation allows it to be near fully customizable. And while vim is too, you need to learn its custom configuration language vimscript. I never really did more than a few lines here and there.
Pi is in TypeScript -- but you barely need to know because you just talk to Pi and tell it to configure itself.
Imagine that.
Imagine telling your kitchen, "I think the cutlery should actually go over there... and let's turn this coffee machine into an airfryer? And the fridge should go here. And every time you're done doing the dishes I want you to send me a message and it should be in the form of a haiku."
Even, "and then only when I'm cooking fries the oven should actually be a deepfrier."
Sorry, I'll stop with this questionable metaphor. But imagine.
Now, the only thing holding you back is the feeling that maybe I should do some actual work instead? Which was always the nagging thought in the back of your mind while you were fiddling with your setup, nerd. Only this time you can dig your own grave so much deeper, so much faster!
Anyway, here's my (current) Pi setup for Tuna development:
The Setup

From, umm, the outside in:
macOS: Least worst OS. I used to love it uncondtionally. Lately, it's complicated.
Ghostty: It's good.
tmux: I'm used to it. I keep projects running in sessions. I use tmuxinator for session bootstrapping. I've done so for 10+ years. Nothing new there.
Ghostty and tmux are configured to add key bindings native to macOS, like cmd + shift + [ and ] to move between windows (tmux for tabs). opt + ← to move cursor whole words.
The workshop
I tried worktrees first in a spawn-on-demand fashion, making new ones ad hoc. I found it distracting and cumbersome. What's working for me instead is to have separate, parallel worktables ready for work. I can work on just one table, and I often do, and when there's more to do while one is busy, I move to another.
Sometimes I have all 4 going. But when I do, I don't want a fifth. Four, one mostly stable main, three active work tables, is hitting the max capacity of my brain. I don't think one more would make me more productive, only more confused.
It's kinda like load balancing but for agentic workloads. My mind can somehow better contain this stable, known workshop than sporadic expansion and contraction. I've even found that I sometimes automatically use the same table whenever the work is of a specific character.
The loop
In Tuna, I track issues using tickets. I used beads before it started to feel like malware and ticket does enough.
I have a Poof snippet that expands to …
Investigate and plan issue [cursor] then $ask-questions-if-underspecified
I've told Pi to recreate Codex' trigger skills inline with $ behaviour. I like the explicitness of requesting them manually.
When Pi starts working, it runs a hook that toggles a bot glyph in its tmux window title.
When done it sends a terminal bell signal which tmux has support for built-in. I just made it display as a cute waving Nerdfont hand glyph.
With a project-local extension to Tuna, I can build and run Tuna from inside Pi with ctrl + space. That's the ▶ just run line above the prompt box. If an existing Tuna process is running, it's killed when the new one starts. No Xcode necessary.
This makes it extremely easy to switch between contexts and worktables. The only reason I ever have Xcode open now is for its SwiftUI previews which sometimes come in handy for the quick feedback cycle.
For review, a ctrl + b g in tmux opens a full-size delta git diff view. For most reviews I just use that.
For proper review with comments, I have a /vim-review extension that opens a vim with the full diff. I can annotate and comment inline and when I quit, the relevant parts get staged as a prompt for Pi to consider.
As tasks finish, I refactor pass, commit and regroup. These are three separate, globally available, generic skills.
refactor-passchecks the changes and simplifies. Removes dead code or premature optimization. It's like 15 lines of Markdown and it works surprisingly well to keep codebases clean at the micro level.commitdescribes my preferred commit message style. Nothing crazy. I'm of the [Imperative] [change description] school. Update docs, Fix billing, that sort of stuff. Nochore: whatever.regrouprebases onmainthenmerge --ff-onlyies the work branch from there. I've always preferred a linear git history and when agents can so easily fix rebase conflicts, I don't see why not.
The aesthetics
I like things to look clean. Enough info to be helpful, not so much that it's distracting.
I made Pi replace the existing prompt box with the bordered, annotated one you see above. Over time I added more bits to it, like the git branch and status.
A small model generates a summary of the current task. It has Pi status and some current model info.
Notably, I don't include context size. Contrary to what many smart people are saying, I don't find it necessary to babysit your context size. The GPT models are very good at compacting and carrying over the right bits.
So flushing the context and starting anew is mostly just a gut feeling thing for me. Like how hiding you battery percentage level makes you stress less about your battery percentage level (!) I've found I only unnecessarily worried about context size when I was constantly confronted with it and its cost.
I use GPT 5.5 for everything. On very rare occasions I'll use Opus for some design work but that's going away too. I used to run on high reasoning for everything but 5.5 is actually better on low, curiously enough. I think the models are just so highly tuned for agentic workflows and tool calls now that the extended reasoning just gets in the way.
Overthinking isn't helpful. Such a human thing for a computer to experience.
I made Pi figure out how to run the OpenAI models on Codex' /fast mode by looking at the open source Codex source code and it did. Spends double the tokens (or whatever) but I've never run out on my $200 Pro plan.
I made Pi make a terminal ANSI colors based, Zenbones theme for itself. I switch back and forth between light and dark mode and hate it when tools, terminal tools especially, don't work in both. Keeping things to my 16-color ANSI Ghostty theme makes things much easier. Syntax highlighting, the unicorn vomit kind, is a scam.
The future
I wrote none of the code for any of this setup. I have barely read it. But seemingly it works. I am not worried about this. On the contrary, I find it thrilling that I can just speak my ideal workshop into existence. What a time to be alive.
All of this is shared and copyable from my public dotfiles – however before you do: I would encourage you to instead prompt your own way there. If you want something specific, send the link to Pi and tell it recreate. Modify it to your liking. Get a feel for what it's like.
Now, the future of software... Is this ... it? Will all software be like this where you just tell it what it should do and look like and it does? It's interesting to imagine. Until then, might as well make ourselves comfortable.