26/26
In 1976, twenty-six years after Alan Turing's 1950 machine-intelligence paper, Bill Gates wrote to the hobbyists.
Software had become valuable before the culture around it had agreed what kind of object software was. Was it craft, research, property, infrastructure, speech, shared experiment, or something else? Gates' letter did not settle that question. It did mark a public moment when software stopped being only a thing people ran and became a thing people had to argue about.
In 2026, twenty-six years after Y2K, this is a letter to the future hobbyists.
Not because 2050 is an agreed deadline. Not because a hidden counter will turn over and break the world. Because 2050 is close enough to plan for and far enough away that planning still matters. It is one hundred years after Turing's paper, which makes it a useful horizon for asking what the second century of computation should be allowed to inherit from the first.
Y2K gave the public a simple technical fear: old systems might fail because hidden assumptions had been built into them. Many people later treated it as a false alarm because the worst visible outcomes did not happen. That is the lazy lesson. The better lesson is that risk can become quieter because people do the work before the deadline.
Turing 2050 should be the reverse of Y2K: not a panic, but a cutover. Not a date where the world waits to see what breaks, but a public horizon where humanity decides that the next computing world should not inherit the first one by accident.
The First Accidental Century
The first century of computation proved that machines could run almost anything. That was the miracle, and it was also the problem.
A general computer can run useful software, broken software, malicious software, old software, half-understood software, and software that still works only because nobody has touched the wrong dependency for fifteen years.
The first computing world was not designed as one coherent civilization layer. It grew through research, hobby, business, war, bureaucracy, entertainment, convenience, emergency, and habit. Research code moved into products. Products moved into infrastructure. Infrastructure moved into public life. Public life moved into machine-dependent society.
That movement produced extraordinary capacity. It also produced a stack that nobody fully owns, fully reads, or fully understands.
This is not theoretical. Critical institutions still carry systems that are decades old, expensive to maintain, short on specialist skills, and exposed to security risk when hardware, software, or languages outlive their support world. The old stack does not always retire when the brochure says it should. Sometimes it becomes payroll, tax processing, health care, dams, transport, or national security.
The result is not simply bad code. That would be too easy. The result is an inherited stack of old assumptions, old protocols, old languages, old build systems, old devices, old permissions, old secrets, old dependencies, and old interfaces that now carry things too important to treat as historical accident: money, health, identity, public records, energy, transport, work, language, weapons, memory, and now AI agents.
The first century proved that machines could run. The second century must prove that civilization can survive what it runs.
This Is Not a Call to Destroy Old Machines
Old electronics should not be hated. They should be preserved, repaired, studied, archived, and loved.
A broken router, a laptop, an old server board, a game console, a phone, a forgotten embedded device, a mainframe interface, or a hobby computer can be part of the record of how humans learned to build with electricity, logic, language, memory, and error.
But an artifact is not the same thing as a safe foundation.
By 2050, much of today's electronics should be treated as legacy or antique computing. That does not mean it disappears. It means it should no longer silently carry the critical layers of the future unless it has been understood, bounded, bridged, or certified for that role.
Old computation may be preserved. Uncertified computation may be studied. Experimental computation may be sandboxed. Local systems may keep running where they are known and bounded.
The line is not between old and new, or between human and AI, or between open and corporate. The line is between computation that can explain its right to carry critical responsibility and computation that cannot.
No Certificate, No Civilization-Level Execution
The old software rule was simple: it works, so ship it.
That rule built a world. It should not be allowed to build the next one alone. A future rule should be harder: it builds, but it is not certified for this responsibility, so it cannot run in critical mode.
This rule must apply to AI-written code and human-written code. AI code is not trustworthy because it was generated quickly. Human code is not trustworthy because a person wrote it. Corporate code is not trustworthy because it was funded. Open-source code is not trustworthy because it is visible. Government code is not trustworthy because it is official.
Code becomes trustworthy only when it can declare what it is for, what it depends on, what it may access, what it may not do, how it was built, how it can be checked, and why it is allowed to run in the context where it is being used.
Trust is not authorship. Trust is not branding. Trust is not speed. Trust is the result of a system that can be inspected and refused.
AI may generate. Humans may generate. Compilers may build. But only certification may authorize. No certificate, no civilization-level execution.
The Pieces Already Exist
The future stack does not begin from nothing.
There are already formally verified kernels. There are verified compilers. There are memory-safe languages. There are software supply-chain frameworks that ask where an artifact came from, how it was built, and what produced it. There are software bills of materials, transparency logs, reproducible-build practices, proof-carrying code, secure-by-design arguments, sandboxing traditions, capability systems, hardware capability research, proof assistants, fuzzing, model checking, and risk frameworks for generative AI.
None of these are enough by themselves.
A verified kernel does not verify the whole society that runs above it. A verified compiler does not prove that the program was worth compiling. A memory-safe language does not fix a wrong requirement. A software bill of materials does not make a dependency safe. A signature does not make a supply chain honest. A reproducible build does not prove that the reproduced thing is the right thing to run. A sandbox does not decide what a system should be allowed to want. An AI risk framework does not become enforcement unless institutions and machines are built to enforce it.
That is the point. The second century of computation does not need a mythic ultimate language. It needs a public protocol that connects intention, implementation, compilation, dependency lineage, runtime authority, hardware limits, audit, refusal, and governance.
It needs a way to say what has been checked, what has not been checked, what assumptions remain, and where the result may run.
The Future Stack
A future stack might need a language for intention: a way to say what the system is for before anyone writes implementation code.
It might need a language for implementation: a way to build the system without making unsafe patterns normal.
It might need a language for certificates: a way to express what has been checked, what has not been checked, what assumptions remain, and what context the result is allowed to run inside.
It would also need a compiler that does more than accept syntax, a certifier that can reject complexity, a runtime that can enforce limits, and hardware that can participate in refusal rather than only execution.
That does not mean hardware can magically know truth. It means future machines should be designed so unclear authority, unreadable permissions, and untraceable lineage are not normal conditions for critical operation.
The human should be able to state the purpose and the boundary in plain terms: what the system is for, what it must never do, what data it may touch, what actions require permission, what assumptions it is allowed to make, and what failure modes are acceptable or unacceptable.
The AI can help implement, refactor, test, document, migrate, and explain. But the AI does not get authority because it can produce code. The implementation must pass the gate.
If the module is too complex to certify, it may be too complex to run in critical mode. If the permissions are too broad to explain, they are too broad to grant. If the dependency chain cannot be traced, it cannot be trusted as a foundation. If the system cannot say what it is allowed to do, it has not earned the right to operate at civilization scale.
Future software must explain its right to execute.
Can All Bugs Be Fixed?
No. Not in the absolute sense.
A bug is not only a typo in code. A bug can be a wrong requirement, a bad specification, a human misunderstanding, a broken incentive, a hardware fault, a migration bridge, an old assumption, a political choice, or a system used in a context it was never designed to survive.
Computation cannot remove reality, and no certification regime should pretend otherwise.
But the question is not whether every possible bug can disappear. The question is whether known classes of preventable failure should still be allowed to carry critical systems when humanity has had decades to remove them from that role.
Memory corruption should not remain a normal foundation. Unknown dependencies should not remain a normal foundation. Unsigned builds should not remain a normal foundation. Invisible permissions should not remain a normal foundation. AI agents with unclear authority should not remain a normal foundation. Legacy systems nobody owns should not remain a normal foundation.
The goal is not a world without bugs. The goal is a world where known classes of preventable failure are no longer allowed to carry civilization.
Using Compute to Repair Compute
The strange possibility of the next twenty-four years is that computation can be used to repair computation.
Not as magic, and not as a reason to trust whatever machines produce. As labor.
Large-scale compute can search state spaces, test edge cases, fuzz protocols, inspect dependencies, generate proofs, find memory hazards, map build chains, rewrite unsafe modules, and compare intended behavior against real behavior.
AI systems can help with the boring work humans avoid until it becomes dangerous. They can help read old code, translate old interfaces, produce candidate implementations, explain why code was rejected by a certifier, and reduce complexity until a system becomes small enough to check.
That is not AI replacing responsibility. It is AI being used inside responsibility.
If a civilization can spend vast compute on advertising, trading, entertainment feeds, synthetic persuasion, and arms-race acceleration, it can also spend compute on making the machine world less accidental.
That is the Great Refactoring: not a product, not a startup category, and not a magic button. A species-level maintenance task.
The 2050 Cutover Rule
The cutover should be simple enough to read:
After 2050, no critical system should depend on software that cannot declare its purpose, permissions, dependencies, lineage, limits, and certification status.
That sentence is not a law. It is not a standard. It is a proposed rule for thinking clearly about what the next computing world should refuse.
Old systems may remain. They may be bridged, preserved, repaired, studied, and used locally. But they should not remain hidden foundations of critical future infrastructure.
The bridge matters, because a bad migration can become its own attack surface. A new protocol can become a monopoly. Certification can become a corporate toll booth. Safety language can become control language. That must be refused from the start.
The specification must be open. The checker must be small enough to inspect. The build should be reproducible. The lineage should be readable. The certification logic should not be owned by one company.
A future machine that can only be trusted by trusting a platform owner is not yet a public machine.
Anti-Doom by Construction
This is not a doom document. It is not a prophecy, and it is not the claim that 2050 will break the world.
The point is the opposite. If the world becomes safer by 2050, that will not mean the risk was imaginary. It may mean the work was done early enough.
That is the right Y2K lesson. Risk can fall when it becomes visible, public, specific, and attached to repair work.
P(doom) is not fate. It is a way of saying that catastrophe becomes more plausible when civilization runs systems it cannot read, limit, repair, verify, or inherit.
The purpose is not to predict doom. The purpose is to make doom increasingly implausible.
2626
If 2050 sounds far away, look further. Look to 2626, not as a prediction, but as an inheritance test.
Six hundred years after this letter, someone may open an archive and find the machines we now call modern: a phone, a router, a laptop, a server board, a broken sensor, or a forgotten dependency printed on old paper.
They may smile at the fragility of it all, the same way we smile at vacuum tubes, punched cards, early home computers, and the strange optimism of the first software age.
But let them not discover that we knew the foundations were accidental and did nothing.
Let them find that, in 2026, twenty-six years after Y2K, we began to ask a better question: not only whether machines can think, not only whether software has value, and not only whether old systems might fail, but whether future computation can be built so that it may be inherited.
The answer should be readable, repairable, limited, verifiable, open enough to study, safe enough to trust, and strange enough that hobbyists still want to touch it.
The next computing world should not be an accident.
Let 2050 be the cutover horizon. Let 2626 be the proof that someone cared early enough to begin.
Begin writing the specification now.