I have a 2 TB backup drive that was written on Linux: LUKS2 encryption,
ext4 inside. Plugging it into a Mac gets you the "The disk you inserted was not
readable by this computer" dialog, with Initialize… sitting right there
next to Ignore — which is not the most desirable default for a
backup disk. I could always attach it to a Raspberry Pi 4 I had running at the time, but the Pi USB power envelope is generally too tight for M.2 SSD drives — the supply browns out on anything this power hungry, and getting a powered USB hub just to read a file from a backup was a hassle.
The usual advice is to install a Linux VM and pass the USB device through. On
an Apple Silicon Mac that is an x86-emulation-shaped afternoon, and macFUSE
plus ext4fuse means a kernel extension and the security-approval dance. Both
felt like too much machinery for "read some files".
So instead I did what I had recently done with vdiread and created luksext4, a pure-Python
read-only reader that implements LUKS, LVM and ext4 well enough to get files
off the drive. Nothing is mounted, nothing is installed into the system, and
the device is opened O_RDONLY — it physically cannot damage the drive.
Like the VDI project, this one was also almost single-shot prompted with Opus 4.8, so what follows is mostly an AI-created tour of an AI-created tool. The main takeaway is that these types of tools can now be created basically on demand, since all the components (LUKS, ext4) are open source, and an agent can either reach for existing libraries or, in a pinch, read the relevant kernel modules and adapt the logic to whatever language you want.
I got to do some data recovery work with an old HDD that used to be in the office machine of a small nonprofit. The PC was decommissioned, but the files needed going through. Turned out the HDD had a few huge (30 GB+) VirtualBox .vdi disk images as its main data — an Inception-style data recovery indeed, disks within disks!
Unfortunately, macOS on Apple Silicon proved very resistant to any easy attempt to get the drives read. After some hours of installing VirtualBox and QEMU and trying to get the things running, I decided to abort that route. Maybe modern AI could write a standalone tool that reads the image file and the filesystem inside it, and provides simple file listing and extraction?
Turns out it very much can — I was able to basically single-prompt the vdiread tool into existence. It is a small read-only CLI that opens a .vdi file, finds the NTFS partition inside it and lets you list,
stat and copy out files. No VirtualBox, no mounting, no root. And, compared to the earlier options, I did not have to use some VDI tool to extract a 30 GB compressed file into a 70 GB uncompressed one and then try to mount it. I could work straight within the original image.
I've been doing a lot of AI-assisted projects lately, and I've felt that many of
them might be interesting to others as well and thus worth sharing. With work
and family keeping me busy, however, I have very little time to document their
progress and publish posts about them. With newer models, I'd rather use my
creative input to guide as many interesting projects as possible and accelerate
the sharing part.
So I'm introducing AI-assisted posts. For these write-ups, AI helps speed up
the reporting part: starting from my project idea, following the implementation
through Git history (with some guidance from me in most cases), and curating
suitable snapshots of the app, script, or whatever to make it clear to others
what it does and how to use it.
Each AI-assisted post will carry a clear disclaimer linking back to this
explanation. The aim is simple: get useful projects out there while they
are still fresh, without taking too much time away from creating them.
I'm very happy to receive feedback on the projects and the idea. You can
probably find my contact info easily and get in touch either through this site
or through the projects themselves. I plan to keep publishing them on GitHub,
at least for the time being :).
Vibe coding has left me with quite a few small development apps. Starting any
one of them is easy, but first I need to remember where it lives, whether it
uses Bun, npm, uv or something else, and which command starts it. Doing this
for a dozen projects started to get a bit old.
So I made bunrun, a local dashboard for
starting, stopping and watching development apps:
It is intentionally quite simple. A project is just a path and one or more
shell commands. bunrun starts them as child processes, shows their output with
ANSI colors, detects URLs from the output and can open the app in a browser.
When bunrun exits, the child processes exit too — no containers, daemons or
process archaeology required.
KittenTTS is a neat open-source
text-to-speech model that packs a surprising amount of punch in sizes as low as 25 MB. It
has over 11,000 stars on GitHub and for good reason — the output quality
is impressive for something you can run locally. The catch? It's Python-only,
needs pip install gymnastics, and you certainly can't just hand someone a link
and have them try it out.
The KittenTTS folks say they have browser version planned, but I was a bit impatient and also was eager to find out if a modern AI agent like Codex could pull off a Javascript port. The plan was simple: you open a page, pick a voice, type some text, and hear it speak. No server, no Python, no installs, available to client side web projects easily.
Spoiler alert: It actually worked almost single shot (I had to prompt my way through the plan and run a bunch of pnpm install commands to work around the sandbox basically). The results are up in https://github.com/jokkebk/KittenTTS-JS, but read on to find out how I got there with ChatGPT Codex 5.3 doing the heavy lifting.
The Plan
I started by asking Codex how hard it would be to create a browser JS port.
It studied the Python codebase, identified the pipeline stages, and came back
with a surprisingly thorough analysis. The core pipeline is:
Text preprocessing (cleanup, sentence chunking)
Phonemization via eSpeak
Token mapping (phonemes to integer IDs)
ONNX model inference per chunk
Waveform concatenation
The model itself is a single ONNX graph that takes tokenized phonemes, a voice
style vector, and a speed parameter, and outputs raw audio samples directly.
No separate vocoder needed. This is key — it meant the browser port just
needed ONNX Runtime Web and the right input pipeline.
Codex also noted the tricky bits: voice embeddings stored in NumPy's .npz
format (basically a ZIP of .npy files), and the eSpeak phonemizer which is a
C library. Both have WebAssembly ports available, making the whole thing
feasible. It laid out a 7-phase plan with API design, repo layout, risk
mitigations, and estimated about 7–8 days for a robust V1. I had it write
the plan to PLAN.md before proceeding — having that concrete reference
turned out to be valuable.
Letting Codex Work
With the plan saved, I told it to go ahead. Here's roughly what happened over
the next few hours, based on the commit history:
Longer version (templated with Claude Sonnet using the github commit):
I've been thinking about getting a MIDI controller to use as a Stream Deck type
of device — not to do any music stuff, but use the midi messages to
automate workflows. Not having found anything compact, robust and with cool
twiddly knobs, I thought to beta test my actual interest by loaning a Novation
Launchpad Mk3 from a friend.
I started by asking ChatGPT if we can control this thing with MIDI and the
answer was yes. It even suggested a Python test script to try it out. I obliged
and ran it, and it didn't work, but a few rounds of discussion revealed the
culprit to be two input and output devices, and the script had defaulted on the
wrong one.
Now Chrome nowadays has all these awesome local USB capabilities, so what about
MIDI? Turns out, you can skip all Python package dependencies and just write a
single HTML page that can connect to the launchpad and program it using the Web
MIDI API!
The Launchpad Mk3 uses MIDI messages also to control the LEDs, so you can not
just receive input, but actually control the 8x8 LED matrix with 127 colors
(ChatGPT said first half is static and the other half pulsing colors, but I was
not quite sure how this worked).
Snake and Blob Games
Once I had the basic LED control working and a HTML debug console that showed
the MIDI messages flowing, I couldn't resist adding some games. Snake is the
classic — use the arrow pads to guide the snake around the 8x8 grid. The
Blob game is a variant I asked Claude Code to whip up for me, or actually my
daughter, who still lacks the dexterity to play Snake, but might be happy with
some animation if she succeeds in hitting the blob on the grid.
