Essay
A weekend with Omarchy, and the end of default software
One weekend with Omarchy Quattro and a coding agent turned a 13-year-old MacBook Air into a personally shaped operating system. The deeper story is economic: defaults existed because customization was expensive. Agents just collapsed that cost, and the consequences run from the desktop to enterprise IT.
I spent the weekend trying out Omarchy Quattro, the new open Linux system, on my 13-year-old MacBook Air. The machine got a new life, which is a nice outcome on its own. But the hardware revival turned out to be the least interesting part of the experiment.
Omarchy out of the box is simple and elegant. The shift happened when I connected it to a coding agent. Once dictation was configured, I could ask the agent to control, build, or change essentially any function of the system by talking to it. To test how far this goes, I built a full theme based on Black Myth: Wukong, the game by Game Science. The color tone and style extend across everything: terminal, desktop, wallpaper. One coherent visual identity through the whole system, not a wallpaper pack bolted on top. Then I created a customized menu bar in a single dialogue with the agent.
What used to mean an evening in dotfiles and forum threads now takes one spoken sentence. That speed is not a convenience improvement. It breaks an economic assumption that has shaped all of personal computing.
Defaults were never a design choice
Software has always been the most extreme economy of scale we know: enormous cost to write once, near-zero cost to copy. That economic shape forced a product shape. To amortize the writing cost, everyone had to run the same artifact, so the vendor’s job became choosing defaults that offended the fewest people. The menus, the theming options, the settings panel: all of it is a negotiated compromise between millions of users who will never meet.
Customization existed, but it was priced in scarce human attention. Reshaping your environment meant config-file literacy and weekends of forum archaeology, so almost nobody paid. The Linux desktop proved this for twenty years: infinitely malleable in principle, rarely reshaped in practice. Openness alone was never the constraint. Labor was.
Agents change the input that was scarce. When the cost of a deep modification drops from an evening to a sentence, the amortization logic that justified identical copies stops binding. The vendor no longer has to guess what the median user wants, because the median user no longer exists as an economic necessity. What ships is not a finished product but a starting point: raw material the agent shapes around one person.
Why it takes both halves
Neither ingredient gets you there alone, and it is worth being precise about why.
An agent on a closed system can only rearrange the furniture it is allowed to touch. The boundary of personalization is set by the vendor’s API surface, and that surface is itself a mass-market compromise, drawn where the vendor’s liability and business model allow. The agent inherits the median-user assumptions it was supposed to dissolve.
An open system without an agent has the opposite problem: unlimited surface area, no labor to work it. Omarchy plus an agent combines the halves. The openness supplies legibility, because everything the agent needs to change is a readable text file rather than an opaque binary or a locked settings store. The agent supplies hands. It matters that Omarchy’s whole design (plain configs, one coherent structure) happens to be the ideal substrate for a language model. Systems built to be legible to humans turn out to be legible to agents, and that property is suddenly worth more than any feature list.
The fork problem
Here is the harder question the weekend left me with. My laptop now runs something no one else runs. Multiply that by every user with an agent and you get millions of divergent forks of the same system. Who maintains mine when the upstream ships a security patch that conflicts with my Wukong theme and my hand-rolled menu bar?
The honest answer is: the same agent that built it. The agent is not a one-time customizer; it is a resident maintainer that can re-apply my intent on top of every upstream change. That inverts how we think about software updates. Today an update replaces your copy with the vendor’s new copy. In the agent model, an update is a merge: upstream’s changes reconciled with a personal layer the agent knows how to regenerate. Configuration stops being state you accumulate and becomes intent you can replay.
That only works if the intent is captured somewhere durable, which is a discipline problem, not a technology problem. The failure mode is a system full of changes nobody remembers asking for. The systems that win this era will treat the personal layer as a first-class artifact, versioned and replayable, not as drift.
The enterprise version of this question
I run platforms for a living, so I cannot help translating. Enterprise IT is built on the same economic assumption that just broke: standardization exists because variance was expensive to support. Golden images, managed endpoints, locked-down configurations. We standardized because every deviation used to cost a human’s time twice, once to make and once to support.
When employees carry agents, variance becomes cheap to create, and the old response (forbid it) starts fighting the productivity the company bought the agents for. The sustainable posture is the one the fork problem points to: stop governing state and start governing intent. Let the environment vary; require that the variance be declared, versioned, and replayable; pin the guarantees (security baseline, compliance, data boundaries) to a layer the personal layer cannot touch. That is a platform contract, and almost no enterprise tooling is shaped for it yet.
Where this lands
A 13-year-old laptop running an operating system shaped to one person in a single weekend is a small event with a long shadow. Mass-produced software was an artifact of expensive labor, and that era is ending at the exact layer where it started: the operating system, the most default-laden software we use.
For forty years the question was how well you knew your tools. The better question now is how well your tools know you, and the question after that, the one worth building for, is who maintains the version of the world that knows you.