¿Está la IA generando un mundo lleno de code slop?

La IA puede aumentar la cantidad de código que se produce. La pregunta que investiga este artículo es si un equipo puede verificar ese resultado al mismo ritmo.

Eso no demuestra que el código sea malo. Plantea una posibilidad más incómoda: cuando producir cambios plausibles se vuelve más barato sin un aumento proporcional de la capacidad de verificación, los equipos pueden acumular código más rápido de lo que pueden demostrar que es necesario, correcto, seguro, comprensible y que vale la pena mantenerlo.

Esa brecha es donde crece el code slop.

La expresión es provocadora, pero la pregunta que hay detrás se puede medir. ¿Los repositorios que usan asistencia de IA acumulan más ediciones innecesarias, advertencias, complejidad, churn, pruebas superficiales, trabajo de revisión, vulnerabilidades y costos de mantenimiento? ¿O estamos confundiendo una autoría poco familiar con una calidad deficiente?

La evidencia disponible hasta August 12, 2026 no respalda la afirmación simplista de que el código generado por IA siempre es peor que el escrito por humanos. Los estudios controlados a veces encuentran una calidad local igual o ligeramente mejor. Sin embargo, a escala de repositorio y producción, estudios más recientes reportan señales preocupantes en complejidad, revisión, verificación y uso de recursos, con importantes salvedades metodológicas.

Mi conclusión es más acotada que «la IA está arruinando el software», pero sigue siendo seria:

La IA no está generando automáticamente un mundo de code slop. Puede abaratar la creación y el envío de cambios con poca evidencia, mientras deja la verificación como un costo elevado para quien los recibe.

En resumen

• Escrito por IA no significa baja calidad. Un estudio controlado y prerregistrado no encontró una penalización sistemática en la mantenibilidad posterior dentro de sus tareas de Java, y GitHub reportó mejoras moderadas de calidad en un ejercicio acotado con Copilot.
• La advertencia más fuerte aparece a escala de repositorio. Dos estudios cuasiexperimentales relacionados de 2026, realizados por equipos de investigación con integrantes en común, reportaron estimaciones preocupantes de complejidad después de adoptar herramientas de IA. En el estudio de Cursor, los estimadores alternativos apuntaban en la misma dirección, pero eran menos concluyentes estadísticamente; considera los resultados como evidencia de riesgo, no como un veredicto causal universal.
• Parte del slop se puede medir directamente. El artículo TRIM de July 2026 define CodeSlop como modificaciones que se pueden eliminar conservando el comportamiento de la tarea. En las trayectorias de reparación exitosas, eliminó entre 17.9% y 32.9% de las líneas de los parches en los escenarios evaluados de Live-kBench; en SWE-Bench, 327 de 330 reparaciones minimizadas conservaron el resultado del oráculo oculto.
• Las pruebas pueden generar una falsa confianza. Un clasificador sintáctico etiquetó el 80.2% de 86,156 diffs acumulados de parches en archivos de pruebas escritos por agentes como carentes de señales explícitas de un oráculo o con señales débiles. Eso no evalúa las aserciones existentes fuera del diff ni demuestra debilidad semántica.
• La revisión se está convirtiendo en parte del cuello de botella. Los comentarios de revisión generados por IA pueden añadir su propio ruido, y los desarrolladores son mucho mejores para reconocer aserciones generadas correctas que incorrectas.
• La seguridad sigue siendo una dimensión de calidad independiente. La evidencia a nivel de aplicación muestra que pasar pruebas funcionales no implica seguridad; los benchmarks a nivel de repositorio también encuentran dificultades persistentes para escribir código seguro.
• El open source puede absorber la externalidad. La generación barata puede reducir el esfuerzo de envío mientras los maintainers siguen pagando el costo de verificación.
• No uses un único «puntaje mágico de slop de IA». Da seguimiento a un perfil de salud del repositorio que abarque corrección, mantenibilidad, costo de revisión, seguridad, responsabilidad y externalidades, comparado con tu propia línea base histórica.

Qué aprenderás aquí

• Qué preguntas podemos responder actualmente sobre el impacto de la IA en la calidad del código
• Qué puede significar «code slop» sin reducirlo al estilo o a impresiones subjetivas
• En qué discrepan los experimentos controlados y los estudios a escala de repositorio
• Por qué pasar pruebas, las tasas de merge y un análisis estático sin hallazgos son señales incompletas
• Cómo el slop pasa de un parche a la arquitectura, las colas de revisión y los ecosistemas open source
• Cómo implementar un perfil sencillo de salud del repositorio usando datos de Git, pull requests, CI, seguridad e incidentes
• Cómo establecer un presupuesto de complejidad generada sin fingir que la telemetría del repositorio demuestra causalidad de la IA

Audiencia: ingenieros y arquitectos que deciden cuánto cambio generado por IA puede absorber de manera segura su sistema de entrega.

Empieza con mejores preguntas

«¿Es malo el código generado por IA?» es una pregunta demasiado vaga para investigarla bien.

Mezcla al menos cinco artefactos diferentes:

1. la salida original del modelo
2. el código que un desarrollador aceptó en un editor
3. un pull request después de la revisión humana
4. el código integrado después de la revisión y CI
5. el código desplegado después de los controles de producción

Esas poblaciones no son intercambiables. La selección humana elimina algunas sugerencias malas. La revisión reescribe otras. CI detecta algunas fallas y pasa por alto otras. Un estudio de las sugerencias originales no puede indicar la tasa de defectos en producción, mientras que un estudio de pull requests integrados mide principalmente resultados que sobrevivieron a un filtro.

Las preguntas útiles son más específicas:

• ¿La asistencia de IA hace que una tarea de programación acotada sea más correcta o mantenible?
• ¿La adopción de agentes cambia con el tiempo la complejidad, las advertencias, la duplicación o el churn del repositorio?
• ¿Cuánto contenido de los parches generados es innecesario con respecto a las pruebas disponibles?
• ¿Las pruebas generadas son lo bastante sólidas para detectar un comportamiento incorrecto?
• ¿Cuánta atención humana consume el cambio generado antes y después del merge?
• ¿El código que pasa las verificaciones funcionales aun así introduce costos de seguridad u operativos?
• ¿Quién paga cuando la generación barata produce contribuciones externas de baja calidad?

Estas preguntas producen respuestas diferentes porque miden distintas capas del sistema.

Una definición práctica de code slop

No es útil llamar «slop» al código porque es verboso, genérico o evidentemente escrito por una máquina. Los humanos escriben código repetitivo. La IA puede escribir código elegante. El estilo es una señal débil tanto del origen como del daño.

El artículo TRIM nos da una definición técnica acotada:

CodeSlop es un cambio que se puede eliminar conservando el comportamiento requerido por la tarea.

Para un parche P y un oráculo de validación O, una proporción observada de slop se puede expresar así:

observed_slop_ratio =
  (size(P) - size(minimize(P, O))) / size(P)

La palabra observada importa. Si O solo contiene pruebas públicas débiles, la minimización demuestra únicamente que el código eliminado era innecesario para esas pruebas. No demuestra que el parche más pequeño conserve requisitos ocultos de seguridad, arquitectura, rendimiento o producto.

TRIM usa la trayectoria de un agente para ayudar a encontrar ese contenido eliminable, pero el historial de búsqueda no forma parte de la definición formal.

Para tomar decisiones de ingeniería, mantén acotada la definición formal de CodeSlop y considera las preocupaciones más amplias por separado, como riesgos posteriores:

Esta distinción evita dos errores comunes.

Primero, el código defectuoso no siempre es slop. Un bypass de autenticación conciso es peligroso, pero puede no contener líneas que se puedan eliminar. Segundo, el código redundante no siempre es defectuoso. Un helper duplicado puede conservar perfectamente el comportamiento y, al mismo tiempo, aumentar el costo futuro de mantenimiento.

El repositorio debe medir ambos.

Qué dice realmente la evidencia

La literatura actual no es ni una condena ni una absolución inequívoca.

La interpretación mejor fundamentada es:

1. La IA puede mejorar el trabajo de implementación acotado.
2. El código asistido por IA no es automáticamente más difícil de mantener para otro desarrollador.
3. A medida que crece la adopción, varias señales a nivel de repositorio merecen seguimiento, pero los resultados no son uniformes entre métodos.
4. El diseño del flujo de trabajo puede mitigar esos efectos; no son propiedades inmutables de un modelo.

Este último punto se observa en una pequeña intervención dentro del estudio de producción de Google. En un benchmark controlado de reimplementación de 50 funciones C++ sintetizadas, el uso de prompts específicos por categoría redujo los hallazgos objetivo en 11.1% con respecto al prompt base y mejoró el puntaje de eficiencia del benchmark. No fue un despliegue en producción en toda la organización, pero muestra que el perfil de fallas medido respondió a feedback específico.

El primer mecanismo del slop: los agentes dejan rastros de su búsqueda

Una persona que investiga un bug puede probar tres ideas, descartar dos y enviar el cambio válido más pequeño. Un agente puede dejar ese mismo proceso de búsqueda visible en el diff final:

hypothesis A -> edit files -> tests fail
      |
      v
hypothesis B -> add workaround -> tests partly pass
      |
      v
hypothesis C -> fix root cause -> tests pass
      |
      v
submit A + B + C residue

El parche final pasa las pruebas, así que el ciclo se detiene. Se trata el hecho de pasar las pruebas como si equivaliera a haber minimizado el cambio.

El resultado de TRIM importa porque demuestra que esta no es solo una queja estética. En las trayectorias de reparación exitosas evaluadas, se pudieron eliminar porciones importantes de los parches conservando los resultados medidos.

Esto sugiere que falta una fase en el trabajo del agente:

explore -> implement -> validate -> minimize -> validate again -> submit

El paso de minimización debería preguntar:

• ¿Qué archivos modificados no requiere la solución aceptada?
• ¿Qué ramas y abstracciones provienen de hipótesis descartadas?
• ¿El parche agregó una dependencia para un comportamiento que ya estaba disponible en el repositorio?
• ¿Se puede revertir un bloque del diff y seguir pasando todas las verificaciones independientes?
• ¿El diff final todavía coincide con el alcance solicitado?

Esto no es una instrucción para optimizar en función del menor número de líneas. Un parche pequeño puede ocultar complejidad, y una migración puede ser legítimamente grande. El objetivo es eliminar los residuos de la búsqueda, no la evidencia ni la claridad necesarias.

El segundo mecanismo del slop: la verificación parece más sólida de lo que es

Las pruebas generadas son fáciles de contar. Los buenos oráculos de prueba son más difíciles de crear.

Un oráculo es la parte de una prueba que decide si el comportamiento observado es correcto. Ejecutar una función sin comprobar el resultado correcto ejercita el código, pero no lo verifica de manera sólida.

El estudio All Smoke, No Alarm de June 2026 examinó 86,156 diffs acumulados de parches en archivos de pruebas de 33,596 pull requests escritos por agentes en 2,807 repositorios. Su clasificador sintáctico etiquetó el 80.2% como carentes de señales explícitas de un oráculo o con señales débiles. Tras ajustar por agente, tamaño del pull request, popularidad del repositorio, tipo de tarea y lenguaje, los pull requests cuyo parche de pruebas más sólido contenía varios tipos distintos de oráculos sólidos tenían más probabilidades de integrarse (OR 1.28). Es una asociación, no un efecto causal.

Eso no significa que el 80.2% de esas pruebas fueran inútiles. El clasificador era sintáctico y las verificaciones implícitas todavía pueden detectar fallas. Sí significa que los equipos deberían dejar de tratar estas cosas como pruebas equivalentes:

test file exists
    != assertion checks the requirement
    != test can detect a plausible wrong implementation
    != implementation is secure
    != production behavior is safe

El problema de revisión es más difícil que «que lo revise una persona». En July 2026, un experimento controlado con 86 programadores de Python encontró que los participantes identificaron las aserciones generadas correctas con una precisión del 74%, pero las incorrectas con solo una precisión del 49%, pese a tener una confianza similar. Los comentarios poco especificados redujeron la precisión con respecto a los comentarios exactos, mientras aumentaron la confianza con respecto a no tener comentarios; en general, los comentarios no aportaron mejoras de precisión.

La consecuencia práctica es importante: la plausibilidad es asimétrica. Los artefactos incorrectos que parecen correctos son precisamente los que a los revisores les cuesta rechazar.

Una estrategia de verificación más sólida usa evidencia independiente:

requirement examples
  -> unit and integration tests with meaningful assertions
  -> mutation or negative testing for important rules
  -> static and dependency analysis
  -> security or performance checks where risk requires them
  -> human review of assumptions, scope, and architecture

El agente puede ayudar a crear cada capa. No debería ser el único autor y el único juez de una misma afirmación.

El tercer mecanismo del slop: el éxito funcional oculta otros costos

El código puede ser correcto para la entrada solicitada y aun así ser inseguro, estar acoplado, ser costoso o difícil de operar.

Seguridad

BaxBench evalúa aplicaciones backend generadas mediante pruebas funcionales y exploits ejecutables. En su evaluación de 392 tareas de 2025, el mejor modelo alcanzó 62% de corrección funcional y, en promedio, aproximadamente la mitad de los programas generados correctos pudieron explotarse con éxito.

El benchmark A.S.E. trasladó la evaluación a escenarios a nivel de repositorio y encontró que los parches podían integrarse y pasar verificaciones de sintaxis o calidad estática mientras conservaban alertas de las vulnerabilidades objetivo. No validó dinámicamente la corrección funcional completa.

Estos benchmarks no estiman la tasa de vulnerabilidades del código generado por IA en producción. Generan código en condiciones controladas y prueban deliberadamente escenarios sensibles a la seguridad. BaxBench respalda la conclusión más acotada de que la corrección funcional y la seguridad son resultados separables. A.S.E. muestra por qué el contexto del repositorio y las verificaciones específicas de seguridad siguen importando. Pasar pruebas ordinarias no puede sustituir una afirmación de seguridad.

Rendimiento y acoplamiento

El estudio de C++ en producción de August 2026 encontró un perfil más complejo que «la IA es mala». El código con alto uso de IA presentaba mayores cargas de interfaz y acoplamiento, costos adicionales de copia y asignación, y una mayor dependencia de ciclos explícitos en lugar de APIs optimizadas. La misma cohorte observacional requirió más esfuerzo de revisión; el crecimiento normalizado de la proporción de uso de CPU fue aproximadamente 5% mayor y el de memoria aproximadamente 8% mayor para las funciones con alto uso de IA que para las escritas mayormente por humanos. El diseño no puede establecer que la autoría de IA haya causado esas diferencias. El artículo también reporta menores tasas de reversión y tasas más bajas en varias categorías de corrección y seguridad.

Ese resultado mixto es precisamente la razón por la que un único puntaje de calidad es engañoso. La misma población de cambios puede ser mejor en una dimensión y peor en otra.

Churn

Las reescrituras y eliminaciones a corto plazo pueden indicar que el código se integró antes de estabilizarse. También pueden indicar una limpieza saludable. El estudio de 2026 de aproximadamente 110,000 pull requests encontró resultados de supervivencia y churn a corto plazo sistemáticamente menos favorables para las contribuciones de agentes, pero con efectos generalmente pequeños e importantes diferencias de población entre los repositorios de agentes y humanos.

Trata el churn como un indicador de diagnóstico, no como un veredicto. Resulta útil cuando cambia junto con otras señales, como regresiones, rondas de revisión, complejidad o reinvención repetida.

La capacidad de revisión es un recurso finito

Cuando la cantidad de código que genera un equipo aumenta sin una capacidad de verificación proporcional, las colas de revisión pueden crecer. La revisión no escala automáticamente al ritmo de la generación.

Este es un problema de colas:

agent generation rate > human verification rate
                     |
                     v
             larger review queue
                     |
          +----------+-----------+
          |                      |
          v                      v
   slower delivery       shallower review
                                 |
                                 v
                      more downstream rework

Los patrones observados de tamaño de pull request y tiempo de revisión varían según el agente, la tarea, el repositorio y la población estudiada. Sería incorrecto afirmar que todos los pull requests de IA son más grandes o más lentos.

Lo que sí está bien respaldado es que la automatización de la revisión no elimina su costo.

En un estudio industrial de ICSE de antes y después que abarcó 4,335 pull requests, el tiempo promedio de cierre aumentó de 5 horas 52 minutos a 8 horas 20 minutos, con tendencias divergentes entre proyectos. Después de implementar una política obligatoria de clasificación por parte de los autores, estos marcaron como resueltos el 73.8% de 1,408 comentarios automatizados elegibles en pull requests integrados. Los profesionales percibieron en su mayoría solo una mejora menor de la calidad del código. El diseño no demuestra que la revisión automatizada haya causado el mayor tiempo de cierre.

Un estudio de CodeRabbit de July 2026 examinó 31,073 pares de revisión y feedback de repositorios seleccionados, aproximadamente 9.3% de los 332,693 comentarios de CodeRabbit recopilados. Un análisis etiquetado mayormente por LLM clasificó 36.4% como aceptados, 7.3% como discusión y 56.3% como rechazados. El estudio solo incluyó comentarios que recibieron respuestas, por lo que 56.3% no es una tasa universal de rechazo para todos los comentarios de revisión de IA. Aun así, es evidencia de que la revisión automatizada puede generar una carga considerable de clasificación por falsos positivos, redundancia, desviaciones del alcance y desacuerdos con la intención del desarrollador.

Usar un agente para generar código y otro para revisarlo puede ser útil. No es una prueba independiente por defecto. Los modelos similares pueden compartir puntos ciegos, y un revisor optimizado para comentar siempre puede añadir ruido más rápido de lo que elimina defectos.

El slop sale del repositorio

Dentro de una empresa, el autor y el revisor suelen compartir el costo de mantenimiento. El open source rompe esa simetría.

Un contribuidor puede generar reportes o pull requests plausibles a bajo costo. Los maintainers todavía deben entender el proyecto, reproducir lo que se afirma, inspeccionar el cambio, proteger la compatibilidad y explicar el rechazo. La generación puede reducir el esfuerzo de quien envía una contribución sin reducir en la misma proporción el costo de verificación de quien la recibe.

El proyecto curl ofrece un ejemplo concreto de reportes de seguridad. El July 14, 2025, el maintainer Daniel Stenberg escribió que alrededor del 20% de los envíos de 2025 parecían ser slop de IA, mientras que solo alrededor del 5% de todos los envíos habían demostrado ser vulnerabilidades genuinas a principios de July. Cada reporte podía ocupar a tres o cuatro miembros del equipo de seguridad durante entre 30 minutos y varias horas.

Se trata de un proyecto y un canal de envío, no de una prueba de que la mayoría de los pull requests open source sean spam de IA. De hecho, curl distinguió más tarde su problema de reportes de vulnerabilidades del de los pull requests, donde una CI exhaustiva ofrecía un filtro más sólido.

Un estudio de métodos mixtos de July 2026 que abarcó 294 repositorios grandes orientados a contribuciones externas encontró que la proporción de merges de contribuidores de una sola vez en 2025 estaba 18.18% por debajo de una proyección univariada de series temporales basada en 2023 y 2024. Su análisis de repositorios trató 2025 como una intervención a nivel del ecosistema, no identificó la autoría de IA en cada contribución y no pudo controlar todos los demás cambios de 2025. El estudio respalda con más fuerza una preocupación sobre la capacidad del open source que una causalidad de la IA en toda la plataforma.

La lección arquitectónica sigue siendo útil:

Cuando disminuye el esfuerzo de envío, los sistemas necesitan controles de evidencia en sus puntos de entrada o pueden transferir una carga desproporcionada de verificación a maintainers cuyo tiempo es limitado.

Entre los controles útiles están los ejemplos reproducibles, las pruebas que fallan, los diffs acotados, CI, la declaración de cómo se hizo la contribución, la procedencia y la responsabilidad explícita de un maintainer. Deben evaluar la evidencia en lugar de la identidad o el estilo de escritura del contribuidor, porque los controles demasiado estrictos también pueden excluir a personas nuevas con contribuciones legítimas. El objetivo no es rechazar la asistencia de IA. Es exigir que quien envía una afirmación aporte evidencia junto con ella.

Un perfil práctico de salud del repositorio

No empieces intentando detectar si el código «parece escrito por IA». La autoría mixta de humanos e IA hace que eso no sea confiable, y los equipos pueden ocultar fácilmente la procedencia.

Mide el resultado.

Este perfil es una medida de protección, no un sistema de atribución a la IA. Puede mostrar que la salud del repositorio cambió después de la adopción, pero no puede establecer por qué. Para probar causalidad se necesita un despliegue gradual, un diseño aleatorizado o un estudio cuidadosamente emparejado de antes y después que controle la mezcla de tareas, la cantidad de trabajo entregado, los cambios de equipo y los cambios de herramientas.

Usa seis dimensiones independientes en lugar de promediarlas en un solo puntaje:

Mantén el contexto del valor entregado junto al perfil de riesgo: resultados de producto completados, cantidad de trabajo entregado y tiempo de entrega de extremo a extremo. Un trabajo de mayor valor puede consumir legítimamente más CI, revisión o cómputo. No combines valor y riesgo en un único puntaje opaco; examina si el costo adicional produjo un resultado útil.

Muestra un perfil:

Correctness       GREEN   stable
Maintainability   AMBER   complexity increasing
Review cost       RED     p90 latency above baseline
Security          GREEN   no new high findings
Ownership         AMBER   one critical module under-owned
Externalities     RED     CI and compute cost rising

Esto conserva los compromisos entre dimensiones. Un equipo puede tener una corrección estable mientras sube el costo de revisión, o mejorar la mantenibilidad mientras aumenta temporalmente el churn durante una limpieza.

Implementa la primera versión

Un MVP necesita datos que la mayoría de los equipos ya tiene:

Git history ----------+
Pull-request events --+
CI and scanners ------+--> classify + normalize --> metric snapshots
Deploys and incidents +                               |
                                                       v
                                              compare with baseline
                                                       |
                                                       v
                                              review in engineering retro

Empieza con diez métricas:

escaped_defect_rate
change_fail_rate
new_duplication_density
rewrite_rate_30d
changed_function_complexity_p90
pull_request_size_p90
first_review_latency_p90
new_high_security_findings
critical_path_ownership_coverage
ci_minutes_per_merged_change

Define cada métrica antes de automatizarla. Tres ejemplos:

La primera métrica muestrea directamente el CodeSlop formal, con respecto al oráculo de validación. Las métricas restantes detectan una presión más amplia sobre el repositorio. Nunca describas un aumento en una métrica de reescritura o revisión como prueba de CodeSlop o de causalidad de la IA.

Para cada métrica, guarda suficiente contexto para que sea auditable:

metric: rewrite_rate_30d
value: 0.18
numerator: 1274
denominator: 7078
sample_size: 64
coverage: 0.91
baseline_period: 2026-01-01..2026-06-30
current_period: 2026-07-01..2026-07-31
exclusions:
  - generated files
  - lockfiles
  - migrations
tool_version: repository-metrics@1.3.0

Clasifica las rutas modificadas antes de calcular métricas basadas en líneas. Los clientes generados, el código de terceros incorporado, los snapshots, las migraciones, los fixtures y los archivos de bloqueo tienen patrones de cambio distintos a los del código de producción y no deberían dominar el resultado sin que se note.

Usa medianas y valores p90 para las métricas de revisión y tamaño de cambio. Los promedios pueden ocultar la cola costosa en distribuciones asimétricas.

Compara con tu propia línea base

Los umbrales universales suelen ser un punto de partida incorrecto. Un kernel, una aplicación web, un SDK generado y un pipeline de datos tienen distintos patrones normales de cambio.

Usa de 6 a 12 meses de historial comparable cuando sea posible, segmentado por tipo de trabajo:

• funcionalidad
• corrección de defectos
• respuesta a incidentes
• refactorización
• actualización de dependencias
• migración
• cambio generado

Mantén fija la línea base durante un trimestre. Si cambia todas las semanas, el deterioro se convierte rápidamente en la nueva normalidad.

Para las métricas en las que un valor menor es mejor, una señal robusta de anomalía puede usar la mediana histórica y la desviación absoluta mediana:

robust_z =
  (current_value - historical_median)
  / (1.4826 * historical_median_absolute_deviation)

Si la MAD histórica es cero, no calcules este puntaje. Usa en su lugar una regla explícita para varianza cero, un intervalo de bootstrap o un límite de percentil acordado.

Usa el resultado para iniciar una conversación, no como una evaluación automática del desempeño. Exige anomalías sostenidas para las métricas de proceso ruidosas, pero nunca normalices hasta hacer desaparecer los hallazgos críticos de seguridad o los incidentes graves.

Establece un presupuesto de complejidad generada

El perfil muestra dónde aumenta la presión. Un presupuesto limita cuánto cambio sin verificar entra al sistema.

El presupuesto útil no es «la IA solo puede escribir el 30% del código». Los porcentajes de procedencia son difíciles de medir y fáciles de manipular. En cambio, establece presupuestos para los recursos escasos:

• líneas modificadas y módulos revisables por pull request
• pull requests de agentes simultáneos por revisor calificado
• antigüedad máxima de la cola sin revisar
• nuevas dependencias por funcionalidad sin aprobación de arquitectura
• regresión de complejidad o duplicación permitida en el código modificado
• evidencia de seguridad y rendimiento requerida según la clase de riesgo
• hallazgos de alta severidad sin resolver permitidos al hacer merge: cero, salvo que el riesgo se acepte explícitamente

Una política sencilla podría verse así:

La política debe incluir la opción válida de no hacer cambios. Los agentes tienen un sesgo hacia la acción: si toda tarea termina en un parche, el cambio innecesario se convierte en la condición de éxito.

Reglas contra la manipulación de métricas

Las métricas se vuelven perjudiciales cuando se convierten en cuotas individuales.

Usa estas medidas de protección:

• Nunca clasifiques a los desarrolladores por un puntaje de slop.
• Mantén separadas las seis dimensiones; no las ocultes en un único número ponderado.
• Muestra numeradores, denominadores, tamaños de muestra, exclusiones y cobertura de los escáneres.
• Trata los datos faltantes como desconocidos, no como indicadores verdes.
• Acompaña los pull requests pequeños con el tiempo de entrega y los defectos para que los equipos no puedan manipular el tamaño creando cadenas opacas de PRs.
• Acompaña un número bajo de hallazgos de seguridad con la cobertura de escaneo y auditorías de los hallazgos descartados.
• Acompaña un churn bajo con el valor entregado para que los equipos no puedan mejorar la métrica evitando trabajo necesario.
• Mantén las exclusiones de métricas bajo control de versiones y revisa sus cambios.
• Audita una muestra aleatoria de atribuciones de incidentes, clasificaciones de PRs y hallazgos descartados por los escáneres.
• Usa tendencias de repositorio y equipo, no vigilancia de las pulsaciones individuales.

El perfil existe para mejorar el sistema de entrega, no para demostrar que un desarrollador usó demasiada IA.

Lo que la evidencia todavía no puede decirnos

La investigación avanza rápidamente, pero quedan varias preguntas abiertas:

• ¿Qué sucede con el código escrito por agentes después de 12 o 24 meses, no de tres semanas?
• ¿Qué señales de mantenibilidad predicen incidentes o esfuerzo futuro de ingeniería en lugar de simplemente generar alertas en un analizador estático?
• ¿Los cambios pequeños de agentes guiados por especificaciones superan a los cambios autónomos grandes después de controlar el tipo de tarea?
• ¿Qué controles mejoran realmente los resultados: minimización, pruebas de mutación, restricciones de arquitectura, revisión independiente o modelos más sólidos?
• ¿Cómo se comparan los repositorios empresariales privados con los proyectos públicos de open source?
• ¿Pueden los estudios que consideran la procedencia comparar el trabajo de IA y de humanos dentro del mismo equipo, repositorio, clase de tarea y política de revisión?
• ¿La revisión automatizada reduce el esfuerzo humano total o lo traslada a la clasificación de falsos positivos?
• ¿Cuánta presión sobre las contribuciones open source es generada directamente por IA, en lugar de deberse a un crecimiento más amplio de envíos de bajo esfuerzo?

Cualquier artículo que afirme que esas preguntas ya están resueltas se está adelantando a los datos.

Entonces, ¿está la IA generando un mundo lleno de code slop?

No por sí sola.

La evidencia controlada es suficiente para rechazar la afirmación simplista de que el código asistido por IA es inherentemente imposible de mantener. Los desarrolladores pueden usar IA para producir código correcto, legible y mantenible, y los estudios acotados a veces muestran mejoras moderadas.

Pero el sistema en su conjunto está mostrando señales de alerta.

Los agentes pueden conservar residuos innecesarios de su búsqueda. Las pruebas generadas pueden parecer más rigurosas de lo que son. Dos estudios relacionados sobre adopción en repositorios reportan estimaciones preocupantes de complejidad, con menor confianza estadística en algunas estimaciones de advertencias y comprobaciones de sensibilidad. Los revisores pueden equivocarse con confianza al evaluar artefactos generados plausibles. El código funcionalmente correcto todavía puede ser explotable, y una cohorte empresarial mostró un perfil distinto de costos operativos.

El mecanismo común no es la autoría de una máquina. Es el costo asimétrico:

effort to generate falls
        +
effort to submit falls
        +
verification does not scale proportionally
        =
low-evidence output becomes cheap to produce

Eso convierte la calidad del código en un problema de diseño de capacidad.

Si tu ritmo de generación aumenta, tu ritmo de producción de evidencia debe aumentar con él. Si la capacidad de revisión se mantiene fija, reduce el trabajo en curso. Si los agentes dejan residuos de búsqueda, agrega una fase de minimización. Si las pruebas son fáciles de generar, mide la solidez del oráculo en lugar de contar archivos de pruebas. Si los contribuidores externos pueden enviar afirmaciones a bajo costo, exige evidencia reproducible en el punto de entrada.

La IA no nos obliga a vivir en un mundo de code slop. Puede eliminar la fricción económica que antes limitaba la cantidad de código sin verificar que un equipo o contribuidor podía crear. Que eso se convierta en una ventaja o en contaminación depende del sistema que rodea al modelo.

Lecturas relacionadas

• Cómo mejorar la calidad del código durante el vibe coding
• Cuando el código se abarata, la complejidad se desplaza
• Cómo construir un buen revisor de código basado en agentes
• Un proceso seguro de programación con agentes no es solo un LLM más grande
• El futuro de los ingenieros: por qué entender el sistema perdura más que escribir el código

Fuentes

• Mathai et al., TRIM: reducción del CodeSlop generado por IA mediante la minimización de trayectorias de agentes, July 20, 2026 - definición formal de CodeSlop y resultados de minimización de parches con distintas estructuras de agentes.
• He et al., Velocidad a costa de la calidad: cómo Cursor AI aumenta la velocidad a corto plazo y la complejidad a largo plazo en proyectos open source, MSR 2026 - estudio emparejado de diferencias en diferencias sobre velocidad, advertencias y complejidad después de adoptar Cursor.
• Agarwal et al., ¿IDEs con IA o agentes autónomos? Medición del impacto de los agentes de programación en el desarrollo de software, January 2026 - estudio longitudinal emparejado que compara la adopción centrada en agentes y en IDEs.
• Popescu et al., Investigación de las contribuciones de agentes autónomos en entornos reales, MSR 2026 - aproximadamente 110,000 pull requests y supervivencia del código y churn a corto plazo.
• Borg et al., Ecos de la IA: investigación de los efectos posteriores de los asistentes de IA en la mantenibilidad del software, revisado el February 26, 2026 - contraevidencia controlada sobre mantenibilidad.
• GitHub, ¿GitHub Copilot mejora la calidad del código? Esto es lo que dicen los datos, November 18, 2024, actualizado el February 6, 2025 - estudio aleatorizado de una tarea acotada realizado por el proveedor.
• Tran et al., Caracterización del perfil de calidad de C++ generado por IA en producción, August 6, 2026 - estudio en producción de 3.52 millones de cambios, carga de revisión, señales de calidad y uso de recursos.
• Banik et al., Mucho humo, ninguna alarma: señales de oráculos en código de pruebas escrito por agentes, June 16, 2026 - análisis de 86,156 parches de pruebas escritos por agentes.
• Kaufman et al., Los programadores juzgan mal y con exceso de confianza las aserciones generadas por LLMs, July 9, 2026 - estudio controlado del juicio humano sobre aserciones generadas correctas e incorrectas.
• Vero et al., BaxBench: ¿pueden los LLMs generar backends correctos y seguros?, revisado el May 30, 2025 - pruebas funcionales a nivel de aplicación y exploits de seguridad ejecutables.
• Lian et al., A.S.E: un benchmark a nivel de repositorio para evaluar la seguridad del código generado por IA, revisado el September 18, 2025 - evaluación de código seguro a nivel de repositorio.
• Lin et al., ¿Es útil la revisión de código con agentes? Análisis del feedback de desarrolladores sobre revisiones de CodeRabbit en entornos reales, revisado el July 23, 2026 - respuestas de desarrolladores a 31,073 comentarios de revisión de agentes.
• Samaan et al., La revisión automatizada de código en la práctica, ICSE-SEIP 2025 - estudio industrial de comentarios de revisión, tiempo de cierre de pull requests y calidad percibida.
• Afroz et al., «El slop de IA está haciendo DDoS al open source»: comprender el impacto de las contribuciones generadas por IA en la sostenibilidad del open source, July 4, 2026 - estudio de métodos mixtos sobre la presión de contribuciones open source y las respuestas de los maintainers.
• Daniel Stenberg, Muerte por mil slops, July 14, 2025 - relato cuantificado de un maintainer de curl sobre la carga de reportes de vulnerabilidades de baja calidad.
• Google Cloud DORA, Estado del desarrollo de software asistido por IA 2025 - la IA como amplificador del sistema organizacional que la rodea.
• Stack Overflow, Encuesta de desarrolladores 2025: IA - confianza autodeclarada, resultados casi correctos y frustración al depurar; útil como dato de percepción, no como medición de defectos o tiempo de depuración.
• Forsgren et al., El SPACE de la productividad de los desarrolladores - por qué la productividad de software y la efectividad de ingeniería no deberían reducirse a una sola métrica.
• Google Engineering Practices, CLs pequeños y El estándar de revisión de código - fundamentos prácticos para facilitar la revisión y mejorar la salud del código con el tiempo.