Click here to go see the bonus panel!

Hovertext:
I want to be buried at the K-T boundary holding a box of brass gears marked Time Machine.

In the past few months, I’ve been stress-testing how far AI coding agents can take us when building real, production-grade distributed systems.

The result: a Rust-based multi-Paxos consensus engine that not only implements all the features of Azure’s Replicated State Library (RSL) [1] — which underpins most major Azure services — but also modernizes it for today’s hardware.

The entire project took me ~3 months, with 100K lines of Rust code written in ~4 weeks and performance optimization from 23K operations/sec to 300K ops/sec achieved in ~3 weeks.

Besides unprecedented productivity, I discovered several techniques that were instrumental. This post shares my most valuable learnings on: ensuring correctness with code contracts, applying lightweight spec-driven development, and pursuing aggressive performance optimization — plus my wish list for the future of AI-assisted coding.

Why Modernize RSL?

Azure’s RSL implements the multi-Paxos consensus protocol and forms the backbone of replication in many Azure services. However, RSL was written more than a decade ago. While robust, it hasn’t evolved to match modern hardware and workloads.

There are three key gaps motivated this project:

1. No pipelining: When a vote is in flight, new requests must wait, inflating latency.
2. No NVM support: Non-volatile memory is now common in Azure datacenters and can drastically reduce commit time.
3. Limited hardware awareness: RSL wasn’t built to leverage RDMA, which is now pervasive in Azure data centers.

Removing these limitations could unlock significantly lower latency and higher throughput — critical for modern cloud workloads and AI-driven services.

Given my interest in Rust and AI-accelerated development, I set out to build a modern RSL equivalent from scratch.

Massive Productivity Boost

In roughly six weeks, I’ve driven AI and implemented over 130K lines of Rust code covering the full feature set of RSL, including multi-Paxos, leader election, log replication, snapshotting, and configuration changes.

I utilized many available AI coding agents: GitHub Copilot, Claude Code, Codex, Augment Code, Kiro, and Trae. My workflow evolved quickly, but today my main drivers are Claude Code and Codex CLI, with VS Code handling diffs and minor edits.

I’ve found that coding from the CLI creates a perfect asynchronous flow that maximizes my productivity. I also discovered a simple psychological trick:

I pay $100/month for Anthropic’s max plan. This became a forcing function — if I don’t kick off a coding task with Claude before bed, I feel like I’m wasting money.

When Codex CLI arrived, I added a second ChatGPT Plus subscription to handle rate limits — one subscription for Monday–Wednesday, the other for Thursday–Sunday.

Code Contracts — By AI, For AI

The question I get most often is: How can AI possibly implement something as complex as Paxos correctly?

Testing is the first layer of defense. My system now includes 1,300+ tests — from unit tests to minimal integration tests (e.g., proposer + acceptor only), all the way to multi-replica full integration tests with injected failures. See the project status.

But the real breakthrough came from AI-driven code contracts.

Code contracts specify preconditions, postconditions, and invariants for critical functions. These contracts are converted into runtime asserts during testing but can be disabled in production builds for performance. While I started using this approach long ago with .NET [2], AI has made contracts vastly more powerful.

Here’s how I apply them at three levels:

1. Ask AI to write contracts. Opus 4.1 writes good contracts, but GPT-5 High writes excellent ones. I focus on reviewing and refining. For example, the process_2a method (handling phase 2a messages in Paxos) has 16 contracts, including this one:

2. Generate tests from contracts. Once contracts are defined, I ask AI to create targeted test cases for each post-condition. It excels at this, generating meaningful edge cases automatically.

3. Property-based tests for contracts. This is my favorite. AI translates contracts into property-based tests, exploring a vast space of randomized inputs. Any contract violation triggers a panic, exposing deep bugs early.

For instance, one AI-generated contract found a subtle Paxos safety violation:

That single contract saved what could have been a serious replication consistency issue — well before it ever hits production.

Lightweight Spec-Driven Development

I’ve tried various Spec-Driven Development (SDD) tools. In fact, the earlier components (such as leader election, proposer, acceptor, and learner) were all implemented following a rigid SDD approach. I would start with a requirement markdown, turn it into a design markdown, and then a task list markdown. However, I gradually found this process too rigid; making changes along the way and ensuring all documents remained consistent became a headache.

I’ve now switched to a more lightweight approach. When I work on a feature (e.g., snapshotting), I use /specify from spec kit [3] to generate a spec markdown. This spec consists of a few user stories and acceptance criteria.

Here is an example user story for snapshotting:

I then use /clarify to ask the AI to self-critique and improve the user stories and criteria. I also ask it to suggest additional user stories not covered in the initial spec. I spend the majority of my time here.

Once satisfied, I jump into plan mode and ask AI to generate a plan for a specific user story. Given the capability of today’s AI coding agents, a single user story feels like the “sweet spot” unit of work they can manage effectively. Along the way, we may discover additions or tweaks, which are easy to handle in the same coding session (agents might compress context, but I typically don’t worry about losing too much).

Here is a sample /clarify interaction for configuration changes:

● Question 4: Starting Slot Determination

  How should the starting slot for the new configuration be determined relative to the ending slot?

  Recommended: Option A - Always exactly ending_slot + 1

  This ensures no gaps in the slot sequence and maintains continuity between configurations, preventing any slots from being orphaned or unassigned.

  | Option | Description                                                    |
  |--------|----------------------------------------------------------------|
  | A      | Always exactly ending_slot + 1                                 |
  | B      | Allow operator to specify any value > ending_slot              |
  | C      | Next multiple of 1000 after ending_slot for cleaner boundaries |
  | D      | Same as ending_slot (both configs share final slot)            |

  You can reply with the option letter (e.g., "A"), accept the recommendation by saying "yes" or "recommended", or provide your own short answer.

Aggressive Performance Optimization

Performance optimization is where AI really shines. After ensuring initial correctness, I spent about three weeks purely on throughput tuning — and AI became my co-pilot in performance engineering.

Through iterative cycles, we boosted throughput from ~23K ops/sec to ~300K ops/sec on a single laptop. Here’s the loop I followed repeatedly:

1. Ask AI to instrument latency metrics across all code paths.
2. Run performance tests and output trace logs.
3. Let AI analyze latency breakdowns (it writes Python scripts to calculate quantiles and identify bottlenecks).
4. Ask AI to propose optimizations, implement one, re-measure, and repeat.

This process surfaced insights I might have missed — for example, lock contention on async paths, redundant memory copies, and unnecessary task spawns.

Rust’s safety model made it easy to push these optimizations confidently. Key gains came from minimizing allocations, applying zero-copy techniques, avoiding locks, and selectively removing async overhead. Each improvement felt like peeling another layer of latency off a high-performance engine — without fear of corrupting memory.

Wish List for AI-Assisted Coding

Reflecting on my journey, I keep wondering where AI could deliver even more value. Here are some items on my wish list:

End-to-End User Story Execution: I still prefer to define the user stories myself. As an architect, I feel I have a better sense of what I’m building and how I’d like to build it. However, the delivery of a perfect execution is something I believe AI can handle increasingly well. Today, I still have to spend a fair amount of time steering the AI — telling it to continue when it pauses, suggesting refactoring, reviewing test coverage, and suggesting additional tests. I would prefer the AI take more autonomy to drive this end-to-end.

Automated Contract Workflows: The flow of applying contracts seems largely automatable. While I’d still want to review the contracts and offer suggestions, I’d like the AI to drive the rest: generating tests based on contracts, debugging individual test cases, ensuring consistency between tests and contracts, and writing property-based tests. When a test fails, I’d like the AI to debug and fix trivial issues automatically, only notifying me when there are genuine correctness issues in the contracts or the implementation.

Autonomous Performance Optimization: Performance tuning seems ripe for more automation. Much of what I’ve done is repetitive and parallelizable. Projects like AlphaEvolve (or OpenEvolve) show promise in this direction. Ideally, I would suggest potential optimization avenues, and the AI would execute the experiments completely by itself. While current tools handle small bodies of code, applying similar techniques to larger codebases with end-to-end measurement seems feasible.

Appendix: Project Status

The seed of the project is an elegant design markdown authored by Jay Lorch [4] from Microsoft Research. This design greatly simplifies all the components in multi-Paxos, making it easier to implement and reason about.

So far, 2 out of the 3 RSL limitations have been addressed: pipelining and NVM support (Jay integrated the fully verified persistence log for NVM which was published in the PoWER Never Corrupts paper [5] at OSDI 2025). The RDMA support is still TBD.

To date, the project has grown to over 130K lines of Rust code, with 1,300+ tests accounting for more than 65% of the codebase.

Adblock test (Why?)

This is a virtual museum of operating systems (and standalone applications) running under emulation, implemented as a Linux VM for QEMU, VirtualBox, or UTM.

A custom emulator-independent launcher is provided, and all OSes and emulators are pre-installed and pre-configured. The launcher includes a snapshot feature to quickly revert broken installations back to a working state. Hypervisor installers and shortcuts to run the VM on Windows, macOS, and Linux are also included.

Want to see the earliest resident monitors? The ancestor of all modern OSes (CTSS)? The earliest versions of Unix? The first OS with a desktop metaphor GUI (Xerox Star Pilot/ViewPoint)? Early versions of mainstream OSes? If you want to explore historical OSes and platforms without having to worry about configuring/installing emulators and OSes or corrupting emulated installations, you’ve come to the right place.

Just about every well-known OS and platform (and also a lot of obscure ones) is included in some form, spanning the entire history of stored-program computing from the Manchester Baby of 1948 (the first stored-program computer) to the present day.

The catalogue covers, among many other things:

• The earliest mainframes: Manchester Baby test/demo programs, Mark 1 Scheme A/B/C/T (the earliest examples of system software that could be considered as an OS), various EDSAC software, etc.
• Later mainframes and minicomputers: CTSS, MVS, VM/370, TOPS-10/20, ITS, Multics, RSX, RSTS, and more
• Workstations and Unix variants: PERQ OSes, SunOS, IRIX, OSF/1, A/UX, NeXTSTEP, Plan 9, various BSDs, plus Linux distributions across the decades, and more
• Home computers: various CP/M variants, Apple II, Commodore 8-bit machines, Atari 8-bit, MSX, Tandy TRS-80, BBC Micro, ZX Spectrum, Sharp MZ, and more
• Personal computer operating systems: various DOS variants, OS/2, BeOS, Windows from 1.0 to early Longhorn betas, classic Mac OS through Mac OS X 10.5 PPC, and more
• Mobile and embedded: PalmOS, EPOC/Symbian, Windows CE, Newton OS, early Android and iOS where emulation permits, QNX, etc.
• Research and obscure systems: ZetaLisp, Smalltalk environments, Oberon, Plan 9, and many more that few people now have ever booted

If a working version of an operating system exists somewhere, the goal is to have it here, in a form anyone can run on a reasonably modern laptop/desktop.

Downloads

Both a full and a lite version are available. The full version ships with everything pre-downloaded and runs offline. The lite version downloads disk/tape/etc. images for guest VMs the first time they are run. Automatic and manual updates are supported on both editions so new installations land without re-downloading the whole VM.

Download the Virtual OS Museum

Screenshots

More screenshots

Why this exists

While the state of software preservation has improved significantly over the past two decades, many of the existing software preservation projects are still not particularly accessible.

When I started collecting emulator images (2003), there were only a few small archives of software images and the corresponding documentation, and relatively few emulators for anything other than well-known consumer-oriented platforms. Nowadays there are many large archives of historical software and documentation, and a lot of emulators for even a lot of very obscure platforms.

However, while such efforts are valuable when it comes to keeping historical software available and runnable (and without them this project would have never been possible; see the credits page for a list of emulators, pre-installed images, and media archives I have used), it often still takes time and effort to get runnable VM installations from them. OSes may have complicated install procedures. Some may depend on particular device configurations within an emulator. Some will only run in certain emulator versions, breaking in later ones due to regressions. Some emulators might have complex configuration files, or may require a specific environment on the host system.

This project is an attempt to keep reachable as much of the history that’s been preserved in various places as possible. Not theoretically reachable. Not “bootable in principle if you assemble the right toolchain on a Tuesday.” Reachable. You click an entry, it runs, and where possible it runs with software of the era already loaded the way someone might actually have used the machine at the time.

The work behind it

This is the result of over 20 years of collecting. OS installations have been sourced from various places. Some have been downloaded as pre-installed images, whereas others were installed from images of original install media. Some were installed in less than an hour, whereas others took almost a week.

A decent number only run in particular emulator versions due to regressions in later versions, and some emulators needed minor patches to run on modern Linux or to play nice with the launcher. A few emulators have been patched to run OSes that were previously broken.

Many installations also include various add-on software - applications, development tools, games, utilities, etc. - set up the way it actually might have been used.

This is still far from finished; I have many more images sitting around that I have yet to install and emulators I want to fix; check out my YouTube channel, blog, or BlueSky to see what I’m currently working on.

Support the project

This is a personal project, run and curated by one person, sustained by patience and time. If you find it interesting, the easiest ways to support it are:

• Patreon for ongoing support
• Ko-fi for one-off contributions
• Discord/Fluxer to talk about it, ask questions, or suggest new platforms/OSes to add (new entries may not be added immediately since I’ve got a lot of stuff to add)
• GitLab to submit bug reports or patches related to the launcher and scripts
• Telling someone who works on, writes about, or studies the history of computing that this exists

Adblock test (Why?)

In the early 1960s, Fred Brooks managed the development of IBM's System/360 computer systems. After it was done he penned his thoughts in the book The Mythical Man-Month which became one of the most influential books on software development after its publication in 1975. Reading it in 2026, we'll find some of it outdated, but it also retains many lessons that are still relevant today.

The book contains Brooks's law: “Adding manpower to a late software project makes it later.” The issue here is communication, as the number of people grows, the number of communication paths between those people grows exponentially. Unless these paths are skillfully designed, then work quickly falls apart.

Perhaps my most enduring lesson from this book is the importance of conceptual integrity

I will contend that conceptual integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas.

He argues that conceptual integrity comes from both simplicity and straightforwardness - the latter being how easily we can compose elements. This point of view has been a strong influence upon my career, the pursuit of conceptual integrity underpins much of my work.

The anniversary edition of this book is the one to get, because it also includes his even-more influential 1986 essay “No Silver Bullet”.

Adblock test (Why?)

My note to my kids about AI went viral with many parents. I touched on the note this week while taping an NPR segment — the topic clearly hit a nerve.

• I asked lots of people why. Put simply, parents don't know what to say — and kids don't know where else to turn — with so much changing so fast. So here's another look at AI and beyond.

Hey kid, we gotta talk.

I want to be blunt — and insanely useful — in helping you navigate the uncertainty, fast change and new opportunity of the current moment. It's bolded because it's so easy to lose hold of hope and action, a dynamic duo. Don't. Ever.

First, a gut check. It's normal to be anxious. I see what you see: AI eating up work, phones eating up attention, politics eating up hope. That's a lot. It's real.

• For better or worse, you're living through history, with once-in-a-century changes happening in technology, politics, media and how you work. I can't sugarcoat reality.

I'm not here to lecture or scold. I want to provide a different, brighter way to think about this moment — and help you navigate it.

You're not behind. You're early. Nobody knows what the hell they're doing with AI yet — not your professors, not your boss and not your friends. They simply know what you do: This is big, perhaps discovery-of-electricity big.

• The people who'll thrive in the next decade won't be the smartest or first to master it. They'll be the ones who use it smartly for their specific job. That lane is still wide open. It can still be you.
• It's fine to be skeptical or even a little scared of AI. It's not OK to ignore it. It would be like refusing to use the internet.
• Start using AI for something other than searching for an answer or rewriting a paper. Don't ask Claude or ChatGPT to do the work. Ask it to make you better at the things you don't want to do. Do that every day for 30 days. You'll be in the top 5% of your generation.

Your major isn't your destiny. Yes, this is a tougher-than-usual job market. Yes, it's likely to get tougher as AI gets better. Yes, it will get more competitive to land your dream job.

• Whining or worrying about this does only one thing: It gives someone else a leg up. Most people take crappy jobs before finding good ones.
• Out-hustle your peers. Apply to more jobs than they do. When you get one, outwork them. Beat them to the office. Use AI better. Be the most competent person in the office and the kind of coworker others admire.
• The skills that compound aren't in course catalogs. They're writing clearly, thinking clearly, selling your ideas, handling hard conversations and learning fast when the thing you just learned goes obsolete. Do all of this and there's zero chance you won't eventually succeed.

Build a bionic brain. Use your phone differently. Find smart people on social media or YouTube with smart, practical tips for doing what you want to do better. Replace your daily doomscrolling with that content.

• Things aren't remotely as gloomy as your TikTok algorithm might have you believe. This isn't a get-off-your-damn-phone rant. I want you to realize the apps you use are engineered to convince you that life is worse than it is. They keep you engaged by pointing out what's wrong or scary.
• These are the simple facts: Violent crime is down. Your peers are smoking and drinking a lot less. More Americans are literate, housed and fed than at any point in history. We're curing cancers we couldn't touch a decade ago. You're living in the safest, richest, healthiest version of America — and being told every 30 seconds it's ending.
• It's not. This is a great country.

You control you. Those are the three most important words I can give you. Say them to yourself every morning. You don't control the economy. You don't control AI. You don't control the president, the algorithms, the job market or the group chat. But you control you.

• You control when you wake up. What you eat. Whether you exercise. Whether you pray, meditate or take five minutes to think. What you read, watch and listen to. How you treat the person in front of you. Whether you send the text, make the call, apply for the thing, show up for the friend.
• Every one of those is a decision. Every one makes you a little better — or a little worse. Nobody else is making these decisions for you.
• When it gets hard, control what you can control. AI can't do that for you. I can't do that for you. You can. It's quite liberating, even empowering.

Get engaged. Nothing makes us feel better than being with others and helping others. I'm not being cheesy or preachy, so don't roll your eyes.

• Throw yourself into action — and to people.  If you're truly so worked up about politics, don't vent. Volunteer. Vote. Use social media to spread smarts and sanity. Worried about poverty? The environment? Homelessness? Go make a difference. You can, even if it's small.
• Here's the pattern I've noticed in every successful or happy person: They showed up. They volunteered. They applied even though they weren't qualified. They said yes before they were ready. They just did things, anything, to create natural momentum in their life. 
• Worst case? You're too busy to fixate on the craziness around you. Best case? You change the world. And I'm right — again.

I'm not going to pretend the world isn't changing faster than it ever has. And no, I don't have all the answers.

• I know this: You're not alone. You're not crazy. You've got this.
• I'm rooting for you. Go make it happen.

📱 Let Jim know what you think: finishline@axios.com.

📈 If you're a CEO or on a CEO's team: Ask to join Jim's new weekly Axios C-Suite newsletter.