Paul Phan 👨‍💻

You really need to check this out

MCP vs CLI for LLMs is the wrong discussion. People are debating at the wrong layer. Both work incredibly well as long as they are run through a repl like environment that can persist state. The funny thing about CLI is that CLI tools are usually accessed through BASH which happens to be a repl with persistent state (the file system), therefore cli works much better than mcp. But this isn't even close to being an intrinsic property of MCP. Just means that we need better harnesses. Right now the best repl for this are: - bash + fs - jupyter kernels - codemode type repls, usually quickjs LLMs understand the concept of forward evolving a system to solve a need very well. This comes from the agentic RL. They understand how to change the state of a codebase or acquire data from databases and then operate on it similarly to humans. But without an execution environment, they actually cannot do this properly. My bet? Sometime soon someone will (or has already?) create a embeddable, sqlite style mini execution environment that parses bash, typescript, or tool calls into a common IL execution plan that's easy to security check before executing. And design this specifically for durable execution environments. Then we will just connect cli, mcp, webmcp, whatever to that and it accepts any of the input modalities as they can all be represented as each other.

Yep. Except: 1. This was about important internal tools. The team was stuck in some architecture nightmare of their own doing (writing it in rails but headless, with graphql api, and a SPA react app, constantly needing frontend engineers for changes). I call this kind of thing 'cosplaying an enterprise production app'. All that complexity was in the way and using straight rails was perfect in that case. 2. I make calls like this all the time. Usually someone on the team asks me to. They see what needs to happen but don’t want to be the bad guy. I’m happy to just make the call if I agree with the premise. Saves enormous amounts of meetings and change management etc. Sometimes this is jokingly referred to as Founder-mode-as-a-service here. 3. For ten years I’ve also run an internal podcast called Context, where I revisit decisions like these and explain the reasoning so everyone can learn from them. This is helpful to give people all the variables that were considered and why this was the choice made given the information available at the time. I want to teach how to make such decisions effectively without needing me. Sunk cost fallacy is a problem. 4. Any notions that Shopify is succcessful despite of me doing this, instead of because of it, will have a hard time making their argument come together I think 😄 the part of 'two weeks later tobi learns about...' is nonsese and the pivot of that project up there happens one of the more successful examples of interventions. But getting the company to work effectively with great architecture and low technical debt baggage into the right direction is literally the job, so guilty as charged I suppose. But there are always cope stories floating around like this because they are more fun, than saying 'somehow we needed tobi to stop doing silly architecture astronautics'. I can totally see that.

my favorite way to explain people herdr is to just open a new workspace, launch an agent and tell it to: read `herdr --skill` then split 10 other panels that make my computer look like some scifi hacker terminal from the movies