Forkable Beats Polished. Your Reviewer Too.
Roughly one in ten weekly users of T3 Code have forked the repo. That ratio used to mean "hobbyist project." In 2026, it means you just won the building block economy.
The 25-out-of-1000 Problem
Theo Browne put numbers on something every PM at a mature SaaS already knows. Your product probably ships a thousand features. Any single customer uses fifty. Twenty-five of those are used by almost everybody. The other twenty-five are bespoke weirdness: one team's specific chart, another team's specific approval flow, a third team's specific severity rule.
For twenty years, that long tail was your moat. Competitors couldn't rebuild it. Customers couldn't leave. The scoreboard lived at companies like Salesforce, Retool, and the AWS service sprawl, because nobody could ship a clone fast enough to matter.
Agents broke that moat. Not by cloning the mainline, but by making the long tail fork-able.
There is a Reddit thread making the rounds where a developer describes nearly churning from a popular analytics platform because they wanted one specific chart. The vendor's support loop ran three weeks and ended in "we don't think that's important enough." Multiply that story by every team with a non-standard workflow and you get the real shape of the market in 2026. Customers no longer want to wait. They will fork, prompt an agent, and ship the feature themselves by Friday.
Mitchell Hashimoto, the Terraform and Ghostty creator, calls this the building block economy. Ghostty got a million daily users in eighteen months. libghostty, the library underneath it, passed Ghostty's user count in two months. The block outgrew the app. That pattern is not an accident. Independent model evals keep finding that agents pick open, installable, modular tools over closed commercial ones, even when the closed tool is technically better. The factory is agentic. The factory prefers parts it can own.
What This Means for Code Review
Code review is one of the cleanest cases for this shift, because every team's review rules are slightly wrong out of the box.
Your ORM is fine for most teams. Yours got bought by a fintech parent last quarter and now every unbounded query is a compliance incident. Your "N+1 is a Minor" default is correct for most teams. Yours just scaled past 500M rows and N+1 means a 3am page. Your diff-only reviewer doesn't know that PaymentProcessor is tombstoned and nobody should be extending it. Your reviewer. Yours. Not the generic one.
With a closed reviewer you file a ticket, attach a screenshot, and wait. With a forkable one, you open the repo on Monday and ship it by lunch.
Octopus as a Building Block
Octopus Review is Modified MIT licensed and on GitHub. The CLI is an npm package. It uses RAG over your full codebase via Qdrant, so when you fork the reviewer and change its behavior, it still sees the whole project, not just the diff. You bring your own Claude or OpenAI key, so the fork works whether you self-host the whole stack or just patch the binary.
The practical version of "fork your reviewer" usually does not mean rewriting the pipeline. It means feeding the reviewer your actual rules through the Knowledge Base. Your fork of Octopus can ship with your standards baked in, and every teammate who installs it inherits them.
# Log in and point Octopus at your self-hosted instance
octopus login --api-url https://octopus.internal.corp
# Encode your house rules as first-class knowledge
octopus knowledge add ./docs/db-safety.md --title "DB Safety Rules"
octopus knowledge add ./docs/payment-module-freeze.md --title "Payments Freeze"
octopus knowledge add ./docs/severity-calibration.md --title "Severity Map"
# Index the repo so reviews carry full project context
octopus repo index
# Review a PR against the customized rules
octopus review 42
Now when a junior ships a PR that extends the frozen payments module, the review reflects your reality, not a generic default:
š“ **Critical** ā Extension of frozen module
`src/payments/processor.ts:87`
`PaymentProcessor` is tombstoned per `docs/payment-module-freeze.md`.
New payment logic should route through `src/billing/gateway.ts`.
š” **Major** ā Unbounded query against large table
`src/reports/usage.ts:44`
No `LIMIT` on a table over 500M rows. Team rule (DB Safety Rules) requires
explicit cursor or LIMIT for any query against `events_raw`.
That is the same Octopus Review everyone else is running, except yours knows about your tombstones, your hot tables, and your severity map. You did not wait for a roadmap slot. You added three markdown files.
Forking Is the New Feature Request
If your reviewer is closed source, your top-1% issue stays a ticket forever. If it is forkable, the user becomes the R&D team. That is the part Mitchell kept coming back to: the maintenance burden gets lower, not higher, because outsourced forks surface the best ideas before you build them. Mainline stays polished. The long tail gets handled by the people who actually need it.
For code review specifically, that is how you stop shipping a reviewer that is right for most teams and start shipping one that is right for yours.
If any of this resonates, try the hosted version at octopus-review.ai, clone the repo and run docker compose up -d, or come argue about the building block economy with us on Discord. The future of dev tools is open. The reviewer sitting in your pipeline probably should be too.