Pi is a tool for craftsmen
I have been completely hooked on agentic coding for a few months now, in a way I did not expect after the hesitations I wrote about earlier. These past weeks I also spent a lot of time watching long podcast conversations:
- Anders Hejlsberg on designing TypeScript,
- Mitchell Hashimoto on building HashiCorp, and
- Mario Zechner with Armin Ronacher on building Pi.
One question kept surfacing: not whether to use agents, but how to remain the person driving them.
Developers have always been opinionated about their tools; some of this is tribalism, but mostly it is that a tool you genuinely own changes how you think with it. The shell config, the vim config you spent hours on is not time wasted; it is what lets you stop thinking about them.
Pi starts from this idea.
It is a minimal coding agent: a terminal UI, a handful of tools (read, write, edit, bash), a TypeScript extension system. No hidden layers; no features you did not ask for. Mario built it after leaving Claude Code, which kept doing things behind his back: system prompts changing silently between releases, workflows breaking without warning. A hammer should not update itself overnight. When the core is small enough to read in an afternoon, you understand what you are working with.
Because Pi extends itself through TypeScript modules, you can ask it to build the harness your specific project needs. Pi ships with no plan mode, no MCP, no sub-agent orchestration. People add them by asking Pi to build them into itself.
The craft has not disappeared. It has moved upstream.
Before, the hard part was writing code line by line, feeling the design take shape. Now it is reading agent output critically, knowing when something is wrong, building the feedback loops that let an agent do good work. Agents write more fluently in languages with deep training data, Python or TypeScript. They improve faster with tight feedback: a type checker, Rust’s compiler, a test suite they have to pass before moving on.
Agents accumulate complexity without feeling it. They will add another catch clause, another fallback, without ever having maintained the tangle those choices eventually become. Senior engineers know which shortcuts compound into disasters six months out; that knowledge does not come from prompting well. It comes from having been burned.
Mitchell Hashimoto has a rule: always have an agent working on something in the background, of course he decides what. The agent does not interrupt him; he checks in when ready. There is a game to it: before leaving his desk, he asks what slow task the agent could work on while he is away. Not a hundred agents running unsupervised. One person with enough understanding to design the right question.
I like Pi, it does not answer whether to use agents. It answers how to stay the person driving them.
