The Positive Effects of Friction in Automated Development; or, Pi Is Bad — Dan's Musings
Dan's Musings
The Positive Effects of Friction in Automated Development; or, Pi Is Bad
Published on August 4, 2026
Introduction
I have recently tried the AI harness Pi . I'm coming from it<br>from a harness that I first picked up when all this stuff was sort of newer<br>called Goose. I can see what all the hype is about,<br>but I actually had a bit of a "better is<br>worse" experience with it. I think<br>I'll be sticking with Goose for now. I have come to the conclusion that it is<br>because of the friction Goose introduces into the system makes it better.
In the rest of this blog post, I describe the differences in my experience<br>running Pi versus Goose using Open Router's<br>deepseek-v4-flash model.
Experiment Design
I type a short three-to-four sentence prompt into Goose and it just works.<br>Sometimes I would need to provide guidance, but once I get it going, I can often<br>step away from my desk and come back. I often heard anecdotes about how AI could<br>"slip the leash," like cheat on unit tests, implement the wrong thing, do<br>exactly what they were told not to do, that sort of thing. I really didn't<br>understand these complaints. I would just write stuff, give the AI the<br>occasional dont-do-that-do-this, and it would do okay. However, I tried the same<br>short-style prompting on Pi, and it immediately started slipping the leash.
I tested using Pi on a project I'm porting from Clojure to Common<br>Lisp. I wrote a skill that told it how I<br>like Common Lisp to be<br>written.<br>In there I said to write a bunch of<br>beads. I initially set up Pi to write<br>beads via the bead MCP<br>server.<br>Then I told the AI to use the beads MCP in the skill I wrote and later it was<br>also in the AGENTS.md file. I started Pi up, and told it to read AGENTS.md and I<br>also gave it an initial prompt to use the skill and start porting code.
Problem 1: Pi Ignores MCP Servers
When I started Pi up, it also immediately ignored what I told it to do in the skill. It<br>didn't write any beads and just started writing code almost immediately. I had<br>to yell at it two or three times before it figured out "oh yeah, I should stop<br>and write beads." I stopped Pi and did some research to determine the underlying<br>cause of this flagrant ignorance on the part of the AI.
The Pi MCP plugin lazily loads the MCP<br>servers into the context by default. Mario Zechner wrote an interesting blog<br>post about<br>how MCP might not be great because it introduces tokens into the context window<br>about the MCP tools whether you use them or not. The MCP adapter in Pi follows<br>this philosophy. It only loads the definitions of the MCP tools into the<br>context. Because of this, my mention of beads was probably the first occurrence<br>of beads that the AI saw. Not knowing what to do about it, it probably just blew<br>past it.
I started it up again with a bead plugin instead of using the bead MCP server.<br>However, I couldn't take this approach with the Common Lisp<br>cl-mcp MCP server. No one had written<br>an equivalent plugin. Pi kept deviating from my telling it to use the MCP<br>server, and this was a big problem. Running Common Lisp code from the CLI often<br>drops into the Lisp interactive debugger. Common Lisp doesn't like being vibe<br>coded,<br>and the interactive debugger is one of those reasons, but there are many.<br>Long-running REPL development, REPL reloading, one-off Lisp evaluations within<br>the REPL environment, Lisp-form-level editing (rather than line editing), and<br>parenthesis balancing are all problems with which AIs often struggle. The cl-mcp<br>server fixes several of these problems, and more besides.
Goose handles the Lisp debugger really poorly when it runs Lisp code through the<br>CLI. In Goose, the debugger totally hangs the Goose session and Goose must be<br>restarted. When I restart it, I tell Goose "You used Lisp CLI tools again, don't<br>do that, use the MCP server." I use Goose's Top Of Mind<br>feature to remind Goose to use the MCP<br>server instead. When Top Of Mind enabled, I have more or less stopped having<br>this problem with Goose.
Pi handles the debugger and even parenthesis balancing<br>more gracefully than Goose, but this actually caused problems within the<br>session. Pi seems to put the Lisp process in its own shell and handles the<br>interactive prompt gracefully by killing it when it gets to the debugger prompt.<br>Like Goose, though, I still wanted to enforce the use of cl-mcp . Pi didn't<br>have a top-of-mind-style context injection system available in its package<br>system, when I was running this test, so I made a top of mind plugin for<br>Pi and used that to<br>remind Pi of the MCP server. Even with my putting it into the context every 10<br>tools calls or so though, Pi kept messing up and stopped using the MCP server.<br>It kept getting big enough rewards from the ad-hoc interactions it had with<br>Common Lisp through the CLI that it stopped using the proper tool for the job,<br>specifically designed to help it get better results.
Problem 2: Pi Is Too Fast
With...