Essay
A weekend with Omarchy - is the end of default software coming too soon?
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.

Wukong Ink And Bronze — one visual identity across the desktop, terminal, wallpaper, and menu.
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: huge 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.
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.