I’ve been working on a Go library called ostiole—a little door into the inner workings of chips. At the moment, the door opens onto one very specific path. It starts with native USB on Linux or macOS, passes through an FTDI H-series adapter and SWD, and reaches just far enough into Arm’s debug architecture to identify a Cortex-M. That isn’t debugging, but it is enough to get a sense of the project’s layers. They’re separate, composable libraries that anyone comfortable with Go can use to build their own hardware tools.
Hardware-debugging tools are happy to do exactly what I asked instead of what I intended, then hand me enough hexadecimal rope to hang myself trying to work out what happened. An AI gets the same two chances. It can hallucinate the script and the result.
I want to optimize for a different target, one where AIs compose exactly the tools they need. Ostiole’s libraries should have small jobs and clear boundaries. The simulators should let an AI try them without a bench. The documentation should point it at the library that already owns an operation before it goes rummaging through the whole repository.
Eventually, I expect Ostiole to inspect, control, and program whole systems, with debugger and MCP interfaces using the same libraries instead of growing their own hardware stacks. That is a long way from reading a Cortex-M identity, but building it is the fun part—and somewhere along the way an AI will use Ostiole to debug a chip as part of doing something genuinely useful.