Buildooor Research Brief -- March 2026

Everyone Is Recreating Everything: Status Signaling, Labor Anxiety, and the Case for Wheel Factories

buildooor % claude --model opus-4.6 -p "/research-paper build a wheel factory, not another wheel"
Published March 22, 2026 -- Working Paper v1.0
Keywords: wheel reinvention, status signaling, open source labor, AI coding, developer identity, MCP, protocol standardization, generator businesses, software abundance, template economics
What does this mean for me?MarkdownPlain text

Abstract

Software culture is saturated with a peculiar paradox. Open-source software appears in 96% of codebases, a recent Harvard analysis estimated its demand-side value at $8.8 trillion, and GitHub now hosts 4.3 million AI-related repositories. The wheel already exists almost everywhere. Yet builders continue to recreate tools, wrappers, prompts, decks, legal packets, and micro-products at industrial scale. This paper argues that wheel reinvention is not primarily a failure of engineering rationality. It is a rational response to incentive systems that reward visible creation more than invisible maintenance, public artifacts more than quiet reuse, and greenfield proof-of-work more than brownfield stewardship. Recent labor-economics research shows open-source contributions rise during job-search periods and skew toward externally visible, labor-market-valued work. AI sharpens the pattern by making first drafts, wrappers, and demos cheaper even as integration and verification remain costly. The result is a software economy that overproduces new wheels and underinvests in dependable ones. The operational conclusion is not moralistic "stop reinventing." It is architectural: separate creation domains from selection domains, and when variation is frequent but bounded, stop building single wheels and build the wheel-creation machine.

1. Introduction: The Wheel Glut Is Social, Not Technical

The modern software stack is already a stack of reused parts. Harvard's Digital Data Design Institute, summarizing recent work on the value of open-source software, notes that OSS appears in 96% of codebases and estimates roughly $8.8 trillion in demand-side value from software that companies would otherwise need to recreate internally. At the same time, GitHub's 2025 Octoverse report counted 4.3 million AI-related repositories and more than 1.1 million public repositories importing an LLM SDK, up 178% year over year. Software abundance is not a future condition; it is the present operating environment. There are reusable wheels everywhere.

Yet the observable culture does not look like rational reuse. It looks like endless re-creation. Every week yields another AI wrapper, another cloned SaaS surface, another "custom" internal tool that reproduces a well-known workflow, another prompt-generated legal or operational packet that mostly restates a public template. The question is not why reusable components are scarce. The question is why their abundance has not reduced the appetite to build from scratch.

Table 1. The Abundance Paradox: Reuse Is Ubiquitous, Yet Reinvention Keeps Rising
SignalFindingWhat It Implies
OSS ubiquity96% of codebasesMost software already starts from inherited wheels, not blank pages.
OSS value concentration95%+ from 5% of programmersA small maintainer minority carries a disproportionate share of the commons.
Career-signaling spike~12% more OSS activity during job searchPublic building increases when developers need visible labor-market proof.
AI repository growth4.3M AI repos on GitHubCheap creation tools expand the surface area of wheel recreation.
LLM SDK imports1.1M public repos (+178% YoY)AI building is shifting from novelty to default workflow infrastructure.
Sources: Harvard D^3 summary of Hoffmann, Nagle, and Zhou (2024); Abou El-Komboz and Goldbeck (2025); GitHub Octoverse (2025).

The thesis of this paper is that wheel reinvention persists because its incentives are social and economic before they are technical. Creation is visible. Maintenance is not. A new artifact can be owned, posted, demoed, and attached to a personal brand or career narrative. An existing wheel, by contrast, arrives with constraints, dependency risk, hidden complexity, and someone else's authorship. In an attention economy and a volatile labor market, that asymmetry matters. The result is not merely overbuilding. It is an economy that systematically rewards new wheels even when the better engineering decision would have been careful adoption, adaptation, or generator-building.

2. The Existing Wheels Are Real, but Their Labor Is Socially Invisible

The best recent empirical work on open-source value makes the hidden base layer impossible to ignore. Hoffmann, Nagle, and Zhou estimate a supply-side value of roughly $4.15 billion for recreating the most commonly used OSS once, but a demand-side value of $8.8 trillion when measured as replacement cost across firms that rely on it. This is the first clue that the software economy's most important work is often the least theatrically rewarded. Most firms do not build their stack from first principles because they cannot; they survive by standing on a commons maintained elsewhere.

The second clue is how concentrated that commons is. The same Harvard summary reports that more than 95% of demand-side OSS value is generated by only 5% of programmers. In plain language: a small maintainer class carries an absurd share of the useful wheels everyone else depends on. If one wants a non-metaphorical version of the looming "underclass" inside software, this is a good candidate: not non-builders, but the disproportionately small group doing boring, unglamorous maintenance while status and narrative accrue to the launch layer on top.

This helps explain why abundance does not automatically create reuse culture. Reuse is economically rational, but psychologically and socially awkward. It means inheriting unknown tradeoffs. It means becoming dependent on maintainers you do not control. It often means the most important work is integration, reading, debugging, and adaptation rather than authorship. Many builders would rather own a thinner wheel than inherit a thicker one, because ownership is legible while dependency is not.

Hence one of the defining distortions of software abundance: the more reusable the base layer becomes, the more the scarce status good shifts upward from code existence to authored framing. People do not merely want software that works. They want software that is visibly theirs.

3. Wheel Reinvention Often Functions as Labor-Market Signaling

A 2025 paper in Labour Economics makes the signaling logic explicit. Studying roughly 22,900 GitHub developers, Abou El-Komboz and Goldbeck found that OSS activity among people moving for a job rises about 12% during the job-search period relative to otherwise similar movers. More important than the aggregate lift is the direction of the effort: signaling activity disproportionately focuses on externally visible projects and programming languages with high labor-market value, even when that work has lower direct use-value for the community. This is a clean result. Developers are not just contributing because the commons needs more code. They contribute more when their labor must be publicly legible to employers.

The same paper also stresses why this behavior is rational. Technical skills decay quickly, formal education certifies practical software ability poorly, and employers rely on observable artifacts to reduce information asymmetry. Public code becomes a substitute credential. Build-in-public is therefore not merely a taste preference. It is labor-market infrastructure.

Broader workforce evidence points in the same direction. In January 2025, the World Economic Forum reported that 85% of employers planned to prioritize reskilling, while 86% expected AI and information processing technologies to drive major business change. In that environment, builders do not just want private competence. They want portable proof that they are current. Recreating the wheel can therefore function as insurance: a visible artifact that says "I can still ship in the new regime" even when the underlying wheel was already available.

When skills age quickly, public artifacts stop being vanity and start becoming labor-market insurance. That is one reason wheel reinvention survives even in a world full of usable wheels.

4. AI Made Reinvention Cheap, but It Did Not Make Stewardship Cheap

Generative AI intensified this signaling economy by collapsing the cost of first drafts and proof artifacts. GitHub's 2025 Octoverse data shows AI-related repositories now exceed 4.3 million, with roughly 80% of new GitHub users trying Copilot within their first week. Stack Overflow's 2025 AI survey reports that 84% of respondents are using or planning to use AI tools in their development process, 51% of professional developers use them daily, and 52% report a positive effect on productivity. The floor has risen: it is easier than ever to produce something demoable.

But the productivity story is not cleanly monotonic. GitHub's earlier controlled-task research found Copilot users completed a bounded coding task 55% faster. By contrast, METR's 2025 randomized trial on experienced open-source developers working in mature codebases found AI tool use made them 19% slower on average. These findings are not actually contradictory. They describe different parts of the work. Greenfield tasks with clear boundaries compress well. Mature systems with accumulated assumptions, integration risk, and validation burdens do not necessarily compress at the same rate.

Table 2. AI Lowers the Cost of New Output Faster Than the Cost of Validation
MetricFindingInterpretation
New GitHub users trying Copilot~80% in first weekAI is becoming part of the default developer on-ramp, not an advanced add-on.
Developers using or planning AI tools84%The floor for AI-assisted creation is now mainstream.
Professional developers using AI daily51%Daily interaction turns prompt fluency into a career hygiene factor.
Developers reporting positive productivity effect52%Perceived speed gains are real enough to change behavior.
Controlled-task Copilot speedup55% fasterGreenfield or bounded tasks compress dramatically under assistance.
Experienced OSS developers with frontier AI19% slowerMaintenance, integration, and verification remain stubbornly expensive.
Sources: GitHub Octoverse (2025); Stack Overflow Developer Survey (2025); GitHub Copilot productivity research (2022); METR (2025).

A reasonable inference from this split is that AI currently over-rewards activities that look like creation: wrappers, demos, cloned tools, fresh repositories, "custom" packets, and visible shipping. It is less obviously transformative for the less theatrical layer where real durability often lives: fitting a component into an existing system, verifying edge cases, understanding constraints, and carrying maintenance. This is why the internet feels full of productivity porn. The easy-to-show part of AI assistance is the moment of output, not the slower reality of verification.

GitHub's 2025 developer-identity research reinforces the point. Advanced AI users increasingly describe themselves less as code producers and more as orchestrators and verifiers. That shift is real. But it has a side effect: the public artifact now signals not only that one can code, but that one can direct machines. Recreating a wheel is no longer just a demonstration of implementation skill; it is also a demonstration of AI fluency.

5. Many So-Called Creation Tasks Are Really Selection Tasks

The wheel-recreation impulse becomes most absurd in domains where the base artifact is not merely available but official. Consider legal and compliance workflows. The Administrative Office of the U.S. Courts publishes standardized forms such as Complaint for a Civil Case for self-represented litigants. Many filing environments begin from official packets, checklists, and form families rather than a blank page. In those settings, asking an LLM to "create the packet" from scratch is often a category error. The expensive problem is usually selecting the right template, filling it correctly, gathering facts, and validating jurisdictional detail, not inventing a base document.

The same pattern appears far beyond law. Internal policies, proposals, scopes of work, onboarding sequences, API adapters, CRM workflows, and procurement responses frequently live in what might be called selection domains. The archetype exists. Variation is bounded. Risk comes less from lack of creativity than from using the wrong version, omitting required fields, or failing review. In these domains, generation is useful, but only when nested inside retrieval, templating, and approval.

Table 3. Creation Domains vs. Selection Domains
Domain TypeBase Artifact AvailabilityReal BottleneckFailure Mode
Commodity software patternsOpen-source packages, starter kits, example reposIntegration, maintenance, and distributionShipping another thin clone with no leverage below the UI
Standardized legal or compliance formsOfficial forms, public packets, filing guidesJurisdiction choice, fact collection, reviewInventing a fresh packet when the official one already exists
Protocolized integrationsSchemas, SDKs, interface specs, server templatesCorrect mapping, testing, and monitoringOne-off glue code that cannot be reused or checked
High-judgment domainsSparse or contested templatesExpert interpretation and liability-bearing reviewOver-trusting generic generation where judgment is the scarce asset
Selection domains do not eliminate AI utility. They change where AI should sit in the process: inside a guided template or generator, not as a blank-page authority.

This distinction matters because a large share of contemporary AI prompting mistakes arise from misclassifying selection problems as creation problems. A user asks for a "custom legal packet" when what they actually need is the official form plus jurisdiction-specific guidance and fact filling. A team asks for a "new internal tool" when what they actually need is a controlled adaptation of an existing package. Blind generation in such cases widens the error surface while pretending to reduce effort.

6. When Everyone Recreates the Wheel, Build the Wheel Factory

The strongest response to rampant reinvention is not purism about reuse. It is to move one layer up and build the machine that makes reuse operational. The Model Context Protocol is an instructive example. MCP presents itself as an open standard for connecting AI applications to external systems, analogous to a universal port that normalizes how tools, prompts, and resources are exposed. Whatever one thinks of any specific vendor, the economic direction is clear: once a class of integration becomes protocolized, value shifts away from artisanal one-off glue and toward templates, registries, validators, SDKs, and generators.

This is the deeper answer to the question "why does everyone want to recreate the wheel?" Because in an abundant environment, wheel creation is easy, visible, and individually rational. But when repetition is high and variation is bounded, the durable opportunity is rarely the nth wheel. It is the wheel factory: the scaffold that instantiates reliable variants, the validator that catches broken outputs, the migration layer that keeps variants current, the approval workflow that makes automation trustworthy, and the registry that makes prior work discoverable.

Standardization also improves AI usefulness directly. This is an inference from the evidence above, not a separate experimental result: systems with explicit schemas, stable interfaces, and tighter validation loops give models a narrower and more legible target. That is why typed languages, protocol specs, and repeatable templates often feel disproportionately "AI-friendly." The model does not need to be innately creative. It needs the acceptable output space to be compressible.

In abundant software markets, the scarce asset is usually not generation. It is acceptable variation. Build for that, and the generator becomes more valuable than the one-off artifact.

7. Framework: The Recreation Ladder

The practical problem for builders is not deciding whether reuse is morally superior to reinvention. The practical problem is choosing the right level of intervention. The recreation ladder below offers a compact decision model. Each rung changes the unit of value and therefore changes where AI should sit in the process.

Table 4. The Recreation Ladder
MoveUse It WhenUnit of ValueAI Best Use
ReuseA reliable public artifact already exists and variation is lowReliability and time savedSearch, summarize, and adapt lightly
ForkThe base artifact is sound but local changes are materialLocal fit with inherited leverageDiffing, refactoring, migration help
TemplateThe same task repeats with bounded variable fieldsConsistent speed with lower error rateField filling and drafting under guardrails
GeneratorVolume is high and the schema or protocol is stableScalable customization with validationProduce variants plus tests, validators, and approval hooks
BespokeRequirements are genuinely novel or judgment-heavyProblem framing and expert reasoningResearch assistance and option exploration, not final authority
Default rule: if the base artifact exists and error costs are high, start lower on the ladder. Climb only when variation or volume justifies it.

Two heuristics fall out of this ladder. First, when the base artifact is public or official and the cost of being wrong is high, default to reuse or fork. This is the correct posture for legal forms, compliance packets, security controls, and many infrastructure components. Second, when the same adaptation recurs often enough that humans are manually repeating variable substitution and basic checking, move upward from template to generator. A generator earns its keep not by being more "creative" than the human, but by making bounded variation cheaper and safer.

The only place bespoke work remains obviously dominant is where the problem itself is unstable: unclear requirements, contested domains, human taste, contrarian judgment, or liability-heavy contexts where the scarce asset is responsibility rather than syntax. In those cases, AI can still help -- especially with research, synthesis, and branching options -- but the wheel factory does not replace the wheelwright.

8. Implications: Reward Fitting, Not Just Shipping

For builders, the first implication is personal. Stop confusing blank-page output with leverage. The work that compounds is usually the work that reduces future verification cost, not the work that maximizes visible artifact count. If the same prompt, packet, integration, or workflow keeps reappearing, the next move is not usually another custom draft. It is a template, generator, validator, or test harness.

For engineering managers, the implication is incentive design. Promotion systems and team rituals that mainly reward visible net-new output will overproduce wheels and underfund maintenance. In an AI-heavy environment, that distortion gets worse because greenfield demos become easier while brownfield stewardship remains hard. Teams should therefore measure time-to-fit, review burden, failure rate, and reuse depth alongside shipping volume.

For operators in legal, compliance, consulting, and operations-heavy domains, the implication is procedural. Start from the official artifact whenever one exists. Put AI inside the flow as a field-filling, explanation, summarization, and checking layer. Do not let it hallucinate a new base object when the governing template is already public. The more regulated the domain, the more this matters.

For researchers, one implication is methodological. Productivity debates that focus only on output speed will misread the phenomenon. The central economic question is not whether AI can create another wheel quickly. It is whether AI reduces the total cost of fitting, validating, and maintaining the wheel inside a real system. Until more studies separate greenfield generation from brownfield stewardship, productivity discourse will keep overstating where the gains actually land.

9. Conclusion: Abundance Changed Where Value Lives

People do not recreate the wheel because they are uniquely irrational. They recreate it because modern software culture rewards authored surfaces, because labor markets reward visible proof, because AI makes first drafts cheap, and because maintenance remains both socially invisible and operationally annoying. The past twenty years of productivity culture did not invent this dynamic, but they did aestheticize it. Shipping became an identity performance. AI simply lowered the cost of performing it.

But the presence of too many wheels does not mean there is no opportunity. It means opportunity moved. In domains with public base artifacts, the scarce move is selection and validation. In domains with repeated bounded variation, the scarce move is the generator. In domains with genuinely novel or contested requirements, the scarce move remains judgment. The winning operators will not be those who moralize reuse the loudest. They will be the ones who know when to inherit, when to fork, when to template, and when to build the wheel factory.

If everyone is recreating everything, the strategic response is simple: stop competing on the existence of a wheel that already exists. Compete on the system that turns abundant parts into reliable, reviewable, and situation-specific outcomes.

References

Abou El-Komboz, L., & Goldbeck, M. (2025). "Career concerns as a public good: The role of signaling for open source software development." Labour Economics, 97, 102800.

GitHub. (2022). Research: Quantifying GitHub Copilot's impact on developer productivity and happiness.

GitHub. (2025). Octoverse: A new developer joins GitHub every second as AI leads TypeScript to #1.

GitHub. (2025). The new identity of a developer: What changes and what doesn't in the AI era.

Hoffmann, M., Nagle, F., & Zhou, Y. (2024). The Value of Open Source Software. Harvard Business School Strategy Unit Working Paper No. 24-038.

METR. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity.

Model Context Protocol. (2026). What is MCP?

Stack Overflow. (2025). 2025 Stack Overflow Developer Survey: AI.

United States Courts. (2016, rev. 2025 posting). Complaint for a Civil Case (Pro Se 1).

World Economic Forum. (2025). Many employers plan to prioritize reskilling their workforce.

Suggested citation: Baratta, R. (2026). "Everyone Is Recreating Everything: Status Signaling, Labor Anxiety, and the Case for Wheel Factories." Buildooor Research Brief, March 2026.

Correspondence: buildooor@gmail.com