Manifiesto No AI Slop: 12 reglas contra el código de IA

Manifiesto No AI Slop: qué propone y por qué nace ahora

Doce compromisos, cinco valores y una definición incómoda: eso es el manifiesto No AI Slop, firmado por los ponentes y asistentes del AIE Code Summit 2026. El documento abre con una comparación deliberada. En 2001, 17 ingenieros y líderes de software se reunieron en un refugio de esquí en Snowbird, Utah, para responder al problema de su época: los procesos de desarrollo pesados y guiados por documentación. De ahí salió el Manifiesto Ágil, cuatro valores y doce principios que reordenaron la industria. Sus autores aspiran a lo mismo ahora, con la IA como telón de fondo.

Para un founder el tema es operativo, no filosófico. Si tu equipo ya usa agentes para escribir código, documentación o propuestas, es probable que el cuello de botella se haya movido de producir a revisar. Eso cambia dónde conviene invertir el próximo dólar en herramientas y dónde conviene poner personas.

¿Qué es el ‘slop’ según el manifiesto?

La definición del texto es quirúrgica: hay slop cuando ponemos menos esfuerzo en producir algo que el que le pedimos al consumidor para entenderlo.

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 →

De ahí se derivan dos aclaraciones que evitan malentendidos frecuentes:

Usar IA no convierte algo en slop por sí solo. El manifiesto incluye el vibe coding y los prompts de un solo tiro entre las herramientas de alto apalancamiento.
El slop aparece cuando pasamos la salida de un modelo sin asumir responsabilidad por su calidad ni por la experiencia de quien la lee.

El documento enmarca el problema como una asimetría de costos: producir un pull request de mil líneas o un documento de diez páginas cuesta casi cero, mientras revisarlo sigue costando lo mismo que siempre. Y agrega dos advertencias que cualquier CTO reconocerá: el slop se compone (cuanto más queda en la base de conocimiento, en el chat y en el código, más de eso lee y copia el siguiente agente) y desgasta (cuanto más slop circula en un equipo, menos voluntad queda para pelear contra él, y la calidad empeora con el tiempo en lugar de mejorar).

Los cinco valores del manifiesto No AI Slop

El texto replica la estructura del Manifiesto Ágil con cinco pares de valores. En cada par, lo primero pesa más que lo segundo:

Resultados por encima de volumen producido.
Entendimiento por encima de velocidad.
Tu propio pensamiento por encima del primer borrador de un modelo.
Mejor trabajo por encima de trabajo más fácil.
Mejorar el sistema por encima de parchear la salida.

El quinto valor es el que suele separar a los equipos maduros del resto. Parchear la salida resuelve el incidente de hoy; mejorar el sistema evita que el mismo error vuelva la semana que viene.

Los doce compromisos que un equipo puede adoptar mañana

Las resoluciones del manifiesto se pueden agrupar en cinco bloques prácticos:

Tiempo humano como recurso escaso. Optimizar para usar bien la atención del equipo, y no para generar más artefactos.
Pensar antes de escribir. Los firmantes se comprometen a explorar recursos, código y trabajo previo para entender el problema antes de que empiece la ejecución, y a ser dueños de la intención, el criterio y las consecuencias de lo que publican.
Transparencia y revisión proporcional. Cuando algo lo escribió un agente, se dice. Lo que importa se revisa antes de salir. La revisión automática ayuda, pero no alcanza: qué subconjunto se revisa a mano depende del riesgo de cada cambio.
Medir lo que de verdad importa. Qué se envió, quién lo usa y cómo le ayuda pesa mucho más que las líneas de código, los pull requests mergeados, los tokens gastados o la cantidad de agentes corriendo en paralelo.
Convertir errores repetidos en guardarraíles. Cuando un fallo aparece dos veces, la corrección va al sistema: lo que un linter, un chequeo de tipos o una validación automática pueda atrapar, que lo atrape.

También hay una regla de convivencia que vale la pena copiar tal cual: cuando alguien te envía slop, se lo dices con amabilidad y le pides que lo revise primero. Casi todos necesitamos esa nota en algún momento.

El manifiesto tiene respaldo en los datos: más código no es más software

El documento no es solo una declaración de principios. Un estudio de investigadores de Harvard, reportado por Ars Technica con datos de la plataforma de analítica de ingeniería Jellyfish —300 millones de eventos de trabajo, más de 700.000 empleados y más de 700 empresas de software entre 2021 y marzo de 2026— encontró un patrón que confirma la tesis central del manifiesto.

La adopción de agentes de IA en una empresa se traduce en un aumento promedio del 30% en las líneas totales de código, del 20% en los commits y del 23% en los pull requests. Pero la tasa de resolución de Issues y Epics —es decir, de funcionalidades completas— no cambió de forma estadísticamente significativa tras la introducción de esas herramientas. La ganancia en la fase de escritura se absorbió aguas abajo: según el estudio, el proceso de revisión de código se alarga, los pull requests tienen más probabilidades de requerir revisiones adicionales y los revisores dejan más comentarios.

En otras palabras: la revisión humana funciona como cuello de botella del rendimiento total, y el aumento de volumen no se traduce automáticamente en más producto terminado.

Cuando el código se abarata, la escasez se muda de lugar

Forbes publicó en su consejo tecnológico un análisis de Luis Aburto, fundador y CEO de Scio, que apunta en la misma dirección desde la economía de la ingeniería: la IA baja el costo de producir código, pero el código es solo un insumo del software. Alguien tiene que decidir qué construir, entender cómo encaja en el entorno existente, verificarlo, asegurarlo y comprobar si genera el resultado de negocio esperado.

El artículo ofrece un ejemplo útil para dimensionar el problema: si implementar una función baja de dos semanas a tres días pero la validación sigue tomando 10, el siguiente dólar de mejora probablemente corresponde a automatización de pruebas, observabilidad o documentación de sistemas, no a más generación de código. La misma nota recuerda que DORA describe la IA como un amplificador de lo que ya existe en el entorno de ingeniería, y advierte sobre métricas de actividad como pull requests, tickets cerrados y velocidad: la IA puede inflarlas todas sin mejorar el resultado.

El slop no vive solo dentro del repositorio

El fenómeno excede al código. DoubleVerify detectó más de 500 millones de impresiones de contenido generado por IA de baja calidad —AI slop— durante el primer semestre de 2026, según reportó ExchangeWire. El mismo informe señala que casi la mitad (48%) de los consumidores del Reino Unido afirma que ver una marca anunciada junto a contenido de IA de baja calidad afectaría negativamente su percepción de esa marca, y un 30% dice que el impacto sería muy negativo.

Para un founder que produce contenido o compra medios, la lectura es directa: el slop que tu equipo genera en marketing tiene un costo de marca medible, igual que el slop que se acumula en el repositorio tiene un costo de mantenimiento.

¿Qué significa esto para tu startup?

El manifiesto es útil porque convierte una intuición difusa en decisiones concretas de gestión. Cinco movimientos aplicables esta semana:

Audita dónde está tu cuello de botella real. Mide cuánto tarda un cambio desde la idea hasta producción, no cuánto tarda el agente en escribirlo. Si el tiempo se pierde en revisión, pruebas o decisiones de producto poco claras, generar más código no te va a salvar.
Define un umbral de revisión por riesgo. No todo merece la misma atención: establece qué tipos de cambio requieren lectura humana completa y cuáles pueden pasar con validaciones automáticas. El propio manifiesto lo plantea así, con el nivel de escrutinio atado a las consecuencias.
Declara el origen. Si un agente redactó un documento, un correo a un cliente o una especificación, dilo y revisa lo que importa antes de enviarlo. Cuesta segundos y te protege de firmar algo que no leíste.
Convierte errores repetidos en guardarraíles. La primera vez se arregla a mano; la segunda se automatiza el chequeo. Es la diferencia entre aprender y solo apagar incendios.
Cambia el tablero de métricas. Si tu reporte de ingeniería celebra tokens consumidos o agentes en paralelo, está midiendo actividad. Muévelo hacia tiempo hasta valor validado, confiabilidad y costo operativo.

Cómo se ve esto en un equipo pequeño de LATAM o España

En equipos con menos capital, la asimetría del slop pega más fuerte. Un equipo grande puede absorber una revisión que se duplica; una startup de ocho personas que dedica dos días a revisar código generado en una hora acaba de perder la semana. Por eso la parte más aprovechable del manifiesto para una empresa temprana no son los valores, sino los compromisos operativos: guardarraíles automáticos, transparencia sobre lo que escribió un modelo y métricas orientadas a resultado.

El otro punto relevante es cultural. El documento reconoce explícitamente que mucho slop nace de la presión: empresas que le piden a su gente redefinir lo que es humanamente posible. Si tu equipo está enviando trabajo sin revisar, antes de culpar al entusiasmo por la IA vale la pena revisar qué incentivos y qué plazos estás fijando tú.

Conclusión

El manifiesto No AI Slop llega en un momento en que la evidencia empieza a ordenarse: la IA multiplica el volumen de código y de documentos, pero no garantiza mejores productos, y el costo de revisar sigue siendo humano. Los firmantes —nombres conocidos del ecosistema de ingeniería de IA como Dex Horthy, Philip Kiely, Kent C. Dodds, Lauren Tan, Tejas Kumar y Francisco Javier Arceo— no presentan una receta cerrada. El propio texto admite que ninguno tiene esto resuelto y que cada equipo está redefiniendo qué acepta y qué no.

Esa honestidad es, quizás, la parte más útil. No hay una política de IA correcta y universal para 2026, pero sí hay una pregunta que separa a los equipos que escalan de los que se ahogan en su propio output: ¿estamos usando la IA para pensar mejor, o solo para producir más rápido de lo que podemos entender?