GHC estrena política de IA para contribuciones de código

GHC ya tiene una política concreta para el código asistido por IA

El compilador GHC (Glasgow Haskell Compiler) tiene más de 6.500 tickets abiertos y un equipo de mantenedores que no alcanza a revisarlos. A partir de esa realidad —no de un debate filosófico sobre si la IA es buena o mala— el proyecto acaba de fijar una política formal para las contribuciones asistidas por modelos de lenguaje.

La noticia importa más allá de Haskell. Cualquier equipo que hoy use asistentes de código y reciba contribuciones externas enfrenta el mismo problema: generar un parche es barato, revisarlo sigue siendo caro.

La política sigue el documento que Simon Peyton Jones desarrolló en la discusión de la lista ghc-devs, y no la "declaración compartida" alternativa que se propuso en julio. Los propios autores de esa declaración aclararon que no pretendía reemplazar una política de contribución, y Teo Camarasu argumentó en contra de tratarla como tal.

Leíste lo que hace la IA. ¿Y en tu negocio?

Un agente de IA puede quedarse con parte de tu día: ordenar lo pendiente y pedirte el OK antes de actuar. El Kit «tu mano derecha con IA» trae un video de 11 minutos y una ficha para dejar al tuyo trabajando. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

¿Qué dice exactamente la política de GHC sobre la IA?

El documento no toma posición sobre los costos y beneficios de los LLM: afirma explícitamente que el proyecto no tiene consenso al respecto. Lo que hace es definir expectativas para contribuciones y revisiones. Son cuatro puntos de política y una preferencia fuerte:

P1 — Priorizar a las personas y la comunidad. Se permite usar LLM, pero la discusión directa con los revisores debe seguir siendo humana. El texto generado no puede reemplazar el juicio del contribuyente. Usar un modelo para navegar el código, traducir o investigar un problema está permitido; lo que no puede es sustituir las conversaciones por las que un proyecto open source forma a sus futuros mantenedores.
P2 — Facilitar la revisión. Quien contribuye debe invertir bastante más esfuerzo en el aporte de lo que el revisor necesitará para entenderlo: objetivo claro, diseño explicado, ejemplos y tests útiles, y cambios divididos en piezas digeribles. Un parche que compila pero obliga al revisor a reconstruir el razonamiento no cumple el estándar.
P3 — Autoría humana y responsabilidad total. Cada contribución necesita un autor humano identificable que entienda y pueda explicar cada línea de código y cada frase de documentación. El material generado se acepta si el contribuyente lo revisó lo suficiente como para responsabilizarse. Los tickets se tratan con más laxitud, porque un buen reporte de bug puede venir de alguien que no entiende la falla del compilador.
P4 — Declarar la generación directa. Si un LLM generó cualquier parte del código, la documentación o los tests, hay que divulgarlo, normalmente con una línea Assisted-By: en la descripción del issue o merge request y en el mensaje de commit. No hace falta publicar los prompts ni rendir cuentas de cada interacción.
P5 — Preferentemente, escribir la versión final tú mismo. Sigue siendo una preferencia, no un requisito. El argumento es práctico: reescribir la versión final suele ser la forma más simple de garantizar que el contribuyente pensó cada línea y mantuvo el parche pequeño. Las notas de arquitectura de GHC reciben atención especial porque preservan razonamiento que importará años después.

Las revisiones asistidas por IA siguen las mismas reglas, y el documento usa "LLM" de forma amplia para cubrir también agentes.

El cuello de botella no es generar código, es revisarlo

El punto central del documento es económico: el tiempo del mantenedor es el recurso escaso. Un parche producido en veinte minutos puede costar dos horas de comprensión a un revisor. Generar código más barato no ayuda si la revisión se vuelve más cara.

LLVM tiene un nombre para esto: extractive contribution, tomado del libro Working in Public de Nadia Eghbal. El contribuyente obtiene el beneficio de enviar algo mientras el proyecto gasta más esfuerzo en revisarlo e integrarlo de lo que el aporte vale. El problema es anterior a los LLM —cualquiera podía enviar un parche de 2.000 líneas que apenas entendía—, pero ahora es mucho más fácil generarlo.

El fenómeno no es exclusivo del open source. Según el reporte de Faros citado en el documento, los equipos con mayor adopción de IA produjeron más pull requests y de mayor tamaño, mientras los tiempos de revisión también subían. Los datos son observacionales y una organización corporativa no es directamente comparable con GHC, pero el cuello de botella es el mismo.

Hay un matiz que suele perderse: la revisión en GHC depende fuertemente de la historia del proyecto. Un parche puede verse correcto en aislamiento y contradecir una propuesta de hace cuatro años, reintroducir una regresión de rendimiento o dificultar un cambio planificado del compilador. Los modelos reducen el contexto que alguien necesita para producir algo que parece plausible, no para producir algo que respeta esa historia.

¿Cómo están respondiendo otros proyectos?

El panorama es heterogéneo y conviene mirarlo antes de copiar cualquier regla:

Linux permite contribuciones asistidas. El contribuyente humano revisa el código, se responsabiliza y certifica el DCO; un agente de IA no puede añadir el tag Signed-off-by. La asistencia se registra con un tag Assisted-by:. Linus Torvalds fue explícito: "Linux no es uno de esos proyectos anti-IA, y si alguien tiene problemas con eso, puede hacer lo que hace el open source y bifurcarlo", según recogió Virtualization Review en julio.
OpenJDK tomó la ruta estricta: su política interina excluye material generado total o parcialmente por LLM, aunque permite uso privado para comprensión, investigación y depuración. Reconoce además el problema de aplicación: distinguir de forma fiable contenido generado de contenido humano es, en general, imposible.
GCC rechaza contribuciones "legalmente significativas" que contengan material generado, por las reclamaciones de licencia de la FSF.
LLVM acepta contribuciones asistidas si un humano verifica el resultado y se responsabiliza; no permite que la IA resuelva tareas de tipo good first issue, pensadas para introducir gente al proyecto.
Zig es más restrictivo. Loris Cro describió su enfoque como contributor poker: el tiempo del mantenedor es una inversión que conviene gastar en personas que se quedarán, no en parches de paso generados con un LLM.
OCaml permite contribuciones asistidas con condiciones y pide divulgación; Clojure rechaza código generado; Agda debatió una prohibición total y la propuesta se cerró sin adoptarse.

Las políticas también envejecen. QEMU todavía publica una política que rechaza contribuciones generadas por IA, pero Paolo Bonzini trabaja en un reemplazo: en mayo argumentó que la prohibición era más fácil de justificar cuando la salida de los LLM rara vez era útil sin reescritura sustancial. Para septiembre, la propuesta se había ampliado a una política que incluye instrucciones para agentes que operan dentro del repositorio.

El caso de curl muestra cuán rápido cambia el terreno. A fines de enero, el proyecto cerró su bug bounty tras verse desbordado por reportes de seguridad pobres, muchos asociados al uso de IA: históricamente más del 15% de los reportes se convertían en vulnerabilidades confirmadas, y la tasa había caído por debajo del 5%. En marzo volvió a HackerOne, y en abril Daniel Stenberg escribió que casi todo reporte entrante parecía involucrar IA, pero que el slop de baja calidad ya no era el problema principal: la tasa de confirmación había vuelto a rondar el 15-16%.

¿Qué significa esto para tu startup?

Si tu equipo usa asistentes de código, el problema de GHC es tu problema en miniatura. La lección no es "prohibir" ni "permitir todo", sino diseñar la divulgación y el estándar de revisión antes de que el volumen te desborde.

Adopta una línea Assisted-By: en tus commits y descripciones de PR. Es el mecanismo que ya usan Linux y GHC. Te da contexto para el revisor sin obligar a nadie a publicar prompts, y te deja trazabilidad si más adelante necesitas auditar procedencia por razones legales o de licencia.
Fija el estándar en el revisor, no en el autor. La regla útil es la de GHC: quien contribuye debe invertir más esfuerzo en el aporte de lo que el revisor gastará en entenderlo. Si un PR generado obliga al revisor a reconstruir el razonamiento, no está listo.
Separa el trabajo de backlog del trabajo de diseño. Reproducir un bug viejo, reducir un caso de prueba o añadir un benchmark son tareas donde la asistencia de IA aporta sin mover la responsabilidad al revisor. Un cambio de arquitectura es otra cosa.

El caso de coercion zapping en GHC ilustra bien el límite. Varios ingenieros experimentados —Ben Gamari, Adam Gundry, Sam Derbyshire y Richard Eisenberg— ya habían explorado el problema sin resolverlo del todo. En julio, Sylvain Henry produjo una prueba de concepto con Claude Fable que combinaba ideas de intentos previos; después Sam Derbyshire reescribió la implementación desde cero y siguió investigando. El modelo no resolvió el problema de investigación: la definición del problema, los intentos anteriores y el juicio para evaluar el resultado vinieron de ingenieros que conocían el compilador.

Esa es, probablemente, la conclusión más trasladable. La IA no elimina la necesidad de entender el trabajo; cambia dónde se concentra el esfuerzo. Y en un proyecto con 6.500 tickets abiertos y mantenedores escasos, la pregunta correcta no es cuánto más rápido se escribe código, sino si la tarea se habría hecho en absoluto.