Claude as a driver engineer: what it teaches a small business

There is a scene that repeats itself in many Spanish small businesses: an expensive peripheral that doesn't work on the employee's laptop, a manufacturer that offers no support, and an IT team that wastes days looking for a solution. The story told by Christian Schaller, an engineering executive at Red Hat and a veteran contributor to GNOME and Fedora, is an extreme version of that problem, and at the same time a practical lesson on how to use code assistants with judgment.

Schaller had a box of family negatives and a Plustek OpticFilm 8200i scanner that he bought precisely because it was listed as compatible with Linux. When he got home he discovered that the manufacturer had changed the chipset to one that no Linux driver recognized. His first attempts to get Claude Code to write a working driver went nowhere and the project was shelved for months. When he took it up again with a different approach, in a few hours he obtained a first recognizable scan and within a few days the driver already supported infrared scanning.

The trick wasn't the prompt: it was the context

The key to the change was to stop asking for code blindly. Inspired by a post by Tom Crider (known as Glorious Eggroll), who had fixed a mouse driver by giving an agent access to a Windows machine, Schaller set up an environment where Claude could run the manufacturer's official software, capture the USB traffic and compare it with what his Linux implementation was sending. The agent used the Windows driver as a reference to locate where the Linux one was failing.

Schaller himself sums up an unromantic but decisive advantage: Claude "doesn't get bored." Reconstructing undocumented protocols from USB captures, registry values and control transfers is not an especially complex task, but it demands a lot of patience. That is where an agent truly delivers, as long as someone validates the result on the real hardware.

A reusable method, not a one-off patch

Schaller published the approach as an open source project under the MIT license under the name hw-harness. It includes the tools to capture a device's behavior, compare a working implementation with a failing one and give a code agent the information it needs to work with hardware that Linux does not yet support. That is, the valuable thing is not only the scanner driver, but the procedure.

The case had a bittersweet ending: while he was working, support for the OpticFilm 8200i reached SANE in September thanks to another developer. Schaller does not plan to maintain a competing driver; he will use the upstream one when it has the features he wants and will keep his own as a proof of concept. His version, however, shows concrete advantages: infrared dust removal, exposure adjustments for dense negatives and color and grayscale scanning between 300 and 7,200 dpi. In a single-frame test, his driver completed a full-resolution scan in 34.6 seconds versus 54.4 for the upstream one, although the comparison is limited.

The same method worked for the camera of a Lenovo ThinkPad X1 Carbon Gen 14, which on Linux produced dark images, with darker corners and a yellow-green tint. Here there was no USB traffic to analyze, so Schaller fed the agent the configuration files of the Windows driver, registry entries, ACPI tables and device properties, and added a USB webcam as a working reference. By the end of the day he had patches for the kernel and for libcamera: a crop selection bug, a poorly defined test pattern register and an analog gain limit that cost about 1.8 stops of sensitivity. In libcamera there were also lens shading correction and black level calculation problems that affected white balance. In the low-light test, the frame brightness went from 31.1 to 90.9.

What this means for a small business

Your company doesn't need to digitize family negatives. But it is worth drawing three lessons applicable to any IT team with limited resources:

• The agent needs a working reference. Just as Claude compared the Windows driver with the Linux one, a code assistant performs much better when it has a correct implementation, real logs or a reproducible environment in front of it. Without that, it generates plausible and often useless code.
• Human validation is not optional. Schaller had to test every change on the scanner and on the laptop. A driver that compiles is not a driver that works. That principle applies to any automation that touches production.
• Document the process, not just the result. Publishing hw-harness turns a personal achievement into a reusable capability. In a small business, that translates into runbooks and shared test environments, not loose scripts on one person's laptop.

There is also a warning. The camera patches have not yet been merged: they are being reviewed by Kate Hsuan, a development engineer at Nvidia, for the kernel, and by Wim Taymans, a principal engineer at Red Hat, for libcamera. And not everything goes well: a fix to the Linux page cache generated by Claude recently ran into a race condition during review. The message for any team is clear: AI speeds up exploration, but the quality bar is still set by technical review.

For a small business, the practical recommendation is to start with bounded, verifiable problems: a rebellious peripheral, an integration with an ERP, a deployment script. Prepare an environment where the agent can observe real behavior, define how you are going to check each change and save what you learn. It is the same discipline we apply when we talk about engineering for traffic spikes or about AI decision models in operations: the tool matters, but the process around it decides the result.

Source: The New Stack. Analysis and adaptation: ForgeNEX.