I learned how to code in 2019. At the time, my coding setup was extremely minimal: it was just my code editor, Sublime Text. I later switched to VS Code and stuck with it for years. It worked for me so I had no reason to question it.
The first real shift came with GitHub Copilot.
When it arrived, the value was easy to see, so I immediately gave it a try and quickly incorporated it into my workflow. Copilot felt like magic in the most practical way. It was mostly autocomplete, but a much better version of autocomplete than anything I had used before. I could start writing a function, or even better, write the TODO comment for it, and Copilot would take care of the next few lines.
Then everyone started switching to Cursor. Especially the indie hackers I was following on Twitter (sorry, I still can't bring myself to call it X). They were posting demos, chatting with AI about their codebase, and moving through tasks in a way that made VS Code and Copilot suddenly feel limited. The value was obvious again. I tried Cursor and loved it instantly.
It was also around that time that I discovered Model Context Protocol (MCP). By connecting the Google Workspace MCP, I brought my emails, calendar invites, and call transcripts directly into Cursor, instead of constantly switching tools. By connecting the Shopify Dev MCP, I got direct access to the latest Shopify documentation, without ever leaving my development environment.
Cursor quickly became the place where I spent most of my computer time. It was a great centralization tool, wrapped in a familiar interface.
Then everyone started talking about Claude Code. This time, what intrigued me was the terminal experience. I had watched multiple Anthropic demos, and there was something very compelling about the idea of interacting with a coding agent directly from the terminal.
So I tried it. And Claude Code changed the game for me.
I loved the interface, the built-in tools, and still had my MCP servers available. I felt that there were no limits to what I could build, so I leaned in. I built a mobile app around one of my passions, I launched a playful website for Valentine's Day, created my personal health dashboard based on years of data, and more.
Claude Code was my default coding companion and I was very happy with it.
Recently, I started hearing more and more people talk about Pi. They kept saying it was "better". But this time, unlike Copilot, Cursor, or Claude Code, the reason why was not immediately obvious to me. Because the value seemed unclear, I was reluctant to switch to it blindly. It was the kid in me asking "but why?".
I felt that I needed to pause.
I wanted to understand what Pi is, the vision behind it, the pain it solves, and the solutions it brings. I sat down and watched a couple of talks by its creator, Mario Zechner (@badlogicgames). I also read the documentation, which was beautifully designed. I had no interest in feeding it to Claude and asking for a summary. I wanted to read it myself. Taking the time to process the ideas, understand the tradeoffs, and form my own opinion.
That alone felt important. We are now in a phase where AI tools change so quickly that it could be tempting to even outsource our understanding of them. But that never feels right.
Very quickly, I realized that to understand the value of Pi, I needed to understand the limits of Claude Code, and that's why I didn't understand it at first. I had never felt limited with Claude Code, except regarding how fast it was burning tokens maybe.
The thing is in Claude Code, a lot of decisions have already been made for you: the models, the interface, the built-in workflows, the permissions, the way context is handled, the features available out of the box.
Pi is much smaller by design. It is a coding agent harness: the system around the model that manages the terminal interface, the tools the model can call, how sessions are stored, how context is loaded, and how the whole workflow can be extended.
Its GitHub repository describes Pi as a self-extensible coding agent, and after a week building with it every day, that phrasing makes a lot of sense.
By default, Pi gives the model a small set of basic capabilities: reading files, writing files, editing files, and running commands.
The rest is up to you.
This is where I started to understand the appeal. Claude Code feels like a very capable assistant. Pi feels more like a workshop. The workshop is not empty. The basics are there. But you decide where the tools go, which ones you need and don't need.
The first thing Pi will ask you to do is choose a model provider. Pi supports 15+ providers including Anthropic, OpenAI, Google, Azure, Mistral, Ollama, and Groq, with authentication through API keys or OAuth. It opens the door to hundreds of models.
This reminded me of something obvious: making Claude Code my default tool meant I was limited to Anthropic's models. Anthropic's models are excellent for my use cases, but in an AI world where things move so quickly, it feels useful to compare models against each other and see which ones suit us best, and at what price.
Switching to Pi was an opportunity for me to give OpenAI's Codex 5.5 a try. I won't spend too much time writing about Codex here, I'll just say so far it's been a really enjoyable experience. On my use cases for personal projects, it often seems to land much closer to a complete and robust solution. It feels like I spend less time correcting the direction and more time reviewing actual work.
But model choice was only one part of the shift. The bigger change was realizing that some features I thought I needed could be replaced by simpler, more visible workflows.
A good example is Plan Mode. I used Plan Mode in Claude Code and liked it. It is useful to have the agent think through an approach before touching the code. When I first moved to Pi, I wondered if I would miss it. Then I realized I did not actually need a special Plan Mode. A simple PLAN.md file does the job just fine for my use cases. If I want the agent to plan first, I ask it to write the plan in PLAN.md. I review it, edit it if needed, and then ask it to execute against that file. It is boring, explicit, and surprisingly effective.
This is the part of Pi I am starting to appreciate most. Sometimes the simpler version is better because I can see it.
A concrete example of this happened in a side project where I am building a configurator for my dream car. At first, the project was just a web app with research files, source-backed trim data, and a rough 2D SVG. Then I wanted to explore the path toward a turnable 3D model.
As a first step toward this goal, I asked Pi to build a project-local extension for Blender. The extension adds a tool that can run Blender headlessly, execute a Python script, generate a simple car blockout with separated objects and materials, and export it as a .glb for the browser prototype.
I could probably have approximated parts of this in Claude Code with a skill, a shell script, or an MCP server. But in Pi, extending the harness itself felt like the natural move. The Blender workflow became a project-local tool with explicit parameters, prompt guidance, execution logic, and failure behavior.
Digging deeper into Pi's philosophy, it makes sense why it does not have MCPs built in by default. Of course, you can add MCP support if that is the workflow you want, but Mario Zechner's argument is that many MCP servers try to cover every possible use case, which means they expose lots of tools with long descriptions and consume a lot of context before you even need them. His alternative is simpler: let the agent use Bash, small scripts, and README files that explain how to use them. You pull that context in when you need it, and you can change the tools yourself. If you want to go deeper on this, he wrote an article about it: "What if you don't need MCP at all?"
The other piece that helped me understand Pi is context. Mario Zechner made an excellent point: in many coding agents, your context is not fully yours. The system prompt can change. Tool definitions can change. Extra reminders can be inserted.
I had not thought deeply enough about this before. When an agent gives a strange answer, the issue can come from the model, but it can also come from the tool around the model. The harness, the thing deciding what the model sees, what tools it can use, and how context is assembled, matters just as much.
With Claude Code, I often feel like I am using someone else's very polished workflow. With Pi, I feel like I am slowly building mine.
Of course, this comes with tradeoffs. Pi is not as immediately comfortable as a more polished product. It asks more from you. That is not what everyone wants.
But for coding agents specifically, I am starting to care more about control. These tools are becoming powerful enough that their defaults really matter.
Claude Code was a huge step forward in my workflow. Cursor was too. Even Copilot autocomplete was, at the time, a real shift. But Pi made me realize something important: the best coding agent may not be the one with the most features. It may be the one that gives you the most agency over how you work.
For now, Pi and Codex 5.5 make my coding sessions feel calmer, more controllable, and surprisingly more productive. I am curious to see if that feeling lasts.