My feelings about LLM-based coding are mixed. I think that the supposed “productivity multiplier” is heavily negated by the fact that humans still need to understand the code they get written from an agent (at least a little bit), but that for certain classes of tasks where you “know” what the solution will look like, having the clanker whip it into existence is a huge timesaver. If you do not review the output, though, slop will slowly accumulate, and it will infect even a good codebase and ruin it. At some point, even the agent will struggle to understand its ancestors’ works.
However, if we throw away all the guardrails in a situation where the consequences are limited to perhaps one laptop and one user, what can we do?
Here I will share an example of such an experiment that I now use in “production”: using the Android Bluetooth stack on Linux instead of BlueZ.
The Android Bluetooth code is called Fluoride. As part of the Android OS, it has been attacked, fixed, linted, fuzzed, written in Rust (at least some of it, a lot of the core is still C++) etc. by a multi trillion dollar corporation’s engineers (not to mention a consortium of engineers from other big companies, and myriad hobbyist and amateur programmers finding and fixing bugs on their own time).
By contrast, on Linux we have BlueZ, which was written by Qualcomm almost 26 years ago, is still maintained to this day, and is written almost entirely in C. While it also runs on millions of systems, it has not gotten nearly the same resources devoted to it due to its relative nicheness compared to Android, the most widely used consumer OS in the world.
Besides security, there is the question of interoperability- Bluetooth devices are more likely to adapt to Android’s Bluetooth quirks than other such stacks, and vice versa- Android might just have better field testing.
Google recognized this exact thing for ChromeOS (their loosely-based-on-Linux desktop OS) and ended up adding support for ChromeOS in this codebase, and replaced BlueZ entirely. The project, called Floss, also added support to run on “vanilla” Linux partially (at least the parts that talk to the Bluetooth kernel driver I guess).
In reality, it is not that simple: while Google controlled the entire userspace on ChromeOS and could adjust the entire audio subsystem to work with a completely different Bluetooth stack, Linux is pretty overwhelmingly BlueZ-coded, with almost everything speaking the BlueZ language over D-Bus to the BlueZ daemon, like Pipewire, Wireplumber, any frontends for Bluetooth you might use (like KDE’s BlueDevil).
This is where Codex came into the picture.
I tasked Codex (gpt-6-astra to be exact) with a “simple”
task - first go through the Floss/Fluoride codebase, the BlueZ codebase,
and Pipewire and tell me how hard it could be to adapt Floss to talk
like BlueZ (perhaps a wrapper that can translate between the two). This
exploration proved to be a waste of tokens, with Astra suggesting it be
easier to patch the codebases involved to speak to Floss instead.
So how is Floss different from BlueZ anyways? The Google article explains a bit better, but in the context of “normal” Linux (as normal as NixOS is anyways) and as a bit of a summary, here’s what is going on:
BlueZ defers a lot of responsibility to the kernel, whereas Floss simply lets the kernel create the bluetooth device (HCI socket) and controls it from userspace. The btadapter service owns the device effectively and controls it all (and is heavily sandboxed). Floss handles encoding into the various codecs Bluetooth devices support (like AAC, aptX, LDAC etc.) by itself and lets the audio server (Pipewire) send it raw PCM data instead.
After learning a bit more about this, I let Codex slop away in as many codebases as it needed to, and eventually let it make four forked repos for housing these changes. Because I wanted stuff to “just work”, I had it reason about code statically, let subagents go through and pick it apart for issues, test stuff in mocked environments relentlessly etc. before I even thought of deploying any of it.
I then let it make another repo that would house a NixOS module to configure this entire mess “automagically”, and in the process I converted those four repos into patch files and commit hashes on which those patch files were good to apply.
The build steps are thus a programmatic clone + checkout hash + apply patch + build, so that I don’t have to keep 4 forks around on my Github account, and it is easier to perhaps imagine that one or two patches may make their way upstream after I’ve had enough time to review them (believe me, there are some real stinkers in there).
This pattern also gives future agents enough information to reproduce and build from scratch, and is one central repo to keep docs and context in as well.
By the time this was done, I was able to do music playback perfectly. What was less perfect was microphone support.
On a normal Linux system, the kernel handles SCO transfers and exposes SCO sockets which would transmit the microphone audio for the userspace daemon to consume. Floss, however, assumes ownership of the controller and does this process by itself, so it never knew to read the SCO sockets the kernel set up. Because of this, even when a headset connected, there was nothing to consume the SCO socket data for headset playback, so no mic audio would ever get picked up.
If you, like me, did not understand that, SCO stands for Synchronous Connected-Oriented link. This is one of two ways Bluetooth links work, the other being ACL (Asynchronous Connection-Less). ACL is for high quality music, file transfer, and is packet based. SCO is circuit switched and is the voice channel of Bluetooth, hence why it is traditionally used for mic input (although now there are newer, improved variants). Astra had already handled ACL when doing the pairing setup and got music playback working over this setup, and now SCO was the missing bit.
The fix involved letting Floss own my laptop’s RealTek USB Bluetooth
controller and have Codex create floss-usb (housed in the
same repo as the one with the patches), which owns the controller and
lets floss control a virtual hci0 interface. I should note
here that I had to coax this simpler solution out of it, because
initially when I was vibing Codex was just casually drafting a kernel
patch and also altering the Nix config to build this custom kernel
instead of my LTS kernel with ZFS support. Phew.
The other bug after this that still kept the mic silent was a small
mismatch between Floss and my Bluetooth card. Floss was framing the
audio into 60-byte SCO payloads, but my card was effectively only doing
24 byte payloads. This required just exposing the byte size from
floss-usb so that the btadapter daemon can pick it up and
run accordingly. Once this was fixed I was able to speak!
All this was done by doing sophisticated prompt engineering and thoughtful context curation along the lines of “hey my headphones’ mic doesn’t work look at logs and figure it out”, and it would, true to its word, look at all the logs of all the relevant services and processes (I am on Linux anyway, the most open OS), figure out root causes, develop mock tests to repro the issue, figure out a fix, test it using the mocks, and then even temporarily deploy the fixed version and ask me “did that work?”. If it did, I committed its changes, pushed them, and updated my NixOS config. If it didn’t, it would start all over again.
Had there been kernel bugs involved (like with BlueZ), I’d have given up. I can’t be compiling kernels for half the day and then rebooting! The feedback loop would’ve been much slower and disruptive to normal operations.
I use omega, my own
persistent harness, which runs as its own dedicated user, can use nix
develop to get toolchains setup, and doesn’t have any root user access.
Every week it is woken up with a prompt to check upstream repos inside
the floss-desktop repo for updates, rebase patches against them, and
push the changes to GitHub. It supports a GitHub PAT for authentication,
which I have scoped per-repo, so the model can’t do more damage than
required. It is powered by DeepSeek v4.1 Flash, easily one of the best
and cheapest models around. I could probably get away with something
much cheaper, but DeepSeek is cheap enough and handles the edge cases
that tend to pop up with this kinda stuff better as well.
Why build my own? Because the others don’t have a SourceHut-like UI, aren’t NixOS-native (I just configured and set up omega using Nix), and aren’t very well set up to run as a different user. They kinda assume their human user will be running it as themselves and have to resort to things like Landlock, seccomp profiles, bubblewrap, containers, VMs etc. which seem pretty annoying and fiddly. I’d rather just use the most stable separation: the one between Unix users, along with systemd service sandboxing for certain parts.
I was thinking of writing on omega, but at this point it seems like a cliche to write about coding agents, so I decided to just keep the details to this one section. I can already feel the eyeballs glossing over these words.
After much lazy iteration (on my part), I have a stack that could well be adopted instead of BlueZ with more effort. In my limited testing, it has become rock solid, and the services are sandboxed more heavily than BlueZ (especially the kernel equivalent parts), which gives me more confidence that this is a more secure setup. While I am focused on audio mostly, with similar effort, stuff like Bluetooth file transfer etc. could also work if someone else was similarly interested.
It is impressive to see the pace of progress through this project. If I did this a year ago I’d have been fighting the model much more often, and would’ve ended up with more dubious results. Now, I am using this on a semi-daily basis with no real downgrades aside from UI bugbears that I can live with.
Also, I didn’t really even set up skills, agent swarms, or fancy features like that. A hand-written AGENTS.md, a decent-ish prompt and checking in every so often and critiquing its approach (and less often, code) was enough to keep it doing mediocre-to-good work at freakishly fast rates.
If you’re interested, check out the floss-desktop repo where you can also see the clanker push rebases.
In order to comply with SourceHut’s new LLM policy, I will not be pushing new LLM-made projects to SourceHut. Existing projects are mirrors to GitHub (I push to both remotes simultaneously), and it seems mirrors are still allowed. I have one SourceHut Build job I need to deactivate for a vibecoded project (and unfortunately need to use GitHub Actions instead). I suppose it doesn’t affect me much, none of my projects have been something with communities, and have been more like solo side projects to pass the time and hopefully learn something.
While I understand the policy, it just kind of sucks I can’t use unlisted projects anymore for these kinds of experiments. C’est la vie, I suppose.
Note: this blogpost is all human effort. I believe writing improves my knowledge and hopefully the reader’s, it is another avenue to get my creative juices flowing, and it is an activity I enjoy. I wouldn’t want a bot doing it for me in much the same way that I wouldn’t want a bot to generate me a summary of a book to read or a song to hear.
This website was made using Markdown, Pandoc, and a custom program to automatically add headers and footers (including this one) to any document that’s published here.
Copyright © 2026 Saksham Mittal. All rights reserved. Unless otherwise stated, all content on this website is licensed under the CC BY-SA 4.0 International License