The Programming Language That Went Unfinished for 20 Years Is Now Split Into a Task Graph

Luke Hutchison posted an update on Zed's progress on X. He has worked on this language for more than 20 years, but had never really finished it before. Original post

Zed's design goals are demanding. It is based on category theory, and its core goals include: automatic parallelization up to the Amdahl limit, i.e. the theoretical upper bound constrained by the serial portion; automatic memory management without GC or manual malloc/free; extensive use of partial evaluation to strengthen the language's capabilities; units integrated into the type system, e.g. accel = 5 with units("m s^-2").

Luke gave the 200-page design notes and the code already written to Opus, and had Opus organize them into a coherent, detailed plan. He then had Claude, ChatGPT, and Gemini conduct multiple rounds of cross-review, meta-criticizing one another, and merged the critiques into an improvement plan until convergence. Next, he had agents perform all-pairs comparisons on the specification to check for inconsistencies and gaps, then split the spec into a long list of tiny incremental steps, topologically sort them, and obtain a DAG of underlying dependencies.

He also had Opus build a visualizer that shows the status of each task in the DAG in real time. In progress and completed are both visible. Luke recommends that others use this approach when having Opus tackle large, complex tasks, because it makes it clear what it is actually doing.

Someone asked how agents coordinate and avoid conflicts with such a long DAG. Luke said the orchestrator launches agents in the work tree, and when an agent needs to merge back into main, it creates a lock file and acquires the lock. When necessary, the orchestrator has the agent rebase. He only allows one layer of the DAG to be processed at a time, so agents running at the same time should theoretically not conflict. This DAG structure comes from an in-depth all-pairs analysis of all nodes. Theoretically, if there is no explicit directed path between two tasks, they can run in parallel. But Luke's orchestrator is stricter and only allows a single fan-out and fan-in to run at the same time. Luke said this is not perfect yet; sometimes the orchestrator has to rebase code, but the effect is “shockingly well.”

One detail in community feedback is interesting. A user named Flower built zed-testgen based on code already in the Zed repository. It calls the backward solver built into the Zed compiler and asks, for each if branch: is there an integer input that can reach this branch? If yes, it generates one line of test; if no, it tries to prove that the branch is dead. The tool independently confirms each witness and then cross-checks dead-branch claims with small-scale brute-force search. In the example, the branch in classify where x > 5 and x < 3 hold at the same time is proven dead. The limitations are also clear: it only handles functions whose parameters are all int, only handles if branches, calls an internal solver module in Zed rather than a stable public API, and the commit is pinned at a3c52bf. Luke replied that he would have agents take a look at the tool.

In another reply, Christian Findlay said he wanted to wrap the Zed plugin on top of Osprey's LSP. Osprey is a functional language emphasizing algebraic effects, Result, and native compilation via LLVM. Luke replied, “nice work.”

Someone else asked how Zed would close the training gap. Dart-like syntax helps, but the semantics are new. Would it teach agents through compiler errors, or generate a corpus? Luke did not elaborate in this thread. Breck Yunits of PLDB invited Luke for an interview; Luke said to let him first finish and release the language, and that the first real release is probably still a month or two away.

Luke also mentioned that during the documentation phase, he wants the documentation site to embed the compiler so that every code example can be edited and run directly in the browser. This goal is much more concrete than “writing documentation.”

Looking at this workflow, LLMs here handle review, decomposition, and scheduling, while agents do the construction according to the DAG. What was missing after 20 years of not finishing may not just be ideas, but also the bandwidth of one brain working 24 hours a day. But parallelism has costs: locks, rebases, and the single-layer DAG are all costs. Zed has not been released yet; once the first version comes out, we can see whether this task graph can support the complexity as the language grows.