netwatcher v0.8.0 - the AI bugfix release

17 August 2026

My little Rust library netwatcher has a new release and the changelog is unusually long. As you’ve probably already guessed from the title, this is because I took the time to run some LLMs over it looking for bugs and doc inconsistencies. It turns out that even within Rust’s guardrails I wrote plenty of bugs. Who could have seen that coming?

This won’t be a surprise to anyone who’s been using LLMs in 2026. There are no special tricks and you don’t have to overthink it[1]. We really are at the point where you say to any modern model “find the bugs” and it finds the bugs. It’ll even fix them too. Isn’t that magical? I may be slinging slop but darned if my library isn’t substantially better for it.

The only findings I had to reject were cases where I’m actually being sloppy on purpose. For example, some platforms have edge cases where a network’s hardware address might not be readable. I choose to leave it as a String with possible placeholder, since it kind of sucks to make it an Option for the normal case. Similarly, in principle it’s possible for an interface watcher to start failing in the middle. I choose to swallow the errors. Virtually everything was validated when the watch was first created, and transient errors will be handled gracefully by incorporating changes into the next update. Because I do this, you don’t need to check for an error every time and the code is lovely and clean. LLMs don’t enjoy this kind of corner-cutting (nor do certain humans) but I put my foot down. If there’s evidence that this causes problems in the real world then I’ll reconsider.

The majority of the bugs were the sort of things where I think “oh yeah I could see that being a problem” but it wasn’t particularly likely to come up for most users most of the time: race conditions, handling panics over FFI, unusual interface types, things like that. Pre-LLM, these are the sorts of things that would come up as intermittent faults on the bug tracker and I’d have to spend hours poring over the code and vendor docs to figure out what went wrong. I feel like I’ve done a kind of speed-run on that hardening and now it’s ready for more users[2].

That said, the most significant bugfix in this release was not detected by LLM inspection, and I’m a little surprised that it wasn’t. It fell out by accident when I added IPv6-specific integration tests and I realised that if I changed an IPv6 address on Linux it wasn’t picked up by the library at all.

The history of this bug is mildly amusing. On Linux the standard way to subscribe to IP address changes is to open a NETLINK_ROUTE socket and use group bits to indicate what event types you care about. I needed to specify the constants RTMGRP_IPV4_IFADDR and RTMGRP_IPV6_IFADDR, which I took from the nix crate. At this point, everything was correct.

Later I was trying to make this work on Android (which is a kind of Linux) and the build failed because those constants were not present in the Android version of the nix crate. To make the compiler happy I switched those constants to local definitions: 

const RTMGRP_IPV4_IFADDR: u32 = 0x10;
const RTMGRP_IPV6_IFADDR: u32 = 0x20;

Unfortunately for me, this was wrong. If you look at the relevant kernel header, you can see that I copy-pasted the correct value for IPv4, then for IPv6 I used the value of the line directly underneath it, which is actually RTMGRP_IPV4_MROUTE. IPv6 really needed the value 0x100.

For whatever reason, my LLMs didn’t see this. Naively I’d have expected RTMGRP_IPV6_IFADDR and 0x20 in the same line to be a glaring, self-contained error, if you’ve been trained on lots of code where this would have been set to 0x100. Yet it didn’t, so we found the bug the boring, traditional way. (Tests.)

The best part of this bug is that as soon as I got Android compiling, I learnt that modern Android restricts netlink sockets and I was going to have to build an entirely different watcher mechanism involving their Java API. Thus I subtly broke the code for no gain whatsoever.

So there we have it. Enjoy the new release. If you’re maintaining a public library, at this stage you really have nothing to lose by asking an LLM to find the bugs. (Except for maybe getting put on strange lists.)

  1. If you really want to know I used a mixture of DeepSeek v4 Flash and Pro and GPT-5.6 Luna and Sol, but it really doesn’t matter on a small codebase like this one. ↩︎
  2. If crates.io downloads mean anything, usage seems to be increasing, which is gratifying. ↩︎

Serious Computer Business Blog by Thomas Karpiniec
Posts RSS, Atom