NLnet Labs exige poder discutir el diseño del código que genere una IA
La fundación que mantiene Unbound, NSD y Routinator publica una política de uso de LLM: aceptar código que su autor no sabe explicar es cargar con un perro gratis durante años.
NLnet Labs ha publicado una política sobre el uso de modelos de lenguaje en sus proyectos. La fundación lleva 25 años escribiendo software para infraestructura crítica de internet —resolutores DNS, BGP, RPKI— y en los últimos doce meses ha visto cambiar la forma en que le llegan las contribuciones. Alex Band lo cuenta en el blog: si quien envía un parche no puede discutir contigo las decisiones de diseño que lleva dentro, ese parche es un problema, no una ayuda.
Veinticinco años revisando línea a línea
El punto de partida importa para entender la queja. NLnet Labs mantiene Unbound, NSD, Routinator y Cascade con equipos pequeños y dedicados, con hoja de ruta y calendario de versiones, casi como una empresa comercial. Todo es open source con licencia permisiva, pero el nicho es tan estrecho —DNS, BGP y RPKI, en C y Rust— que en un cuarto de siglo apenas han recibido contribuciones externas más allá de arreglos de erratas y algún typo.
Las que llegaban tenían un motivo reconocible: una organización parcheaba Unbound para su caso concreto y prefería subir el cambio al tronco principal antes que reaplicarlo en cada versión. El equipo revisa esos envíos con lupa, y a veces el resultado es reescribir la funcionalidad desde cero, como ocurrió con Serve Stale, o dejarla en la carpeta /contrib. Nada de eso es nuevo. Lo nuevo es el volumen y la procedencia.
El prompt de las 4.000 líneas
Band describe la escena: pedirle a un agente que implemente los Catalog Zones del RFC 9432 en Cascade, irse a por café y volver con 4.000 líneas de código que parecen razonables y que quizá hasta funcionen.
Implement Catalog Zones defined in RFC 9432 in Cascade by NLnet Labs. Stop only when all the tests pass and all specifications in the RFC are covered. The final result must include man pages, tests and full coverage of the RFC.
El problema no es que el código sea feo. Es que el RFC no describe todas las decisiones de diseño, y alguien tiene que defenderlas ante el equipo que va a mantener ese código durante años. Ahí se rompe la conversación: preguntado por sus elecciones, el contribuyente responde que no sabe, que eso es lo que le salió al modelo. Para la fundación eso no es «free as in beer» ni «free as in speech»: es un cachorro gratis, bien intencionado y con años de consecuencias.
La política de uso de LLM mantiene el mismo principio de siempre: nada entra sin que alguien pueda razonar sobre por qué está escrito así. La revisión no cambia porque el código lo haya tecleado una máquina. Cambia quién responde por él, y ese es justo el hueco que el envío generado deja abierto. A otros proyectos con mantenedores ahogados les va a tocar decidir lo mismo, y pronto.
