Claude como ingeniero de drivers: qué enseña a una pyme

Hay una escena que se repite en muchas pymes españolas: un periférico caro que no funciona en el portátil del empleado, un fabricante que no da soporte y un equipo de IT que pierde días buscando una solución. La historia que ha contado Christian Schaller, directivo de ingeniería en Red Hat y veterano colaborador de GNOME y Fedora, es una versión extrema de ese problema, y a la vez una clase práctica sobre cómo usar asistentes de código con criterio.

Schaller tenía una caja de negativos familiares y un escáner Plustek OpticFilm 8200i que compró precisamente porque aparecía como compatible con Linux. Al llegar a casa descubrió que el fabricante había cambiado el chipset por uno que ningún driver de Linux reconocía. Sus primeros intentos de que Claude Code escribiera un driver funcional no llegaron a ninguna parte y el proyecto quedó aparcado meses. Al retomarlo con otro enfoque, en pocas horas obtuvo un primer escaneo reconocible y en pocos días el driver ya soportaba escaneo por infrarrojos.

El truco no era el prompt: era el contexto

La clave del cambio fue dejar de pedir código a ciegas. Inspirado por una publicación de Tom Crider (conocido como Glorious Eggroll), que había arreglado un driver de ratón dando a un agente acceso a una máquina Windows, Schaller montó un entorno donde Claude podía ejecutar el software oficial del fabricante, capturar el tráfico USB y compararlo con lo que enviaba su implementación en Linux. El agente usaba el driver de Windows como referencia para localizar dónde fallaba el de Linux.

El propio Schaller resume una ventaja poco romántica pero decisiva: Claude «no se aburre». Reconstruir protocolos no documentados a partir de capturas USB, valores de registro y transferencias de control no es una tarea especialmente compleja, pero exige mucha paciencia. Ahí es donde un agente rinde de verdad, siempre que alguien valide el resultado sobre el hardware real.

Un método reutilizable, no un parche suelto

Schaller publicó el enfoque como proyecto open source con licencia MIT bajo el nombre hw-harness. Incluye las herramientas para capturar el comportamiento de un dispositivo, comparar una implementación que funciona con otra que falla y entregar a un agente de código la información que necesita para trabajar con hardware que Linux aún no soporta. Es decir, lo valioso no es solo el driver del escáner, sino el procedimiento.

El caso tuvo un final agridulce: mientras trabajaba, el soporte del OpticFilm 8200i llegó a SANE en septiembre gracias a otro desarrollador. Schaller no piensa mantener un driver competidor; usará el upstream cuando tenga las funciones que quiere y conservará el suyo como prueba de concepto. Su versión, eso sí, muestra ventajas concretas: eliminación de polvo por infrarrojos, ajustes de exposición para negativos densos y escaneo en color y escala de grises entre 300 y 7.200 dpi. En una prueba de un solo fotograma, su driver completó un escaneo a resolución completa en 34,6 segundos frente a 54,4 del upstream, aunque la comparación es limitada.

El mismo método sirvió para la cámara de un Lenovo ThinkPad X1 Carbon Gen 14, que en Linux daba imágenes oscuras, con esquinas más negras y tinte amarillo-verde. Aquí no había tráfico USB que analizar, así que Schaller alimentó al agente con los ficheros de configuración del driver de Windows, entradas de registro, tablas ACPI y propiedades del dispositivo, y añadió una webcam USB como referencia funcional. Al final del día tenía parches para el kernel y para libcamera: un fallo de selección de recorte, un registro de patrón de prueba mal definido y un límite de ganancia analógica que costaba unas 1,8 stops de sensibilidad. En libcamera aparecieron además problemas de corrección de sombreado de lente y de cálculo de niveles de negro que afectaban al balance de blancos. En la prueba en baja luz, el brillo del fotograma pasó de 31,1 a 90,9.

Qué significa esto para una pyme

No hace falta que tu empresa digitalice negativos familiares. Pero sí conviene extraer tres lecciones aplicables a cualquier equipo de IT con recursos limitados:

• El agente necesita una referencia que funcione. Igual que Claude comparó el driver de Windows con el de Linux, un asistente de código rinde mucho más cuando tiene delante una implementación correcta, logs reales o un entorno reproducible. Sin eso, genera código plausible y a menudo inútil.
• La validación humana no es opcional. Schaller tuvo que probar cada cambio en el escáner y en el portátil. Un driver que compila no es un driver que funciona. Ese principio vale para cualquier automatización que toque producción.
• Documenta el proceso, no solo el resultado. Publicar hw-harness convierte un logro personal en una capacidad reutilizable. En una pyme, eso se traduce en runbooks y entornos de prueba compartidos, no en scripts sueltos en el portátil de una persona.

También hay una advertencia. Los parches de la cámara aún no se han fusionado: los revisa Kate Hsuan, ingeniera de desarrollo en Nvidia, para el kernel, y Wim Taymans, ingeniero principal en Red Hat, para libcamera. Y no todo sale bien: una corrección del page cache de Linux generada por Claude se topó recientemente con una condición de carrera durante la revisión. El mensaje para cualquier equipo es claro: la IA acelera la exploración, pero el listón de calidad lo sigue poniendo la revisión técnica.

Para una pyme, la recomendación práctica es empezar por problemas acotados y verificables: un periférico rebelde, una integración con un ERP, un script de despliegue. Prepara un entorno donde el agente pueda observar el comportamiento real, define cómo vas a comprobar cada cambio y guarda lo aprendido. Es la misma disciplina que aplicamos cuando hablamos de ingeniería para picos de tráfico o de modelos de decisión con IA en operaciones: la herramienta importa, pero el proceso que la rodea decide el resultado.

Fuente: The New Stack. Análisis y adaptación: ForgeNEX.