pi-lot: a slop creep journey

Back in early February I announced on X that I was building pi-lot, a desktop GUI for pi. I had a devlog going, screenshots, the whole thing. "Will post updates as replies below."

Then I just... stopped posting. And stopped building.

This is the post I should have written back then. Not a postmortem. Just an honest look at a bet I made and what came out of it.

The pain

If you've been using coding agents seriously for any amount of time, you know what happens to your terminal.

That screenshot is a typical day for me. I'm switching between two to five repositories daily, and some features span across multiple codebases in a single sprint. That's just the day job. On top of that, once AI became part of my daily workflow, I started picking up more side projects and dev tools. More agent sessions, more split panes, more windows.

My brain was fried from context switching. Something had to give.

The attempt

Around that time, the Codex desktop app dropped and I liked it. But I was already using pi for my day-to-day development and wanted to go deeper with it. I'd been testing and comparing a lot of tools by that point. Pi let me configure my own environment, extend the harness, switch between different LLMs, and honestly my API limits lasted longer. So I saw a gap and thought: maybe I should build that.

pi-lot was going to be a desktop app that brings pi agents to your screen with full visual control. Streaming chat, tool execution display, model selector, session management, analytics. The whole thing.

I set it up and started building. And by "I started building" I mean I told the agents to build it. The project was 99% vibe coded. I barely wrote any code of significance myself. Fixed a few UI flickering bugs as the agent streamed responses, but that's about it.

It felt pretty good. I wanted specific things like a review view, a way to see changed files, some analytics on my workflow. And once the project was set up it was quick to just tell the agent what I wanted and watch it happen. I felt powerful, like I could just do things. Every evening I ran this code quality and security audit pass where I refactored code, made sure things would scale, explored new technologies on the side. It was genuinely fun.

~57,000 lines of code across 339 files in 10 days. Session managers, event reducers, regression test harnesses, a full theme system, routing, analytics. The kind of codebase that normally takes a small team a couple of months.

160 agent sessions. $389.65 in API costs (if I didn't have a subscription). 525 million tokens. 9,806 tool calls.

You can see the curve. It ramps up fast, peaks around Feb 6-8, and then drops. That curve is basically this entire blog post in one image.

But as a software engineer, you know what that much AI-generated code actually creates. You know the complexity hiding underneath.

The reckoning

The feeling of power was real, but it was also temporary. Here's what started becoming clear:

I have a full-time job. And friends, and family. Even if I could multiply my capabilities by 10x or 100x with agentic coding, I wouldn't be able to maintain a desktop app long-term. And beyond the maintenance, I'd never build the kind of gut feeling you get from working on a codebase over months and years. Given the scope and possible ways the project can evolve I quickly realized that it is not a small task. I would have needed to basically quit my job to do it properly. And that didn't look like a justifiable action.

It was mentally draining. Work doesn't slow down because you had a productive weekend on a side project. Friends and family don't pause. Other side projects that are waiting on you don't disappear. I was constantly toggling between everything: day job, pi-lot, personal life, other things I was working on. And on top of all that, I had announced it publicly. I felt like people were expecting updates, expecting something to ship. Whether anyone actually noticed or cared, I honestly don't know. But the pressure I put on myself was real either way. The combination of trying to sustain that intensity while carrying all these other responsibilities just wasn't sustainable.

The ecosystem was moving fast and I was missing it. Pi's plugin system was thriving. New things dropping every day. Tools like cmux, Superset, and Conductor were showing up and tackling the same problems as standalone products. While I was heads-down wrapping features in a desktop app, new extensions, new patterns, new ideas were passing me by. I slowly re-realized that the actual core of the work is just becoming coding with agents, talking to them, adding tools and documentation and context to support them in each project.

I wasn't the right person to solve this. Even Theo (t3.gg) published T3 Code around the same time, which showed this was a real, widely-felt problem worth solving. But I didn't have years of agentic workflow experience to really feel the pain deeply enough to come up with the right solution. I also hadn't worked in the problem domain of streaming chat interfaces, building GUI dev tooling used by many people daily. That's a tool people rely on every day, especially when it aims to be the primary tool they use to code. That comes with a responsibility to make it work without bugs. That's a big undertaking that shouldn't be done on the side. The solution wasn't fully set yet and I didn't have the passion to drop everything and figure it out. That's okay. Not every gap you see is your gap to fill.

I knew better. I've been doing side projects for years. I already learned the lesson of how hard it is to maintain one or more projects on the side. But the feeling of speed and efficiency made me forget about that. It pulled me into this dopamine-filled journey where everything felt possible. You see the lines of code stacking up and you start thinking you can actually ship a product. But even with good architecture, even if you read most of the code, you can't keep the full context in your head when things change this quickly. The knowledge and efficiency you get isn't earned. You're moving on instinct, but you've never felt the pain of working on that codebase for long enough to make the right nuanced decisions.

The pivot

The better investment was obvious once I saw it: build my own workflow and plugins within the pi agent instead of building an app around it.

The things that actually matter for my day-to-day work, the documentation, the context, the extensions, the knowledge base, none of that requires a GUI. It requires thoughtful configuration. And building for agents versus building for yourself as a human turned out to be two very different things that belong in different places. pi-lot was trying to be both at once.

So I shifted to building extensions and skills for the agent-facing layer, and a separate observation tool for the human-facing layer that gives me session analytics, cost tracking, and usage patterns. Not a GUI wrapper around the agent. Just visibility into what it's doing. The reason I open sourced the agents setup isn't for people to copy-paste or use my extensions. It's more for me to experiment in public. One of the things I've started doing is adding specs to each plugin so people have an overview and can point their own agents to build something similar for their own setup.

The insight

Your agent setup is your vim config now. But for the cognitive layer.

Developers have always brought personal tooling with them. You spend years configuring your editor, building macros, setting up snippets. When you start a new job, you pull your dotfiles and keep working. What's changed is what you can encode. Previously it was mechanical stuff: shortcuts, formatting, navigation. Now you can encode how you do PR reviews, what you check during a security audit, how you structure documentation. Your analysis patterns, your knowledge base, the things you know.

I think the highest leverage thing I can do as an engineer right now is investing in that personal infrastructure. Not building products for other people, but building the systems that make me more effective. And if a calling does come one day, all of that compounds and makes me better equipped to build it.

And unlike a product, your personal infrastructure can be disposable. A typical personal tool is maybe 500 to 2000 lines. If it breaks, you know immediately because the scope is tiny. You can write a spec and have the agent rebuild the whole thing in a couple of hours in the background. The cost of failure is basically zero, which means you can experiment freely. Compare that to maintaining a product where every feature you ship is a promise to every user who depends on it. That's a completely different game.

The cost of building has collapsed, but the cost of maintaining, supporting, and committing to the thing you built hasn't changed at all. I've seen this play out at work too, where the instinct is "AI is the solution, now let's find the problem." Speed makes it tempting to build everything you can see a gap for. Knowing what not to build might be the more important skill right now.

The reframing

If I could go back and talk to February version of me, I wouldn't tell him not to build it. I learned a lot about agentic coding, how to set up a project from scratch, how to maintain one, how to work with agents on something real. It was genuinely good to get my hands dirty and explore.

What I would change is how I framed it publicly. I posted it on X like "I'm building this thing, it's coming, follow for updates." Got some people excited. Set expectations. Then went silent.

I should have framed it as: "Hey, this is an experiment I'm doing and I want to share it with you. This is cool and you can do it too, it's fairly easy." That's a very different energy. One is a product announcement. The other is sharing a learning journey.

Armin Ronacher wrote a blog post recently that really resonated with me:

What makes a good Open Source project is that you think and truly believe that the person that created it is either going to stick with it for a very long period of time, or they are able to set up a strategy for succession, or they have created enough of a community that these projects will stand the test of time in one form or another.

I completely agree with this. And it's exactly the test I failed with pi-lot. I didn't have that belief. I didn't feel like I'd stick with it for years.

So this is the official update to that X thread: pi-lot is shelved. The learnings are not. And the slop creep was absolutely worth it.