Saltar al contenido
ReviewRamble

El boletín semanal

La IA, analizada, en tu bandeja de entrada.

  • Nuevas reseñas de herramientas, modelos, servidores MCP y repos, con el veredicto por delante
  • Precios y valoraciones revisados cuando algo cambia
  • Nuevos análisis en cuanto se publican

Modelos, agentes, servidores MCP y las herramientas que de verdad merecen tu tiempo.

Un correo a la semana. Date de baja con el enlace de cualquier boletín. Cómo usamos tu correo

Noticias e investigación de IA

Noticias ·

Desarrolladores publican un manifiesto 'No AI Slop' inspirado en el ágil

Ponentes y asistentes de la AIE Code Summit 2026 publicaron un manifiesto que define el 'slop' como un trabajo que costó menos producir de lo que exige al lector. Recoge cinco valores, como la comprensión por encima de la velocidad, y 12 propósitos, entre ellos indicar cuándo un agente escribió algo y revisar los resultados según lo que esté en juego. Reúne 352 firmas.

Cualquiera que haya recibido una pull request enorme o un documento de diez páginas que nadie parece haber leído antes de enviarlo reconocerá el problema del que trata este manifiesto. Ponentes y asistentes del AIE Code Summit 2026 han publicado un manifiesto No AI Slop, inspirado a propósito en el Manifiesto Ágil que 17 ingenieros escribieron en un refugio de esquí de Snowbird, Utah, en 2001. No es un producto ni una norma, pero da a los equipos palabras comunes para un coste que los agentes de programación han hecho muy visible.

El formato copia de cerca al Ágil. Hay cinco pares de valores: resultados por encima de volumen, comprensión por encima de velocidad, tu propio razonamiento por encima del primer borrador de un modelo, mejor trabajo por encima de trabajo más fácil, y mejorar el sistema por encima de parchear el resultado. La definición central es práctica: hay slop cuando alguien pone menos esfuerzo en producir algo del que pide al lector para entenderlo. Usar IA no convierte por sí solo el trabajo en slop; sí lo hace pasar el resultado sin responsabilizarse de él.

El argumento más sólido es el de la asimetría. El coste de producir un cambio de mil líneas o un documento largo tiende a cero, mientras el coste de revisarlo sigue igual, y los autores señalan que un enjambre de agentes puede producir en un día más de lo que una persona podría revisar en toda su vida. También advierten de que el slop se acumula, porque el siguiente agente lee y copia lo que haya en el código, la wiki y el historial del chat.

Las resoluciones son modestas y aplicables. Decir cuándo un agente ha escrito algo que envías y revisar las partes importantes. Avisar a los compañeros, con amabilidad, cuando te han enviado slop. Dejar que linters, comprobadores de tipos y pruebas automáticas detecten lo que puedan, y arreglar el sistema cuando el mismo error aparece dos veces. Medir lo que se ha entregado y a quién ayuda, no líneas de código, pull requests fusionadas, tokens o agentes en paralelo. Para los equipos que usan Claude Code, Cursor o Codex, este último punto es un desafío directo a los paneles de uso que muestran esas herramientas.

Los límites son los de cualquier manifiesto. No tiene forma de hacerse cumplir, quienes lo firman son sobre todo personas a las que ya les importa, y admite que ninguno lo tiene resuelto. También reconoce que los prompts de un solo intento y el vibe coding son útiles. Que cambie conductas depende de que se sumen los responsables, no solo los ingenieros.

Nuestra opinión: Lo valioso es la definición: carga el coste sobre quien revisa, que es justo donde duelen los pull requests e informes generados con IA. Aun así, un manifiesto cambia poco por sí solo, y lo difícil, la presión laboral por producir volumen, se nombra pero no se resuelve.

Fuente: Hacker News

Más historias