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.

248 commits in 10 days. ~57,000 lines of code across 339 files. 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 248 commits of mostly AI-generated code in 10 days 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. That intuition for where things break, what the code actually needs next, how the pieces fit together. You don't get that by vibe coding 248 commits in 10 days. That kind of project is not a small task. I would have needed to basically quit my job to do it properly. And I didn't want to quit my job for this.

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. For most use cases, you don't really need to build your own GUI. The actual core of the work is just 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. About a month later, Theo (t3.gg) published T3 Code, which confirmed the problem was real. Everyone was seeing it. But it was a huge and heavy lift for one person to do on the side. I had a gut feeling about the problem, but I didn't have years of agentic workflow experience to really feel the pain deeply enough to come up with the right solution. 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.

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 what became my agents project: a pi package with custom extensions, skills, and themes for the agent-facing layer. And for the human-facing layer, I'm building a separate observation tool that gives me session analytics, cost tracking, file hotspots, and usage patterns across all my projects. Not a GUI wrapper around the agent. Just visibility into what it's doing.

That's been my main investment since, and I update both almost daily. The difference is I can see myself doing this for years. Building a desktop editor for other people? That's not my thing.

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 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. I do have that belief for my agent setup whether it is public or not...

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.