Status	Last updated	Parent	Read before this
complete	2026-04-30	none	Product - Vision

Boris Cherny 259 PRs

The throughput claim that started this project.

Current state

In late 2025, Boris Cherny (creator of Claude Code) reported merging 259 pull requests in 30 days, with Claude writing every line of code. The reported setup was "vanilla" Claude Code — slash commands, stop hooks, plan mode — without bespoke tooling.

This number was the existence proof for devwork-skills. If one developer could ship at that volume on vanilla tooling, the question became: what does it take to make that throughput repeatable across projects, stacks, and people who haven't built up Boris's intuition?

What we kept from the reported workflow:

• Plan mode as a discrete step before implementation. Now /technical-plan with a human approval gate.
• Stop hooks that check completion criteria before allowing the agent to finish. Generalised into the validate/tests/fix triplet and the Ralph Wiggum pattern.
• TDD discipline as a recurring practice. Now Concept - TDD Through Structure rather than agent habit.

What we changed:

• The orchestrator was lifted out of the skills (see Role - The Orchestrator). Boris's "vanilla" workflow had the human as the implicit orchestrator running everything from the terminal — fine when you're Boris, less reliable as a baseline for everyone else.
• The Contract - Forge Adapter exists because we work across Forgejo, GitLab, and possibly GitHub — Boris was on GitHub.
• Contract - Phase Outcome turn the implicit "ask the user" handoffs into structured, machine-readable artifacts.
• Role - Coding Harness Agents generalise the Ralph pattern into something that runs reliably without per-feature tuning.

Rationale

Documenting the inspiration explicitly matters because the volume claim is easy to misread. "259 PRs" is not a target — it's an existence proof that the bottleneck wasn't Claude's coding ability. The bottleneck was the developer's attention and the absence of process structure to use that attention efficiently.

The vision (see Product - Vision) deliberately doesn't optimise for matching that number. It optimises for repeatability — the kind of throughput that works for someone who hasn't spent months building the workflow themselves. That's a different goal, and it justifies the additional scaffolding that the "vanilla" workflow doesn't have.

Open questions

• Specifics of Boris's actual setup beyond the high-level summary aren't widely documented. The page reflects what's been publicly shared and what fits the patterns we observed. If more detail surfaces, this page updates.