machine-learning A field note by Vikrant Sharma
Claude wrote a printer driver from scratch
An LLM reverse-engineered a 2008 HP laser printer's protocol and generated a working macOS driver. No human debugging required.
Someone asked Claude to make an HP LaserJet 1008a work on macOS Sequoia. The printer came out in 2008. HP stopped maintaining the driver years ago. Claude wrote a complete CUPS driver by reverse-engineering the USB protocol from scratch. The printer speaks PCL, HP’s page description language. Claude figured out the init sequence, the job control commands, the raster encoding. It generated C code that compiles into a CUPS backend. The user installed it. The printer printed. No Stack Overflow. No GitHub issues. No HP documentation. Claude worked from USB packet captures and PCL reference manuals it presumably scraped during training. The whole conversation is public. You can see the model debugging segfaults, rewriting buffer handling, fixing endianness errors. It is not pretty code, but it works. This is the first time I have seen an LLM write kernel-adjacent code that interfaces with real hardware and ships. Not a toy demo. Not a refactor of existing code. A driver for a physical device that was not supported. The interesting bit is not that Claude can write C. It is that it can hold enough context to reverse-engineer a proprietary protocol, map it to CUPS conventions, and debug the result without a human in the loop. That is a different category of useful. Printer drivers are usually written by engineers who read vendor docs and debug with oscilloscopes. This one was written by a chatbot that read USB logs. If this works for printers, it works for a lot of unsupported hardware.
Source: Claude Code Teaching macOS to Natively Print to the HP Laser 1008a
