Paint.NET reescribe Direct2D con Claude: 180.000 líneas

Paint.NET acumula unas 700.000 líneas de código escritas a lo largo de más de veinte años. Su autor, Rick Brewster, acaba de sumar 180.000 de golpe, y no las ha escrito él: son una reimplementación desde cero de Direct2D, la API de gráficos 2D de Windows, generada con Claude para que el editor funcione sobre WINE en Linux.

La cita la recoge Simon Willison en su weblog, a partir del anuncio que Brewster publicó en el foro de Paint.NET. Lo que ha hecho circular el mensaje no es el volumen de código, sino la franqueza con la que su autor explica qué ha hecho después con él: nada. No lo ha revisado.

El problema de fondo: Direct2D sobre WINE

Direct2D es la capa de renderizado 2D acelerado por GPU que Paint.NET usa para dibujar prácticamente todo lo que aparece en pantalla. Sobre WINE, la capa de compatibilidad que ejecuta binarios de Windows en Linux, esa API nunca ha llegado a estar completa. Brewster lo resume sin adornos: Direct2D siempre ha sido el mayor obstáculo para Paint.NET en WINE y está claro que nunca estará lo bastante terminado para lo que el programa necesita. Desactivarlo tampoco era una opción, porque el editor depende de él.

La salida ha sido una reimplementación interna, hecha por ingeniería inversa en sala limpia, que vive en PaintDotNet.Windows.Direct2D1.Managed.dll y se activa pasando el flag /wine. Es un camino de código alternativo que solo entra en juego cuando alguien lo pide de forma explícita, en un entorno concreto.

180.000 líneas que nadie ha leído

Brewster describe el resultado como «vibe coded», en modo «trust me bro», y su justificación es puramente aritmética: no puede revisar 180.000 líneas de código porque son demasiadas. La cifra equivale a cerca de una cuarta parte de todo Paint.NET, un producto que mantiene una sola persona desde hace dos décadas.

Ese es el dato que conviene retener. No es que revisar código haya dejado de importar: es que generarlo se ha abaratado tanto que la revisión se ha convertido en el cuello de botella. Un revisor humano competente rinde unos cientos de líneas por hora antes de empezar a mirar sin ver. 180.000 líneas son meses de jornada completa para alguien que ya tiene otro trabajo, que es mantener las otras 700.000.

Por qué aquí el riesgo es asumible

Hay cuatro factores que contienen el problema y que merece la pena separar del titular:

1. La funcionalidad no existía. La alternativa a este código no era una versión revisada, era que Paint.NET siguiera sin funcionar en Linux.
2. Está aislado detrás de un flag y de un DLL propio, en una ruta que no se toca al ejecutar en Windows.
3. El soporte está etiquetado como extremadamente experimental por el propio autor, así que el contrato con el usuario es explícito.
4. El dominio es verificable. Un render se puede comparar píxel a píxel contra la salida de Direct2D real, sin necesidad de leer el código que lo produce.

Cambia cualquiera de esos cuatro y el cálculo se rompe. 180.000 líneas sin revisar en un backend de pagos, en una ruta activa por defecto, no son la misma decisión.

Para quién es útil

Para cualquier equipo que esté decidiendo dónde acepta código generado sin auditar. Las preguntas útiles son las de arriba: ¿la alternativa es no tener la funcionalidad?, ¿está el código aislado?, ¿lo sabe el usuario?, ¿se puede verificar la salida sin leer la implementación? Cuando las cuatro respuestas acompañan, aceptar el código es defendible. Cuando no, toca volver a la revisión clásica y generar menos.

Nos parece un caso más honesto que la media, porque Brewster documenta el método y su nivel de confianza en lugar de vender el resultado. La pregunta que queda abierta no es si el código funciona hoy, sino quién lo depura dentro de dos años, cuando falle un caso raro de renderizado y nadie, ni humano ni modelo, recuerde por qué esa función estaba escrita así.