I'm Boris and I Created Claude Code  Full Document Contents/Tweets/I'm Boris and I Created Claude Code.md, I'm Boris and I Created Claude Code, Boris Cherny. ## Document Notes > [!note]+ Document Notes > ```yaml > tags: [Claude-Code, Developer-Workflow, AI-Tools] > author: Boris Cherny > source: Twitter > reference: [https://twitter.com/bcherny/status/2007179832300581177/?rw_tt_thread=True] > date created: 2026-01-04 00:00 > > --- > > # 🏷️ Title: I'm Boris and I created Claude Code > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - Include links cited in or relevant to the article. ## 📝 Summary - What happened. - Boris Cherny describes his day-to-day setup for using Claude Code across local, web, and mobile, plus repo-level practices and verification workflows. - Why it matters. - Shows how to turn an AI coding assistant into a reliable teammate through planning, automation, and feedback loops. - Key stakeholders. - AI-assisted developers, tool builders, engineering teams adopting Claude Code. - Risks and tradeoffs. - Opus 4.5 is slower but higher quality; powerful automation requires careful permissions and strong verification. - Bottom line. - The single most important lever is giving Claude robust ways to verify and iterate on its work. ## 📖 Main Content - Boris runs 5–10 Claude instances in parallel: local terminal sessions plus web sessions (desktop and iOS), often “teleporting” conversations between them as he codes. - He standardizes on Opus 4.5 with thinking for all coding tasks, arguing that although it’s slower per step than Sonnet, it’s faster end-to-end because it needs less steering and is better at tools. - The Claude Code team keeps a shared `CLAUDE.md` in the repo, checked into git and updated whenever Claude makes a mistake, so the model learns repo-specific constraints and anti-patterns. Other teams maintain their own files. - During code review, they tag `@.claude` on PRs and use the Claude Code GitHub Action to update `CLAUDE.md` as part of the workflow—what he likens to “Compounding Engineering.” - Most sessions start in Plan mode. For a pull request, Boris collaborates with Claude on a plan first, then switches to auto-accept edits so Claude can often one-shot the implementation. A strong plan is treated as critical. - Repeated “inner loop” tasks are turned into slash commands in `.claude/commands/`, such as `/commit-push-pr`, which uses inline bash to pre-compute git status and other info, cutting down back-and-forth with the model. - He uses subagents (e.g., `code-simplifier`, `verify-app`) for common workflows after coding or for end-to-end testing, similar in spirit to slash commands but more autonomous. - Instead of disabling permissions, he uses `/permissions` and shared `.claude/settings.json` to pre-allow safe bash commands, reducing friction while keeping guardrails. - Claude is wired into many tools: Slack via MCP, BigQuery via CLI, Sentry logs, etc., with shared `.mcp.json` for team-wide tool configuration. - For long-running tasks, he either prompts Claude to verify its work, uses agent stop hooks, or relies on the “ralph-wiggum” plugin, sometimes combined with permissive modes in sandboxes so the agent can run uninterrupted. - His core principle: always give Claude a way to verify its work. For Claude Code itself, Claude uses the Chrome extension to open a browser, test the UI, and iterate until both correctness and UX quality are satisfactory. Verification can be as simple as a bash command, a test suite, or manual-feeling UI runs, but it must be rock-solid. ### 🗒️ Notes - “My setup might be surprisingly vanilla! Claude Code works great out of the box” — emphasis on using defaults plus a few high-leverage customizations. - Heavy parallelization: multiple local Claudes plus 5–10 web sessions; moves sessions between environments (terminal, Chrome, iOS) depending on context. - Always-on use of Opus 4.5 with thinking: prefers higher-quality, tool-savvy reasoning even with slower raw speed, trusting that better autonomy saves time. - Shared `CLAUDE.md` pattern: - Lives in the repo and is version-controlled. - Updated whenever Claude behaves incorrectly. - Helps encode tribal knowledge and constraints for the assistant. - Code review practice: - PR authors or reviewers tag `@.claude`. - GitHub Action keeps `CLAUDE.md` evolving with each PR. - Plan-first workflow: - Start sessions in Plan mode. - Iterate on the plan until it’s good enough. - Switch to auto-accept edits, often yielding a near one-shot PR. - Slash commands: - Created for every frequently repeated inner-loop workflow. - Stored in `.claude/commands/` and part of the repo. - `/commit-push-pr` uses inline bash to gather state upfront. - Subagents: - `code-simplifier` cleans up code post-edit. - `verify-app` runs detailed end-to-end testing instructions. - Conceptualized as automation for repeated, per-PR workflows. - Permissions: - Avoids `--dangerously-skip-permissions` by default. - Uses `/permissions` to whitelist safe commands. - Shares config via `.claude/settings.json` so the team benefits. - Tool integration: - Slack MCP server for search and posting. - BigQuery CLI for analytics queries. - Sentry for log access. - All coordinated via shared `.mcp.json`. - Long-running tasks: - Explicit verification prompts. - Agent Stop hooks for deterministic follow-ups. - “ralph-wiggum” plugin for more robust automation. - Sometimes uses permissive permission modes in sandboxed contexts. - Verification principle: - Claims 2–3x quality improvement when Claude can verify its work. - Uses Chrome extension to test the product in a browser and iterate. - Encourages domain-specific verification: tests, commands, simulators, etc. ## 📚 References - Original thread by Boris Cherny: https://twitter.com/bcherny/status/2007179832300581177 - Claude Code product page: https://www.anthropic.com - GitHub Actions docs: https://docs.github.com/actions - BigQuery CLI reference: https://cloud.google.com/bigquery/docs/bq-command-line-tool - Sentry: https://sentry.io ## 🗣️ Paraphrase - Paragraph A paraphrase. - Boris uses a mostly standard Claude Code setup, augmented with a few powerful conventions (shared instructions, slash commands, subagents, and permissions) to make Claude an effective teammate across devices. - Paragraph B paraphrase. - The real performance gain comes from planning and verification: start with a solid plan, automate repetitive flows, and always give Claude reliable ways to test and correct its own work. ## 📰 Newsletter In this week’s WordPress-adjacent tooling corner, Anthropic’s Boris Cherny pulled back the curtain on how he actually uses Claude Code day to day. His approach is surprisingly simple: start every PR in Plan mode, wire Claude into your existing tools (git, CI, Slack, analytics), and then ruthlessly automate the inner loop with slash commands and subagents. For WordPress developers, the takeaway is clear: you don’t need a complex AI rig to get leverage. A few repo-level conventions—like a shared `CLAUDE.md` for your plugin/theme, safe pre-approved commands, and a `/commit-push-pr`-style script—can turn Claude into a reliable collaborator instead of a one-off copy-paste assistant. Pair that with strong verification (test suites, Playwright runs against wp-admin, or browser-based UI checks) and you can safely let Claude handle more of the scaffolding while you focus on product decisions. If you’re curious, start by: - Creating a `CLAUDE.md` in your main plugin or theme repo describing coding standards, WordPress-specific pitfalls (nonces, caching, translation), and deployment rules. - Adding simple slash commands for `wp-env` or `wp-cli` tasks. - Pointing Claude at your error logs (e.g., via Sentry) and test runner. Used well, AI coding tools are less about “magic code generation” and more about designing tight feedback loops around your existing WordPress workflows. ## ✅ Action Items #### DevRel - Developer advocacy: - Prepare demos showing Plan mode + auto-accept edits for building WordPress plugins or blocks. - Collect case studies from devs using Claude Code in WP projects. - Education: - Run workshops on setting up `CLAUDE.md` and `.claude/commands/` in OSS repos. - Create short curricula around verification-first AI development. - Developer experience: - Offer WordPress-focused starter templates: `CLAUDE.md` examples, slash commands for `wp-cli`, and sample subagents. - Improve docs on MCP integrations (Slack, BigQuery, logging) with WP-friendly scenarios. - Developer marketing: - Publish content comparing “prompting in the browser” vs “repo-integrated Claude Code” for PHP/JS stacks. - Track adoption via signups, extension installs, and repeat usage. - Community management: - Facilitate a shared gallery of `CLAUDE.md` and command examples from different ecosystems, including WP. - Gather survey feedback on the hardest parts of integrating AI into existing dev flows. - Internal/external/cross-project: - Align Claude Code roadmap with popular frameworks (WordPress, Laravel, Next.js). - Define clear feedback loops from community repos back into product changes. #### OSPO - Policy & Governance: - Recommend patterns for `CLAUDE.md` and `.mcp.json` in organization-wide OSS repos. - Clarify who owns and reviews AI config changes (commands, permissions). - License Compliance: - Ensure generated code and automations respect project licenses and third-party dependencies. - Security Management: - Define safe defaults for permissions; discourage `--dangerously-skip-permissions` except in sandboxes. - Document treatment of secrets and environment variables when tools run via Claude. - Software Inventory: - Track where MCP servers, subagents, and slash commands are defined across repos. - Developer Support: - Offer office hours on safe AI usage in internal and OSS projects. - Provide starter policies and checklists. - Community Engagement: - Encourage sharing of `CLAUDE.md` patterns across upstream projects. - Strategic Alignment: - Set OKRs around safer, more reproducible AI-assisted development. #### Community - Maintainers: - Host “roadmap clinics” to identify automation candidates (tests, releases) for Claude. - Encourage PR templates that include or update `CLAUDE.md`. - Contributors: - Publish simple onboarding docs explaining how to use Claude Code with the project. - Label “good first issues” that are especially suitable for AI-assisted changes. - Sponsors: - Tie funding to improved tests and verification infrastructure that AI relies on. - Ecosystem: - Practice incident drills where AI-assisted automation is paused or adjusted during outages. #### WordPress - Core: - Explore adding example `CLAUDE.md` guidance and AI tooling notes in contributor docs. - Identify low-risk areas where AI-generated patches can be trialed under strong review. - Core Performance: - Provide test profiles and metrics that Claude can invoke after performance-related edits. - Core AI: - Define responsible AI guardrails for Claude-style tools operating on Core and major plugins. - Build evaluation sets for common WP coding patterns and anti-patterns. - **Core Program Team:** - Coordinate experiments using Claude Code in selected components (e.g., Docs, Meta). - Run retrospectives on where AI assistants helped or hindered. - Mobile: - Draft commands and subagents for mobile app builds and test suites. - Playground: - Offer pre-configured sandboxes with Claude Code examples for plugin/block development. - Community: - Add meetups/WordCamp sessions on AI-assisted WP development workflows. - Training: - Create learning paths around “AI + WordPress” with emphasis on verification and tests. - Marketing: - Tell stories of teams using Claude Code to accelerate block/theme/plugin work. - Support: - Prepare guidance for handling AI-generated support snippets without leaking data. - Design: - Document UX verification patterns that Claude can automate (e.g., per-browser checks). - Documentation: - Write examples-first docs on integrating Claude Code with WordPress CLI and test tools. - Photos / TV / Polyglots: - (Light) Consider AI-assisted scripts for metadata, captions, and translation with review. - Accessibility: - Encourage AI use to generate initial a11y checks, followed by human verification. - Meta: - Explore whether .org contributor tools could expose simple hooks for Claude integration. - CLI: - Add or document `wp-cli` commands that are safe to pre-approve in permissions. - Hosting / Tide / Openverse / Themes / Plugins: - Assess where auto-verification (tests, linting, scanners) can be wired into Claude flows. #### The WPOCC - Programs: - Offer fellowships for maintainers experimenting with Claude-assisted workflows. - Projects: - Run documentation sprints to capture best practices from early adopters. - Funding experiments: - Pilot grants targeted at building robust test suites and tooling Claude can lean on. ### FAIR - Technical independence: - Encourage local or self-hosted MCP servers where feasible. - Track provenance and signatures for automation scripts. - Policies and covenants: - Clarify funding and governance for AI infrastructure in OSS communities. - Productized governance artifacts: - Publish reusable charters and operator agreements for AI-assisted repos. ## 🧪 Hypotheses - H1: Teams that maintain a shared, up-to-date `CLAUDE.md` will see fewer AI-induced regressions than teams without such a file. - H2: Starting in Plan mode and then auto-accepting edits is faster end-to-end than ad-hoc prompting, for non-trivial PRs. - H3: Structured verification (tests, browser runs, logs) yields at least 2–3x higher perceived quality of AI-generated code. - H4: Pre-approved permissions plus shared `.claude/settings.json` reduce friction without materially increasing safety incidents. ### 📊 Methodology - For H1: - Compare incident and rollback rates across repos with and without `CLAUDE.md` over time. - For H2: - Run controlled experiments where developers implement similar tasks with and without Plan mode; measure time-to-merge and review comments. - For H3: - Survey developers using Claude Code before/after adding automated verification; track bug counts and satisfaction scores. - For H4: - Log permission prompts, blocked operations, and security exceptions across different permission strategies; analyze correlations. ### ❓ Questions - How large and specific should `CLAUDE.md` be before it becomes hard to maintain? - Where is the break-even point between Opus 4.5 quality and Sonnet speed? - Which verification strategies give the best ROI for small teams? - How should organizations govern shared MCP configurations across many repos? ### 🔮 Future Research - Systematic patterns for AI agents that manage their own verification. - Standardized schemas for `CLAUDE.md` and `.mcp.json` across ecosystems. - Best practices for cross-tool automation (Slack, metrics, logs) that stay secure. - Empirical studies on developer productivity with deeply integrated AI tools. ### 💡 Implications - Practice: - Teams should invest in tests and verification harnesses as first-class AI enablers. - Policy: - Organizations may need AI usage and permissions policies, similar to coding standards. - Security: - Centralized permission configs and sandboxing are crucial for safe automation. - Education: - Training should emphasize workflow design and verification, not just prompting tips. - Funding: - Grants and sponsorship could prioritize infra (tests, tooling) that unlocks safe AI use. ### 🧠 Learning Styles Assessment - Reading level estimate: - Approximately upper high-school / early college; mostly plain technical English with minimal jargon. #### 👀 Visual learners - Present: - No diagrams; purely text-based thread. - Improve: - Add architecture diagrams showing Claude, tools, and repos; sample screenshots of Plan mode, slash commands, and `.claude` layouts. #### 🔊 Aural learners - Present: - No audio component. - Improve: - 2–5 minute audio summary of the workflow; podcast-style discussion of tradeoffs. #### 🗣️ Verbal learners - Present: - Clear explanations, concrete examples (e.g., `/commit-push-pr`, Opus 4.5). - Improve: - Add a short glossary (Plan mode, MCP, subagents, permissions). #### 🧩 Kinesthetic learners - Present: - Implicit tasks (set up commands, permissions) but not step-by-step. - Improve: - Provide a small lab: “Configure `CLAUDE.md` and one slash command in a test repo.” #### 🧠 Logical learners - Present: - Causal reasoning: better verification → 2–3x quality; larger model → fewer steering steps. - Improve: - Add explicit flowcharts or decision trees for choosing modes and verification patterns. #### 🧑‍🤝‍🧑 Social learners - Present: - Team-shared configs and GitHub workflows. - Improve: - Suggest team rituals (PR reviews that always update `CLAUDE.md`). #### 🧘‍♀️ Solitary learners - Present: - Thread is easy to read and reflect on alone. - Improve: - Add reflection prompts: “Which of your inner-loop tasks should become a slash command?” #### 🌿 Naturalistic learners - Present: - No explicit environment/sustainability framing. - Improve: - Discuss compute costs and efficiency of using higher-quality models vs many retries. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: - Basic tweet thread; headings and alt text depend on the platform. - Improve: - Provide structured article format with clear headings and descriptive alt text for any future visuals. #### Keyboard navigation - Present: - Standard Twitter navigation, but limited structure. - Improve: - For any mirrored docs, ensure logical tab order and skip links. #### Contrast and readability - Present: - Default Twitter contrast, generally adequate. - Improve: - In a dedicated article, ensure strong contrast and generous line spacing. #### Text resizing and reflow - Present: - Platform-dependent resizing. - Improve: - Ensure responsive layouts and support for large text without clipping in hosted versions. #### Media and captions - Present: - Text only. - Improve: - If adding demos or videos, include captions and transcripts. #### Forms and interactions - Present: - N/A beyond typical platform interactions. - Improve: - For future docs/tools, ensure accessible controls and error messages. #### Standards reference - Map gaps to WCAG 2.2 AA for headings, contrast, keyboard access, and media alternatives. ### 🌍 DEIB Assessment #### Cultural breadth - Present: - US/Western-centric tech context; generic but narrow. - Improve: - Include examples from varied regions and bandwidth constraints. #### Inclusive language - Present: - Generally neutral, non-derogatory. - Improve: - Define specialized jargon for broader audiences. #### Neurodiversity support - Present: - Threaded, bite-sized content; somewhat consistent structure by numbered tweets. - Improve: - More explicit headings, summaries, and predictable patterns in a long-form version. #### Representation - Present: - Focus on a single author’s practice. - Improve: - Add perspectives from different teams and roles. #### Psychological safety - Present: - Constructive, non-blaming tone. - Improve: - Explicitly acknowledge that different setups can be valid; encourage experimentation. ### ✅ Logical Validity #### Strong reasoning - The claim that Opus 4.5 is faster overall is inductive: fewer steering steps and better tool use reduce total time. This is plausible, especially for complex tasks. - The argument that verification increases quality 2–3x is causal: better feedback loops let the model correct itself. While not numerically proven, the logic is sound and experience-based. #### Fallacies - No obvious major fallacies; some numeric claims (2–3x) are anecdotal rather than empirically demonstrated. #### Tone of voice - Pragmatic and modest: “my setup might be surprisingly vanilla.” - Encouraging experimentation: emphasizes “no one correct way” to use Claude Code. ### 🛡️ DARVO Analysis - Deny: - No denial of problems; mistakes are acknowledged and fed into `CLAUDE.md`. - Attack: - No attacks on critics or other tools. - Reverse victim/offender: - None present; the thread is descriptive and constructive. ## 🎯 Conclusion Boris’s setup illustrates that the real power of Claude Code comes from workflows, not clever prompts: shared repo knowledge, automated inner-loop commands, cautious but streamlined permissions, and—above all—strong verification. For readers, the next step is to identify a single project, add a `CLAUDE.md`, one slash command, and one reliable verification path, then iterate from there. ## 🧱 Refactor Appendix (append after 🎯 Conclusion) ### 📚 Literature Split Pad - Purpose: Stage Konik CEE units that become per-source Literature notes. - Split level: **H3**. - Include verbatim quotes under 25 words and a [view highlight] link. ### [H1] Claude plans and auto-verifies code changes > [!quote] [I'm Boris and I created Claude Code](https://twitter.com/bcherny/status/2007179832300581177/?rw_tt_thread=True) by [[Boris Cherny]] via [[Twitter]]. Published 2026-01-02. Accessed 2026-01-04. > “Probably the most important thing to get great results out of Claude Code -- give Claude a way to verify its work.” Two lines: context and use. Cite data if relevant. [view highlight](https://twitter.com/bcherny/status/2007179832300581177/?rw_tt_thread=True#H1) #xref #articleseed ID:rw_[MISSING] ### [H2] Shared CLAUDE.md encodes team learnings > [!quote] [I'm Boris and I created Claude Code](https://twitter.com/bcherny/status/2007179832300581177/?rw_tt_thread=True) > “Anytime we see Claude do something incorrectly we add it to the CLAUDE.md, so Claude knows not to do it next time.” Two lines: context and use. [view highlight](https://twitter.com/bcherny/status/2007179832300581177/?rw_tt_thread=True#H2) #xref ID:rw_[MISSING] --- ### 🔖 Atomic Split Pad (Zettel Candidates) - Purpose: Promote reusable claims into Atomic notes. - Split level: **H4**. - Each item: one idea, present tense, specific, testable. #### [Z1] Verification loops multiply AI code quality - Scope/condition in one line. - Pointer to page/time or dataset. - Links: [[AI-Verification]] [[Claude-Code-Workflows]] #### [Z2] Repo CLAUDE.md captures assistant constraints - Scope/condition in one line. - Pointer to page/time or dataset. - Links: [[AI-Configuration]] [[Team-Knowledge]] --- ### ✏️ Fleeting Queue (Extract by Selection) - Purpose: Capture quick actions or sparks for Fleeting notes. - Extraction: **Select one line** → “Refactor: Extract selection to new note (content only).” - Keep each line short and self-contained. - [F1] Create a `CLAUDE.md` for my main repo and seed it with current pitfalls — context/https://twitter.com/bcherny/status/2007179832300581177/?rw_tt_thread=True #fleeting #inbox - [F2] Design one `/commit-push-pr`-style slash command for my workflow — context/https://twitter.com/bcherny/status/2007179832300581177/?rw_tt_thread=True #fleeting #inbox - [F3] Add a simple automated verification step (tests or browser run) Claude can trigger — context/https://twitter.com/bcherny/status/2007179832300581177/?rw_tt_thread=True #fleeting #inbox --- <!-- deep-read:sections end --> ## Highlights - 7/ I use slash commands for every "inner loop" workflow that I end up doing many times a day. This saves me from repeated prompting, and makes it so Claude can use these workflows, too. Commands are checked into git and live in .claude/commands/. ([View Highlight](https://read.readwise.io/read/01ke4vnt1f4jjpj7arnwtg6fzm)) - Tags: 👻 ai highlighted