A SIGCOMM Workshop Turns AI Coding Agents Into an Argument for Teaching Judgment Over Protocols

Bruce Davie helped design Multiprotocol Label Switching, the technology that still routes traffic through much of the internet’s backbone. So when he spends a day at an academic workshop arguing that networking students need to learn less about how protocols work, not more, it’s worth asking what he actually means. The occasion was the SIGCOMM Education Workshop 2026, and the conclusion Davie brought back, laid out in a column for The Register, is that AI coding agents make teaching judgment and system design tradeoffs more important, not less, precisely because agents are now so good at generating the protocol-level implementation details that used to anchor a networking course.

A Workshop Built Around a Provocative Title

The event’s formal name is Networking Education for the AI Generation, or A4NE, a full-day hybrid workshop held August 17, 2026 at the University of Colorado Boulder alongside the main SIGCOMM conference. It was organized by Matthew Caesar (University of Illinois), Vasanta Chaganti and Ranysha Ware (both Swarthmore College), and James F. Kurose (University of Massachusetts Amherst). The organizers’ own framing was blunt: “the AI revolution demands we rethink networking education from the ground up,” with an explicit goal of building “frameworks for AI integration that deepen understanding rather than shortcut learning.”

Davie was an unusually skeptical attendee by his own admission. He writes that he has “repeatedly voiced my skepticism about AI in education,” and draws a pointed parallel to his own student days in the mid-1980s, which were followed by an AI winter. He attended with Larry Peterson, his co-author on Computer Networks: A Systems Approach, the open source networking textbook whose seventh edition the two are currently writing. Peterson is the Robert E. Kahn Professor Emeritus of Computer Science at Princeton University, a National Academy of Engineering member, and the researcher behind PlanetLab, one of the more influential internet-scale testbeds of the last two decades. Davie himself, per his own career record, led the architecture team that built MPLS as a Fellow at Cisco Systems, was Chief Service Provider Architect at Nicira, and became a CTO at VMware after Nicira’s acquisition. He’s also a former chair of ACM SIGCOMM itself, the professional body running the workshop.

That pedigree matters for the argument that follows. This isn’t an outside observer speculating about how AI might change engineering education. It’s two people who wrote one of the field’s longest-running open source networking textbooks, trading ideas in real time with the author of the field’s best-selling introductory networking textbook (Jim Kurose, co-author of Computer Networking: A Top-Down Approach with Keith Ross), trying to figure out whether their life’s work still teaches the right thing.

The Case for Problems Over Protocols

The workshop’s throughline, according to Davie’s own account and a companion reflection posted to the Systems Approach site, kept returning to one idea: teach the problem space a protocol is solving, not the protocol’s implementation details. Peterson opened the relevant session with QUIC as the motivating example, a protocol new and complex enough that it’s still routinely absent from introductory networking courses. His position, which Davie shares, is that a student who understands the underlying principles, reliable transmission, congestion control, end-to-end security, should be able to make sense of QUIC by relating it to concepts they already have, rather than needing to learn it as a standalone artifact.

Davie extends this to a harder case: BGP, the protocol that holds internet routing together and that he calls “famously complex.” His claim is that a student can learn, in one semester, why BGP exists and what design problem it solves, without coming anywhere close to being able to configure real BGP policy for an internet service provider. The pedagogical bet is that a semester spent on the problem/solution model, working through a series of problems and the tradeoffs each solution makes, builds a mental model students can keep extending on their own, long after the course ends and long after any specific protocol they studied has been superseded.

The Trouble With an AI That Can Talk About Networks

The AI angle sharpens rather than undercuts that argument, and this is where Davie’s piece gets more interesting than a routine pedagogy debate. He invokes a term coined decades ago in cognitive science and recently revived by roboticist Rodney Brooks: the symbol grounding problem. Brooks’ point, as Davie paraphrases it, is that large language models “manage symbols (words) but can’t connect those words to real objects,” which is why he’s skeptical that transformer-based models can reliably control physical robots operating in the real world.

Davie’s contribution is applying that same critique to networking itself. “A real understanding of, say, transport protocols and their relationship to end-to-end security is not the same as how the words written about transport protocols normally show up in a document,” he writes, adding that this “matches my experience from asking an LLM about QUIC and the Internet hourglass.” The Internet hourglass is networking’s own classic teaching device: a narrow waist, the Internet Protocol, that every layer above and below has to pass through, which is exactly the kind of architectural constraint a model trained on text about the hourglass can describe fluently without necessarily having any grounded sense of why the constraint exists or what breaks when you violate it.

That distinction, between producing text that correctly uses the vocabulary of a field and possessing a working model of the system that vocabulary describes, is the whole argument in miniature. An AI coding agent can now generate a plausible BGP configuration or a working QUIC client faster than most students could write one from a spec. What it can’t reliably do, at least not in a way anyone in that room was willing to trust, is explain why a particular tradeoff was made, or predict what happens when the same pattern gets applied somewhere it doesn’t belong.

Abstraction Is a Bet You Might Lose Later

The workshop also spent real time on abstraction itself, the practice of hiding implementation details behind a clean interface. Jim Kurose offered a modern example: using Zoom to teach students about application architecture, since a video call is no longer a simple end-to-end connection but a distributed system with real components sitting inside cloud datacenters. Abstracting away the client-to-datacenter connection details is reasonable if your goal is to understand how a multipoint control unit serves a large call. But Davie’s caution is that “abstracting away the details can lead to later problems,” and he points to the original design of HTTP running over TCP as the field’s textbook case of exactly that.

He doesn’t spell out the specific failure mode in the column, but it’s a well documented one: TCP’s strict, in-order byte stream means a single lost packet stalls every request multiplexed over that connection behind it, a problem known as head-of-line blocking. HTTP/1.1 absorbed that cost for over two decades before QUIC, built on UDP specifically to sidestep it, became the workshop’s own headline example of a protocol students now need a mental model to reason about. The lesson Davie draws is that abstraction is never free; it’s a bet that the hidden details won’t matter later, and teaching students to recognize when that bet is about to go bad is arguably more valuable than teaching them any single protocol’s current implementation.

Where AI Agents Actually Earn Their Keep in the Classroom

None of this makes Davie an AI-in-education skeptic across the board. MIT CSAIL’s Karen Sollins, a longtime networking researcher, offered what Davie flagged as a genuinely positive use case: since AI coding agents can now take on the grunt work of implementation, students could be given “bigger and more realistic system-building and measurement assignments” than a single semester used to allow, freeing class time for the harder questions, what constraints shaped this design, and what alternatives the original designers considered and rejected. Sollins separately described modeling her own systems classes on law school case studies, where the professor doesn’t lecture but assigns papers and lets students argue about the tradeoffs baked into a real design.

Both ideas point at the same reallocation: let the agent handle the parts of the assignment that are now cheap to generate, and spend the reclaimed time on the parts, judgment, tradeoff analysis, and design critique, that remain expensive because they require a grounded understanding the agent doesn’t have.

The Same Debate Is Already Live in Production

Sxz.io readers will recognize this argument, because it’s not confined to classrooms. It’s the same gap this site has covered on the production side of the industry all year. A Red Hat engineer’s warning that faster AI-assisted coding isn’t producing faster software delivery lines up with research showing developers consistently overestimate how much AI is actually helping them, the same mismatch between fluent output and grounded understanding Davie is describing in a classroom instead of a sprint retro. A workflow for reviewing AI-generated code before merging it exists precisely because static analysis tools miss the functional bugs an agent introduces with total confidence; static analysis, like an LLM describing a protocol, can use all the right vocabulary while missing what the code actually does. And a tutorial on writing an AGENTS.md file to guide coding agents is, in effect, an attempt to hand-feed a model the grounded context, the project’s actual constraints and conventions, that it has no other way of acquiring on its own.

The starkest version of the same failure mode showed up outside software entirely, when a hallucinated cargo manifest nearly triggered an armed boarding operation against a vessel that was carrying nothing of the kind, because a model reported a shipment that didn’t exist as confidently as it would have reported one that did. That’s the symbol grounding problem with the stakes turned all the way up: a system fluent enough to be trusted, operating with no grounded connection to the physical reality it was describing.

What Comes Next

Davie and Peterson’s own answer, beyond the column, is to keep writing. They describe actively developing new slides, labs, and exercises to accompany the seventh edition of their textbook, on the reasoning that a book alone was never going to be sufficient even before AI entered the picture, and is even less sufficient now. Davie closes his own piece by pointing readers toward SIGCOMM award winner Walter Willinger’s keynote on traffic modeling, and toward Rodney Brooks’ own recent essay on the four time scales that govern how new technology actually gets deployed, a piece Brooks published 16 days before the workshop and that Davie cites as a useful antidote to AI hype more broadly.

The uncomfortable version of the argument, for anyone building software rather than teaching it, is that the fix isn’t a better model. It’s the same fix Davie is proposing for a classroom: spend the time an agent frees up on understanding the system well enough to know when the agent is wrong.