Whether it is music, research, courses, or books, I use the following maxim as a guide:

Make the things you want to exist in the world.

The courses I teach, for example, I have created from scratch. They are the courses I wished I had as a student. One of those courses is “Internet Censorship and Online Speech”.

When one teaches a course, it is helpful to have accompanying reading material, but material that you didn’t create yourself is always a bit of a shoehorn. One of the most valuable things we can do as instructors, especially in the age of AI, is synthesis.

For that reason, I’ve created textbooks and online courses from scratch in an attempt to synthesize everything I learn as I continue to teach the material.

As one such effort, I’ve been writing a textbook on Internet censorship and information control for the past five years. What started as a way to capture my lectures has evolved into a fascinating journey in human-AI collaboration. Here’s how I used AI tools—culminating in Claude’s new “agent teams” feature—to transform raw lecture transcripts into a polished manuscript.

The Starting Point: A Course Without a Textbook

When I began teaching my course on Internet Censorship at the University of Chicago, I faced a common problem: there was no textbook that covered the breadth of topics I wanted to address. The field spans technical mechanisms (DNS manipulation, BGP hijacking, deep packet inspection), platform dynamics (content moderation, algorithmic curation, disinformation), legal frameworks (Section 230, copyright, net neutrality), measurement techniques, and circumvention technologies.

So, I decided to write one.

Phase 1: Capturing Lectures (2021)

The first step in drafting the book was getting some initial thoughts down. During the Covid lockdown, we were all teaching online, and so I had a significant cache of online videos (now on YouTube!) comprising the course lectures. Arvind Narayanan once told me that he started some of his books from video lecture transcripts. So, rather than staring at a blank page, I recorded my lectures and extracted transcripts from YouTube.

My earliest commits tell the story:

Feb 2021: first draft of Chapter 2 material from YouTube transcripts
Feb 2021: BGP draft text from transcript
Mar 2021: transcripts through first seven chapters/weeks
Mar 2021: transcripts for legal aspects

The raw transcripts were messy—full of verbal tics, digressions, and the natural meandering of spoken explanation. But they contained the core ideas, organized roughly the way I wanted the book structured. Back in 2021, there were no LLMs, and so I spent a fair amount of time manually editing the spoken prose. This, frankly, was a painstaking process, and not particularly creative—it mainly involved changing my spoken “lecture voice” into something more appropriate for a book, while preserving the content.

Phase 2: Transcript to Prose (2021–2025)

Prior to AI, transforming spoken lectures into readable prose was tedious work. This past fall, I began to use Claude to help me. I would record all of my lectures and get transcripts which now included not only my lecture but also student questions.

Again, this step was painstakingly manual at first, but as AI models and agents have improved over the past several years, I’ve been able to leverage these tools to really speed up this part of the process.

• Clean up the language: Removing filler words, fixing grammar, smoothing transitions

• Restructure for reading: What works in a 75-minute lecture doesn’t always work on the page

• Add pedagogical scaffolding: Signposting, summaries, clearer section breaks

Sample commits from this period:

Edit DNS and TCP sections into polished book prose
Enhance BGP section with class discussion insights
Enhance traffic shaper explanations with clearer pedagogical flow

I kept teaching the course while continuing to write, saving notes, questions, and presentations from students. Each semester gave me new material:

• Student questions revealed where explanations were unclear

• Class discussions surfaced interesting angles I hadn’t considered

• Student presentations brought in current case studies and examples

I fed these back into the manuscript:

Add points and case studies raised in Fall 2025 class presentations
Add citations and content from student project references (782 words)
Enhance BGP section with class discussion insights

Phase 3: Case Studies, Examples, and Sources

Writing of this nature requires up-to-date examples and case studies, with citations—lots of them. Of course, left to their own devices, AI models have a well-known tendency to hallucinate citations, inventing plausible-sounding papers that don’t exist.

I developed a rigorous citation workflow, codified in a custom /add-citations command for Claude Code. The core principle being that every single citation needs to be verified by an agent through: (1) download; (2) analysis of the abstract; (3) inclusion of a URL that I can subsequently go manually read myself.)

The workflow uses a hierarchy of academic APIs:

1. DBLP API for computer science papers (returns clean BibTeX directly)

2. CrossRef API when you have a DOI

3. arXiv API for preprints

4. Semantic Scholar API for discovery

Every citation must be verified with WebFetch on the actual publisher page before being added. If the title doesn’t match, it doesn’t get added. Period.

# Example: Search DBLP and get BibTeX directly
curl "https://dblp.org/search/publ/api?q=censorship+measurement&format=bib&h=5"

# Verify with CrossRef
curl -LH "Accept: application/x-bibtex" https://doi.org/10.1145/...

This approach takes longer than just asking an AI to “add some citations,” but it produces a bibliography you can actually trust.

Phase 4: Agent Teams for Deep Editing (February 2026)

Recently, Claude Code introduced an “agent teams” feature that lets you spawn multiple AI agents to work on a task in parallel. I decided to use this for a comprehensive editing pass.

The Workflow

Step 1: Launch Six Parallel Editors

I spawned six agents simultaneously, one for each chapter:

Each agent received detailed instructions:
- Read all chapter files thoroughly
- Add verified citations (using the citation workflow)
- Edit for clarity without changing structure (it matches my course syllabus)
- Report back on edits made, citations added, and cross-chapter issues

Step 2: Cross-Chapter Consistency Review

After the initial edit, I had the agents swap chapters. Each agent reviewed a chapter they hadn’t edited, specifically looking for:
- Voice consistency across the book
- Working cross-references between chapters
- Consistent terminology
- Flow and length balance

Step 3: Image Pipeline

I also used a specialized four-agent pipeline for figures:

1. Image Sourcing Agent: Reviewed ~400 images from my own lecture slides, identifying useful diagrams, charts, and maps

2. Image Quality Reviewer: Checked each candidate for accuracy, currency, copyright permissions, and resolution

3. Placement Finder Agent: Located exact insertion points in the LaTeX source

4. Insertion Agent: Actually added the figure code to the manuscript

The agent teams processed six chapters in parallel, adding dozens of verified citations, improving clarity throughout, and ensuring consistency across the book. Work that would have taken me weeks of tedious editing happened in under an hour.

Lessons Learned

1. Start with your own voice. The transcripts captured how I actually explain these concepts to students. AI helped refine the prose, but the pedagogical approach and examples are mine.

2. Iterate with students. Teaching the course while writing the book created a feedback loop. Student confusion pointed to unclear explanations. Their presentations brought in fresh case studies.

3. Build guardrails for citations. AI-generated citations are a minefield. Building a verified citation workflow was essential for producing something I could stand behind academically.

4. Parallel agents are powerful for editing. Having multiple agents work simultaneously—then swap and review each other’s work—catches issues that a single pass would miss.

5. AI is useful, but the author must be in the loop at every stage. At every stage, I reviewed what the agents produced. Ultimately, the book reflects my voice, expertise, and judgment; AI was a tool that accelerated the work.

6. Work with AI agents like you might a collaborative human editor. The agents did not “write the book” per se; rather, they incorporated all of my inputs, including full chapter drafts that came from my own words (either through transcripts or my own typing). They helped me take care of annoying formatting things, identified thematic gaps, helped me find places to integrate content and examples that I devised (often “on the fly” in lecture), and served to provide me with important editorial feedback along the way.

What’s Next

The manuscript is nearing completion. It’s been a five-year journey from “I need a textbook for this course” to a full manuscript with six chapters, hundreds of citations, and dozens of figures.

The tooling has evolved dramatically over that time. What started with simple transcript cleanup has progressed to sophisticated multi-agent workflows. I’m excited to see where these tools go next—and what other professors might be able to accomplish with them.

The book, tentatively titled “Filtered,” covers Internet censorship and information control, based on my course at the University of Chicago (course website). The techniques described here could apply to any textbook project built from lecture materials.

I’ve found that agents work best under three conditions:

1. Limited Context

LLMs have finite context windows, and even within those windows, attention degrades over distance. When you ask an agent to work on a 50-line function with a clear input/output contract, it can hold the entire problem in focus. When you ask it to “refactor the whole application,” it starts losing track of things—dependencies, side effects, earlier decisions.

The practical implication: decompose your tasks aggressively. Break big tasks into small ones.

Give the agent a piece it can fully comprehend. This isn’t just good practice for AI; it’s good software engineering. But with agents, it’s mandatory.

I’ve found that when Claude Code starts making inconsistent changes or forgetting earlier context, the problem is almost always that I’ve let the scope creep too wide. The fix is to step back, carve off a smaller piece, and let it finish that completely before moving on. Carve a task up into sub-agents, if necessary (something I myself am still learning how to do).

2. Tight Constraints

The problem space is bounded. You’re not wandering through infinite possibilities—you’re meeting a spec, passing tests, satisfying types.

Constraints are liberating. When you tell an agent “write a function that takes a list of integers and returns the sum,” there’s not much room for hallucination. When you tell it “build something useful,” you get chaos.

This is where the spec becomes critical. A good spec is a set of constraints that bounds the solution space. Types are constraints. Tests are constraints. “Use this library, not that one” is a constraint. “Follow the existing code style” is a constraint.

The more constraints you provide, the less the agent has to guess—and guessing is where things go wrong.

I’ve started thinking of spec-writing as constraint-specification: what are all the ways this could go wrong, and how do I rule them out in advance? Inevitably, you will miss some constraints. This is where the third factor comes into play

3. Verifiable Outputs

First of all, tests pass or fail; code compiles or doesn’t. This simple fact actually makes coding very suitable for agentic tasks, because the models can do some amount of verification simply based on whether the code runs.

But, just because code runs doesn’t mean it is correct. I started writing MCP servers in Claude in the domain of music; it became painfully clear when something wasn’t working because I could hear it (four measures played instead of eight, dissonant sounds wildly out of the diatonic, etc.)

The verifiability of coding and its outputs make it particularly amenable to agentic coding. Verification creates a feedback loop. The agent can try something, check if it worked, and iterate. This is why agentic coding tools run the code they generate, execute the tests, read the error messages. They’re not just generating—they’re generating, checking, and refining.

Verification can be automated, but it doesn’t have to be. Human review is verification too. The key is that verification is possible and cheap enough to actually do. In coding, you get both automated checks (tests, types, linters) and human review of outputs.

There is an important lesson here, too: You want to make sure that what is generated is actually verifiable.

I work in Internet measurement and so the code I generate often involves data analysis; there are easy ways to check the output of analysis. One way is simple sanity checks and knowing “the back of the envelope” (e.g., how many seconds in a day, what’s the round-trip latency across the United States, etc.).

Having both specific and general domain knowledge internalized allows one to quickly spot non-sensical or incorrect output. But, regardless of the domain, the output must be checked—these days, still by a human—and thus it is imperative that whatever the model generates is easy to check. You can instruct the model to do this! I tend to provide instructions that include both automated checks and instructions that make it easy for me to verify outputs (think “clicking and reading” to verify).

Takeaway: Specify Constraints, Limit Context

Rich tooling and clear feedback are immensely helpful in this context. But the tooling isn’t what makes this work—it’s how the domain lets you structure the problem. The magic isn’t in the compiler or the shell. It’s in the fact that coding naturally decomposes into small, constrained, verifiable pieces.

This matters because the better you specify constraints and limit context, the better the agents do.

This insight forms the foundation of the workflow I describe below.

My Development Cycle

Here’s the short version:

1. Specify and document. Specify requirements, tools, structure, language, basic test cases and expectations. Importantly, specify constraints (what the agents should not do!). The spec is often incomplete at first because step 1 is hard. Humans are bad at specs. Fortunately, the model is probably better at writing a good spec than you are.

   I often start by telling Claude Desktop what I want to build, and asking it to help me write the spec. We iterate. I refine. Then, when I’m happy with it, I take that spec to Claude Code. I’ve found that this can be an iterative process. Part of why I hadn’t written this up earlier is that I haven’t fully wrapped my head around what really works well versus what doesn’t. But a little supervision and independent thinking goes a long way.

   This is the question I ask myself when creating a spec and documentation on which to build a piece of software: Imagine that you are starting up Claude Code for the very first time and want it to read the docs and run the code. What would it need to know?

2. Feed the specification into Claude Code to get a first pass. This is the part that feels like magic. You hand it a spec, and code appears. But don’t get drunk on the magic. The output needs to be checked. This isn’t “fire and forget.”

3. Iterate. Try using the code, check all outputs, supervise, take notes of errors and missing features. Use Claude itself to note things like missing features, things that are not working correctly, etc. Use the tool for a while. Check the outputs. Does it actually do what you wanted? Does it handle edge cases? Does it fail gracefully? This is where you catch the hallucinations, the subtle bugs, the things that “work” but don’t work correctly. Or, you notice that something you wanted the code to do, it simply …can’t, because you forgot something in your spec.

4. Push documentation to “memorialize”. Take note of (a) what went wrong and how you ended up fixing the issue; (b) make sure that updates and fixes to the code are also memorialized in the updated specification and documentation. Before I close a Claude Code project, I always take time to work on the documentation. Think of it like this: If I were to come back to this later, what would I want Claude to immediately pull into context and not have to type again? That should all be in the updated docs.

5. Use Git for everything. Commit early, commit often, push often. Agents make mistakes. You will make mistakes supervising them. You need to be able to roll back, and you will. Treat every commit as a potential restore point. Be very careful with rebasing; consider disallowing it unless you explicitly ask for it—I've lost work by letting Claude Code "clean up" commit history or resolve a merge conflict when I actually needed that history preserved. As with other parts of your project, if you are not explicit about constraints, the agents will fill in the gaps and you may not like the results.

Why Things Break, When They Break

Here’s what I’ve learned:

• Poor specification or constraints → limited (or unwanted!) functionality. The specification is king. If the spec doesn’t capture what you actually want, you’ll get something that technically meets the spec but doesn’t solve your problem and may also do things you never asked for. It is thus critically important to specify constraints.

• Context window exceeded → weird failures. The model starts losing track of things. You get inconsistencies, repeated mistakes, or outputs that ignore earlier instructions. The trick here is to limit the context window. I am still working on ways to do this; for example, I am learning a bit more about sub-agents. I am interested to hear how others deal with this.

• Missing implementation → need to update the server. Sometimes the model assumes a feature exists that doesn’t. This is a signal that your spec or your tooling has a gap. The model won’t often tell you that it’s missing a feature; you have to intuit from the output that you’re asking it to do something that it doesn’t know how to do. From there, you can go back to iterating on a spec.

• Config sprawl → When you’re building tools, configurations multiply, and agents are not particularly good at keeping configuration organized and tidy. Periodically step back and ask: “If I had to set this up on a new machine, how painful would it be?” If you couldn’t migrate in under a minute, or you have to think about where every part of your project configuration is living (auth, environment settings, etc.), this your signal to consolidate. I periodically blow all of my software away and re-install just to make sure my processes are streamlined.

Example Workflow: Desktop MCP ↔ Code Iteration

Claude Desktop and Claude Code don’t know about each other. They’re separate tools with separate contexts. But with good specs and MCP connections, I’ve found that you can stitch them together to really enhance productivity. I now have MCPs for calendaring, briefing, email triage, invoicing, … not to mention countless creative projects, as well.

My typical pattern is as follows:

• Desktop for ideation and spec writing. I think out loud with Claude, brainstorm approaches, write the spec collaboratively.

• Code for execution. I copy the spec over and let Claude Code generate.

• In the case of MCP, back to the Desktop. I try to use my MCP servers. At the outset, I trust nothing. I verify what the agents are doing manually, because often they will make mistakes—and typically the source of the mistake was a failure in my specification. When something breaks or does not work as planned, I often talk through it with Desktop first, figure out exactly what the MCP is not seeing, then work on an updated specification, and bring the fix back to Code.

I use the spec, not the conversation, as the conduit. The conversation is ephemeral. The spec persists and is continually being updated.

Note: “AI Failures” are Often User Failures

We’ve all seen the headlines: AI loses money, AI gets tricked, AI does something absurd. For example, recently the Wall Street Journal ran an experiment where they let an AI agent run a vending machine. It gave away inventory for free, bought a PlayStation 5, ordered a live fish. Chaos, laughs, great clickbait.

A closer read reveals what actually happened, though: the user gave an agent vague instructions (”generate profits”), no guardrails, no supervision, and let 70 journalists red-team it unsupervised. When it predictably fell apart, the diagnosis was “the context window filled up”—which they present as an inevitable AI limitation rather than a design failure.

While this might be an entertaining cautionary tale, that’s not AI “failing”, but simply a user failing to understand how the tools work. A clear spec, incremental testing, active supervision, and documented fixes would have caught every one of those problems. The vending machine wasn’t a case study in AI limitations. It was a case study in not having a workflow.

Bottom Line: Understand How Your Tools Work

If you think you know how these systems work (and how they fail), you can understand what is likely to work for input and how to check the output.

There is a lot of benefit to structured thinking and clear spec. The limited context window is something to be aware of—so I’m continually refining the docs and code as I go, almost like a “compressed” version of what I want the model to be remembering. Truly thinking about it as a collaborator or “coding engineer who can meet a spec”... but a little supervision and independent thinking goes a long way. None of this is by any means a substitute for thinking. If anything, it pushes us to think more clearly than ever, because errors in specification end up even more amplified.

Agents work best when you give them limited context, tight constraints, and clear ways to verify their outputs. Coding happens to be a domain where all three are natural. But the lesson generalizes: if you can structure any problem that way, you can make these tools work.

I must admit that I still don’t really know “how to write a good spec” for these systems. But that can be a bit of an iterative process too, and one that the models are pretty good at, themselves.

I was finishing up an NSF grant proposal with Claude Code when my collaborator flagged something odd.

She’d been reviewing the bibliography and couldn’t find some of the papers I’d cited. First of all, here’s one of the fabricated entries Claude created:

@inproceedings{chanenson2023,
    title={Privacy in K-12 Schools},
    author={Chanenson, Emily},
    booktitle={Proceedings of CHI},
    year={2023}
}

The real paper, which my collaborator is a co-author on, was this:

@inproceedings{chanenson2023K12PrivacySecurity,
    title={Uncovering Privacy and Security Challenges In K-12 Schools},
    author={Chanenson, Jake and Sloane, Brandon and Rajan, Navaneeth 
            and Morril, Amy and Chee, Jason and Huang, Danny Yuxing 
            and Chetty, Marshini},
    booktitle={Proceedings of the 2023 CHI Conference on Human Factors 
                in Computing Systems},
    year={2023},
    pages={1--28},
    doi={10.1145/3544548.3580777}
}

Wrong first name. Simplified title. Missing six co-authors. No DOI.

Safeguards aren’t enough if you don’t define the workflow

I traced the problem back through git history to understand how this happened. I’d been using Claude to adapt a “PI Qualifications” paragraph describing my co-PI’s prior work that I had from a previous proposal, a simple request that should have been a small text edit based on text that was already in the proposal elsewhere.

I never asked Claude to find or create citations. My workflow was designed to be safe—Claude was supposed to reference only my existing .bib file. I thought that was sufficient.

But Claude knew my co-PI had expertise in educational technology privacy, VPN user studies, and privacy mental models. So when it wrote the qualifications paragraph, it included citations:

Chetty brings expertise in empirical studies of privacy attitudes 
and technology adoption, including NSF CAREER-funded research on 
educational technology privacy~\cite{chanenson2023}, prior work on 
VPN mental models~\cite{kumar2023understanding} and privacy 
adoption~\cite{wagman2023}.

Then—without being asked—Claude created bibliography entries to match. It didn’t have the actual papers. It didn’t verify they existed. It didn’t check my existing .bib file. It invented plausible-sounding entries based on what it thought the papers should be about. I didn’t immediately catch it either, because the text itself read well-enough; the error was in a citation that was added that I didn’t ask for.

This is more subtle than the typical “AI hallucinated a citation” story you hear about. I wasn’t asking Claude to find papers. I had safeguards in place. But because I didn’t explicitly bound the capabilities of the agents, they went off-script anyway, proactively (“helpfully”) fabricating entries that looked like they belonged.

Plausible-looking output is the danger zone

The fabricated entries had proper BibTeX formatting, reasonable titles, plausible author names. If my collaborator hadn’t caught them during review, they might have made it into the final submission. And once fake citations enter a bibliography file, they propagate—other researchers copy them, students cite them, the misinformation spreads.

This is a known problem with large language models. The technical term is “confabulation”—filling gaps with plausible-sounding but false information. LLMs can generate text that looks right but can’t reliably distinguish between “plausible” and “true.” That’s not something that gets fixed by trying harder or being more careful. It’s a fundamental limitation that requires external verification.

If you don’t define the workflow, the AI will

The incident revealed something important: I didn’t have a citation workflow. So Claude invented one. And the workflow it invented was wrong—create content with citations first, create bibliography entries to match, never verify they’re real.

That’s the core lesson here. If you don’t explicitly define how citations should be handled, the AI will fill the gap with its own approach. And its approach prioritizes plausibility over truth.

So I built an actual workflow around a simple principle: verify first, not after. Search for and verify papers exist first, add verified entries to bibliography, then write content citing them. No exceptions, no “I’m pretty sure this exists.”

I also added explicit rules for Claude. If it’s creating BibTeX entries for papers it hasn’t verified via web search, or guessing at author names or titles, or writing about someone’s prior work without their actual paper list—stop. For co-PI qualification sections specifically, it’s faster and more accurate for Claude to just ask me “What are the key papers on educational privacy?” I have her CV. I know her work. I can point to citation keys already in my .bib file.

I documented all of this in an check-citations.md command file (included below) that includes the exact failure mode, step-by-step verification procedures, and mandatory checklists. The goal is to make it impossible to repeat this mistake through inattention. I also added a step to add DOI and URL to every single citation so that human verification becomes easy—all one has to do is go through the citations and click the links to perform manual verification on each.

This isn’t just about citations

This incident captures a fundamental tension in AI-assisted work. These tools can genuinely increase productivity—Claude can help one become significantly more efficient at formatting, restructuring, finding inconsistencies, even drafting prose. But agents require explicit workflows with constraints because they will, inevitably, fill gaps with plausible-sounding fabrications. Citations are just one example. The same problem applies to any task where the AI needs to reference external facts: legal documents, financial data, technical specifications, historical records.

For anyone using AI assistants: trust but verify. Every factual claim needs human verification. Design your workflows assuming AI will occasionally fabricate things. Make verification cheap and easy so you’ll actually do it. And when AI makes a mistake, analyze it, update your workflows, share what you learned.

For AI developers: confabulation is the hard problem. Don’t just generate content—build in verification steps. Flag unverified claims. When uncertain, say “I need to verify this” instead of generating something plausible-looking. It’s better to be slow and right than fast and wrong.

It would be great if citation verification APIs integrated directly into tools like Claude—automatic checks against CrossRef, Semantic Scholar, DBLP before any citation gets added. Confidence scoring that distinguishes “verified from publisher” from “generated from context (UNVERIFIED).” Audit trails tracking where each citation came from.

In the meantime, I’ve built my own workaround: a Claude Code command that enforces verification before any citation gets added, requires WebFetch to confirm titles match actual webpages, and checks for broken references in the bibliography. It’s not foolproof, and I’ll continue verifying manually. But it makes the workflow explicit instead of leaving gaps for Claude to fill with fabrications. In some ways, it is actually better than what I had before and better than humans—the process ended up finding several other erroneous citations that humans had entered.

My collaborator caught these errors. Otherwise, fake citations would have landed in an NSF proposal. AI assistance is valuable, but human verification remains essential.

AI will improve, but we need critical self-examination and post-mortems like this.

Finally, I will note that git revision history was extremely valuable in helping diagnose the root cause of how this error occurred. AI will make mistakes. The answer is not to avoid it, but rather to firmly understand why and how it makes mistakes, and improving our systems and workflows so that the tools can work better for us. A careful, critical, honest eye towards mistakes is how we make progress, which is why I thought it was important to share this cautionary tale.

Update: A friend tells me that even this approach below may not be good enough. Relying on WebSearch is not constrained enough, and that all information that comes in should be brought in via an API, not via the web. Additionally, dividing up tasks with subagents helps preserve the context window, so this approach I have laid out above may ultimately require a bit of re-design.

## Citation Verification Workflow

1. **Never create citations without verification**
   - Search for the actual paper using WebSearch
   - Use WebFetch to verify the title on the publisher's page
   - Cross-check authors, year, venue against official sources
   - Test that DOIs/URLs actually work

2. **Verify before you write, not after**
   - Search for and verify papers exist first
   - Add verified entries to bibliography
   - THEN write content citing them

3. **When citing someone's prior work**
   - Ask the user: "Which papers should I cite for [topic]?"
   - Search their Google Scholar or DBLP page
   - DO NOT fabricate entries based on what you think should exist

4. **Red flags that require stopping**
   - Creating BibTeX entries for papers not verified via web search
   - Guessing at author names or titles
   - Writing about someone's prior work without their actual paper list
   - Adding incomplete metadata

I spent a couple of days in the studio this week, working on my first professionally produced track. Here’s what I learned.

1. Get a chord chart on a grid.

I did this with MIDI over my demo track before going in, and it ended up saving hours. There will be many opportunities to re-track things with different arrangements - bass, synths, guitars - and this goes much faster if your producer knows the chords you’re using rather than figuring them out on the fly.

2. Know how to play your songs in different ways.

If you’re layering tracks, there will be countless opportunities to “paint” in the mix. A part that sat one way in your bedroom demo might need to breathe differently when there’s a live drummer pushing the energy.

3. Be flexible.

Some things will change. Having a complete song is critical - not because it’s necessarily “done,” but because it gives you a foundation to make small adjustments from. Sometimes we’d spend an hour or two on eight bars of just one track. (”How is this going to sound? Only one way to find out!”) This isn’t writing the song in studio. It’s being willing to experiment with what best brings out the emotion of what’s already written.

4. Basic music theory is critical.

Theory can be limiting if the rules pen you in, but in the studio, it’s essential because it gives you a common language. It lets you communicate efficiently with session musicians and your producer, and helps you understand why different layers work together.

5. Practice the new parts.

In pre-production, your producer may send back additional ideas - new riffs, alternate bass lines, different voicings. Practice playing anything you like, because you’ll likely be playing it yourself. In hindsight, I would have saved time if I’d practiced some of those parts on bass guitar before showing up.

6. Learn about production.

The goal isn’t necessarily to become a professional producer yourself. It’s to know what’s possible and speak the language. You don’t have to be an expert in compression, reverb, or EQ, but knowing what they do helps you communicate the sound you want.

7. More survives than you’d think.

Much more of the original composition survives the demo process than I expected, even though almost everything gets re-tracked.

8. There is no substitute for a human drummer.

Enough said. It’s good to go in with programmed tracks to give a feel for groove. We definitely also layered drum machine tracks over the human drummer, because that’s the sound I’m going for. But, nothing quite captures the energy like a live human drumming to a track you wrote.

I’ve always wanted to make music, and do it at a high level. Two years ago, I had not written a single song. How did I get here?

The same way I end up doing anything. Little by little. With consistency and focus, and a healthy dose of fearlessness. Approaching the practice with humility and curiosity. Not being afraid to be bad at first. Asking countless stupid questions. Surrounding myself with good, kind, generous people who are better than me at the craft and trying to learn from them as much as possible.

It’s all worth it. Because what a beautiful thing, to make something where there was once nothing.

I was fortunate to be able to present this morning at the Understanding Latency 4.0 Conference on our new technology, SwiftQueue.

SwiftQueue uses a compact transformer model to perform sub-millisecond prediction of traffic latency, allowing per-packet queue assignment and reduction of tail latency by as much as 45%.

But there’s a problem with how L4S works today. It treats every packet in a flow the same way. All your video call packets get the same queue assignment, even though congestion is bursty. Some packets sail through; others hit a traffic jam and spike your tail latency. It’s that variance that kills real-time apps—not the average, the outliers.

We asked a simple question: what if we could predict which packets are about to get hammered, and route them differently?

The Approach

SwiftQueue uses a Transformer—the same architecture behind large language models like ChatGPT—to predict per-packet latency based on the timing of recent ACKs. The insight is that packet-level latency variations aren’t random. They follow patterns from complex interactions at shared router queues: video apps have periodic bursts, TCP congestion control creates predictable queue buildups and back-offs. Traditional time-series models can’t capture these patterns efficiently. Transformers can.

Armed with that prediction, the sender dynamically marks each packet’s header to route it to whichever queue has lower predicted latency—even if that means packets within the same flow end up in different queues.

Why Transformers?

The core innovation in Transformers is self-attention: the model learns to weigh which elements in a sequence matter for predicting what comes next. In language, “bank” means different things depending on whether “river” or “financial” appeared earlier. The same logic applies to packet latencies—a spike three packets ago might be highly predictive, or irrelevant, depending on context.

RNNs and LSTMs can learn sequences, but they suffer from vanishing gradients and memory limitations. Transformers parallelize attention across the whole context window, making them faster to train and better at long-range dependencies.

SwiftQueue’s Transformer is deliberately small—about 100K parameters, nothing like the billions in language models. Two encoder attention blocks, two linear layers. Input features include latency, timestamp, packet size, flow ID, and receiver ID. The history window is sized to the bandwidth-delay product of the link.

One nice result from the paper: even when two packets have nearly identical recent latency histories, the Transformer maps them to completely different positions in its internal feature space if one is about to experience a spike. The model learned to detect signals that aren’t obvious to human inspection.

Key Design Choices

Custom loss function. Standard MSE tries to minimize error everywhere. We don’t care about predicting smooth periods—we care about catching spikes. SwiftQueue uses a 10× penalty when true latency change exceeds 20ms and 20% relative difference. Trades slightly higher average error for dramatically better spike detection.

Fast online fine-tuning. Network conditions change constantly. SwiftQueue only fine-tunes the linear layers using the most recent minute of data—takes under 30 seconds on a commodity GPU.

Batched predictions. At 200 Mbps, you can’t wait for each ACK before predicting the next packet’s latency. SwiftQueue predicts batches of up to 8 future packets simultaneously, keeping inference under 400 microseconds.

Oscillation prevention. A naive controller could thrash between queues. SwiftQueue includes un-ACKed packets (with queue assignments but not latencies) in the prediction input, so it knows how many packets it’s already assigned to each queue.

Results

Evaluated on real traces (Netflix and Facebook traffic over WiFi and Ethernet) and NS-3 simulations:

• Prediction accuracy: 45-65% higher F1 scores on sharp latency changes vs. LSTM and XGBoost baselines

• Tail latency reduction: P99 latency drops 36-45% compared to default L4S or LSTM-driven selection

Show Image

SwiftQueue achieves better prediction on sharp changes by 45-65% and reduces P99 tail latency by 36-45% compared to baseline approaches.

Results hold across different network conditions—even with 500 concurrent flows or 200ms propagation delay.

Deployment Reality

SwiftQueue has some deployment considerations:

• Hardware. Needs a GPU for fast inference, albeit a cheap one (TITAN RTX, 2GB peak memory utilization). Datacenter-scale with 10+ Gbps links would need beefier hardware.

• Delayed ACKs. High propagation delay means less recent information to predict from. The model degrades gracefully but can’t overcome fundamental information constraints.

• Scaling. Handles hundreds of concurrent flows well; thousands would need architectural changes.

• Congestion control coupling. SwiftQueue only does queue selection—doesn’t touch congestion control. The predictor is trained on specific CC algorithms (primarily DCTCP+L4S) and may not generalize perfectly. TCP BBR’s probing behavior creates more random-looking patterns.

• L4S availability. Assumes L4S-enabled routers along the path. Deployment is growing but not ubiquitous.

Why This Matters

This is part of a broader trend: using ML to make fine-grained, per-packet decisions that were previously impossible. Traditional congestion control operates at the flow level because that’s what humans could reason about. Neural networks don’t have that limitation.

You also don’t need billions of parameters. A 100K-parameter model, purpose-built for the domain, beats larger general-purpose architectures. Match the architecture to the problem structure.

Read More

SwiftQueue will appear at the New Ideas in Networked Systems (NINeS) Conference in 2026.

SwiftQueue: Siddhant Ray, Xi Jiang, Jack Luo, Nick Feamster, Junchen Jiang. University of Chicago. arXiv:2410.06112

“AI Detection” Software is the Wrong Approach

Simply put: Surveillance and policing is the wrong response to pedagogy.

First, AI detection tools are unreliable at best. Even the latest tools operate at a 5% false positive rate in ideal scenarios. In more challenging conditions—like a university where students are smart and motivated—accuracy drops further.

Second, the harm to students from inevitable false positives is asymmetric. A student accused of academic dishonesty carries the weight of that accusation, regardless of outcome.

What concerns me more than the technical failures is that this is fundamentally the wrong way to think about pedagogy.

What I’ve Learned Actually Using AI in My Teaching

I’ve written before about my approach: I fully encourage the use of AI tools in all my courses. The core principle is simple: you must understand what you’re turning in. I’ll ask you about it on exams, in discussions, and during assessments. Use whatever tools help you learn and complete your work, but you’re responsible for understanding the output. I also require attribution—tell me what assistance you used.

The classroom is a simulator for the real world, and in the real world, these tools are everywhere. Ignoring them doesn’t serve our students well.

But I don’t just permit AI use—I’ve restructured my teaching around it:

• Automated class notes. I take transcripts of my lectures and use LLMs to generate summaries and notes for students. These get posted immediately after every class. (Example: my agenda files on GitHub)

• AI-assisted exam creation. I use past exams and instruction files with LLMs to generate draft copies of exams. Even better—I share the prompts with students so they can generate their own practice exams based on past materials and covered topics. (See the exam generation setup)

• Discussion preparation. I use AI to organize student reading responses to prepare better class discussions.

• Reduced friction. AI helps me set up environments so students focus on concepts, not configuration.

• The result? Students spend less time on grunt work and more time on higher-level thinking about security, privacy, and online speech. That’s what my courses are actually about.

The Mode Switch

Here’s what I’ve learned using AI for both pedagogy and my own creative work (I’ve been building MCP servers to control my Digitakt sequencer and drum machine, learning about music production as a lifelong learner): there’s a critical distinction between modes of operation.

Are you in push-button mode or evaluation mode?

When you’re creating something, are you expressing yourself or having something else do it for you?

Push-button outputs from LLMs are usually terrible. They produce statistical token completion—the most likely next word. That’s exactly what you don’t want in creative work. You want emotion, lived experience, surprise.

But using AI to break through a block? To help figure out how to express something that’s already inside you? That works.

The principle applies in teaching: Use the tools, absolutely, but ultimately the goal is to further your understanding. If you just copy-paste, you didn’t learn anything, and the learning objectives were not met. We must instead focus on how to design our pedagogy to achieve the learning objectives.

It is Time to Stop with “AI Shaming”

A colleague recently shared something striking from a survey of undergraduates at our university: about 40% won’t admit to using AI but are happy to say their peers do. That’s mathematically impossible if students and their peers are the same population.

What does this mean? Our students are deeply ashamed of using AI, regardless of whether that use is detrimental or instrumental to learning.

This culture of “AI shaming” harms students—psychologically and in terms of their ability to leverage their educational experience to prepare for the real world.

Are policies that encourage policing and punishment of AI use conducive to making our institutions the best they can be right now? I’d argue no. Blanket bans prevent the very conversations that would help students and faculty distinguish between beneficial and harmful uses.

AI as Normal Technology

AI is the latest in a long line of cultural and social technologies—like writing, print, and the internet. I’ve been making this point for two years: this is just another tool—like IDEs, Stack Overflow, or GitHub before it. Potentially more powerful, but fundamentally another instrument in the problem-solving toolkit.

Assessment should be conversation, not surveillance. The question moves from “What do you know?” to “How do you think?” That’s exactly what my approach operationalizes: I test comprehension, not compliance.

What Forward-Thinking Pedagogy Looks Like

Pedagogy will vary widely by course, learning objective, design, mode of interaction, type of assignment, level. I would caution against any prescriptive approach, especially one that generalizes.

But here are some principles that have worked for me:

• Make AI use visible, not hidden. Build tasks that incorporate AI into the learning process. Require students to explain how they used it, what they learned, what choices they made.

• Teach prompt design as critical thinking. Crafting effective prompts is itself a lesson in precision and clarity.

• Restructure tasks around critical thinking, evaluation of outputs, judgment, testing, and debugging. Design assignments that require uniquely human contributions and insist on transparent, reflective use of technology.

• Use AI as complement to group work, not substitute. Treat interactions with AI as opportunities for consolidating core skills to support participation in peer discussions.

CS Education Is More Important Than Ever

Computer science degrees are becoming more important than ever. These models can assist us and make us more efficient, but they can’t (yet) do the same level higher-level reasoning and creative thinking that we are capable of—they automate tasks we specify and lead us to probabilistic likely outcomes and outputs. Such tools are hugely useful—but only if we know how to integrate them into our workflows and thought processes and adapt them for new ones.

The real differentiators are what CS degrees teach: abstraction, specification, testing, debugging, and reasoning about complex systems.

Entry-level isn’t “junior developer” anymore—it’s project manager and test engineer. The thinking doesn’t change. The tools do.

The real question isn’t whether to use AI in education—students are already using it. The question is: Are we teaching them to use it thoughtfully, critically, and ethically? Or are we leaving them to figure it out alone while we chase an unwinnable arms race?

My previous post on this topic: Embracing AI in the Classroom.

Bespoke AI tutors and teaching assistants are here and they are replacing the traditional functions of professors and teaching assistants. This is a wake-up call.

Earlier today, a colleague recently shared some striking data from his course this quarter: page views on Ed Discussion down 65%, discussion threads down 48%, comments down 44%. TA office hours are ghost towns.

Other instructors in our department are reporting similar trends. While it’s important to distinguish between correlation and causality, the hypothesis is clear: Students are increasingly asking for help from LLMs instead of human instructors (specifically, professors and teaching assistants in office hours).

Some of my colleagues have responded in particular ways: concern, a bit of alarm, suggestions that we should run all assignments through GPT before releasing them to see what it spits out. One colleague noted that even plain Google searches now surface LLM-generated responses—making AI assistance essentially “unavoidable” (as LLMs were a technology to be avoided).

I think this discussion needs a careful re-thinking and framing.

The Uncomfortable Reality

If students are consulting “bots” instead of humans, we should consider the uncomfortable reality that the way we used to do our jobs is potentially quite replaceable.

As students become more skilled at using these tools and evaluating their outputs—which is, in part, what we should be training them to do—the old model of “ask the TA how to fix your code” becomes less central to learning.

This presents both disruption and opportunity.

A Different Approach

In my courses, I’ve leaned into this shift rather than fighting it. I give students all of my old homeworks, midterms, and finals. I share full lecture summaries and transcripts. I even share the prompts I used to generate draft exams, so students can create essentially infinite practice material. I’ve written about my approach to AI in the classroom this year in a previous post.

I was really nervous about how this would work out. The result? Students loved it.

Just as many students came to my office hours as in the past—and the discussions were much more interesting. They were engaged at a higher level, asking deeper questions rather than asking “how do I get this to compile?”-style debugging questions

I did discover, that, in allowing my students to use LLMs to assist with assignment completion—a couple of assignments were completed more quickly than in past years. I noted several where it was clear that the assignment was perhaps too “AI-friendly”, in the sense that my earlier assignment design makes it a little too easy for students to “phone it in” without understanding the learning objectives.

My response to that, “in the offseason”, will be to think about how to tune the assignments and syllabus accordingly—probably adding a couple more, as well as asking students to think more deeply about the outputs, testing them more on exams on the concepts I want them to be learning.

In short, we need to think hard about how we adapt learning objectives to these new realities training our students to work with the tools as we prepare them for their eventual occupations.

And, as educators ourselves, we need to be thinking hard about how to incorporate these tools into our own occupation as educators. That ultimately makes us better educators for two reasons: one, we can teach better having had direct experience with the tools, and two, we can improve our own teaching efficiencies with AI to improve the delivery of our own content and steamlining the logistics of teaching (and anyone who has taught before can appreciate, there are a lot of rote logistics that are ripe for automation).

Caveat: Your Mileage May Vary

It’s early days here, and nobody has the answers. In my courses, I treat my students as “co-learners” and partners in the journey. I bring value to the classroom, and AI can also bring value—to myself as an educator, and to the students as learners. The answers are not all clear, but one thing I think is clear even in these early days: The answer is not to ban or police the tools or deny their existence, but to think hard about what integrative approaches can help us achieve learning objectives, which themselves are ultimately going to to evolve.

And finally, I’d caution against any prescriptive approach here, especially one that generalizes across all courses and contexts. Pedagogy, material, learning objectives, style of instruction, and general philosophy all matter. What works for a systems course may not work for discrete math. What works for a Master’s seminar may not work for an intro programming class.

But if the old indicators of engagement—Piazza/Ed posts, TA queues—are dropping, maybe we should ask whether those were ever the right metrics for learning in the first place.

After some moderanvestment of time and energy on my side, I now have my own administrative assistant. I’ve spent a chunk of time building model context protocol (MCP) servers that run against my calendar, email, notes, and meeting transcripts. The setup wasn’t trivial—this took actual work, actual code, actual debugging—but the payoff has been immediate and substantial.

Now I can fire off queries like “brief me for my meetings today” or “find the emails related to my 2pm” or “when’s the best time to schedule a meeting with this person based on my preferences,” and while the system cranks away, I go do something else. Play guitar. Go for a run. Do laundry. Or—radical thought—get on with the actual work that requires my brain.

The time savings alone would justify the effort. But the real win isn’t just efficiency. I show up to meetings prepped and briefed. My meetings get scheduled with my actual preferences in mind, the way a human admin would do it. I’m not burning mental cycles on calendar optimization, or trying to remember what that person emailed me about three weeks ago (or search for it with bad email search tools).

What actually matters: I’ve reduced time spent on rote tasks significantly, but more importantly, my brain is free for creative thinking—the kind where I can actually add value. The stuff that requires human judgment, intuition, synthesis. The work that matters.

I feel like this is the AI productivity story that isn’t getting enough attention.

It’s not about AI doing your job for you. It’s about AI handling the cognitive overhead that prevents you from doing your job well.

When used well, AI can help us minimize the endless context-switching, the administrative tax, and the mental load of keeping track of everything. We talk a lot about “augmenting human intelligence” in the abstract, and this is one example of what it looks like in practice.

The tools I built are open source:

• spark-mcp for email and meeting transcripts, and

• calendar-mcp for calendar management.

They’re hardly “production ready” for the masses, but they work for my needs. They’ve changed how I work.

And that idea of “just good enough” bespoke tools brings me to my final point. It has become so easy to build these bespoke tools for ourselves, what may ultimately happen to all of the companies that build these kinds of bespoke “productivity” tools that revert to the common case but never seem to quite fit anyone’s specific workflow. I do wonder if many of us will simply build these kinds of tools for ourselves now instead of paying for things that don’t quite work.

Think about that timing for a moment. In 1990, Tim Berners-Lee was still working on the first web browser at CERN. Most people had never heard of email. The idea that computer science would become as fundamental to modern life as it has—that it would reshape everything from how we communicate to how we work to how we think—was far from obvious. And yet Georgia Tech made a bet that computer science deserved to stand on its own, separate from electrical engineering, as a full college.

While I don’t know the full history of the establishment of the College, I remember hearing stories about how the restructuring was quite controversial at the time. I can only imagine what those faculty meetings must have been like. Academic reorganizations are never easy, and this one was particularly bold. It meant pulling computer science out from under the traditional engineering umbrella and giving it independence, resources, and autonomy. That kind of move doesn’t happen without fierce debate and, I imagine, some bruised egos along the way.

Even when I started there as an assistant professor in 2006—sixteen years after the College was established—I remember thinking that the structure was pretty unusual. As a fresh Ph.D. graduate, I really couldn’t wrap my head around it. The thought of CS in a completely separate department from EE seemed utterly foreign to me at the time. I had come from a world where computer science and electrical engineering were tightly coupled, where the organizational chart reflected the historical reality that computing had emerged from electrical engineering. Separating them felt almost unnatural.

But so many faculty there, including and especially Ellen Zegura, sold me on the College, saying how advantageous this structure was. I took a leap of faith at the time, but over the years it has become increasingly clear to me how right she was about this—and many other things. Organizational structure is critical for innovation, in scholarship as it is in anything. When you give a field room to define itself on its own terms, rather than as a subset of something else, it can move faster and think bigger.

I think it’s one of the reasons Georgia Tech has been able to remain so agile in thinking about CS over the years. The Online MS in CS program, which launched in 2014 and ultimately reached over a million students worldwide, was a radical experiment in making high-quality graduate education accessible at scale. The Threads curriculum reimagined how to teach computer science by letting students weave together their own path through the discipline rather than following a rigid sequence. And more recently, the School of Cybersecurity and Privacy represents yet another structural innovation, recognizing that security and privacy have become foundational concerns that deserve their own institutional home.

None of these innovations were guaranteed to work. All of them required institutional flexibility, a willingness to experiment, and the kind of autonomy that comes from having your own college rather than being a department within someone else’s college. When you have to negotiate with other departments over every curriculum change or new program, innovation slows to a crawl. When you have the independence to move quickly, you can try things that other institutions can’t.

The more experience and perspective I accrue, the more impressed I am that Georgia Tech did this so early, and even more so that they pulled it off in the face of what must have been incredible resistance at the time. It amazes me every time I think about it. Someone—or more likely, a group of people—had the vision to see that computer science was going to be massive and the courage to fight for the institutional structure to support that vision. They were willing to endure the controversy and discomfort of reorganization for something that wouldn’t fully pay off for years or even decades.

Now, 35 years later, other universities are catching on. We’re seeing new colleges of computing announced with great fanfare, as if the idea is novel. And maybe for those institutions, it is. To me, this just makes it all the more incredible that Georgia Tech figured this out in 1990, when it was far from obvious that this was the right move.

That kind of foresight and institutional courage is worth celebrating, and learning from.

Twenty years after these kinds of configuration errors first motivated my Ph.D. thesis research, they remain one of the primary causes of network and system outages.

In May 2005, my advisor Hari Balakrishnan and I published “Detecting BGP Configuration Faults with Static Analysis”. The tool was called rcc (Router Configuration Checker), and it introduced static analysis of router configurations before deployment. Studies at the time showed that 50-80% of network outages were caused by configuration errors. Two decades later, that fundamental problem persists—though the systems have gotten vastly more complex.

The Problem in 2005

In the mid-2000s, network operators were managing increasingly complex routing infrastructures with no systematic way to verify correctness. The state of the art was to push configurations to production routers and see what breaks. When something went wrong, operators would scramble to diagnose the problem and roll back changes.

Configuring routers in an autonomous system is essentially writing a distributed program, but we were doing it with none of the verification tools that software engineers take for granted. BGP’s flexible configuration language made it powerful but error-prone. Operators had to manually decompose network-wide policies into device-level configurations across potentially thousands of BGP sessions, with complex interactions between iBGP, eBGP, route reflection, and filtering policies.

The Approach

rcc introduced static analysis of router configurations before deployment to detect faults automatically.

The approach was to parse vendor-specific configuration files, normalize them into a vendor-independent representation using relational database tables, and then check constraints based on a correctness specification. No need to run configurations in a live network or build expensive emulation environments.

rcc focused on detecting two broad classes of BGP configuration faults:

Route validity faults: Where routers might learn routes that don’t correspond to usable paths. This included issues like:

• Invalid AS paths being propagated

• Next-hop addresses unreachable via IGP

• Undefined references to filters and route maps

• Improper or missing route filtering

Path visibility faults: Where routers fail to learn routes for paths that exist in the network. The classic example was iBGP configuration errors—particularly with route reflection—that could cause network partitions where some routers never learn about certain destinations.

What We Found

We analyzed BGP configurations from 17 real-world networks. rcc found errors in every network. Most operators were unaware of these errors, which ranged from simple single-router problems like undefined variables to complex multi-router interactions.

The errors we uncovered included:

• Potential network partitions caused by route propagation problems

• Invalid routes being propagated due to improper filtering

• Routers forwarding packets inconsistently with high-level policy

• 420 incomplete iBGP sessions across the networks we studied

Many of these errors were latent—not actively causing problems yet, but violations of correctness that would manifest under certain conditions. For example, misconfigured backup paths that would only fail after a primary link went down.

Why Configuration Errors Happen

Our analysis revealed three main causes:

1. Complex propagation mechanisms: The techniques used to scalably propagate routes within a network—particularly route reflection with clusters—are easily misconfigured.

2. Levels of indirection: Even simple policy specifications get implemented using multiple layers of indirection in configuration files (distribute lists, prefix lists, route maps, community values).

3. No systematic process: Most operators had no disciplined approach to network configuration. There were no configuration management tools, no testing frameworks, no verification.

The Impact

rcc won Best Paper at NSDI 2005. The tool was open-sourced and is still on GitHub at github.com/noise-lab/rcc. Operators used it to find and fix bugs before deployment.

The bigger impact was establishing static configuration verification as a research area. rcc showed that you could reason formally about network behavior from configuration files alone, without needing access to live networks or running emulation.

The Research Lineage

Over the past 20 years, researchers have built on rcc’s foundation with increasingly sophisticated techniques:

Header Space Analysis (2012): Kazemian, Varghese, and McKeown extended static analysis from the control plane to the data plane, introducing geometric representations of packet header spaces.

Batfish (2015): Fogel, Mahajan, Millstein and colleagues built a general-purpose configuration analysis tool using Datalog and logic programming, extending beyond BGP to multi-protocol networks.

Minesweeper (2017): Beckett et al. developed SMT-based verification for a wide range of properties including reachability, waypointing, and fault tolerance.

These tools advanced the techniques for network verification—new representations, new algorithms, broader protocol coverage. But they all built on the paradigm rcc established: that you can and should verify network configurations statically before deployment.

Key Design Decisions

Several design decisions proved important:

Vendor-independent representation: By parsing vendor configs into normalized relational tables, we separated the parsing problem from the analysis problem. This pattern has been followed by every subsequent tool.

Focus on correctness, not optimality: rcc didn’t try to find the “best” configuration—it found wrong configurations.

Constraint-based approach: Rather than requiring operators to write formal specifications, rcc checked constraints that must hold for any correct configuration.

Static analysis: No need for live network access, no emulation overhead, no waiting for convergence. You could verify configurations as fast as you could parse and analyze them.

What’s Changed in 20 Years

Networks have gotten more complex. We’ve added software-defined networking, cloud and multi-cloud environments, container networking, network functions virtualization, and programmable data planes. Configuration errors are more consequential than ever. A misconfiguration in a cloud environment can expose thousands of customers’ data. An error in SDN controller logic can take down an entire data center. A faulty configuration update can crash millions of systems worldwide, as we saw with CrowdStrike.

Looking Forward: LLMs and the Next Generation

While outages persist and are often due to increasingly complex software and configuration errors, there is hope that tools with more sophisticated reasoning capabilities will ultimately help us reason about these errors. The rise of large language models has opened new approaches to the problems rcc was designed to solve.

Our recent work on CAIP (Context-Aware Iterative Prompting) demonstrates how LLMs can detect router misconfigurations with over 30% better accuracy than traditional model checkers and consistency checkers, finding over 20 previously undetected misconfigurations in real-world configurations. Unlike traditional tools that require significant manual effort to develop and maintain for each new protocol or vendor, LLMs can learn patterns from vast datasets and apply them across layers and vendors.

This makes the verification that rcc pioneered feasible for much larger and more complex systems—from multi-protocol networks to cross-vendor translations to intent-based configuration generation. The fundamental insight remains the same: configuration errors are preventable through analysis before deployment. But LLMs are making that analysis practical at scales and across domains we couldn’t have imagined in 2005.

The AWS and CrowdStrike outages remind us that configuration errors remain a critical challenge. But they also show us that the problem rcc addressed two decades ago is more important than ever—and that new techniques building on that foundation offer genuine hope for finally getting ahead of these errors.

The original rcc paper: “Detecting BGP Configuration Faults with Static Analysis,” Nick Feamster and Hari Balakrishnan, NSDI 2005. PDF

Recent work: “CAIP: Detecting Router Misconfigurations with Context-Aware Iterative Prompting of LLMs,” Xi Jiang, Aaron Gember-Jacobson, and Nick Feamster, 2024. arXiv

@inproceedings{feamster2005rcc,
  title     = {Detecting {BGP} Configuration Faults with Static Analysis},
  author    = {Feamster, Nick and Balakrishnan, Hari},
  booktitle = {2nd USENIX Symposium on Networked Systems Design and 
               Implementation (NSDI ‘05)},
  year      = {2005},
  month     = {May},
  address   = {Boston, MA},
  publisher = {USENIX Association},
  url       = {https://www.usenix.org/legacy/event/nsdi05/tech/feamster/feamster.pdf},
  note      = {Best Paper Award}
}

• AI and Machine Learning for Networking — generative models for synthetic traffic, traffic classification, and operational analytics

• Internet Access and Broadband Measurement — tools and data for understanding network performance in homes and communities

• Internet Censorship and Online Speech — measuring and circumventing global Internet filtering

• Security and Privacy — protecting users from threats posed by IoT devices and network traffic analysis

Here’s a quick tour of what you’ll find.

AI and Machine Learning for Networking

This is perhaps the area where we’ve seen the most exciting recent progress. The scarcity of high-quality, labeled network traffic datasets has long been a bottleneck for applying machine learning to networking problems—privacy concerns, data staleness, and access restrictions have made it difficult to train models effectively.

Our response has been to develop generative AI techniques that can produce realistic, protocol-compliant synthetic network traffic. NetDiffusion uses a fine-tuned Stable Diffusion model to generate packet captures that closely mimic real network data while adhering to protocol specifications. More recently, NetSSM applies state-space models to generate multi-flow network traces that capture the complex temporal dependencies between simultaneous network conversations. These tools are helping researchers train better ML models for traffic classification, anomaly detection, and network security—without needing access to sensitive real-world data.

Beyond data generation, we’re developing techniques for traffic classification, predictive modeling, and operational analytics. This includes work on efficient representations for network data through tools like netml, and models that can handle the practical challenges of deployment, like cost sensitivity and model drift.

You can read more about our ML for networking research on netml.io.

Internet Access and Broadband Measurement

Understanding how people actually experience the Internet requires measuring it where it matters most: in homes and communities. Our Internet Innovation Initiative develops new tools to measure broadband access and performance, working with community partners to make high-speed Internet accessible to all.

This work builds on a long history of broadband measurement, including the BISmark project and our collaborations with the FCC to develop technologies for understanding access network performance across the United States. Today, we deploy Netrics devices in homes across Chicago and beyond, gathering continuous, granular data that enables comparisons of Internet experience across neighborhoods with different socioeconomic profiles. The goal isn’t just measurement for its own sake—it’s producing actionable insights that can inform policy and investment decisions to close the digital divide.

You can explore our open-source tools and datasets at internet-innovation.github.io.

Internet Censorship and Online Speech

More than 60 countries perform some form of Internet censorship. Our group has been developing technologies to measure and mitigate censorship for over two decades, producing a series of firsts: Infranet (2002), the first system to use covert channels for circumvention; Collage (2009), which used user-generated content platforms as drop sites; Encore (2015), the first system for global, real-time measurement of Web censorship; and Iris (2017), the first system to detect widespread DNS manipulation.

Current work focuses on applying AI to detect censorship in real time. We’re training models to identify the “fingerprints” of filtering devices by analyzing how they manipulate traffic, with the goal of creating a real-time “weather map” for censorship—where observers can see Internet interference as it happens, which sites are being targeted, and in which countries. Recent work has developed more robust machine learning techniques for censorship detection that can discover new blocking signatures missed by existing heuristics.

Security and Privacy

The proliferation of connected devices creates new security and privacy challenges. Smart home IoT devices interact with multiple people, respond to environmental triggers, and operate in a fragmented ecosystem—none of which fits well with traditional security approaches designed for single-user, keyboard-and-screen computing.

Our IoT Lab provides a testbed for studying these devices, where we’ve investigated everything from the tracking behavior of Smart TVs to cleartext data transmissions in consumer medical devices. We developed IoT Inspector, a tool that crowdsources labeled network traffic from smart home devices to detect hidden security and privacy violations. We’re also working on DNS privacy, designing protocols and systems to improve privacy properties even when encrypted DNS solutions are in use.

A key insight from this work is that network traffic itself reveals information users may want to keep private—eavesdroppers can infer in-home behaviors just from traffic rate patterns, even when the content is encrypted. Our research explores both how to detect these threats and how to mitigate them through techniques like smart traffic shaping.

Education and Courses

We’re committed to making our research accessible through teaching.

I regularly offer courses on machine learning for network security, Internet censorship, and security and privacy to undergraduate and graduate students at UChicago.

For online learners, our Software Defined Networking and Applied Machine Learning MOOCs on Coursera have reached millions of students worldwide—the SDN course was one of the first of its kind and helped launch Georgia Tech’s Online Masters in Computer Science program.

Free instructional videos are also available on the nfeamster YouTube channel.

See the full list of courses at noise-lab.net/courses.html. I continue to add more courses and content on these topics, so please subscribe and stay tuned for more updates!

The redesigned site also highlights our commitment to open-source software, real-world deployments, and outreach—from educational programs for underrepresented students to policy comments on spectrum allocation and data privacy. Take a look around, and reach out if you’re interested in learning more about the group or how to get involved.

noise-lab.net

What These Servers Do

calendar-mcp gives Claude access to Google Calendar:

• List events across all calendars (primary, work, shared)

• Find when I last met with someone

• Create events and send invitations

• Accept/decline calendar invites

• Find optimal meeting times based on configured preferences

• Analyze time blocks (deep work vs. flexible time)

spark-mcp gives Claude access to email and meeting transcripts:

• Search and read emails

• Find emails needing responses

• Extract action items from messages

• Access meeting transcripts

• Search transcript content

Using Them Together

The useful part is running both servers at once. Claude can pull from either system as needed, which means queries can span both without any extra work on my end.

Some examples of what this looks like:

“What do I need to be prepared for tomorrow?”

Claude checks the calendar for tomorrow’s meetings, then searches emails for recent threads with those attendees. I get a briefing that includes both the meeting details and relevant email context.

“What were the action items from my meeting with Andrew last Tuesday?”

Claude finds the meeting on the calendar, pulls the transcript from spark-mcp, and extracts the action items. One query, two systems.

“Do I have any emails I need to respond to before my 2pm?”

Claude checks pending responses in email, cross-references with the calendar to see what’s at 2pm, and prioritizes accordingly.

“Find a time to meet with Sarah next week and draft an email inviting her.”

Claude uses calendar-mcp to find available slots (respecting my preferences), then uses the email context to draft an appropriate message.

Why LLMs Beat Existing Solutions:
Understanding Soft Preferences

calendar-mcp has a configuration file for scheduling preferences:

{
  “preferredDays”: {
    “Wednesday-PM”: 100,
    “Thursday”: 100,
    “Monday-PM”: 70,
    “Tuesday”: 40,
    “Friday”: 40
  },
  “preferAdjacentToMeetings”: true,
  “avoidDeepWorkBlocks”: true,
  “neverAvailablePatterns”: [”kids”]
}

When finding meeting times, Claude ranks options by these preferences. Wednesday afternoons and Thursdays score highest. It looks for slots adjacent to existing meetings to consolidate context-switching. It avoids blocks marked as deep work. Events with “kids” in the title are treated as immovable.

Setup

Both servers require OAuth setup with Google APIs—Calendar API for calendar-mcp, Gmail API for spark-mcp. The README files walk through the process. Once authenticated, you add them to your Claude Desktop config:

{
  “mcpServers”: {
    “calendar”: {
      “command”: “python”,
      “args”: [”-m”, “calendar_mcp.server”],
      “cwd”: “/path/to/calendar-mcp”
    },
    “spark”: {
      “command”: “python”, 
      “args”: [”-m”, “spark_mcp.server”],
      “cwd”: “/path/to/spark-mcp”
    }
  }
}

Restart Claude Desktop and both servers are available.

Why This Works

MCP servers are additive. Each one gives Claude access to a different system, and Claude figures out which tools to use based on the query. I don’t have to think about which server handles what—I just ask questions and Claude routes appropriately.

The combination of calendar and email covers most of my organizational needs. I can check my schedule, find context from past communications, schedule new meetings, and respond to emails all in the same conversation where I’m doing actual work.

Both projects are open source: calendar-mcp and spark-mcp.

I’ve been experimenting with live looping in my home studio for months now, layering guitar parts and vocals, building arrangements one pass at a time.

Last night, I performed with a live looper for the first time. Performing live with loops is a different animal entirely. It’s not just about the technology; it’s about managing time, recovering from mistakes, and learning to trust the layers you’re building in real-time while an audience watches.

Here are some lessons I took away.

Tempo Sync Gives and Takes Away

I was looping two tracks with tempo sync set, which ensures that different parts of the song, like verse and chorus, stay at a common tempo.

I learned a crucial lesson: if you’re using tempo sync, it’s best to have click or drum track running when you lay down your foundation, especially when you shift from verse to chorus. On the verse, it matters less because you’re establishing the tempo and you’re tapping out the beat. As you switch to chorus, however, the track assumes that you’re hitting exactly the same tempo, and even a little drift will cause chaos.

On one song, I started a chorus loop without the reference beat going. I was maybe 20 milliseconds off—nothing you’d notice on the first repetition. But loops are precise. That tiny error compounds with each cycle. By the fourth time through, I was noticeably chasing or dragging against my own playing.

It’s disorienting in a way that’s hard to describe: you’re simultaneously ahead of and behind yourself.

You’re the Bandmate and the Conductor

Playing with loops feels remarkably like playing with a band—with one critical difference. When you mess up in a band, the other musicians keep going and you find your way back in. With loops, the band keeps going too, but you’re also responsible for conducting them with your feet.

Miss your cue to transition to the bridge? The loop stays locked in the chorus. Forever. Or until you manually break the cycle.

I found myself literally stuck in a loop during the bridge transition, my foot hovering over the pedal, trying to find the exact moment to switch parts while singing and playing guitar. It requires a kind of split attention that’s genuinely difficult: you’re performing for the audience while simultaneously managing a set of time-synchronized tracks that need precise coordination.

You Always Have the Option to Clear, and It’s Often a Good Idea

Sometimes the best recovery from a drifting loop is to blow it up and start over.

If you’re noticeably out of sync, trying to force your way back into alignment rarely works. You end up fighting yourself. Instead, I learned to keep playing the current section smoothly for the audience while quietly clearing the problematic loop in the background. Then, when the progression cycles back around, you lay down a fresh, properly-synced foundation.

The Blessing of Diatonic Harmony

While loops are unforgiving masters when it comes to tempo sync, they are also more forgiving than they seem, thanks to diatonic harmony.

Afterward, multiple people told me it sounded great and they didn’t notice a single mistake. How? The layers give you cover.

When you’re working within a diatonic framework—all your chords belong to the same key—even a slightly misaligned loop won’t sound dissonant.

The worst that happens is some rhythmic ambiguity or harmonic density that might actually sound intentional. Your verse chords and chorus chords are all swimming in the same tonal pool, so as long as you recover quickly, the ear tends to forgive the temporary confusion.

This doesn’t mean you can be sloppy. But it does mean that the margin for error is wider than it feels in the moment. The perfectionism that serves you in the studio can become paralyzing on stage.

Think About Looping Like a Mix

After the set, someone gave me a tip that should have been obvious but wasn’t: treat your loop layers like you would tracks in a mix.

In the studio, you don’t record everything at the same volume with the same tone. You adjust EQ, panning, dynamics—you carve out space for each element. The same principle applies to live looping, but you have to think about it before you hit record on each layer.

Switch pickups between layers. Move from playing near the bridge to playing near the neck. Adjust your volume knob. Play some parts with more attack, others with a softer touch. Each layer should sit in its own part of the sonic spectrum.

This was a revelation. I’d been thinking of looping as “record parts and stack them,” when I should have been thinking “how does this layer fit in the arrangement I’m building?” That rhythm part doesn’t need to be as loud as the melody. That bass line can be warmer and rounder. That harmonic fill can be brighter and more percussive.

You’re not just a performer when you’re looping—you’re also the engineer, making mix decisions in real-time with the only tools available: your hands, your pickup selector, and your volume knob.

The Paradox of Layers

Live looping presents a fascinating paradox. Each layer you add:

• Makes the arrangement richer and more forgiving

• But also makes each individual mistake more consequential

• Creates more sonic space to hide in

• But also requires more precise coordination to manage

You’re simultaneously more exposed and more protected than playing solo. It’s like being in a band where all the members are slightly out-of-phase versions of yourself.

What I’m Taking Forward

For next time: click track always on during foundation building. Practice the foot transitions as much as the musical parts.

Think about each layer’s place in the mix before recording it.

Trust the diatonic safety net, but don’t rely on it.

And most importantly, stay calm when things drift—the audience almost certainly won’t notice unless you show them you’re panicking.

Live looping is less like recording and more like a very controlled form of improvisation. You’re composing in real-time with a collaborator who remembers everything perfectly but can’t adapt.

You’re also mixing in real-time with tools far more limited than any DAW. It’s challenging in ways I didn’t expect, and rewarding in ways I’m still discovering.

The loop keeps going. You keep going. Sometimes that’s in perfect sync, and sometimes it’s not. But as long as you’re both moving forward, the audience hears a song.

The solution? Build your own testbed ISP.

In 2014, we published “PEERING: An AS for Us,” describing a testbed that let researchers experiment with the Internet’s routing infrastructure for the first time. That work recently received the Test of Time Award from the ACM SIGCOMM Internet Measurement Conference. (The term “AS” in the paper’s title refers to “Autonomous System”, which is a technical term for an independently operated network like an ISP).

The project started under GENI (Global Environment for Network Innovations), an NSF-funded program with an ambitious goal: design a future Internet architecture. GENI built infrastructure to let researchers experiment with networking at scale. The system that eventually became PEERING was called Transit Portal, infrastructure that my Ph.D. student Valas Valancius and I developed at Georgia Tech to give researchers access to interdomain routing.

The GENI and FIND programs had a vision of letting researchers actually experiment with Internet infrastructure and architectures, not just simulate it. I had this idea that it should be possible to experiment with Internet routing on the real Internet. Transit Portal was our way of making that a reality. Actually getting it working—building the control plane, the safety mechanisms, the whole system—was a huge design and implementation lift. Valas really got it off the ground.

Transit Portal leveraged Internet Exchange Points (IXPs), the points in the Internet where networks connect to exchange traffic directly. By connecting to other service providers directly at IXPs, the testbed could peer with hundreds of networks and announce routes just like a real ISP. But the Transit Portal also needed safeguards. Servers sat between researchers and the live network, filtering routes and enforcing policies so a bad experiment couldn’t break anything.

The challenge wasn’t just technical. We had to convince operators at major IXPs like AMS-IX in Amsterdam to let us plug academic research infrastructure into their production network. That required trust, and we had to earn it.

After the GENI program ended, Transit Portal might have disappeared like so many research prototypes do when funding ends and students graduate. Instead, Professor Ethan Katz-Bassett and his team at USC, and later at Columbia, took over leadership of the project and continue to maintain it to this day. They expanded it to more IXPs, maintained the infrastructure, developed new capabilities, and continue to actively support the research community’s use of the testbed.

PEERING has flourished because of Ethan and his team. They’ve kept it running for more than a decade, expanded it, and supported the research community. That sustained effort—deploying at IXPs, maintaining the system, making it possible for so many researchers to actually use it—that’s why the work has stood the test of time. They deserve enormous credit. This work has stood the test of time and remains one of the main lasting, impactful legacies of the GENI program, in large part due to Ethan’s ongoing dedication to the project, as well as many other students and researchers who have continued to extend and support the work.

The testbed enabled research that wasn’t possible before: systems for repairing routing failures, prototypes for software-defined Internet exchanges, and tools for diagnosing path changes. It’s still being used today. Transit Portal, and ultimately PEERING, demonstrated that the Internet’s core could be studied experimentally, not just observed from the outside. In some sense, this is the lasting legacy of the work, as well—that Internet researchers can improve the Internet by building systems that interact with the live network, going beyond the simulation-based experiments that were the de facto mode of operation prior to Transit Portal and GENI.

The impact goes beyond just the testbed itself. We demonstrated that it was possible to do empirical research on the Internet’s routing infrastructure. Prior to Transit Portal and PEERING, the predominant mode of understanding Internet routing was through simulation or theory, both of which had significant shortcomings when translated to practice. We showed that it was possible to conduct experimental research on critical infrastructure if you build the right guardrails. That principle applies to everything I work on to this day, whether it is network security and privacy, performance monitoring and inference, or machine learning models for networks. Ultimately, lasting impact in this field requires building and measuring deployed systems.”

Check out our ongoing research at the Network Operations and Internet Security Lab, focusing on AI- and data-driven security, privacy, and auditing in networked systems.

This month marks the 20-year anniversary of the beginning of our first research project on applications of machine learning to networking, Understanding the Network-Level Behavior of Spammers.

Since 2006, we’ve been pioneering the application of machine learning to networking problems.

Today, we are excited to announce netml.io—a research initiative that brings together two decades of work at the intersection of ML and networking, from security applications to performance analysis to synthetic traffic generation.

Announcing netml.io

netml.io is the home for all things at the intersection of networks and AI—a comprehensive resource for researchers, practitioners, and students working in this space.

The goals of the project include:

• Open-source tools: Implementations of NetDiffusion, NetSSM, Traffic Refinery, and related traffic generation and analysis tools available on GitHub

• Datasets and benchmarks: Curated resources for common ML tasks in networking, making it easier to train and evaluate models

• Research collaborations: Partnerships with industry and academia to tackle real-world problems at the intersection of AI and networking.

• Educational resources: We’re developing comprehensive teaching materials including a forthcoming book on AI and ML for networking, an online course based on our ML Systems course materials, and tutorials and practical guides for applying ML to network analysis.

• Community hub: A central place for the networks + AI community to share ideas, code, and datasets

The netml.io website brings together decades of research applying AI to networking problems and datasets. Read on for a history of the project.

Machine Learning for Network Security (2006-2009)

The NetML story begins in 2006, when we were among the first to apply machine learning to network security problems. Our early work focused on understanding and combating spam and botnets at the network level. Rather than just looking at email content, we analyzed network-level behavior—examining patterns in how messages were sent, identifying spamming infrastructures, and detecting botnet membership through DNS blacklist reconnaissance.

This collection of work on “behavioral blacklisting”, starting with this initial SIGCOMM paper, showed that network-level features were far more difficult for attackers to manipulate than message content. The SIGCOMM 2006 paper on understanding spammers’ network-level behavior became foundational work in the field, demonstrating how ML could identify malicious activity from traffic patterns alone. The paper won a Best Paper Award and formed the basis for a Presidential Early Career Award for Scientists and Engineers (PECASE) in 2008 for contributions at the intersection of AI and cybersecurity.

The key observation behind the initial work was simple: attackers behave differently from legitimate senders, and those differences are evident in network traffic and other signals evident in network data. By examining features like AS numbers, geodesic distance between sender and receiver, sending patterns across time, and recipient clustering, we could distinguish malicious from legitimate traffic without ever looking at message content.

During this period, we also developed techniques for characterizing botnets from email spam records and detecting botnet membership using DNS blacklist counter-intelligence.

Our initial insight was simple but profound, and one that has ultimately stood the test of time and formed the basis of much of our work over the past two decades: networks contain rich signals that machine learning can exploit for a wide variety of inference problems in security, performance, and resource allocation.

Deploying ML in Practice (2009-2016)

Our spam and botnet detection work quickly moved from research to real-world deployment. In 2009, we developed SNARE (Spatio-temporal Network-level Automatic Reputation Engine), an automated system that could identify spammers with over 94% accuracy and just 2% false positives using only network-level features. SNARE was designed to work as a lightweight “pre-acceptance” classifier—fast enough to make decisions before even accepting an email connection. SNARE was deployed at Cisco/IronPort and Secure Computing, demonstrating that network-level ML could work at scale in commercial email security products.

We also developed WISE (What-If Scenario Evaluator), which used statistical learning to predict the effects of configuration and deployment changes in content distribution networks. WISE was deployed at Google, where it helped evaluate “what-if” scenarios for network changes without requiring expensive real-world experiments.

During this period, our research applying machine learning to botnet detection led to the founding of Damballa, a startup based on our research on DNS-based botnet detection. Damballa’s core technology used machine learning algorithms to identify the unique traffic patterns and communication signatures that botnets generate as they interact with command-and-control servers. By monitoring DNS queries for anomalous patterns—like the Non-Existent Domain (NXDomain) responses generated by domain generation algorithms (DGAs)—Damballa could detect botnet infections weeks before traditional signature-based approaches.

Damballa grew rapidly, eventually monitoring nearly 15% of global Internet traffic and protecting over half a billion devices for enterprise customers, ISPs, and telecommunications providers. The company’s FirstAlert service could detect threats 30 days earlier on average than conventional malware detection systems. This work demonstrated that academic research in ML for networking could translate directly into commercial impact.Early Warning Systems (2012-2016)

As attackers evolved, so did our detection methods. By 2012-2016, we were working on PREDATOR (Proactive Recognition and Elimination of Domain Abuse at Time-Of-Registration), which took an even more proactive approach: detecting malicious domains before they were used for harm.

The insight was that malicious actors exhibit different registration behavior than legitimate users—bulk purchasing domains to take advantage of discounts, registering many similar domains at once, and using specific patterns in registration information. By analyzing these behavioral signals at registration time, PREDATOR could identify potentially malicious domains with 70% detection rate and only 0.35% false positives, all before the domains had been used for any attacks.

This work was also featured in Wall Street Journal CIO and resulted in several patents, showing that ML could provide early warning systems for network security—catching threats in their planning stages rather than waiting for them to cause damage. The proactive approach represented a fundamental shift from reactive signature-based detection to predictive, behavior-based prevention.

Inference from Encrypted Network Traffic (2017-2020)

By 2017, encryption was becoming ubiquitous, and network traffic also became increasingly encrypted—certainly a win for privacy, but a challenge for network management and security. At this time, we started to encounter questions concerning what we could learn about network traffic when we can’t see the data inside the packets themselves. The rise of encryption led to a new research direction: inference from encrypted network traffic.

At the intersection of ML and privacy, we demonstrated that even encrypted IoT device traffic could reveal sensitive user activities through traffic analysis. Our work on IoT privacy showed that a Sense sleep monitor’s traffic patterns could reveal when someone was in bed, and that an Amazon Echo’s traffic could indicate when users were speaking to it—all without decrypting a single packet. We also developed traffic shaping techniques to protect smart home privacy.

In the area of network performance and management, we developed developed techniques to infer video streaming quality (startup delay, resolution) from encrypted Netflix, YouTube, Amazon, and Twitch traffic. This work, featured on the front page of the Wall Street Journal in 2019, showed that ML models could provide ISPs with visibility into application performance even as encryption spread across the Internet. The study demonstrated that premium internet speeds above 100 Mbps provide little benefit for video streaming—valuable information for both consumers and network operators.

Making ML Practical: Cost-Aware Representations (2020-2023)

As our ML models became more sophisticated, we confronted a new challenge: deploying them at scale. A critical first step was developing better representations of network traffic for machine learning.

In 2020, we developed nPrint, a standard packet-based representation that was the first system to successfully apply deep learning models directly to raw network traffic without manual feature engineering. nPrint represents packets as standardized bitmaps, enabling convolutional neural networks and other deep learning architectures to automatically discover important features (like IP TTL, window size, protocol fields) across diverse tasks including device fingerprinting, operating system detection, and application identification. Combined with automated machine learning (AutoML), nPrint achieved higher performance than state-of-the-art hand-engineered approaches while being generalizable across multiple traffic analysis problems.

Building on this foundation, we developed Traffic Refinery (2020), which explored the fundamental tradeoff between model accuracy and computational cost. We showed that different ML tasks benefit from different representations of network traffic—some need raw packet data, others can work with flow statistics—and built a framework for automatically selecting cost-effective representations.

This work on cost-aware data representation was crucial because real networks need to analyze traffic at line rate (10+ Gbps). The most accurate model is useless if it can’t keep up with traffic.

We also developed techniques for handling concept drift (LEAF, 2023), recognizing that network traffic patterns change over time as applications evolve, new protocols emerge, and user behaviors shift. Our work on multimodal inference (AMIR, 2023) showed how combining network data with other signals could improve robustness and accuracy.

Dynamic Model Execution: Adapting in Real-Time (2023-2024)

Recent work has focused on making ML-based traffic analysis adaptive and efficient through dynamic model execution—systems that intelligently adapt to changing network conditions and computational constraints in real-time. The core insight: not all traffic is equally difficult to classify. A high-confidence prediction from a simple model is just as valuable as one from a complex model, but costs far less.

• JITI (Dynamic Model Serving for Just-in-Time Traffic Inference): An adaptive ensemble classification framework that dynamically selects which models to use based on traffic characteristics. JITI efficiently manages a pool of classifiers with different performance and cost profiles, using an adaptive scheduler that tracks system memory availability and incoming traffic rates to determine the optimal classifier and batch size.

• ServeFlow: A fast-slow model architecture that recognizes a key insight: inference time across models can differ by up to 141×, while inter-packet waiting time is up to 6-8 orders of magnitude higher than inference time. ServeFlow routes traffic through a “fast” model first, assigning flows to a “slow” (more accurate) model only when the fast model’s predictions show high uncertainty. The system achieves a 40.5× speedup on median end-to-end serving latency while maintaining comparable accuracy, processing over 48.5k new flows per second on a 16-core CPU—matching the order of magnitude of flow rates observed on city-level network backbones.

• Cruise Control: A system-driven approach to dynamically select the best ML model for network traffic analysis based on real-time system performance and network load. Rather than selecting an optimal model offline, Cruise Control pre-trains several models with different accuracy-cost tradeoffs and continuously adapts model selection based on lightweight signals representing the system’s current traffic processing state. Evaluation on real-world traffic analysis tasks shows Cruise Control improves median accuracy by 2.78% while reducing packet loss by a factor of four compared to offline-selected models.

• CATO (End-to-end Optimization): A framework that jointly optimizes both the predictive performance and the systems costs of ML-based traffic analysis pipelines. CATO leverages multi-objective Bayesian optimization to efficiently identify Pareto-optimal configurations across feature selection and packet capture depth, then automatically compiles end-to-end optimized serving pipelines. Compared to popular feature optimization techniques, CATO provides up to 3,600× lower inference latency and 3.7× higher zero-loss throughput while simultaneously achieving better model performance.

Together, these systems represent a fundamental shift in how we think about ML deployment for networking: from static, one-size-fits-all models to adaptive systems that intelligently balance accuracy, throughput, and latency based on real-time conditions.

Synthetic Data Generation: Generative AI for Networks (2023-Present)

Which brings us to our current focus: generative AI for networks. The challenge that motivated this work was fundamental—how do we train better ML models when we can’t easily share network traffic data due to privacy concerns and data staleness?

In the GATEAU (Generative AI for Traffic Engineering and Network Understanding) project, we’ve been developing tools that use generative AI to create realistic, privacy-preserving synthetic network traffic:

• NetDiffusion applies diffusion models—the same technology behind Stable Diffusion for images—to generate high-fidelity, protocol-compliant network traffic. It doesn’t just produce flow statistics; it creates actual packet captures (.pcap files) that work with standard tools like Wireshark and tshark. Critically, models trained on NetDiffusion synthetic data outperform those trained on data from existing GAN-based approaches. As we noted in our recent announcement, “NetDiffusion represents a breakthrough in generating realistic, protocol-compliant traffic, overcoming long-standing data access challenges and opening new possibilities for AI-driven security and network traffic analysis.”

• NetSSM uses state space models to generate multi-flow network traces, capturing temporal dependencies across concurrent flows.

Looking Ahead

Machine learning has become essential for modern network management—from detecting intrusions to optimizing performance to ensuring quality of experience. But the field faces a data crisis:

• Privacy regulations restrict data sharing

• Network protocols and applications evolve rapidly

• Collecting and labeling network traces is expensive

• Datasets become stale quickly

Synthetic data generation addresses these challenges head-on. High-quality synthetic traffic can supplement real data, handle class imbalance, and enable experimentation without privacy concerns.

Announcing netml.io

netml.io formalizes and extends this research program.

Ultimately, we aim to make it easier for researchers and practitioners to work on ML problems in networking by providing easier access to datasets and code that we have developed throughout the years, so that we can grow the community of researchers working in this area and continue to advance the discipline.

What’s Next

We’re actively working on:

• Extending generative models to more protocols and network conditions

• Real-time deployment of ML models for security and performance monitoring

• Federated learning approaches that enable collaborative training without sharing sensitive data

• Understanding and addressing fairness and equity issues through ML-based Internet measurement

Join Us

This work has always been collaborative, involving talented students, postdocs, and industry partners. If you’re working at the intersection of ML and networking—in security, performance, traffic engineering, or measurement—let’s connect.

The networks of the future will be intelligent. The netml.io project is dedicated to advancing this future together, as a community.

One of my recent side projects has been building an MCP (Model Context Protocol) server for my Elektron Digitakt—essentially teaching Claude to control my sampler and drum machine through conversation.

It’s been an amazing playground for exploring how LLMs handle complex, domain-specific tasks. But it’s also exposed some fundamental challenges in how these systems reason about context, state, and when to think versus when to act.

Last week, I hit a particularly instructive bug: an infinite loop that perfectly captured the overthinking problem plaguing current LLM agent systems.

The Bug: The MCP “Infinite Loop”

I was trying to automate parameter changes over a 16-bar musical phrase. The system kept passing an empty dictionary. Then it would detect the error, attempt to fix it, fail to fix it correctly, detect the same error again, attempt another fix—forever. Claude Desktop would have looped indefinitely if I hadn’t manually intervened.

The actual problem? The automation was only populating the first 4 bars of the dictionary, leaving bars 5-16 empty. I could hear this—I’d asked for something to happen over 16 bars, and it only happened over 4. The 16-bar loop played, but the parameter automation stopped after the first 4 bars.

How I Debugged the MCP

Here’s roughly what the debugging process looked like:

1. Desktop Claude hit the infinite loop

2. I stopped it and switched to Claude Code

3. I asked: “Here’s what’s happening. Tell me what’s causing this infinite looping.”

4. Claude Code suggested a specific data structure to pass

5. I went back to Desktop Claude and said: “Here’s the data structure I want you to pass. Try that.”

6. It sort of worked

7. I asked Desktop Claude: “Tell me what would help you not infinite loop.”

8. It responded: “What would help me is an accurate description of this function in the MCP function description.”

9. I went back to Claude Code and worked on improving the function description

10. Finally, it worked

The whole process took about an hour. Without AI assistance, it would have taken a day.

But here’s the key insight: I had to know what was causing the problem at each step. I had to notice: “You’re overthinking a simple query,” or “You’re in a loop,” or “Show me the dictionary structure.”

I had to reason about why parameter automation over 16 bars was only executing over 4 bars, connect that to the empty dictionary complaint, and guide the debugging process.

Domain Knowledge About Outputs is Critical

Having a tangible, audible application made learning faster. This reminds me of my undergrad EE days—there’s something powerful about debugging something you can hear versus just looking at code on a screen.

When I hear a 16-bar loop but only hear parameter changes in the first 4 bars, the bug becomes obvious. The domain knowledge becomes a debugging superpower.

Enter Semantic Router

This experience maps perfectly onto a research project I’ve started to explore with a Ph.D. student. He recently pointed me at the Semantic Router project from the Aurelio Labs team, which tackles exactly these problems in agentic systems.

The main problem: current LLM systems overthink simple queries and underthink complex ones.

I encounter both failure modes constantly:

• Overthinking simple queries: I ask Claude to summarize something that’s right in front of it in context. Instead, it goes off to fetch additional sources. “No, it’s right here. Stop. You’ve already done it.”

• Underthinking complex queries: The music automation bug is a perfect example. The system needed to reason more carefully about state across a 16-bar phrase but instead rushed to a broken solution and then got stuck in a loop.

Semantic Router addresses this by using application state to enable correct inference. The project focuses on:

• Cache persistence across multiple stages of the same LLM call

• Failure recovery from incorrect MCP server responses

• Request routing to ensure sub-requests from the same session hit the same endpoint

• Query classification to allocate the right computational resources

What’s Missing: Domain-Specific Knowledge

Current semantic routing abstractions classify queries as “simple versus complex.” But they don’t yet leverage application-specific knowledge.

In my music MCP debugging session, the relevant signal was: “Only 4 out of 16 bars were populated.” That’s music-specific knowledge, and something I could hear directly from the output.

If I could pass that insight and domain-specific knowledge to the LLM or to a routing system in the right interface, it might be able reason correctly from the start.

While I encountered this mismatch in my own experience, it is evident how it can also rise in other domains:

• Art generation: A query specifies “warm earth tones” but the model generates cool blues and purples. The color palette constraint is domain knowledge that should guide inference.

• Network debugging: A query about packet loss should trigger different reasoning than a query about DNS resolution, even if both are phrased as “connection problems.”

• Code debugging: Information about which data structures are populated or empty (like my dictionary) should influence how the LLM approaches the problem.

Research:
Debugging Agents with Domain Knowledge

The opportunity here is to bridge semantic routing with domain-specific knowledge extraction:

1. Automated domain signal extraction: Can we automatically extract relevant domain signals from queries (like “16 bars” in my music example) and use them to guide inference?

2. User-in-the-loop feedback: When I told Claude “you only populated 4 bars,” that’s a valuable debugging signal. Can we formalize interfaces for users to provide this kind of application-specific feedback?

3. Multi-modal domain knowledge: In my case, the audible output was the debugging signal. For network measurement, it might be latency graphs. For image generation, visual output. How do we incorporate multi-modal domain signals into semantic routing?

4. MCP-to-MCP debugging: I developed a pattern of bouncing between Desktop Claude (executing MCP calls) and Claude Code (debugging the MCP server code). Can we formalize this pattern? Passing error messages and context between different Claude instances dramatically sped up debugging.

Why This Matters for Education and Research

This work sits at an interesting intersection.

From an education perspective, these experiences reinforce why reasoning skills remain critical—I can immediately tell when the LLM is going off the rails. From a research perspective, there’s fundamental ML work to be done on how domain knowledge should flow into semantic routing systems.

Agentic workflow papers at the upcoming HotNets workshop this week are exploring related ideas—using LLM agents for network measurement research, for example. But I suspect the real breakthroughs will come from figuring out how to inject domain expertise into the routing and reasoning process itself.

Putting together an agentic workflow is the easy part. Figuring out how to debug it when the outputs aren’t as expected is the true challenge.

Try It Yourself

If you’re building MCP servers or working with agentic LLM systems, I highly recommend:

1. Choose a domain with tangible, observable outputs (music, images, network measurements)

2. Pay attention to when the LLM overthinks versus underthinks

3. Document the domain-specific signals that help you debug

4. Experiment with bouncing between different Claude instances for debugging

The bugs are frustrating, but they’re also revealing fundamental limitations in how these systems reason. And that makes them excellent research opportunities.

What domain-specific knowledge do you wish you could pass to your LLM agents? Let me know in the comments or reach out—I’d love to hear about your debugging experiences.

I was asked to give a guest lecture for Family Weekend at the University of Chicago this past weekend. Instead of diving into network protocols or cybersecurity frameworks, I picked up my guitar.

I couldn’t decide whether to talk about generative AI, policy, content moderation, so I decided to combine all of these topics and use another passion of mine—music—as the lends to pose various questions about the role of AI in creation.

I gave a talk about AI, creativity, and copyright—topics that have been swirling around in my head as I’ve watched these tools reshape everything from my students’ coding habits to my own songwriting process. And I figured the best way to cut through all the hype and anxiety was to run an experiment.

The Hook: Can You Spot AI in a Song?

The main hook for the lecture was that I played excerpts of five songs for the audience. All of them I wrote, for some definition of the word “wrote”. (For the record, I generally do not use much AI in my own songwriting, typically stopping at #2 on this spectrum below, but for this lecture, I used Suno to create a couple of songs and then learned them on my guitar for the purposes of the experiment/demonstration).

The central question: which ones involved AI, and how much?

Song 1: Pure human. I wrote this one unassisted—lyrics, melody, chord progression, etc., with no AI anywhere in the process.

Song 2: LLM lyric assist. I had most of the song written, but there I had a particular couplet that just wasn’t landing. I had the imagery but I didn’t have quite the right words. So I described what I was going for to ChatGPT, and it gave me various images like “cobblestones”—exactly the mood I wanted but couldn’t articulate. AI helped me find words and imagery that I ultimately selected to integrate into my lyrics. In my view, this was very similar to what Jeff Tweedy describes as a “word ladder” in his book How to Write One Song. They main difference is that instead of having completely random words, I asked for words that matched the theme and lyrics that I had already largely composed.

Song 3: Claude completes the progression. For this one, I took a D minor 6 - D major progression and fed the beginning of the chord progression into Claude. “Finish this for me,” I said. It gave me a really cool sounding Bb maj7 to A7 progression to complete the progression and even explained to me. Everything else—the melody, the lyrics, the arrangement, and even the other progressions in the song—was mine. But I wrote a lot around this foundation.

Song 4: Suno from my lyrics. I took lyrics that I wrote for a completed song, threw them at Suno, and said “make me a song with these lyrics”, generally describing a lo-fi dream-pop vibe. Then I learned it and performed it. The lyrics were mine. The music, melodies, and chords? That came from the model. But the performance, the interpretation—that was all human again.

Song 5: Full Prompt-Based AI. I prompted Suno with nothing but a vague idea and let it generate everything—lyrics, melody, arrangement. Then I learned it well enough to perform it. This is what people typically think about when we hear the phrase “AI-generated” , though even here, I had to interpret and embody what the machine created (“interpolation” as it is sometimes called in music).

What People Heard

Most people correctly identified Song 5 as AI-generated—I think partly because I didn’t know it as well, and partly because there was something missing in the emotional delivery. Several people pegged Song 2 as AI because of the lyrics, which is interesting given that only a couple of words came from AI, but people thought it was AI-generated because the lyrics felt less “personal”.

Almost nobody identified Song 3, the one where Claude completed my chord progression. And that makes sense—a chord progression is pattern-matching, it’s statistics, it’s “what usually comes next.” AI is actually pretty good at that. This was a good hook for the next part of my lecture were I talked about instances of many other artists, from Ed Sheeran to Taylor Swift, writing songs based off of extremely common chord progressions.

AI as Normal Technology in Creation

Here’s what struck me as I was preparing this exercise: we keep talking about “AI-generated” content as if it’s a binary. But, having now experimented with creation along this spectrum, I’ve concluded that this is a false dichotomy.

I’ve been thinking a lot about a concept called “AI as normal technology,” coined by Arvind Narayanan at Princeton. His argument is simple but profound: AI is just technology.

We panicked when calculators came along—nobody will learn math anymore! We panicked when drum machines were invented—real drummers are finished! We panicked when digital audio workstations made it possible to record and mix at home—goodbye, studio engineers!

None of those predictions came true. We still have mathematicians. We still have drummers. We still have studio engineers.

What changed was that the technology became a tool that professionals use, and the people who refused to learn the new tools got left behind.

Interesting questions of course are up for debate as far as our respective roles in creation. When I had Claude complete a chord progression, was that “AI creation” or was it more like using a calculator? What about Song 2, where ChatGPT gave me two words that unlocked an entire verse I’d been struggling with for days? When I threw my lyrics at Suno, was the result mine because the words were mine, or was it Suno’s because the music was its? What about the last one, where Suno did “everything”? Or, did it? I still had to prompt the model and ultimately learn the song. What if I had pulled stems from that last song and cut them up or remixed them? (Artists are actively doing just that these days.) And is that any less creative, or just a different form of creativity with new tools?

We’ve Been Here Before

The music industry has wrestled with these questions for decades, and the outcomes have shaped entire genres.

Take hip-hop. In the early days, sampling was the art form—”Rapper’s Delight” sampled Chic’s “Good Times” in 1979. But then came Grand Upright Music, Ltd. v. Warner Bros. Records in 1991, where Biz Markie sampled Gilbert O’Sullivan’s “Alone Again (Naturally)” without permission. The judge’s ruling was blunt: “Thou shalt not steal.”

That decision fundamentally changed hip-hop. Suddenly, sampling became expensive and permission-based. Artists had to clear every sample, and rights holders knew they could charge for it. The creative process changed in response to the legal landscape. Hip-hop didn’t die—it evolved. But the law shaped what was possible.

Or consider Ed Sheeran’s lawsuit with Marvin Gaye’s estate over “Thinking Out Loud” and “Let’s Get It On.” Sheeran won, partly by demonstrating that chord progressions themselves can’t really be copyrighted—there are only so many combinations that sound good to human ears. He played twenty different songs back-to-back in court, showing how they all used similar progressions. The question wasn’t whether the songs sounded similar (they did), but whether that similarity constituted theft or just the natural constraints of music theory.

Now compare that to what Taylor Swift is doing. If you listen to her recent albums, you’ll hear echoes everywhere—the Pixies’ bass line in one song, Jonas Brothers vibes in another, Jackson 5 in yet another. Music critics call it “interpolation.” It’s credited, it’s acknowledged, but it’s clearly building on what came before. At what point does “inspired by” become “copied from”? And would we even be asking that question if she weren’t using such recognizable sources?

The Industry Response

The platforms are trying to figure this out in real-time. Spotify sees 100,000 tracks uploaded every day now—most of them AI-generated. They account for less than 1% of streams (Taylor Swift has the rest), but they create real problems.

Do you demonetize AI-generated music? Sounds simple, except it creates perverse incentives. Playlist curators get paid based on the royalties of the artists they include. If AI music is free to use and generates no royalties, suddenly there’s no economic reason to include real artists in your playlists. You hurt the humans you were trying to protect.

That’s why the industry is converging on disclosure rather than outright prohibition. There’s a consortium now—DDEX is one of the standards they’re building on—that allows artists to self-report what went into a track. “I wrote the lyrics, my friend played drums, AI generated the guitar part.” The idea is granular transparency: let listeners know what they’re hearing, let platforms make informed decisions, and let the market sort it out.

But this only works if people actually disclose. And it only works if we can agree on what counts as “AI-generated.” Is my Song 3, where Claude completed two chords, AI-generated? What about Song 2, where ChatGPT gave me two words?

Story: That Time AI Helped Make
My Own Music Sound More Human

During the lecture, I recounted a moment in my recent music-making that perfectly captures where we are right now.

I was programming a drum track on my Digitakt, and I asked Claude to “improve it”. It did and it sounded better, and I asked it why. What it told me taught me something surprising.

Claude told me: “Human drummers never hit exactly on the beat, and they never hit with exactly the same velocity. So I shifted some notes slightly off-grid and varied the velocities.”

I was talking to a machine to learn how to sound less like a machine.

This is the uncanny valley we are currently traversing: AI tools are good enough to be useful, sophisticated enough to mimic human imperfection, but not yet advanced enough that we’ve figured out the etiquette and ethics of using them. My students can generate code they don’t understand. I can generate chord progressions I didn’t conceive. Artists can generate entire songs they never played.

How should we think about this? I can tell when the code is wrong because I spent years learning to code. I can tell when a chord progression works because I’ve studied music theory and played enough songs to develop an ear. The technology is a force multiplier, but only if you have something to multiply.

Musicians Already Borrow from Other Humans.
How Is Borrowing from AI Different?

As I told the audience, I’ve found that AI is terrible at writing lyrics. Why might that be? Because lyrics are emotion. They’re personal experience. They’re the thing that makes someone listen to a song and say “oh, that’s about something real.” That’s the human element that—so far, at least—the machines can’t fake.

But chord progressions? Hooks? The ear actually likes things that sound familiar, even simple. We like patterns. We like statistical regularity with just enough variation to stay interesting. That’s literally what these models are built to do.

So now we’re in this gray area where Taylor Swift can interpolate “Where Is My Mind?” by the Pixies into her own song, and we call it inspiration. But if I use AI to complete a chord progression that follows patterns drawn from thousands of existing songs, is that theft? Transformation? Or just another tool in the creative toolkit?

The Hard Questions

The question of whether AI training on copyrighted works should be allowed is the subject of much active litigation. There was a ruling last week in the UK courts saying AI models don’t violate copyright because they don’t actually make a copy—they train on data, extract patterns, then discard the original.

As the courts grapple with applying old copyright laws to this new technology, the deeper questions aren’t legal—they’re philosophical and practical:

• When does “inspired by” become “copied from”?

• At what point does a tool become an active collaborator, and how does that matter for attribution—not only of the model, but also of anything that went into the process of creating that model?

• Should we restrict AI tools from students (or as part of our own learning process) until we first learn to do things “the hard way”?

That last question is one we’re actively grappling with in computer science education. I learned to code by writing everything from scratch. That means when an LLM spits out code that doesn’t meet my specifications I can typically spot it. I can work with the machine to fix it because I understand what it’s supposed to do.

But what about students who only ever learn to prompt? What about the next generation of musicians who never learn music theory because the tools can do it for them? Are they going to be like someone using a calculator without understanding arithmetic—unable to tell when 2+2=5? (Yes, that is a Radiohead reference.)

What I Think (For Now)

Here’s where I’ve landed, at least this week: AI isn’t going away.

It’s not going to replace artists or coders or writers, but it’s going to change what those jobs look like. Just like photography didn’t kill painting, and drum machines didn’t kill drummers, and DAWs didn’t kill studio engineers.

The people who thrive will be the ones who understand both the craft and the tools. The ones who can tell when the machine is giving them something useful versus when it’s spitting out statistically plausible garbage. The ones who bring something distinctly human—emotion, experience, judgment—that the machines can’t replicate.

When I played those five songs, many of people’s favorite songs were in the “grey zone”. Many felt the fully AI song lacked emotion—but the other four modes, where there was a distinct human element in creation, were very hard for humans to distinguish.

I think that’s the future (or increasingly, the present): the future of creation will increasingly be less of a question of humans or machines, but rather humans with machines, and figuring out where the boundary between tool and collaborator actually lies.

Perhaps now the most important skill we can teach—in computer science, music, or anything else—is recognizing where that boundary lies and how to make intentional decisions about where to draw that line for various projects.

This post is based on a talk I gave for a model class at University of Chicago’s Family Weekend. If you want to hear more about AI, creativity, copyright, and the messy intersection of technology and art, stay tuned. I’m still figuring this out myself.

Subscribe now

I recently sat down with a student reporter from The Chicago Maroon to discuss how I’m incorporating AI tools into my teaching.

As someone who’s been teaching computer science for more than 20 years, I’ve watched large language models emerge as transformative tools in education. Below I talk about my philosophy towards how I encourage students to think about them in my own classes, as well as how I’ve been using AI to enhance my own pedagogy and classroom delivery.

My Philosophy: AI as Normal Technology

My approach is straightforward: these tools exist, students will use them in their careers, so we need to teach them how to use them effectively. As I mentioned in the interview, there’s an excellent article called “AI as Normal Technology” that captures this philosophy perfectly. This is just another tool—like IDEs, Stack Overflow, or GitHub before it. It’s potentially more powerful, but fundamentally, it’s another instrument in the problem-solving toolkit.

My AI Policy

I fully encourage the use of AI tools in all my courses. Here’s the core principle I share with students: You must understand what you’re turning in. I’ll ask you about it on exams, in discussions, and during assessments. Use whatever tools help you learn and complete your work, but you’re responsible for understanding the output. I also require attribution—tell me what assistance you used.

The classroom is a simulator for the real world, and in the real world, these tools are everywhere. Ignoring them doesn’t serve our students well. We need to acknowledge the environment we’re operating in and teach accordingly.

Here is what I currently say in my syllabus for my courses.

Use of AI Tools and Large Language Models

I acknowledge and even expect that you will use large language models (LLMs) and other AI tools for assistance in completing assignments. This is perfectly acceptable and encouraged. However, you are expected to understand the output these tools generate.

AI-assisted coding improves efficiency, but only if you understand its outputs. Just as I would not be able to evaluate an LLM-produced essay in philosophy if I didn’t understand the subject matter, these tools do you no good if you cannot understand, evaluate, improve, debug, and iterate on their output.

Therefore, you are allowed to use AI tools to help automate anything you are confident that you understand well enough to implement manually yourself. This approach best simulates the real world, where you will inevitably need to know how to use these tools well and to your advantage, but you will ultimately be responsible for understanding the software and code that you produce.

When using AI tools, please acknowledge their use in your submissions and be prepared to explain and defend any code or solutions you submit.

How I Use AI to Make Teaching More Efficient

I also have been using AI to improve the delivery of my courses. Here are the specific ways I leverage AI tools to enhance my teaching:

1. Automated Class Notes

I take transcripts of my lectures and use LLMs to generate summaries and notes for students. These get posted immediately after every class, giving students a resource they can reference while the material is fresh. For example, here’s the agenda.md file from my Machine Learning for Computer Systems course—an automatically generated “what did we cover” summary for each class session.

2. AI-Assisted Exam Creation

I use past exams and instruction files with LLMs to generate draft copies of exams. Even better—I share the prompts with students so they can generate their own practice exams based on past materials and covered topics. This empowers them to take control of their preparation. You can see examples of past exams and the precise instructions I provide to the LLM for exam generation in my course repository.

3. Discussion Preparation

For classes with reading responses, I use LLMs to help organize student submissions. This helps me identify themes, generate discussion notes, and prepare to lead more engaging class conversations. To date, I have organized responses thematically around three topics: (1) requests for technical clarification (allowing me to focus my lecture towards details that students actually want to hear; (2) points that could be teed up for general discussion (helpful for class discussion, breakouts, etc.); (3) case studies that people want to hear more about (helping me go do additional research on “current events” that I can speak about in class to bring more real-world examples to class.

4. Reducing Setup Friction in Assignments and Labs

AI has made it easier to assign more hands-on work. Much of the “scaffolding” for assignments—the tedious setup that doesn’t directly relate to the concepts I’m teaching—can now be automated. This means students spend time on the concepts that matter rather than configuration headaches.

The Real Risk: Not Understanding

When asked about the greatest risks of AI in the classroom, my answer is simple: people not understanding what they’re turning in. That’s why my approach emphasizes comprehension over prohibition. Students can use these tools, but they must be able to explain their work, defend their choices, and demonstrate understanding on written exams.

Computer Science has Never Been About Coding

A CS degree has never really been about writing code—it’s been about abstraction, specification, testing, software engineering, algorithms, and data structures. If anything, AI makes these higher-level skills even more important.

We’re moving toward a world where people aren’t writing much code anymore. Entry-level isn’t “junior developer” anymore—it’s project manager, software engineer focusing on testing and specification. The “grungy and inaccessible” parts are becoming automated, which means the differentiator is exactly what a computer science degree teaches: how to think about systems, specify requirements, test effectively, and reason about complex problems.

I believe the CS degree is actually becoming more important, not less. These models aren’t capable of higher-level reasoning—they’re good at automating tasks we can specify for them. Understanding how to specify, test, debug, and reason about software remains fundamentally human work.

The Bottom Line

We can’t deny the existence of technology. We have to teach within the world as it is, not as we wish it were. That means embracing AI tools, teaching students to use them responsibly, and focusing on the enduring skills that make computer scientists valuable: clear thinking, specification, testing, and the ability to reason about complex systems.

This post is based on an interview conducted for The Chicago Maroon in November 2025.

Subscribe now

The Internet feels vast and distributed, but the reality is far more concentrated than most people realize. In our recent presentation to the IETF’s Decentralized Internet Infrastructure Research Group (DINRG), we shared findings that reveal just how dependent the modern internet has become on a handful of organizations—and why that matters for everyone who relies on the web.

The Main Finding: Extreme Consolidation

Our research paper, “Measuring the Consolidation of DNS and Web Hosting Providers,” analyzed the Tranco top 1 million domains plus the top 10,000 sites from six global vantage points. What we found was striking:

Two organizations—Cloudflare and Amazon—each host over 30% of popular domains for both DNS and web hosting services. When you expand to the top five providers (adding Akamai, Fastly, and Google), these organizations control 60% of index pages in the top 10,000 websites and host the majority of external page resources.

Perhaps even more concerning is the fact that over 70% of top domains rely on a single organization for DNS resolution. This means that when one of these providers experiences an outage, the impact ripples across a massive portion of the internet.

A Global Phenomenon

One might assume that Internet infrastructure would vary significantly by region, with different providers dominating in different parts of the world. Our measurements from six globally distributed vantage points revealed otherwise: the consolidation trend is remarkably consistent worldwide. The same major players dominate regardless of where you’re accessing the internet from.

This wasn’t always the case. The internet was designed to be resilient through distribution and redundancy. Yet economic forces, economies of scale, and the complexity of modern infrastructure have driven websites and services toward a small number of hyperscale providers.

Our Measurement Pipeline

To understand consolidation, we built a comprehensive measurement pipeline that:

1. Identified authoritative nameservers for DNS hosting across all domains

2. Detected web content hosting providers for both index pages and external resources

3. Mapped infrastructure to organizations rather than just individual autonomous systems (AS)

4. Measured from multiple vantage points to capture global patterns

The distinction between measuring by organization versus by AS is critical. Amazon, for example, operates multiple autonomous systems (Amazon-02, AMAZON-AES, etc.), but consolidating these under the organizational umbrella reveals the true extent of concentration.

DNS and Web Hosting is Consolidated

Looking at our nameserver analysis, Amazon and Cloudflare dwarf all other providers. In the top 10,000 domains:

• Amazon hosts over 2,500 domains for DNS (with most being reachable)

• Cloudflare serves approximately 1,300 domains

• The next tier (Akamai, Google) each serve only a few hundred domains

For web hosting, the picture is even more dramatic. Among the top 100 websites, Cloudflare alone hosts around 70% of domains. As you move down to the top 10,000 sites, the major five providers (Cloudflare, Amazon, Akamai, Fastly, Google) maintain consistent dominance at around 40-50% market share each.

Three Risks of Consolidation

1. Reduced Resilience to Outages

The consolidation of infrastructure means that single points of failure now affect enormous swaths of the Internet. We’ve already seen this play out:

• The 2016 Dyn DDoS attack took down major websites across the internet

• The 2021 Facebook BGP incident made Facebook and its properties unreachable worldwide

• Routine AWS degradations affect thousands of dependent services

As one participant in at the DINRG discussion noted, the October 2025 AWS outage was caused by a race condition in automated DNS updates—a seemingly small technical issue that cascaded across services like DynamoDB, EC2, and network load balancers.

When infrastructure is this consolidated, these “unusual diseases” in one provider can become internet-wide epidemics.

2. Increased Potential for Censorship and Content Control

Beyond technical failures, consolidation creates concerning dynamics for online speech and content moderation. Large hosting providers exercise significant discretion over what content gets hosted and what doesn’t.

As Andrew Campling astutely pointed out in the Q&A, this consolidation has profound implications for free expression. We need only look at cases like Kiwi Farms—where decisions by a handful of infrastructure providers about whether to host particular content effectively determined whether that content could exist online at all—to understand the stakes.

When the majority of websites depend on the same five organizations for hosting and DNS, those organizations become de facto gatekeepers of online speech. Whether one agrees or disagrees with specific content moderation decisions, the concentration of this power in so few hands represents a fundamental shift from the internet’s original distributed architecture.

3. Privacy and Surveillance Concerns

With so much traffic flowing through a small number of providers, these organizations gain unprecedented visibility into internet usage patterns. The consolidation creates what amounts to surveillance chokepoints, where a handful of companies can observe—and potentially be compelled to share—information about vast portions of internet activity.

Extending the Research

The discussion following our presentation highlighted important directions for future work.

Availability Zones and Backend Dependencies

Brian Trammell raised a crucial limitation of our current study: we measured front-end behavior and didn’t provide visibility into back-end dependencies within cloud providers. A website might be “hosted by Amazon,” but which availability zones? What happens when there’s an outage in US-East-1 specifically?

Future research should incorporate IP geolocation to analyze dependencies within cloud providers’ infrastructure. Are sites truly distributed across availability zones, or do the consolidation patterns go even deeper than our organization-level analysis suggests?

Building on ICANN’s Work

Christian Huitema pointed us to ongoing consolidation studies at ICANN, which are examining similar questions about DNS infrastructure. Rather than duplicate effort, we’re eager to collaborate. Our measurement pipelines and data are publicly available, and we’d like to work with ICANN and others to create an ongoing “consolidation monitor”—a dashboard that tracks these trends over time and makes the data accessible to researchers, policymakers, and the public.

New Challenges: ECH and Encrypted DNS

As the internet evolves, new protocols like Encrypted Client Hello (ECH) will obscure some of the signals we used in our measurements. Future studies will need to adapt methodologies to maintain visibility into consolidation trends even as more infrastructure becomes encrypted and opaque.

What Can Be Done?

The concentration of internet infrastructure didn’t happen by accident, and it won’t be reversed overnight. But there are concrete steps the community can take:

1. Establish ongoing monitoring of consolidation trends with public dashboards and regular reporting

2. Develop resilience techniques specifically designed for data center and cloud-wide outages, not just individual server failures

3. Create mechanisms for multi-homing that make it practical for organizations to distribute across providers

4. Examine policy implications of infrastructure consolidation for competition, speech, and internet governance

5. Build guardrails for automation as AI and automated systems increasingly manage critical infrastructure

An Invitation for Collaboration

All of our code, data, and measurement metrics are publicly available. We’re committed to transparency in this research because we believe consolidation is a question that affects everyone who uses the internet. It’s not just an academic curiosity—it shapes the resilience, openness, and character of the global network we all depend on.

If you’re working on related questions, whether at ICANN, within a major provider, at a research institution, or as an independent researcher, we’d welcome the opportunity to collaborate. The internet’s future depends on our collective ability to understand and address these structural shifts.

Thank You to DINRG for Re-surfacing this Work

I want to extend my sincere gratitude to the hosts and participants of DINRG for the opportunity to present this work and for the thoughtful questions and suggestions that emerged from our discussion.

The IETF community’s commitment to understanding and improving internet infrastructure is exactly the kind of collaborative effort needed to tackle these challenges.

Special thanks to Brian Trammell for pushing us to think about availability zones and backend dependencies, to Christian Huitema for connecting us with ICANN’s parallel research efforts, and to Andrew Campling for highlighting the critical implications for free expression and online speech.

Read the full paper: Measuring the Consolidation of DNS and Web Hosting Providers

Authors: Synthia Wang, Kyle MacMillan, Brennan Schaffner, Nick Feamster, Marshini Chetty

Access our data and code: (forthcoming, stay tuned)

Questions, comments, or interested in collaborating? Please reach out! Subscribe to this newsletter, or reach out to me directly.

(And really, if you’re still using Overleaf, you might ask yourself why...If you want to make your life difficult, go right ahead, but VS Code + Latex Workshop does everything Overleaf does but is a thousand times better in every other way.)