Consensus is the part of my Distributed Systems course where students’ eyes glaze over. Not because the idea is hard — a group of processes agreeing on one thing — but because the mechanism is relentless: terms, votes, log freshness checks, quorums, commit indices. Pseudocode on a slide tells you what happens; it doesn’t let you watch it happen.

So I built something that does both at once. I recently published RaftViz, an interactive, step-by-step visualization of the Raft consensus algorithm, in which every animated event is wired to the exact line of lecture-notes pseudocode that produced it. Students can step through a leader election one line at a time, then crash the leader themselves and watch the cluster heal.

The twist: I wrote none of the code. Roughly 6,000 lines of JavaScript, all of it produced by AI coding agents under fairly tight direction. Read on for the pedagogical idea, a tour of what it does, an unexpected bug it found in the lecture notes it was built from — and what I learned about steering coding agents on a project where correctness actually matters.

AI was built in Python. But the code AI agents write will increasingly be TypeScript.

This post is about a pattern that I believe will define how AI agents interact with the world — and why JavaScript’s unusual history makes it uniquely suited for it.

I recently attended a “vibe coding” workshop as part of our lab retreat. The premise was simple: pick a small project, fire up an AI coding agent, and see what you can build in about 30 minutes. No careful planning, no spec — just vibes.

What I ended up with surprised me. Not because the result is groundbreaking software, but because of what the process revealed about the relationship between domain knowledge, AI tools, and the value of a CS education.

Here’s the demo, the full story, and the takeaways.

Over the last few months my PhD student Weihong Wang and me have been studying issues with Web3’s “serving layer” – the infrastructure that makes data stored on a blockchain accessible to the application layer (aka decentralized apps or “dapps”). One of our key findings is that access to major “permissionless” blockchain networks today is, counter-intuitively, quite “permissioned”: because of both technical and economical factors, access is mediated by centralized gatekeepers. In response, we have designed a new RPC (Remote Procedure Call) protocol to interact with permissionless blockchains that attempts to keep the access “depermissioned”, yet without compromising on data integrity or accountability issues that plague the naive use of anonymous public RPC endpoints.

Our paper on this new RPC protocol recently got accepted at the IEEE International Conference on Distributed Computing Systems (ICDCS 2025). Weihong will present the work in Glasgow next week. Here’s a link to the preprint copy of the paper. Read on below for a high-level introduction to the work.

It is no secret that participating as a validator node (aka “full node”) in the Ethereum blockchain requires non-trivial hardware and storage resources. The hardware requirements to run a Geth full node (one of the more popular Ethereum full node implementations) state that the recommended minimum storage is a 2TB SSD drive - and with a default cache size, operators should expect storage to grow at a rate of about 14GB/week.

These storage requirements apply to anyone who wants to help validate transactions on the mainnet, not just to “staking” validators who want to earn Proof-of-stake rewards for validating transactions (who have additional requirements, such as ensuring high node uptime).

The more costly the hardware requirements, the fewer the number of parties capable of running a full node. Less full nodes leads to increased load on fewer servers, or to more parties relying on intermediaries (such as “node providers”) to operate the hardware for them.

This got us thinking: can we modify the block validation protocol used in networks like Ethereum so that storing the full blockchain state is no longer a prerequisite for participating as a block validator? In other words, can we let a node with “small” storage capacity (say, 5-10GB) meaningfully contribute to transaction validation without requiring it to store a full copy of the chain, and without compromising blockchain data integrity?

Today at the BRAINS 2024 conference in Berlin my PhD student Weihong Wang presented our work on “A Scalable State Sharing Protocol for Low-Resource Validator Nodes in Blockchain Networks” which addresses this question.