AI statement
I use language models a lot. This page says where.
Where it shows up
Building the boring parts. This site, its AWS stack, and the tool that writes these pages were mostly written by Claude, task by task, with a review pass on each piece before it went in. I read the plans, I read the diffs, and I made it tear things down and redo them when it got something wrong. One model plans and reviews, cheaper ones type, and I read all of it.
On the bench. I have tools that let a model drive my oscilloscope, pull pin-to-net maps out of KiCad, read synthesis and timing reports, type into a DOS box in an emulator, and grab the Apple IIe’s screen. Each one reads back what the instrument actually did, so the numbers the model works with came off the hardware.
Writing. Logs and project pages start from my bench notes, photos, and a long interview. A model drafts, I cut. If a sentence sounds like a keynote, it goes. If a number isn’t one I measured, it gets marked “about” or “I think” or it gets deleted.
The designs. Sometimes. RTL, microcode, generators, test benches, scripts. I don’t have a rule for when. It’s a judgment call each time about whether there’s more value in doing it myself first or in poking at a draft to understand it better. Nothing goes on silicon or into a board without me simulating it, synthesizing it, testing it on the bench, and understanding it.
How I decide
This is my journey, and I build for the journey. You can tell from the projects. Nobody builds an 8008 server because the world needs one. So with a model I ask one thing: does handing this off cost me the part I wanted? Sometimes the boring parts are the price of the interesting ones and I hand them off. Sometimes the boring part is where the understanding lives and I do it by hand. I get that call wrong now and then, and the logs say when.
A few things hold either way:
- No fabricated results. A number on this site was measured, or it says it’s remembered.
- A model never publishes on its own. It pushes, deploys, or deletes only when I tell it to, one at a time.
- Corrections go into the entry that was wrong. Git keeps the old version.
- When a fault isn’t in the program, I measure the rails before I build a theory.
- Never write a test-bench assertion from reading the schematic. Extract the gate equation from the netlist first.
What I don’t do
I don’t publish something because a model said it works. The opinions on this site are mine, and an empty section stays empty until I have something for it.
The toolchain question
The gateware here is built with open tools on purpose, yosys and nextpnr instead of Quartus and Vivado, and then I lean on a closed model from one vendor to help build it. I don’t have a tidy answer for that. The tools I ship with stay open; the thing that helped me type them isn’t, and I’d rather say so than leave it out.
Training
I haven’t opted in to anything here being used to train models. If it ends up in one anyway, that wasn’t my choice.
Why say all this
Because it changes how you should read the site. The facts are mine and measured. The sentences were often typed by something else and then argued with. If a line reads wrong to you, it probably is, and I’d like to know.