Kyle Kingsbury (Jepsen): los LLM erosionan la confianza

Kyle Kingsbury: la confianza en el software dejó de ser gratis

Kyle Kingsbury, autor del framework de pruebas de sistemas distribuidos Jepsen, advirtió que el uso de LLM erosiona la confianza en la documentación, en el software y en las organizaciones que los producen. Su tesis aparece junto a su análisis de ParticleDB 1.1.4, y llega en un momento incómodo: una encuesta de la Linux Foundation a 234 contribuidores y mantenedores de código abierto estima que el 25% de las contribuciones entrantes son de baja calidad o generadas por IA, una cifra que sube al 31% en los proyectos grandes, según recogió Help Net Security.

Para un founder, la advertencia no es filosófica. Si las señales que usabas para decidir en qué software confiar —documentación cuidada, historial de mantenimiento, reportes de bugs serios— se pueden falsificar a bajo costo, entonces cada decisión de compra, integración o dependencia técnica se vuelve más riesgosa y más lenta.

¿Qué dice exactamente Kingsbury sobre los LLM?

La cita, recopilada por Simon Willison, plantea dos ideas que conviene separar.

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 →

La primera es de diagnóstico: "el uso de LLM erosiona la confianza en la documentación, en el software y en las organizaciones que los producen". Kingsbury agrega que quizá los ingenieros empiecen a tratar cualquier proyecto nuevo con sospecha, porque las señales que usábamos como marcadores de un sistema maduro ahora son más fáciles de falsificar.

La segunda es una pregunta abierta: en la era de los LLM, ¿qué pueden hacer los mantenedores para asegurar software correcto y documentación precisa? Y, una vez hecho ese trabajo, ¿cómo lo demuestran a los usuarios?

Ese segundo punto es el más incómodo para cualquier equipo que construye producto. No alcanza con escribir buen código: hay que poder probar que es bueno, ante una audiencia que ya no confía en las apariencias.

La documentación como señal que ya no se puede leer de un vistazo

Históricamente, la documentación funcionaba como un proxy de calidad. Un README completo, un changelog ordenado o una guía de migración bien escrita sugerían un equipo que se tomaba en serio su producto. Ese atajo mental se está rompiendo: un LLM puede producir en segundos un README impecable para un proyecto que nadie mantiene.

El mismo fenómeno golpea a los reportes de seguridad. Google congeló las presentaciones de vulnerabilidades de producto de su programa de recompensas para código abierto hasta 2027 tras recibir una avalancha de reportes generados por IA, muchos de ellos inexplotables o directamente inventados, según reportó Android Headlines citando a TechCrunch. Los ingenieros gastaban tiempo revisando falsos positivos en proyectos como Golang, Angular y Fuchsia en lugar de arreglar riesgos reales.

El caso de curl muestra que el problema se puede gestionar. En 2025 su líder, Daniel Stenberg, describió el proyecto como desbordado por reportes de vulnerabilidad generados por IA. Para abril de 2026, según Help Net Security, Stenberg afirmaba que el proyecto había dejado de recibir ese ruido y recibía en cambio reportes de seguridad cada vez mejores, casi todos asistidos por IA. La diferencia no fue la herramienta: fue el proceso que el proyecto puso alrededor.

¿Por qué el código generado por IA se ve bien y falla después?

Hay un dato que explica por qué la confianza ciega es peligrosa. Un estudio de New Relic citado por Help Net Security encontró que el código generado por IA introduce casi el doble de problemas críticos en producción que el código humano revisado por pares. La razón es estructural: los LLM generan código que funciona en condiciones limpias y predecibles, pero las fallas aparecen en casos límite, concurrencia, APIs obsoletas y cambios de estado complejos.

El mismo reporte señala que los ingenieros de confiabilidad y DevOps pierden hasta un tercio de su semana laboral depurando y refactorizando código generado por máquinas que llegó a producción sin revisión. Y hay un sesgo de confianza difícil de desactivar: una encuesta de Snyk citada por TechTarget reveló que cerca del 80% de los desarrolladores creía que el código generado por IA era más seguro que el escrito por humanos.

La conclusión práctica es que la revisión en el momento del pull request no alcanza. El código se lee en el editor, pero se comporta en producción. La observabilidad —logs, trazas, alertas— se vuelve parte del trabajo de escribir código, no un paso posterior.

¿Qué significa esto para tu startup?

Si tu equipo usa asistentes de código, la advertencia de Kingsbury se traduce en decisiones concretas de proceso, no en renunciar a la herramienta.

Define una política de contribución con IA por escrito. La encuesta de la Linux Foundation encontró que apenas un tercio de los proyectos tiene una política formal que permita contribuciones asistidas por IA, y uno de cada diez las prohíbe. El resto no tiene nada escrito. En una startup de 10 o 50 personas, esa ambigüedad se paga en discusiones y en código sin dueño. Copia una práctica simple: el kernel de Linux pide una línea "Assisted-by:" en el mensaje de commit que nombre la herramienta y el modelo usados.
Exige que quien envía el código lo haya probado. El mismo estudio muestra que seis de cada diez contribuidores dicen revisar línea por línea el código generado antes de enviarlo, pero uno de cada cinco nunca menciona que usó IA. Poner la responsabilidad de la prueba y la divulgación en quien contribuye es más escalable que revisar todo a mano.
Mueve la observabilidad al prompt. Si tu equipo ya usa IA para escribir código, pídele explícitamente que incluya telemetría: qué loguear, qué alertar, qué trazar. Es más barato que descubrir el problema con usuarios reales encima.
Trata el código de IA como código de un desconocido. No es pesimismo, es el estándar que ya aplican los equipos maduros: revisión, linting y pruebas de seguridad antes del merge, igual que con cualquier contribución externa.

La pregunta que tu producto tendrá que responder

Kingsbury cierra con una pregunta que vale para cualquier empresa de software, no solo para proyectos abiertos: una vez que hiciste el trabajo de construir algo correcto, ¿cómo lo demuestras?

En un mundo donde la documentación y las señales de madurez se pueden fabricar, la respuesta se corre hacia lo verificable: pruebas reproducibles, métricas de comportamiento en producción, auditorías externas, historial público de incidentes y cómo se resolvieron. La confianza deja de ser una impresión y se convierte en evidencia que alguien más puede comprobar.

Para un founder hispanohablante que compite por talento y clientes en mercados donde el capital es más escaso, esto es una oportunidad: si la calidad se vuelve difícil de fingir, quien pueda demostrarla con datos gana una ventaja que no se compra con presupuesto de marketing.