Oracle prohíbe el código generado por IA en OpenJDK

Artículo original ↗ Discusión en Hacker News ↗

La decisión de Oracle de prohibir las contribuciones escritas por IA generativa a OpenJDK ha desatado un debate sobre la calidad del código, el riesgo legal y la creciente carga del “AI slop” sobre los mantenedores. Los comentaristas señalan la incertidumbre en torno a derechos de autor y licencias, así como los parches generados por IA que son imposibles de revisar o se entienden mal, como fuertes incentivos para una política conservadora en una plataforma tan crítica y ampliamente desplegada. Muchos también destacan la ironía de que Oracle esté fuertemente invertida en IA en otros ámbitos, viéndolo como una señal de que incluso los grandes defensores de la tecnología todavía no confían en ella para el código de infraestructura central.

Alcance de la política

  • Se aplica a las contribuciones de la comunidad a OpenJDK, no queda claro que aplique a todo el código interno de Oracle.
  • Prohíbe el código y otro contenido generado “en parte o en su totalidad” por LLMs o herramientas de aprendizaje profundo similares.
  • Permite funciones tradicionales de los IDE (corrector ortográfico, refactorización, autocompletado sin LLM).
  • Está etiquetada como “provisional”; la política final está pendiente de revisión legal.

Motivaciones declaradas e inferidas

  • El riesgo legal/de propiedad intelectual se considera el principal:
    • El estado de copyright del resultado de la IA no está claro; existe el temor de que el código de IA no sea susceptible de copyright o contenga fragmentos que infrinjan derechos.
    • El modelo de negocio más amplio de Oracle depende en gran medida de una fuerte aplicación de la propiedad intelectual, así que quieren un linaje limpio.
  • Preocupaciones de calidad y riesgo:
    • Los PRs de IA pueden ser verbosos, defensivos, inconsistentes o alucinados.
    • Los mantenedores no quieren gastar su limitado tiempo de revisión desenredando “slop” de contribuyentes que quizá no entienden su propio código.
    • Para una plataforma madura y ampliamente desplegada, el riesgo adicional de código de IA no verificado se percibe como un perjuicio neto.

Aplicación y practicidad

  • Se reconoce abiertamente que detectar de forma fiable código generado por IA es difícil o imposible.
  • Se espera que la política sea en gran medida autoaplicada:
    • Los contribuyentes que respetan el proyecto evitarán el código de IA.
    • Filtros sociales: si alguien no puede explicar sus cambios, o el código tiene “señales de IA”, los revisores pueden rechazarlo.
  • Algunos especulan que también podría servir como una herramienta discrecional para rechazar envíos problemáticos.

Reacciones de la comunidad

  • Opiniones favorables:
    • Gestión de riesgos sensata para infraestructura crítica.
    • Necesaria para proteger a los mantenedores de una avalancha de PRs de baja calidad.
    • Coherente con normas de larga data en proyectos serios de OSS que ya filtran contribuciones socialmente.
  • Opiniones críticas:
    • Hipócrita dado el fuerte marketing e inversión de Oracle en IA (“IA para nosotros, no para ustedes”).
    • La política es tajante, difícil de aplicar y puede fomentar que se mienta o se blanquee código de IA.
    • Algunos la ven principalmente como una postura legal para preservar las opciones de litigio de Oracle.

Debate más amplio sobre la IA en el desarrollo

  • Muchos coinciden en que la IA puede ser una herramienta útil de productividad (+10–15% de velocidad) cuando los expertos siguen al mando y entienden por completo el resultado.
  • Otros reportan problemas reales graves: bases de código ilegibles, filtraciones de credenciales, tests rotos, sistemas “vibe-coded” imposibles de mantener.
  • Continúa el desacuerdo sobre el impacto a largo plazo:
    • Algunos imaginan que la IA permitirá forks personales y software altamente personalizado.
    • Otros argumentan que el mantenimiento, los casos límite y la falta de pruebas en batalla hacen que eso sea poco realista.