How high-leverage builders actually work

Six well-documented examples of outsized output per person — three individuals, three teams — and what their real tools and setups have in common, where they flatly disagree, and what you can take from each.

Assembled with our own research toolkit and web search. Our meta-search was rate-limited partway through (the engines throttle heavy use, exactly as its design notes warn), so the named profiles lean on each person's own posts and talks, cited inline. Everything here is public professional record: how these people say they work. A caveat from our own tradecraft: these are self-reported methods, so they're a B-reliability source — builders simplify and romanticise their own process. Where a widely repeated claim isn't in a primary source, it's left out.

The six, at a glance

The individuals

Simon Willison: amplification, done on purpose

Willison is the most thoroughly documented AI-assisted developer working today; he ships a stream of small tools and writes up his method in detail. His core claim is a corrective to the hype: getting good code out of an LLM is "difficult and unintuitive," and takes real effort to learn. The concrete practices:

• Pick libraries the model knows. He deliberately favours popular, stable libraries, because models trained on more examples handle them better; for obscure ones he pastes recent usage into the prompt.
• Context is the skill. He treats managing what the model sees — the files, the examples, the spec — as the central craft, and shares antirez's wariness of editors that hide that context from you.
• Spec first. He popularised Harper Reed's pattern: brainstorm into a spec file, then a plan and a to-do list the model works through.

Sources: Here's how I use LLMs to help me write code (Mar 2025), Pragmatic Engineer interview.

antirez: control the ideas, not the code

The creator of Redis rejoined the project in 2025 and has written two widely read pieces on coding with LLMs. In 2025 he insisted on tight human supervision — LLMs for review, prototyping and pair-design, writing code only under clear specifications, and never pure "vibe coding," because left alone on non-trivial goals they produce "fragile, bloated" code. By 2026 his position sharpened into a provocation: if you control the ideas of your software, reading the code line by line is often pointless, because agents now produce more code than anyone can meaningfully review, and they're already strong at local correctness and weaker at architecture — so spend your attention on the design, not the diff. Like Willison, he pastes context deliberately and distrusts agent-integrated editors.

Sources: Willison's summary of antirez's 2025 workflow, Control the ideas, not the code (2026).

Mitchell Hashimoto: craft on a reproducible floor

After HashiCorp, Hashimoto builds Ghostty, a terminal emulator, largely solo and in the open. His setup is the systems-craft end of the spectrum:

• Zig for the code — low-level, fast, and a deliberate taste choice he calls a "very good" experience despite disruptive version upgrades.
• Nix as the source of truth. The dev environment is defined in Nix; CI builds and tests in it, and a local build is required to match the Nix build exactly. This is reproducibility as a foundation — the same lever as a dev container, taken to its logical end.
• Agents as a power tool. He's said LLM agents made the pain of Zig version upgrades manageable and built a non-trivial Ghostty feature (quiet macOS auto-updates) largely with AI — used on top of deep craft, not instead of it.

Sources: Hashimoto's writing, Open Source Ready, ep. 16.

The teams

Linear: leverage from team design

Linear's output-per-head reputation comes not from a tool but from how the team is shaped, per CEO Karri Saarinen:

• Small, senior teams. More people means more opinions and deliberation; the hiring bar is "already does strong work," set as a standard rather than measured as output.
• No handoffs, no permanent teams. Everyone owns quality; people rotate onto projects that assemble and disperse, to avoid silos and stale ownership.
• Taste over metrics. No A/B tests, no metric-based goals beyond a single North Star; decisions are made on judgment, and the spec is "the baseline, not the finish line."
• Hiring through real work. Candidates do a paid 1–5 day trial on a real project.

Sources: Practices for building Linear, Saarinen's rules for quality, Lenny's Newsletter (partly paywalled).

37signals / DHH: leverage from subtraction

The opposite philosophy, and just as deliberate: output per person goes up when there's less to manage. The positions are long-standing public doctrine:

• The majestic monolith. One application a single person can still change, instead of microservices that solve an organisational-scale problem you probably don't have.
• Omakase. A curated, full-stack set of defaults, so you don't spend judgment wiring tools together.
• The one-person framework. Rails 8 replaces whole categories of dependency with built-ins — the Solid stack for queues, cache and websockets (no Redis), built-in auth (no Devise), Kamal for deploys (no Kubernetes), Hotwire (no React) — so one person can run what used to need a platform team.

Sources: The Majestic Monolith, The Rails Doctrine, Rails 8 release notes. These ideas run through our own Rails mindset notes.

Anthropic's Claude Code team: agent-native

At the far end: a team whose workflow is the agent. Anthropic's engineers use Claude Code for debugging, navigating codebases and automating workflows, and the team dogfoods relentlessly — they call it "antfooding," watching hundreds of engineers use it daily and getting feedback every few minutes. The patterns their own people report:

• Plan mode first. Have the agent map out its approach step by step and agree on it before any code is written — it meaningfully improves hard tasks.
• To-do lists and subagents. The main agent writes a task list, then spins up subagents to work items in parallel.
• A tight loop: gather context, take action, verify the work, repeat.

Sources: How Anthropic teams use Claude Code, Every podcast with the Claude Code team. Some circulated impact figures (e.g. a share-of-code-written number) aren't in primary sources, so they're left out here.

What they share, and where they split

The disagreements are real. 37signals removes tools to go fast; the Claude Code team adds the most powerful one it can. antirez says stop reading the code; Hashimoto's whole value is reading and writing it with great care. These aren't the same bet.

But three things recur across all six:

• Design before code. A spec, a plan, a clear idea first — whether it's Willison's spec file, antirez's "control the ideas," Linear's spec-as-baseline, or Claude Code's plan mode. Nobody high-leverage starts by typing.
• Taste is the moat. Linear makes it the hiring bar, 37signals makes it the product, antirez says it's what to spend attention on. When generation is cheap, knowing what good looks like is the scarce thing.
• Own your environment. Hashimoto's Nix floor, 37signals' curated defaults, Willison's managed context — each removes a source of friction and surprise so the real work has room.

There are four levers behind all of this — amplify (let agents do the work), specify (make intent checkable), tighten the loop (make feedback instant), and ship small and measure. Every one of these builders is strong on specify and on tighten the loop. Where they differ is how hard they pull the amplify lever. That's the live question of 2026–27, and reasonable, excellent builders are answering it differently.

Provided as is, for information only, with no warranty and no liability. Not legal or professional advice. Security and radio material is for authorized, lawful use only. Full disclaimer.

Visits are logged on our own server: IP address, browser and device details, and pages viewed. We use them to understand traffic and spot attacks, and never share or sell them.