Whether you look at ​Anthropic's C compiler, ​Omarchy Linux, ​Rust reimplementation of coreutils or ​ArtCraft Adobe suite replacement, you can clearly see the emergence of a fundamentally new capability.

But where will it lead?

I think we can anticipate some consequences by considering the capability overhang we have now, without postulating future new capabilities.

The Freedom to Fork Is Now A Superpower.

There are 3 types of intellectual property that must be considered when forking a program: copyright, trademarks, and patents.

• Copyright:

For Open Source projects, you have the option to fork the project directly, just as you always have, subject to the license terms. For cases where the program is proprietary, or the license just has terms you find unacceptable, you'd have to rewrite it from scratch to be free from copyright claims by the authors of the original software. This one may see some novel legal challenges, but the fundamental concept seems sound: Given a target program, use an AI agent to create a detailed software specification, take that specification and give it to another AI agent to implement. And the result is an artificial clean room reimplementation no longer tied to the copyright licensing terms of the original.

• Trademarks:

This is well-trod territory; take Red Hat Enterprise Linux, strip the Red Hat logos and name, and your new Linux distro has its own name and logos. AI agents will help with the tedious work of scraping trademarks off a program, but I don't think this has been a significant roadblock, even before AI agents. AI art might mean a more polished-looking rebranding though.

• Patents:

Patent infringement is not avoided by rewriting the implementation; it is a claim on "how it works", not on "how it was written", and "I came up with it independently" does not invalidate the patent (unless you can show you came up with it before the patent holder, in the US anyway). This is not directly addressed by what we're seeing with AI agents, but we may find that we can give an AI agent a patent, tell it "you must not use this patented technology; find another way to accomplish the goal". I don't think I've seen an example of that yet, but it seems plausible to me that the models available today could achieve that.

Practically speaking, the copyright aspect has been the moat; reimplementing a piece of software was a lot of skilled man hours and thus, expensive. Today, reimplementing a piece of software is a large pile of tokens, and thus, inexpensive. Not free. Maybe not even cheap, if the software is solving a hard problem, but inexpensive by the standards of an engineering payroll.

When the cost to fork drops this much, projects that have had internal squabbling but have been held together by the high cost of reimplementation are going to split. Some of those may fight over which side keeps the trademark, but if one side reimplements, that side will naturally pick a new trademark.

Newly Viable Design Choices

If forking has become that easy, what if we took it too far, and just... forked everything in our Linux distro?

With everything forked, there are a bunch of design decisions we can make that have been practically unavailable for decades.

Look at the number of different programming languages used across any Linux distribution. You have C, C++, bash, Python, Perl, PHP, Lisp, Rust, Node.js, Java, and more. With everything forked, a distro could choose a curated set of languages and different roles for each, and translate all the others to that preferred set of languages. At which point the distro could drop support for other programming languages, along with their toolchains, gain complete consistency across components in the CI/CD pipeline, and easily share common functionality as libraries. I expect you could see significant improvements in memory and storage requirements, and likely performance improvements as well.

Similarly, if everything is already a fork, your selected GUI toolkit need be the only GUI toolkit in the system, and every application gets a native-to-my-toolkit implementation, eliminating cross-toolkit abstraction layers in the code, and gaining consistency in look and feel across the distribution. Once on a consistent GUI toolkit, a distribution could go further, with a common visual design language applied across applications on the system.

Or perhaps it's not the implementation language that you care about, but rather the file formats used. There are so many different configuration file formats used on Linux, each with their own syntactic gotchas. Maybe you like YAML, or perhaps you think XML is just the bee's knees. Translate each program's configuration structure from their snowflake format to, say, JSON so every program's configuration can be checked for correct syntax and programmatically updated.

Or maybe you want every program to emit logs in a specific form. Rather than maintaining glue code to translate a myriad different quirks, update the implementations of everything to all follow your One True Logging Pattern.

Then there are design decisions. I've seen a case where a program (I forget what program) was emitting JSON lines for something else to consume, but not all lines were JSON, and those were to be ignored if they failed to parse as JSON. It should have just used SSE as the protocol and eliminated the ambiguities of the other approach. With every program forked, when you came across such problems, you could set an agent to hunt down all instances of that same bad pattern, and wind up with greater design-level consistency across applications.

Code reuse can become more systematic. How many applications have their own set of "utility functions"? With visibility across the entire distro and language uniformity, those can be evaluated and either promoted into shared libraries for use across the distro, or eliminated because they just add pointless abstractions.

Put another way: A Linux distribution can become a cohesive software project with a deliberately chosen direction rather than a packaging practice.

Alternative Language Forks

But let's look at something smaller scale than an entire distro: individual applications.

Picture this: build a generic system for doing artificial clean room reimplementations.

I would expect to see two sides to this: the analyzer side, and the implementer side. And a documented documentation specification for software specifications (are you following me?) as the defined, one-way communication channel from the analyzer to the implementer. These may look a lot like the RFCs we're used to, but perhaps more exhaustively defined.

The analyzer could have different implementations; one for proprietary binary blobs, another for "source available" programs, a third for SaaS products, and maybe another one for "all we have to work from are YouTube tutorial videos". Set up the analyzer to check for changes in the project it's specifying, and it could even keep up with a moving target.

The implementer side would likely have different flavors for different target implementation languages, GUI toolkits, operating systems, or what-not, potentially making use of LLMs post-trained on the target for greater efficiency. Or perhaps all of that collapses to configuration because it's all similar enough.

Point that system at software to replicate, give it a target to implement for, and feed it tokens. So, so many tokens. That system could end up being nearly autonomous.

Given the creation of that tool, we could see a proliferation of "<project>, but in <language>, with 100% compatibility, under <license|public-domain>" projects. Pick the (program, language, license) triple and a catchy name, spin up the pipeline, paste a website on top with a GitHub/GitLab link, a status page, and a donation link to fund the token budget. The agent runs as long as it has token budget and something from upstream to consume, and the project website shows the token account balance and the task queue, and a pitch for donations: "We're out of tokens, and there's work to be done, won't you buy us some tokens?" or "We're chewing through the work; we estimate we have X hours of tokens left, and Y hours of work in the queue; won't you contribute?" or "We estimate we have X hours of tokens left; we're caught up, but we expect the next release of <project> will need Y hours of tokens; won't you contribute?"

If forking is so easy, why have such a project instead of just doing it yourself? Because a common baseline port would allow people to pool their token budgets on that part of the work. They may fork the resulting project to make further changes, but that fork will require fewer tokens than it otherwise would because it's starting from a baseline that is closer to the goal than the original project was.

Sibling Forks

​Shopify announced they are moving to native apps. I wonder if we'll see "sibling projects" where the design documents aim for feature equivalence, the business logic aims for near-convergence, while the GUI code aims to be completely native to that project's GUI toolkit target. Consider the ​Vim editor; we could see a Qt sibling that replaces the GUI toolkit, but works with vim.org as a peer, to structure both code bases with the aim to converge on the text editing implementation (using agents to keep them from diverging), but diverge in the GUI logic to provide native experiences for the different toolkits. Everything stays friendly, but the cognitive overhead of supporting multiple toolkits in the same code base is largely sidestepped, and new toolkits can join the family using the same tactic without overwhelming the existing siblings.

The Future Of Distributions

Today, Linux distributions consume code from a curated set of upstream projects, apply patches, package, and publish. With the capabilities described above, we might see a new generation of distributions which analyze a curated set of upstream projects or reimplementations of the upstream projects, incorporate them with AI agents into a coherent code base, then package, and publish.

As that becomes more feasible, we may see some interesting patterns of competition emerge as different distributions choose one or two minority positions on various technologies and policies, capturing the segment of the market that strongly cares about those particular issues. A distribution that rejected systemd and Wayland for instance might garner market share based on that pair of decisions, while some other distribution might select KDE as its primary desktop environment and attract a different segment. While that is possible today, a lower barrier to forking reduces the gravitational pull of "everyone is moving to Wayland", and makes the endeavor somewhat less daunting.

But What About Security?

I think security is a subset of the larger category of "quality", and I think we're going to see interesting things happen on that front.

For one, I think we're going to see what happens when getting 100% unit test coverage is just a matter of spending tokens, and getting end-to-end testing is... also just a matter of spending tokens, and integration testing is... also, also just a matter of spending tokens, and security analysis and hardening is... yes, tokens. I expect we'll find that some dimensions of software quality will be very nearly solved, but that there are some aspects for which there is no substitute for "hours spent by humans using the software for real". So while the price of "code" is approaching zero and can be created in little time, the price of "software you can rely on" has a different and slower arc. There are things that have been used as a proxy to gauge the quality and expected longevity of a software project -- such as website polish, look and feel of the app -- which are going to take a back seat to other measures, such as the number of active users, and, I think, age. A new project started last month is a neat, promising tool, but not one you build into a critical path. A project that has been around a while, with a slow tick of patches and releases (rather than the flood of commits seen in early development) is going to command a greater respect.

And that means there remains an incentive for shared codebases; as tokens are poured into a project and users spend hours using it, there is residual value that accumulates in the source code, driving up the token cost to reimplement it. We are going to start measuring moats based on the token cost of a replacement, and the user hours to build trust.

We are in the midst of a tsunami of security vulnerability findings, but I don't think there are an infinite number of security bugs in a distribution. It may be a very large number, but not infinite. I think we will see an increase in the defensiveness of library code as AI agents probe for every possible corner case, and every bug gets treated as a security bug by default. And as that happens, we should find that bugs drain out of our (maintained) systems. And for new functionality, each agent that translates the work into another language, toolkit, or license is another set of eyes that can catch newly introduced bugs. And while each of those agents is also a vector for a bug to get introduced during translation, an agent watching multiple translations for inconsistencies has a great vantage point for catching them.

A proliferation of forks also undermines the tendency toward a monoculture, and thus the fragility inherent in all systems being susceptible to the same exploit. A bit more diversity in our software stacks might provide some resiliency. As for which side of that balance wins in the end though, I'm not ready to place a bet.

Obvious Dangers

If every operating system has its own implementation for email clients, office productivity suites, video-editing software, etc. then every one is going to have different bugs. And, setting security issues aside, that suggests we are going to see a rise in the importance of extremely precise file format definitions that everyone adheres to. We may see projects arise that exist solely to define a single file format and publish test suites to demonstrate compliance or non-compliance of any arbitrary implementation.

Code Negative Space

Agentic translations have an interesting pitfall I haven't seen discussed. The negative space in a code base may be there for a reason. Something won't work, so it isn't in the code, but neither is there something in the code telling you so -- that's "code negative space". Perhaps it is because someone never wrote the comment; or maybe the comment got "cleaned up" during some refactor, or maybe the original author understood the domain well enough that he almost subconsciously avoided the problem. An AI agent translating the code to another language might tread straight into that space and wind up with a real problem in the end. Maybe testing will catch it? I dunno, but I think this is something to watch for.

Economics

So. Many. Tokens. The cost is real. Sure, tokens seem cheap right now, but what they would cost in a world not awash in trillions of dollars in venture capital is hard to nail down. Regardless, they require chips and take power, and a DGX Spark that I bought for $4500 in August is today either 2x that price or simply unobtainium. Meanwhile, the cost in energy is reality; unyielding physics. There remains a lot of room for efficiency gains in multiple dimensions, so cost-for-task is likely to decline for a while yet. But the demand is climbing, and the costs can't actually reach zero.

Conclusion

I think we are going to see some amazing projects from people who have a clear vision of "no, all y'all are wrong; we should do it this other way". And we may get to experience what a coherently designed, consistently implemented, polished Linux distribution can feel like.

I think there is a lot to look forward to here.