Posts

I’ve spent the last little while designing 3d printed fan shrouds for a dual NVIDIA V100 card with Claude Code, and the whole CAD model is generated from a python script, no mouse involved. Claude writes the CadQuery, it spits out an STL, I look at it, I ask for changes. Code is cheap now, the geometry basically falls out of the script. The maths was never the hard part though. The hard part, by an embarrassing margin, was telling Claude which bit of the model I was talking about. ...

There’s a particular sound you never want to hear from a machine with two Tesla V100s bolted into it. A sharp zap, then half a second later the smell of magic smoke. I heard both, lunged for the PC’s main power switch and killed everything. Then I just stood there for a bit, not wanting to look. The carrier board those V100s sit on cost around $500 and isn’t the kind of thing you pick up at the local Jaycar; if I’d cooked it, the whole datacentre-under-the-desk project was dead in the water. That proper stomach-drop moment where you know you’ve done something dumb and you’re about to find out exactly how dumb. ...

The Tesla V100 is a 2017 datacentre card that’s gone pretty cheap on the second-hand market, and it turns out it’s still a genuinely good bang-for-buck way to run LLMs locally in 2026. 16 GB of HBM2 at around 900 GB/s, and that memory bandwidth is the thing that actually matters for token generation. I’ve been assembling a few of these into machines and putting together a setup pack so anyone buying one can get going without fighting the toolchain, so this post is partly the story of getting there and partly a pointer to the kit. ...

I spent two weeks debugging a MIPI CSI-2 camera bring-up. The sensor is an AR0234CS, the receiver is a Lattice CrossLinkPlus FPGA bridging into an i.MX RT1176, and the symptom was that 85% of CSI-2 packets failed ECC validation in the FPGA’s integrated parser. Diagnosis took cross-referencing 700+ pages of ON-Semi datasheets, dozens of sensor and FPGA configuration permutations, and forensic byte traces from a debug peripheral inside the FPGA itself. ...

I’ve got an image generator wired straight into Claude Code now. Tell it “draw me a whiteboard diagram of the queue lifecycle” inline in any session, and 30 seconds later there’s a PNG on disk, an inline preview in chat, and a URL that’s good for an hour. It works in Claude Desktop too via a stdio extension that proxies to the same backend. ...

Claude can write MicroPython just fine. The annoying part is everything after that, getting the code onto a board, connecting to the REPL, figuring out why the pin numbers are wrong, iterating. I wanted Claude to be able to do all of that itself, talk directly to the hardware while I watch. ViperIDE is a browser-based IDE for MicroPython and CircuitPython by Volodymyr Shymanskyy. It connects to devices over USB, Bluetooth, or WiFi and gives you a file manager, editor, and REPL terminal. If you haven’t tried MicroPython before it’s one of the easier ways to get started. ...

I’m writing this blog post on my Pixel 5, standing in the kitchen. Termux open, connected to my home server through three layers of infrastructure that make the whole thing feel like I’m sitting at my desk. The same Claude Code session I started on my workstation this morning is right here on a 6" screen, and I can type a prompt, put the phone down, come back in an hour, and nothing has dropped. ...

MicroPython has about 1500 open issues across its repos. Some of them have been there for years. A bunch are duplicates of each other, a bunch more are already fixed by PRs that got merged without anyone linking them back, and a pretty solid chunk are just noise (support questions, cross-posts, wrong-repo stuff). Nobody’s going to sit down and manually review 1500 issues against 8000+ PRs looking for connections though. ...

A colleague had just reached a critical milestone, getting a stable LVGL-based UI running on our product’s 5" MIPI display. It was a significant piece of driver work: MicroPython application code on an NXP i.MX RT1176 (Cortex-M7 @ 1 GHz), driving LVGL v9 on a 720x1280 MIPI DSI touchscreen. An embedded system, not a phone or PC. The UI worked, but the on-screen keyboard was unusable. Each keypress took nearly 200ms to render, dropping to 1-2 FPS while typing, missing many keypresses entirely. For context, touchscreen input generally needs 30+ FPS (under 33ms per frame) to feel responsive, and 60+ FPS to feel smooth. We were at 5 FPS on a good frame. That performance is unusable for a client demo, let alone a shipping product, and without any obvious cause for the lag it wasn’t clear if we had a fundamental hardware/design failure or a fixable configuration issue. ...

I recently got a Lenovo ThinkPad P14s Gen 6 with the AMD Ryzen AI 9 HX PRO 370 and 56GB of LPDDR5x RAM. I wanted to see what I could actually run on it for local LLM inference, and it turns out you can run pretty large models if you know how to get around a couple of gotchas with the AMD iGPU memory model. The short version: I’m running Qwen3.5-35B-A3B (a 35 billion parameter MoE model) and Gemma-4-26B-A4B (26B, also MoE) locally, served as an OpenAI-compatible API accessible from other machines on my network. No discrete GPU required. I’ve since put them to work on a real batch classification task (triaging ~4000 GitHub issues for the MicroPython project) and compared their output quality against Claude Sonnet. ...