LLMs have revolutionized coding. I build systems for a living; in the last year I have built a substantial system without opening an IDE or hand-writing a line of code, which I think is not an unusual experience for software developers in this annus mirabilis for coding agents. However, automating system design still seems just out of reach. This led me to think: is there a way to gauge how good agents are at designing systems?

I don’t have a quantitative benchmark for system design; but I do have three qualitative tasks that would convince me that agents can design systems.

[1] Can it evolve / migrate a system? It’s 2006. You give an agent (trained only on information available until 2006) the API of S3, a specification (e.g., an in-memory single-node implementation), unit tests, a simulator, and access to a scheduler on a large cluster. You set up a load generator to gradually increase / change load, and walk away for a month. Do you come back to a sharded, replicated S3 that has gracefully (and correctly) scaled with increased load?

[2] Can it invent new abstractions? It’s 1970. You ask the agent to build a filesystem. You come back to find a working filesystem. Now you magically invent the SSD and give it to the agent. Did the agent plan for this by introducing a block device abstraction that lets you swap out the hard disk for the SSD?

[3] Can it efficiently verify safety under concurrency and failures? Ensuring safety under concurrency for an arbitrary distributed system often requires the agent to reason about all possible orderings or interleavings of actions in a distributed system. Can the agent use a combination of type systems (e.g., for local thread safety or memory safety), design constraints (e.g., a shared log design that inherently supplies a total ordering candidate to check for linearizability), layered abstractions (e.g., verifying a filesystem assuming the block device is correct; verifying the block device separately) to efficiently provide strong guarantees?

A counterpoint: Is abstraction fundamental to system design; or only applicable to human-driven system design? It is possible that agent-built systems will not look anything like their human-built counterparts. Maybe abstraction is no longer required for hiding hardware complexity, for example, because LLMs with massive context windows can deal with vastly more complexity. As a result, maybe #2 is testing abstraction purely for the sake of abstraction.

But #1 requires an agent to reason about potential futures (which are inherently unbounded); and #3 requires it to reason about potential interleavings (not unbounded, but very large). Brute force does not work. In this case, abstractions are one way to hide exponential blow-up. If I hide the storage layer behind an API, I no longer need to reason about all possible future implementations of that API (#1) or all possible ways in which actions can be interleaved (#3).

And an open research question: how do we construct quantitative, easy-to-run benchmarks around these ideas?