Abre un pull request aleatorio de un equipo que ha "adoptado la IA" recientemente. No de un equipo que la usa con deliberación. De un equipo que simplemente la encendió.
Reconocerás el código al instante. Funciones que casi funcionan. Comentarios que describen qué hace el código en lugar de por qué. Gestión de errores que captura todo y no hace nada. Suposiciones de seguridad tomadas de otro sistema en otra época. Compila. Los tests pasan. Nadie lo entiende del todo.
Eso es slop. El programador Simon Willison lo definió bien: el slop es a la IA lo que el spam es al correo electrónico. Alto volumen, bajo esfuerzo, indistinguible a primera vista de lo real. La diferencia entre slop y código no es el formato. Es la intención, la precisión y la responsabilidad.
Y esto es lo que nadie quiere decir en voz alta: los equipos que envían slop no son víctimas de la IA. Son víctimas de su propio punto de partida.
La IA multiplica. No suma.
"Garbage in, garbage out." (Basura entra, basura sale.)
— George Fuechsel, IBM, años 60
Esa frase es sesenta años anterior a los LLMs. Nunca ha sido más relevante.
Las herramientas de codificación con IA multiplican lo que llevas al prompt. Si llevas un modelo mental claro del sistema, restricciones precisas y el patrón de cada incidente de producción que has depurado en tu carrera, la IA acelera todo eso. Si llevas vaguedad, un requisito copiado y pegado y ninguna idea de cómo falla ese servicio bajo carga, la IA acelera eso también. Solo lo hace más rápido.
El multiplicador no es el problema. El punto de partida lo es.
Un desarrollador junior usando Claude Code y un arquitecto senior usando Claude Code no están utilizando la misma herramienta en ningún sentido real. Los dos sostienen un martillo. Solo uno sabe dónde están los clavos.
Las dos formas en que se envía slop
Los prompts vagos producen código genérico. "Construye un flujo de autenticación" te dará un flujo de autenticación sacado del promedio estadístico de todos los flujos de autenticación que el modelo ha visto. Suposiciones de seguridad promedio. Gestión de errores promedio. Sin considerar tu modelo de amenazas, tu almacén de sesiones, tu middleware existente ni cómo nombra las cosas tu equipo.
Andrej Karpathy acuñó el término vibe coding para esto: describes una sensación y aceptas lo que vuelve. Es una forma válida de prototipar una demo. Es una forma terrible de construir software de producción que otras personas operarán a las 3 de la madrugada.
La aceptación sin revisión es el asesino silencioso. El código generado por IA no tiene calibración de confianza. Suena igualmente seguro cuando acierta y cuando se equivoca de forma sutil. Brian Kernighan planteó el problema en términos que aplican directamente:
"Depurar es el doble de difícil que escribir el código desde cero. Por lo tanto, si escribes el código tan ingeniosamente como puedes, por definición no eres lo suficientemente inteligente como para depurarlo."
— Brian Kernighan, The Elements of Programming Style (1978)
El código que escribe la IA suele ser ingenioso de la manera equivocada. Resuelve el problema declarado mientras crea uno no declarado. Detectar eso requiere un reconocimiento de patrones que solo se construye a través de cicatrices de producción. No hay forma de automatizar la salida de ese paso.
Lo que hacen diferente los arquitectos con experiencia
La diferencia no está en qué herramienta de IA usas. Está en el trabajo que haces antes y después del prompt.
Antes del prompt: Un ingeniero senior codifica contexto que a un junior le llevaría horas encontrar. Los modos de fallo específicos de ese servicio. Las convenciones del equipo sobre los límites de error. El presupuesto de rendimiento que debe respetar esa función. El contrato de datos con el sistema de destino. Todo eso entra en el prompt. El prompt ahora es parte del código base. Trátalo en consecuencia.
Durante la revisión: La pregunta de revisión no es "¿parece correcto?" Es "¿me sentiría cómodo defendiendo esto en un postmortem?" Se lee cada diff. Se ejecuta el código. Se escribe un test contra el caso que habría detectado el último incidente en producción. Si no puedes explicar por qué la implementación es correcta, no lo envías.
A nivel de arquitectura: Los ingenieros senior descomponen el problema antes de tocar la IA. Planifican las costuras: dónde se transforma el dato, dónde se propaga el fallo, dónde debe mantenerse la invariante. La IA rellena los interiores. Los humanos verifican las costuras. La arquitectura sigue siendo trabajo humano.
Martin Fowler escribió que cualquier tonto puede escribir código que entienda un ordenador. Los buenos programadores escriben código que entienden los humanos. La IA optimiza por defecto lo primero. Tu revisión debe corregir hacia lo segundo.
El estándar IBERANT
"El slop ocurre cuando nadie en el proceso tiene las cicatrices para reconocerlo."
— Alejandro Tamayo, Fundador de IBERANT Group
En IBERANT, cada commit pasa por un ingeniero senior que ha vivido el modo de fallo que ese commit podría introducir. La IA acelera el tiempo desde el problema hasta la solución candidata. No cambia lo que ocurre en la revisión. Esa parte sigue siendo humana, rigurosa y lo suficientemente lenta como para ser significativa.
Eso no es una restricción a nuestra velocidad. Es la razón por la que nuestra velocidad es de confianza.
El suelo sube. El techo no.
La IA está subiendo el suelo para el software trivial. Aplicaciones CRUD genéricas, automatizaciones sencillas, andamiaje que antes llevaba un sprint ahora lleva una tarde. Bien.
El techo es otra historia. El techo es donde las decisiones de arquitectura se acumulan, donde los límites de seguridad importan, donde las características de rendimiento interactúan con la topología del sistema de formas que requieren sostener el sistema completo en la cabeza. La IA no puede sostener un sistema en su cabeza. Para eso necesitas un humano, y no cualquier humano.
"La perfección se alcanza no cuando no hay nada más que añadir, sino cuando no hay nada más que quitar."
— Antoine de Saint-Exupéry
Ese instinto, saber qué eliminar del output de la IA, es exactamente lo que da la experiencia. Los ingenieros que lo desarrollen tendrán una década extraordinaria por delante. Los que se salten ese trabajo y simplemente acepten lo que genera el modelo se quedarán preguntándose por qué su código rápido se rompe despacio.
Si quieres un equipo que conozca la diferencia, hablemos.