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

A research brief on why software builders keep reinventing the wheel: public creation is a labor-market signal, AI makes greenfield rebuilding cheap, and the durable opportunity is the wheel factory, not the wheel.

- Canonical URL: https://buildooor.com/research/everyone-is-recreating-everything
- Author: Rob Baratta
- Published: 2026-03-22
- Version: 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

---

<ResearchAbstract>
  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.
</ResearchAbstract>

<ResearchSection number={1} title="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.

<ResearchTable
  caption="Table 1. The Abundance Paradox: Reuse Is Ubiquitous, Yet Reinvention Keeps Rising"
  columns={[
    { label: 'Signal' },
    { label: 'Finding', mono: true },
    { label: 'What It Implies', muted: true },
  ]}
  rows={[
    ['OSS ubiquity', '96% of codebases', 'Most software already starts from inherited wheels, not blank pages.'],
    ['OSS value concentration', '95%+ from 5% of programmers', 'A small maintainer minority carries a disproportionate share of the commons.'],
    ['Career-signaling spike', '~12% more OSS activity during job search', 'Public building increases when developers need visible labor-market proof.'],
    ['AI repository growth', '4.3M AI repos on GitHub', 'Cheap creation tools expand the surface area of wheel recreation.'],
    ['LLM SDK imports', '1.1M public repos (+178% YoY)', 'AI building is shifting from novelty to default workflow infrastructure.'],
  ]}
  footnote="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.

</ResearchSection>

<ResearchSection number={2} title="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.

</ResearchSection>

<ResearchSection number={3} title="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.

</ResearchSection>

<ResearchCallout>
  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.
</ResearchCallout>

<ResearchSection number={4} title="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.

<ResearchTable
  caption="Table 2. AI Lowers the Cost of New Output Faster Than the Cost of Validation"
  columns={[
    { label: 'Metric' },
    { label: 'Finding', mono: true },
    { label: 'Interpretation', muted: true },
  ]}
  rows={[
    ['New GitHub users trying Copilot', '~80% in first week', 'AI is becoming part of the default developer on-ramp, not an advanced add-on.'],
    ['Developers using or planning AI tools', '84%', 'The floor for AI-assisted creation is now mainstream.'],
    ['Professional developers using AI daily', '51%', 'Daily interaction turns prompt fluency into a career hygiene factor.'],
    ['Developers reporting positive productivity effect', '52%', 'Perceived speed gains are real enough to change behavior.'],
    ['Controlled-task Copilot speedup', '55% faster', 'Greenfield or bounded tasks compress dramatically under assistance.'],
    ['Experienced OSS developers with frontier AI', '19% slower', 'Maintenance, integration, and verification remain stubbornly expensive.'],
  ]}
  footnote="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.

</ResearchSection>

<ResearchSection number={5} title="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.

<ResearchTable
  caption="Table 3. Creation Domains vs. Selection Domains"
  columns={[
    { label: 'Domain Type' },
    { label: 'Base Artifact Availability' },
    { label: 'Real Bottleneck', muted: true },
    { label: 'Failure Mode', muted: true },
  ]}
  rows={[
    ['Commodity software patterns', 'Open-source packages, starter kits, example repos', 'Integration, maintenance, and distribution', 'Shipping another thin clone with no leverage below the UI'],
    ['Standardized legal or compliance forms', 'Official forms, public packets, filing guides', 'Jurisdiction choice, fact collection, review', 'Inventing a fresh packet when the official one already exists'],
    ['Protocolized integrations', 'Schemas, SDKs, interface specs, server templates', 'Correct mapping, testing, and monitoring', 'One-off glue code that cannot be reused or checked'],
    ['High-judgment domains', 'Sparse or contested templates', 'Expert interpretation and liability-bearing review', 'Over-trusting generic generation where judgment is the scarce asset'],
  ]}
  footnote="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.

</ResearchSection>

<ResearchSection number={6} title="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.

</ResearchSection>

<ResearchCallout>
  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.
</ResearchCallout>

<ResearchSection number={7} title="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.

<ResearchTable
  caption="Table 4. The Recreation Ladder"
  columns={[
    { label: 'Move' },
    { label: 'Use It When' },
    { label: 'Unit of Value', muted: true },
    { label: 'AI Best Use', muted: true },
  ]}
  rows={[
    ['Reuse', 'A reliable public artifact already exists and variation is low', 'Reliability and time saved', 'Search, summarize, and adapt lightly'],
    ['Fork', 'The base artifact is sound but local changes are material', 'Local fit with inherited leverage', 'Diffing, refactoring, migration help'],
    ['Template', 'The same task repeats with bounded variable fields', 'Consistent speed with lower error rate', 'Field filling and drafting under guardrails'],
    ['Generator', 'Volume is high and the schema or protocol is stable', 'Scalable customization with validation', 'Produce variants plus tests, validators, and approval hooks'],
    ['Bespoke', 'Requirements are genuinely novel or judgment-heavy', 'Problem framing and expert reasoning', 'Research assistance and option exploration, not final authority'],
  ]}
  footnote="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.

</ResearchSection>

<ResearchSection number={8} title="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.

</ResearchSection>

<ResearchSection number={9} title="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.

</ResearchSection>

<ResearchReferences>

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.*

</ResearchReferences>

<ResearchColophon
  citation={`Baratta, R. (2026). "Everyone Is Recreating Everything: Status Signaling, Labor Anxiety, and the Case for Wheel Factories." Buildooor Research Brief, March 2026.`}
  email="buildooor@gmail.com"
/>