AI Agents Do Not Need More Tools: Armin Ronacher's Conservative Approach

Source note: This article is my structured reading of David Ondrej’s interview with Armin Ronacher, “Pi Agent dev reveals his Agentic Engineering Workflow,” followed by my own synthesis. Ronacher is the creator of Flask, Jinja and Rye and part of the team behind Pi. Statements about Pi, his workflow and agentic engineering come from the interview; they are not claims about my own work. Watch the original video.

The conclusion first

AI coding tools tend to pull users in one direction: more tools, more agents, longer context, then move the entire setup into the cloud. Armin Ronacher’s approach is almost the reverse.

He prefers an agent with a small core that relies heavily on Bash. His daily work remains local and grounded in a real development environment. He does not treat token usage, commit count or agent concurrency as evidence of productivity.

This is not a rejection of automation. It starts with a more basic question:

Does the automation produce better software and larger outcomes while remaining understandable and accountable to people?

If Lauren Tan’s workflow argues that trust has to be produced by the environment, Ronacher supplies the other half: a trustworthy environment does not have to be elaborate. Fewer abstraction layers can make verification easier.

A minimal harness lets the model use the computer it already knows

Pi’s core design is deliberately small. Rather than define a specialized tool for every operation, it lets the model make extensive use of Bash, rg and existing command-line tools.

Searching a repository does not require a dedicated code-search tool:

rg "createSession" src/ tests/

The agent can narrow results with a Unix pipeline:

rg "createSession" src/ \
  | cut -d: -f1 \
  | sort -u \
  | head -n 20

The apparent simplicity has practical advantages:

• Models have extensive training data for shells, Git, Linux and common CLIs.
• Intermediate data can be filtered in the process instead of copied into context.
• Engineers can replay the same command and locate failures directly.
• The harness does not need to define, maintain and explain a schema for every capability.
• General-purpose tools compose into workflows that the harness author did not anticipate.

Minimal does not mean incapable. It leaves capability in systems the model already understands. The harness provides a dependable execution environment instead of trying to abstract the whole computer away.

Extensible is not the same as preloaded

Pi also attracted users because they could turn it into their own tool. Its core stays small while extensions and plugins cover specialized needs.

That is different from installing every available MCP server, skill and subagent in advance. Each additional capability has a cost:

A better sequence starts with general capabilities. When a workflow recurs, its steps are stable and the same constraints repeatedly matter, then it is worth packaging as a skill or extension.

flowchart LR
  T[Concrete task] --> B[General tools<br/>Bash · Git · CLI]
  B --> O{Does it recur?}
  O -->|no| D[Finish the one-off task]
  O -->|yes| S[Extract stable steps and constraints]
  S --> E[Package a skill / extension]
  E --> V[Keep verifying; remove stale capabilities]

Skills should grow out of successful practice. They should not begin as an elaborate organization chart.

His workflow is less dramatic than a software factory

Ronacher is candid that he has not built a software factory that automatically works through every issue. His current engineering practice remains conventional in important ways:

1. Coding agents run primarily on local machines, where the real repository lives.
2. Longer tasks can run on a Linux machine reached over SSH.
3. A small amount of Pi automation lives in GitHub Actions.
4. Much of the work is not code generation. He uses the agent to investigate repositories, understand problems and decide how a system should behave.
5. Implementations are tested in an actual development environment.

This does not produce an impressive agent count. It does resemble the reality of complex software: the hard part is often understanding an existing system, its hidden constraints and the correct behavior—not typing the implementation.

Agents can accelerate investigation and implementation. They cannot decide the intended semantics of a product on an engineer’s behalf.

Local versus cloud is a question of environmental fidelity

Cloud agents offer clear benefits: parallel capacity, long-running execution and less pressure on local hardware. Ronacher nevertheless remains local-first today for practical reasons rather than ideology.

In the interview he describes inspecting a cloud setup that appeared to run database tests. PostgreSQL was not running at all; the database behavior had been mocked away.

That reveals an often-missed distinction:

The test command returned success
              !=
The system works with its real dependencies

The useful question is not simply “local or cloud?” It is whether the environment is real enough for the claim being made:

Complex projects need fast, isolated and reproducible development environments. Cloud infrastructure will likely become a strong fit, but only when it can actually boot PostgreSQL, Kafka, queues and the surrounding services—not merely turn a test dashboard green.

Durable state matters more than mystical memory

Ronacher is cautious about framing every agent problem as “memory.” He is more interested in whether state can be stored and manipulated reliably:

• Can a session be suspended and resumed?
• Can it move across machines or model providers?
• Can important information survive server-side compaction?
• Can people inspect, edit and delete data created by the agent?
• Does task state live in explicit files or a database, rather than only in a chat transcript?

This helps explain why Markdown, JSON, Git and Unix pipelines have gained importance in agent workflows. They are not glamorous, but they satisfy three useful properties: people can read them, machines can manipulate them and state can persist.

Instead of hoping a model somehow remembers everything, give important state a visible home.

Chat is a temporary interface

Most agents currently live in a terminal or chat window, but many problems are not naturally conversational.

An agent managing a smart home should be able to show rooms, device state, sensor data and controls. An agent investigating a production incident should be able to present a timeline, service topology, traces and interactive filters.

This may not require a breakthrough in model intelligence. The missing pieces are familiar systems problems:

• State management
• Durable sessions
• Component libraries
• Database access
• Permission boundaries
• Representations shared by humans and agents

The future agent interface needs to let models act while allowing people to understand what they are acting on.

People still need understanding because responsibility cannot be delegated

When the interview turns to banks and other high-accountability systems, Ronacher’s position is direct: an organization cannot blame the model after something goes wrong.

As long as people inherit the consequences, they will demand:

• an understandable view of current system state;
• provenance for changes;
• reproducible verification;
• traceable decisions and inputs;
• a path to diagnose and repair failures.

A future made entirely of machine-generated systems that only agents can understand is therefore not practical on the visible horizon. Even if agents implement most of the code, architecture, state and evidence still need to be legible to people.

This is why agent-friendly and human-friendly codebases overlap: clear boundaries, consistent naming, simple data flow and replayable commands help both.

Agent count is not a productivity metric

Ronacher is skeptical of the current productivity narrative. It is easy to display token consumption, commits or concurrent agents. Those numbers do not necessarily describe product or business outcomes.

Heavy agent use also creates new costs: model subscriptions, cloud execution, review queues, security checks, verification infrastructure and the attention required to switch between workstreams.

Better measurements connect activity to outcomes:

Cheaper code does not automatically mean cheaper software worth maintaining.

Agents are changing technology selection

Some technologies have long been good fits for a problem but expensive for people to learn and operate. Agents can change that balance.

Ronacher mentions Linux, NixOS, Rust, complex databases and Kafka. Their human learning curves can be steep, but an agent can draw from extensive public documentation and examples. Once setup and boilerplate become cheaper, teams may be more willing to choose the more complex but durable option.

The reverse is also true. Products with thin documentation, weak CLIs, unstable automation interfaces or little public material may become harder for agents to use.

Technology selection will increasingly include agent experience alongside developer experience:

• Is the documentation explicit and searchable?
• Is the CLI stable, composable and disciplined about exit codes?
• Do errors suggest an actionable next step?
• Can state be inspected in text or structured formats?
• Can the complete workflow be reproduced in an isolated environment?

My reading: make one loop real before building a factory

Ronacher is not arguing that everyone should use one local agent forever. His objection is to using agent count and token consumption to simulate progress before a single workflow is reliable or valuable.

I would translate the interview into this adoption order:

1. Make one agent complete one bounded task in a real environment.
2. Prefer Bash, Git and project CLIs it already understands over unnecessary abstractions.
3. Let tests touch real dependencies; do not treat a fully mocked path as sufficient evidence.
4. Persist important state in files, Git or a database—not only in conversation context.
5. Package a workflow as a skill, extension or automation only after it recurs.
6. Add cloud execution, parallel agents and a software factory only after one loop is reproducible.
7. Evaluate product outcomes, reliability and total cost instead of using output volume as a substitute for value.

Lauren Tan shows how far a team can go after building strong verification infrastructure. Armin Ronacher reminds us what must be true first: the environment has to be real, the system has to remain understandable, and every added layer of complexity has to earn its place.

Source

• David Ondrej interviewing Armin Ronacher, Pi Agent dev reveals his Agentic Engineering Workflow, 2026.