Vibe-coding WebRTC - webrtcHacks

Skip to primary navigation<br>Skip to main content<br>Skip to primary sidebar<br>Skip to footer<br>Search this website Hide Search

Vibe-coding WebRTC

Well, that title is clickbait for Hacker News. The honest title would have been "using AI to tackle long-standing WebRTC issues."

Posts on webrtcHacks are rare these days, and in German we would say there are Unkenrufe that WebRTC is dead. It is not. It is the infrastructure for meetings, game streaming, and voice AI, as OpenAI laid out recently when they walked through how their stack handles real-time audio at their scale.

Posting less often here does not mean I stopped being involved in WebRTC. Over the past years I have gotten involved more deeply in libWebRTC than ever before, while also doing work across the wider ecosystem. These days I work on rtcstats.com, which does monitoring for WebRTC, with two friends, taking a break from corporate life.

I just fixed webrtc-internals gets throttled while in the background, an issue I had filed in 2022. We had been running into it more often from rtcstats.com users and it was becoming annoying. A "setInterval" in Javascript requesting WebRTC getStats got throttled after minutes of the page being in the background, which caused gaps in timeseries and graphs.

So I changed my attitude and said: "hey Claude, can you move this polling to C++?"

I reviewed the change, tweaked it (not much, it was solid), uploaded it, and reviewers liked it. It landed in Chrome 150.

I started using Claude and Gemini to be more efficient. Going deeper with libWebRTC work, some bigger projects like cryptex, taking what I built into Go, and chipping away at Firefox. While making more steps on my daily walks.

Keep out of my codebase, mate

The initial results of genAI on large codebases were "meh". libWebRTC and Chromium have conventions, internal abstractions, and reviewers who will (correctly) push back on anything that looks like "slop" or as if the author does not understand the current state and the long-term impact and responsibility. Google’s WebRTC team only started to work (publically) on Improving AI agent support for libwebrtc development at the end of 2025.

WebRTC and libWebRTC also have a lot of oral lore. Things you do and don’t do, and why things are the way they are, that nobody wrote down. People who have been around for years know it. New contributors do not. This is bad and we should get better at it, not because LLMs need it as input, but because humans do. The fact that LLMs would benefit too is a side effect (or a convenient excuse to sell AI to management).

So I continued the work I had been pushing for, which was consistency. I had picked up IWYU adoption in libWebRTC and followed up with clang-tidy. Operating on the gut feeling that we need to be more consistent and strict (and the reviewers felt the same). This paid off, honing those tools makes life easier for every tool that comes after, AI included.

Something changed in 2026. The models got better. Finally things worked as advertised.

AI coding works in libWebRTC and Chromium because both have a ton of guardrails. The culture encouraged more tests, including test-only changes, which I land quite often. Using AI works on top of decades of test discipline and the cultural expectation that you add to it rather than just consume it. And we finally got back release notes, a job nobody wanted to do in a long time!

cryptex: who can say "no" to more encryption

Some work is about timing. I have always been drawn to the networking parts of libWebRTC, like SRTP and DTLS, so when RFC 9335 shipped in 2023, it was on my radar. It closes a small but important gap in WebRTC’s cryptography by extending encryption to RTP header extensions, and the more crypto the merrier. One of the things this protects is the ssrc-audio-level extension, which is widely used in conferencing. It is a measure of how much audio energy is in this RTP packet with 20ms of audio data, and Jitsi uses it to determine who is speaking right now. It is one byte of information, sent unencrypted but authenticated. No known attacks exist, but we all are a bit uncomfortable doing this. OpenAI does not negotiate this extension at all.

libSRTP shipped support recently. We just got unblocked, why wait longer. I have been doing the libWebRTC side in SRTP cryptex support in libWebRTC. Some of it was IETF list questions where the right answer was not fully clear to me or my favorite reviewer. We both prefer a paper trail for accountability. Those came out of a pion conversation, and the answers fed back into the libSRTP work.

What it actually takes to deliver this kind of change is driving in multiple venues with different stakeholders, taking lessons from one codebase to another, and improving the specification along the way. The skill being applied across all of those venues is the same one: knowing what should change, why, and what "good" looks like in each codebase. The thing...