DHH Describes Coding with AI Agents as "Wearing a Mech Suit." The Rails Insight Is Genuinely Non-Obvious.

The Pragmatic Engineer profiled DHH's agent-first workflow, and it's the most useful description of how a senior developer actually works with AI agents that I've read this year. DHH runs two AI models in tmux alongside neovim. He describes the experience as "wearing a mech suit" rather than managing a team of junior developers.

That framing matters. The dominant narrative around AI coding agents is that you become a "project manager of agents." DHH rejects this. The mech suit metaphor means you're still doing the work. You're still the one with the intent, the taste, the architectural vision. The AI amplifies your movements. It doesn't replace your judgment.

The shift happened, he says, when models moved from tab-completion to agentic harnesses. Tab completion is autocomplete. Agentic harnesses produce merge-ready code. DHH traces this to Opus 4.5-class models and their ability to hold entire codebases in context while making changes that pass tests.

Here's the genuinely non-obvious insight: DHH argues Rails is one of the most token-efficient frameworks for agent workflows. Why? Because testing is built into the framework. Rails comes with a test runner, fixtures, factories, and conventions that agents can follow without explicit instruction. The agent writes code, runs tests, iterates. The framework's opinions reduce the prompt engineering needed to get correct behavior.

I hadn't thought about framework choice through the lens of agent efficiency. But it makes sense. A framework with strong conventions gives the agent guardrails. A framework that says "do whatever you want" forces the agent to make more decisions, use more tokens, and potentially make more mistakes. This has implications for every framework choice going forward. It's not just about developer ergonomics anymore. It's about agent ergonomics too.

The tmux workflow is also practical. Two models running side by side. You compare outputs. You pick the better one. No special tooling needed. Just terminals. I've been doing something similar with Claude Code in multiple worktrees, but DHH's setup is simpler.

What builders should do: try running two models in parallel for your next non-trivial task. Not with fancy tooling. Just two terminal sessions. Ask each one the same question. The comparison teaches you things about model differences that no benchmark captures.