DEV Community

Cover image for Dev Log #5 Building a Claude-style SRE terminal and tackling WebRTC
Yash Kumar Saini
Yash Kumar Saini Subscriber

Posted on

Dev Log #5 Building a Claude-style SRE terminal and tackling WebRTC

11 commits, 5 PRs, 1 issue, and 3 reviews across 4 repos. This week was all about infrastructure—from RabbitMQ RCA tools to massive WebRTC scaffolding in Python. Hit a 7-day streak and pushed over 11k lines of code.

TL;DR

It’s been one of those weeks where the terminal felt like my natural habitat. I managed to keep the streak alive for seven straight days, which always feels great, but the real win was the sheer volume of infrastructure work I got through.

I logged 11 commits, 5 PRs, and 3 reviews across 4 different repositories. The highlight? Diving deep into the py-libp2p stack to start the WebRTC transport scaffolding and pushing the vision for a persistent SRE terminal in opensre. With over 11,000 lines added and only about 200 deleted, this wasn't a week for refactoring—it was a week for building the foundation of some pretty ambitious features.

What I Built

Most of my energy this week was split between two major domains: SRE tooling and p2p networking.

opensre: The SRE Terminal Vision

I’ve been spending a lot of time thinking about how we interact with infrastructure during an incident. In the opensre repo, I’m working toward making it a persistent SRE terminal—something inspired by the flow of tools like Claude-Code but specifically tuned for system reliability.

I opened a PR for an interactive REPL, which is really the first step toward that "SRE terminal" experience. It’s about 2,400 lines of new code focused on creating a seamless environment where you can run diagnostics without jumping between a dozen browser tabs.

Alongside the terminal work, I also shipped a RabbitMQ integration. This is specifically for queue and broker Root Cause Analysis (RCA). If you’ve ever had a message broker fall over under load, you know how painful it is to piece together the "why" while the system is down. This integration aims to automate that detective work.

py-libp2p: The WebRTC Beast

On the open-source side, I’m still heavily involved with py-libp2p. This week, I tackled a massive task: WebRTC transport scaffolding. This PR alone is over 6,000 lines. It’s mostly spec compliance and tests right now, but getting the transport layer right is critical for browser-to-node connectivity.

I also did some much-needed cleanup in the transport layer by removing the nursery parameter from IListener.listen. This was a follow-up to some architectural changes we’ve been discussing, and it makes the interface much cleaner. (Honestly, passing nurseries around everywhere was starting to feel like a bit of a code smell, so I’m glad to see it go).

Personal Setup & Maintenance

I also spent some time in my nvim config. I pushed 7 commits there—mostly Lua tweaks to keep my environment snappy while I’m jumping between Python and TypeScript. It’s the small things, like optimizing LSP behavior or fixing a keybinding conflict, that keep the flow state going during these high-output weeks. I also touched 100xsolana and DevNotion for some minor maintenance, keeping the lights on while I focused on the bigger infra tasks.

Pull Requests

I had 5 PRs in flight this week, and they really tell the story of the week's progress.

The MariaDB integration docs was my only merge this week, but it was an important one. It closed out an issue I opened earlier in the week to ensure our Mintlify docs stay up to date with the actual capabilities of the tool.

The other four PRs—the WebRTC scaffolding, the transport fix, the RabbitMQ integration, and the REPL—are all currently open. They represent a lot of "work in progress" that I’m looking to land early next week. The WebRTC PR is the one I’m most nervous/excited about; it’s a lot of code to review, and I want to make sure the spec compliance is spot on before we go any further.

Issues & Discussions

I’m really trying to be more intentional about the "why" behind the code, not just the "how." I started a discussion in opensre about whether we should bundle or split the next phases of the persistent SRE terminal.

It’s a classic architectural dilemma: do we keep everything in one tight package for ease of use, or do we start modularizing now to prevent a monolith? No one has answered yet, but getting my thoughts down in a discussion thread helps me clarify the roadmap before I start writing more code.

Code Reviews

I spent a good chunk of time reviewing other people's work in py-libp2p. I think it’s important to give back to the projects you use, and reviewing is often more taxing than writing.

I gave feedback on a QUIC address unpacking PR, specifically looking at how we handle both IPv4 and IPv6. I also requested changes on a BasicHost shutdown enhancement. Shutdown logic is notoriously tricky in asynchronous Python, and I want to make sure we aren't leaving any dangling tasks or resources. Finally, I left some comments on a PR regarding peer identity persistence.

Reviewing these while working on my own massive WebRTC PR was a bit of a balancing act, but it keeps me grounded in the codebase as a whole, not just my own little corner of it.

Tech Stack

This was a very Python-heavy week. Between opensre and py-libp2p, I was deep in the world of asyncio, type hinting, and infrastructure logic.

The language breakdown shows Python as the clear leader, followed by TypeScript and Lua. The 11,185 additions versus 201 deletions really highlights that this was a "feature push" week. I wasn't cleaning up old debt as much as I was laying down new tracks.

And that 7-day streak? It’s not about the "grind"—it’s about the fact that I was genuinely excited to get back to the keyboard every morning to see if I could get that WebRTC transport to behave.

What's Next

Next week is all about the "Merge." I want to get the WebRTC scaffolding in py-libp2p to a state where it can be merged, which means writing a lot more tests and probably responding to a lot of review comments.

In opensre, I’m going to keep pushing the REPL. I want to get to a point where I can actually use it for my own freelance work—eating your own dog food is the best way to find the friction points in a CLI tool.

Catch you all next week! Hopefully with a few more "MERGED" labels on those PRs.


Connect with me:

Website
GitHub
LinkedIn
X (Twitter)

Top comments (0)