Bootstrapping and the Game of Entrepreneurship
Published:
This post supports English / 中文 switching via the site language toggle in the top navigation.
The Pattern
There is a pattern that keeps showing up in places that seem to have nothing to do with each other.
It started when I vibe coded an operating system over a weekend — letting an AI write most of the code while I steered — and watched the system gradually take over its own definition from the host language that birthed it. Then I noticed the same shape in how AI development is evolving. And then again in how startups grow. The pattern has a name — bootstrapping — and once you see it, it is hard to unsee.
At bottom, bootstrapping is about entropy. You cannot conjure order from nothing. To build a new system that sustains itself, you need an already-ordered system to inject the initial structure. A seed crystal dropped into a supersaturated solution. A lit match held to dry kindling. The interesting question is what happens next: does the new system accumulate enough internal order to carry itself forward, or does it fizzle out? That question turns out to have the same shape whether you are building a compiler, training an AI, or starting a company.
The Compiler: A System That Defines Itself
In systems programming, bootstrapping has a precise meaning. A compiler written in its own language cannot compile itself from nothing — it needs an existing compiler, usually written in a different language, to produce the first working binary. Think of it this way: you cannot learn French from a dictionary that is written entirely in French. You need a French-English dictionary first. Once you are fluent, the French-only dictionary becomes useful — but not before.
I watched exactly this happen with my OS project. The system language started out unable to describe its own environment, so a host language handled everything — the shell, the runtime, the filesystem. But as the system language grew more expressive, it took over one layer after another, and the host language shrank to a thin substrate underneath. Each layer of new capability enabled the next. The external dependency never fully vanished, but it receded: the system’s center of gravity shifted from being defined by something else to being defined by itself.
This is the first instance of the entropy principle. The host language was the ordered system that injected structure into a new system that could not yet stand on its own. Once enough internal structure accumulated, the new system became self-sustaining.
AI: The Loop That Closes
The same pattern is playing out in AI at a much larger scale. Early deep learning required enormous human effort: hand-designed architectures, manually curated datasets, hand-tuned training pipelines. The models were entirely passive artifacts of human-built machinery. Humans were the host compiler.
But as models grew more capable, they started participating in their own improvement cycle — writing training code, generating synthetic data, assisting in architecture search. Projects like auto-research push further still: AI agents reading papers, forming hypotheses, running experiments, writing up results. The output of one generation of training becomes the input to the next.
We have arguably crossed a quiet inflection point: the systems we created can now contribute to their own development in ways that go beyond what any individual human could sustain alone. This is not the recursive intelligence explosion of science fiction — human judgment remains essential at every step of the loop, and the bootstrapping is far from complete. But the structural shift is real: AI has moved from being a purely passive product of human engineering to being an active participant in its own evolution.
Here, too, the entropy principle holds. Human researchers are the ordered system that bootstrapped the first generation of models. Those models are now helping to build the next generation. But the question of convergence is open — the loop can compound capability, or it can compound error.
The Startup: A Founder Who Makes Herself Unnecessary
Starting a company follows the same arc. In the earliest stage, the founder does everything — code, sales, finances, supplier negotiations, customer support, and probably taking out the trash. You are the host compiler; the system cannot run without you doing everything by hand.
The first hire shifts one function to dedicated capability, but you are still deeply involved: making key decisions, training the new person, setting processes. The real bootstrapping moment comes later, and you often recognize it only in retrospect. One day you discover that a meeting happened, a decision was made, a customer problem was solved — and you were not in the room. Not only was the outcome fine, it was better than what you would have done yourself, because the person closer to the problem had context you did not. That is the moment the organization starts to self-host.
The recursive structure is the same as in the other two domains: the founder cultivates people who cultivate people, just as the compiler compiles itself and the model trains the next model. The founder’s job is, paradoxically, to make herself less necessary — to inject enough order into the organization that it can generate its own order going forward.
Three Regimes of Bootstrapping
The analogy across these three domains is real, but it hides an important asymmetry that is worth pulling apart.
The converging kind. Compiler self-hosting is a process that converges. Once the compiler can compile itself, the bootstrap is structurally complete, and what follows is incremental improvement on a stable foundation. The external dependency does not disappear — you still need hardware, an OS, a linker — but the core recursive loop closes and stays closed.
The open-ended kind. Entrepreneurship never truly converges. There is no steady-state self-hosting for a company. External dependencies — markets, customers, regulation, competition — are always shifting, and the organization itself needs continuous restructuring. A company that stops adapting does not remain self-hosted; it decays. The bootstrapping never “finishes.”
The fragile kind. AI sits somewhere in between, and this is what makes it the most interesting case. The self-improvement loop can compound capability, but it can also go wrong. Reward hacking, model collapse, and distribution drift are all failure modes where the recursive process amplifies errors instead of capability. A model trained on its own outputs can spiral into incoherence — the exact opposite of the virtuous loop you want. The bootstrap can amplify failure just as easily as success.
Recognizing which regime you are in matters enormously, because it determines what vigilance looks like. In the converging regime, you can eventually relax. In the open-ended regime, you never stop adapting. In the fragile regime, you monitor the loop itself for signs of decay.
Why Cold Starts Kill
Bootstrapping fails more often than it succeeds, and the failure modes are instructive.
Not every language that attempted self-hosting got there. Some were too weak to express their own compiler before the community lost interest — the initial injection of order was not sufficient, and the window of opportunity closed. In AI, self-training can produce a vicious cycle: biases and hallucinations amplified round after round until the model collapses into noise. In entrepreneurship, many companies die precisely in the bootstrap phase, because the initial external structure — the founder’s skills, the quality of the first hires, the size of the seed capital — was not good enough to reach escape velocity.
This is the entropy principle made concrete. You need an already-ordered system to help you build a new ordered system. When the initial injection of order is insufficient, the new system never accumulates enough internal structure to sustain itself. The quality of the cold start — the bootloader, the training set, the founding team — is not just important. It is often decisive.
Bootstrapping Is Not Scaling
There is a saying: one person can go fast, but a group can go far. The connection to bootstrapping is tighter than it first appears, but also different from what it seems.
The essence of bootstrapping is not “more people, more capability.” It is that the output of each stage becomes the input of the next. The compiler compiles itself. The trained model helps train the next model. The people you cultivated go on to cultivate more people. This recursive self-application is the soul of bootstrapping, and it is what separates it from mere scaling. Scaling adds resources linearly. Bootstrapping makes the system generative — capable of producing more of its own capability.
This distinction has a practical edge. A company that keeps hiring but never develops internal leadership has scaled, not bootstrapped. A training pipeline that uses more data but never lets the model contribute to its own improvement has scaled, not bootstrapped. The question is always: can the system reproduce and extend its own capability, or does it depend on external injection for every increment of growth?
What Bootstrapping Teaches
Once you see bootstrapping as a recursive, entropy-fighting process, several things become clearer.
The cold start is everything. A weak bootloader, a noisy training set, a bad founding hire — each can doom the entire chain before it has a chance to become self-sustaining.
Self-sustenance is not the finish line. Even after a system achieves the ability to maintain itself, complexity grows with capability, and unchecked complexity becomes fragility. Continuous internal optimization is not optional; it is the price of survival.
Know which game you are playing. The converging kind of bootstrapping lets you rest once the loop closes. The open-ended kind demands perpetual adaptation. The fragile kind requires you to watch the loop itself, because it can turn against you.
I started this line of thinking by watching an operating system slowly take over its own definition from the language that built it. By the end of that weekend, the host language had receded into the background, and the system was — for all practical purposes — defining itself. It was a small thing, a toy OS on a hobby project. But the shape of it has stayed with me, because it is the same shape I see everywhere: a new system borrowing order from an old one, accumulating enough structure to stand on its own, and then — if things go well — becoming the source of order for the next thing that needs to bootstrap.
Bootstrapping is about building the ability to build — and knowing when the thing you built can carry itself forward.