The Man Behind the Minimalism

I met Peter Steinberger at Claude Anonymous in London sometime in June, and the presentation was properly fun. He's got that energy where you can tell he's not performing, he's just genuinely excited about the stuff he's building. Maintains a 300k line TypeScript React ecosystem. Web app, Chrome extension, CLI tool, Tauri desktop client, Expo mobile app. All maintained by one person with AI agents. And his setup is basically: open 3-8 parallel Codex instances, write short prompts (often 1-2 sentences plus a screenshot), let them go.

He calls everything else "charade."

I've been following his work since and I reckon he's one of the most practical voices in the agentic coding space. No hype. No frameworks for the sake of frameworks. Just a bloke who ships a lot of code with AI and has opinions about how to do it well.

---

His Principles (and Where I Stand)

Here's the full list from his talk and blog posts. I agree with most of it. Where I don't, I'll say so.

Things I violently agree with:

• Use tmux to run CLIs persistently. Absolutely. This is foundational. If you're not doing this, start here.
• Use ast-grep as a pre-commit hook. Proper structural linting that catches things regex can't. Brilliant addition to any agent workflow.
• Ask for options before executing. I built a whole /interview skill around this. Get the model to present choices rather than guessing. Way better outcomes.
• Don't reset context. Cold start wastes time + tokens. Agreed, but I'd go further. Don't reset, /handover instead. Summarise what was accomplished, carry it to the next session. Cold start is a waste. Context reset without transfer is nearly as bad.
• Give examples. Multi-shot prompting is always better than zero-shot. If you want the model to output something specific, show it what that looks like first. Massively improves one-shot accuracy.
• Use voice input. Absolutely. I started with Superwhisper and it changed how I work. Speaking your intent while pacing around the room is faster and more natural than typing. (Update, February 2026: I've since switched to justspeaktoit by Chris Mitchelmore. Deepgram's $200 free credit and the speed is brilliant. Saved myself 9 quid a month on Wispr Flow.)
• Share screenshots. Visual context for UI work is worth a thousand words of description. The model actually understands layouts from screenshots better than from your description of the layout.
• Write tests in the same context. Tests written in the same session as the feature know the implementation intimately. Better coverage, catches bugs immediately.
• Schedule refactor time (20%). Use jscpd, knip, oxlint. Don't let debt accumulate.
• Make small, atomic commit checkpoints. Commit only what the agent touches. Easy to revert. Easy to review.
• Prefer CLI tools over MCP. We wrote a whole post about why MCP is a context tax. mcporter for when you absolutely need MCP.
• Cancel long tasks and ask what's happening. If the agent has been going for 5 minutes and you don't know what it's doing, stop it. Chances are it's in a hole.
• Keep custom prompts minimal. "commit" is a better prompt than "please create a well-formatted conventional commit message with a clear subject line." Less is more.
• Prefer Medium over High reasoning. The model picks its own thinking depth. High reasoning burns tokens for marginal gains on most tasks.
• Use 3-8 agents in parallel on a single repo. Agree, though I'd cap at 4-5 max before the double pendulum problem kicks in.
• Maintain an evolving AGENTS.md. Delete stale guidelines. A lean AGENTS.md is worth more than a comprehensive one that's half wrong.

Where I disagree:

• "You don't need git worktrees." Hard disagree. Worktrees are brilliant when agents need isolated branches. My swarm setup uses them heavily. The merge step adds overhead but the isolation prevents agents stomping on each other's files.
• "Avoid subagents, RAG, etc." Neutral on this. Subagents have real purposes: getting a code review done while you keep developing, running tests in parallel, preserving the main context window from getting polluted by research. The trick is knowing when the fresh context is worth the setup cost.
• "Prototype in a separate folder / PR." Worktrees for this, not folders. Folders are messy. A worktree is a proper git branch with isolated state.
• "Avoid ALL-CAPS for Codex." Fair for Codex. Claude Code is different. Sometimes emphasis matters in system prompts.

The only real disagreement: instructions need structure.

Peter's philosophy is minimal instructions. Just talk to it. And for a solo dev on a single stack, that works. But the moment you're running multiple agents across different projects with varying conventions, you need guardrails. You need the agent to know "this project uses snake_case, that project uses camelCase" without you saying it every time. You need testing policies encoded, not remembered. You need the structure, even if you keep it lean.

---

The Topology Insight

The real variable isn't tools vs minimalism. It's project topology.

Peter's workflow is a star: one developer, one codebase, all knowledge at the hub. That's 300k lines but it's singular. His approach is optimal for that shape.

The moment you introduce parallel work streams (multiple repos, multiple agents needing different configs, team coordination), the topology becomes a mesh. Meshes need infrastructure that stars don't.

Geek Corner

Star vs mesh topology: Steinberger's setup is one central developer with one codebase. Graph theorists call this a star. All decisions radiate from the hub. A team of developers running agents across multiple repos is a mesh: multiple actors, multiple codebases, shared context that needs synchronisation. The scaffold you need scales with the mesh density, not with some absolute measure of complexity. His advice is perfect for stars. It needs adaptation for meshes.

Feels like: Two chefs arguing about whether you need a prep list. If you're cooking dinner for four, no. Crack on. If you're running a restaurant kitchen with six stations, yes. The answer depends on the kitchen, not the philosophy.

Bottom line: Peter's practices are solid regardless of your setup. Short prompts. Screenshots. Tests in context. Refactoring as 20% of your time. tmux. ast-grep. Voice input. These are good habits whether you wrap them in a framework or just talk to the model. I follow most of what he preaches. The disagreements are about scale and topology, not about the fundamentals. Read his stuff. Nick what works for you.