Jos wrote an interesting article about programming in the time of AI, which made me wonder, for what kind of programming would AI make a difference? One possible answer is for writing devices drivers.

Now when I say drivers, I don’t mean the driver for the graphic card or the disk controller. These run in the kernel, and a bug can take down the whole operating system. What I mean here are drivers for small, peripheral devices: a gizmo with a USB interface, for which there is only a Japanese Windows 95 driver, an internet enabled kettle whose cloud provided disappeared.

The important thing here is that the device is effectively useless and that the code to drive said device can run in some reasonably close enclosure. If your kettle can explode because it receives weird instructions, you have another problem.

So why AI? Writing drivers is tedious, and especially when you don’t have access to the documentation of the device, you need to reverse engineer it, which is a lot of trial and error, and knowing various protocols, various chipsets is helpful. This is typically a domain where AI could work well. At the same time, there is a large number of such devices, and their value is very low, so it does not make business sense to pay humans to program drivers for them – this is why typically amateurs and open source project take up this type of work.

How would this work? I suspect it will depend on the device. You would probably feed it some protocol traces, maybe instrument the target device to detect when a desired effect would happen, trigger some sensor, maybe interact with a JTAG interface, or just reset it, as it will probably often crash.
That might mean breaking the device open, and doing some soldering, but this could be optimised using some harness, something similar to the cheap component testers you can buy already.