How Flask Creator Armin Ronacher Uses Claude Code [With Examples]

Armin Ronacher is known for treating Claude Code (Claude CLI) as "a fast but instruction-faithful junior engineer," and for optimizing the environment itself for the agent's work loop. In this article, we dig into his practices, quoting concrete examples from his blog.

This article is our own research-based summary of Armin Ronacher's blog posts. The quotations are excerpts from the original posts, with sources listed at the end of the article. Please always check the original posts for the precise nuance of the wording.

1. A Setup That Is "Cheap, Isolated, and Full Throttle"

The first surprise is his sense of cost. He states clearly that he uses not the expensive Opus but only the Sonnet model on the $100-a-month Max plan.

I predominently use Claude Code with the cheaper Max subscription for $100 a month. I exclusively use the cheaper Sonnet model.

— Agentic Coding Recommendations (2025-06-12)

He then uses a claude-yolo alias that fully skips permission prompts (it is really claude --dangerously-skip-permissions), and neutralizes its danger with environment isolation via Docker. The idea is: "Instead of running full throttle in the open, run it inside a box where any damage stays contained."

# Run at full throttle without showing any permission prompts (conceptual)
alias claude-yolo='claude --dangerously-skip-permissions'

# But seal off accidents by confining the whole dev environment inside Docker

2. Logging Practices That Let the Agent "Self-Diagnose"

One of his especially practical tricks is to record all output to a file as well. This lets the agent re-read the logs and pin down the cause on its own.

I am not only printing the output to my terminal, I'm also always logging it to a file.

— Agentic Coding Recommendations (2025-06-12)

Specifically, he starts the services with make dev and makes the logs followable with make tail-log. For the process manager he uses a fork of shoreman, which writes a pidfile to prevent double startup. He even outputs the sign-in emails (confirmation links) to the logs so that the agent can complete the authentication flow by itself, and he documents that procedure in CLAUDE.md — that thorough.

# Output is also kept in a file with timestamps, so the agent can read it and self-diagnose
make dev        # Start services via the process manager (output also goes to a file)
make tail-log   # Check the latest logs

3. Writing "Code That an LLM Can Read Easily"

His most distinctive argument is the stance of designing code with the agent's ease of understanding as the top priority. His blog lists concrete rules (all quoted verbatim).

Prefer functions with clear, descriptive and longer than usual function names over classes.

Avoid inheritance and overly clever hacks.

Use plain SQL. I mean it.

Keep important checks local.

— Agentic Coding Recommendations (2025-06-12)

• Longer, descriptive function names over classes — easy for both humans and agents to find with grep
• Avoid inheritance and overly clever hacks
• "Use plain SQL. I mean it." — trust the quality of the raw SQL the agent writes over an ORM
• Keep important checks local — make permission and security checks visible right next to the code they relate to

The same logic runs through his language choices. He prefers Go for the backend, citing "explicit context.Context," "cached test results that make the iteration loop efficient," "structural interfaces that are easy for an LLM to interpret," and "strong backward compatibility with little churn in the ecosystem." And he notes that by 2026, for the same reasons, he had started reaching for TypeScript over Python.

I'm now routinely reaching for JavaScript in places where I would have used Python. Not because I love it or the ecosystem is better, but because the agent does much better with TypeScript.

— A Language For Agents (2026-02-09)

4. His Thesis: "Code (CLI) Over MCP"

He is skeptical of MCP (Model Context Protocol) servers and argues that agents should write and run code rather than call tools. The test he recommends to readers is this.

Try completing a GitHub task with the GitHub MCP, then repeat it with the gh CLI tool. You'll almost certainly find the latter uses context far more efficiently.

— Tools: Code Is All You Need (2025-07-03)

A large number of dedicated tools eats up context. In his words, "the more tools you add, the more you contribute to context rot." Instead, he argues, it is more composable and efficient to have the agent program against a single stateful "ubertool" (effectively a Python interpreter). It is an extension of the old maxim "replace yourself with a shell script" to delegation to LLM-generated code.

5. Publishing What "Didn't Work" Too

He frankly records not only his successes but also the techniques that had no effect ("Things that didn't work"). This is extremely valuable for practitioners.

• Custom slash commands (such as /fix-bug, /commit, /add-tests) — they never stuck, because "it ends up being no different from pasting an issue URL" and "they don't fit my own style"
• Hooks — "I tried hard to use them, but I saw no improvement in efficiency." Instead he steers tool selection with a PATH interceptor
• Print mode (-p) — a good concept, but "slow and hard to debug"
• Sub-agents — starting a new session or writing his thoughts out to Markdown often gave better results

In short, his style is to determine through experiments that "a feature touted as a best practice does not necessarily work for your own workflow." He also notes that by the end of 2025 he had shifted from Cursor-centric work to a largely hands-off, Claude Code-centric approach, describing himself as wanting to be "an engineering lead directing a virtual programmer intern rather than the one hitting the keyboard."