Construir en un mundo de slop: calidad de software en la era de la IA

La generación es gratis. El gusto no.

Treinta segundos. Eso es lo que toma generar una página de checkout completamente funcional con integración de Stripe, diseño responsivo y atributos de accesibilidad. El código compila. Los tipos pasan. Incluso se ve correcto para un reviewer junior desplazándose rápido. Pero algo está mal. El espaciado se siente claustrofóbico. Los estados de error no comunican nada útil. El loading skeleton parpadea durante 12ms en una conexión rápida, creando un glitch visual que nadie especificó como bug porque nadie pensó en especificarlo.

Esto es slop (contenido generado en masa sin criterio ni intención humana). No es software roto. No es software con bugs. Es software que técnicamente funciona pero no lleva evidencia de que un ser humano pensante lo moldeó para otros seres humanos.

En product.engineer, definimos la calidad del software en la era de la IA como algo que ya no se trata de si el código se ejecuta. Se trata de si el código merece existir en su forma actual, de si alguien con gusto y convicción miró el resultado y dijo "esto es lo suficientemente bueno para poner nuestro nombre." El product engineer es esa persona. Se sitúa en la intersección exacta donde la capacidad técnica se encuentra con el juicio de producto, donde la pregunta cambia de "¿podemos construir esto?" a "¿debería esta implementación específica salir a producción?"

El término "slop" entró al discurso general a principios de 2025, describiendo inicialmente contenido generado por IA que inundaba las redes sociales. Para mediados de 2025, los ingenieros comenzaron a aplicarlo al código. En el keynote del AI Engineer World's Fair que acumuló más de 319,000 vistas en YouTube, el ponente expuso una tesis que resonó profundamente: cuando los costos de generación se acercan a cero, el único diferenciador es la capacidad humana para distinguir lo bueno de lo suficientemente bueno y de la basura. La audiencia, miles de ingenieros construyendo con IA a diario, respondió con algo entre reconocimiento y temor.

Reconocieron el problema porque lo estaban viviendo.

Cómo se ve el slop en producción

El slop no es binario. Existe en un espectro, y la forma más peligrosa se encuentra justo en el medio: código que pasa cada verificación automatizada mientras degrada la experiencia del usuario a través de mil micro-fallas de juicio.

Así se ve el slop en la práctica en diferentes capas del stack:

Ninguno de los elementos en la columna "lo que la IA genera" está mal. Todos funcionan. Todos pasan CI. Todos cumplen los requisitos literales. Y todos huelen a que a nadie le importó.

El costo compuesto

Según el reporte Developer Coefficient de Stripe, los desarrolladores pasan el 42% de su tiempo lidiando con deuda técnica y mantenimiento de sistemas existentes. Ese número, ya alarmante, fue medido antes de que el código generado por IA se convirtiera en la norma. Cuando multiplicas dramáticamente el volumen de código mientras mantienes la calidad constante en "técnicamente correcto", estás fabricando deuda técnica a escala industrial.

PostHog publicó un análisis interno a principios de 2026 mostrando que los PRs compuestos principalmente por código generado por IA requirieron 2.3x más commits de seguimiento dentro de 30 días comparados con PRs escritos por humanos. No porque el código de la IA estuviera roto. Porque tomó decisiones sutilmente incorrectas que solo se hicieron aparentes cuando usuarios reales interactuaron con la funcionalidad. Órdenes de clasificación por defecto incorrectas. Paginación que cargaba 50 elementos cuando el usuario del percentil 90 tenía 200. Posicionamiento de tooltips que funcionaba en el monitor de 27 pulgadas del desarrollador pero ocultaba información crítica en un laptop de 13 pulgadas.

Estos no son bugs. Son fallas de gusto. Y se acumulan.

Por qué la calidad del software en la era de la IA es un problema humano

El problema fundamental es este: los modelos de lenguaje optimizan para la plausibilidad. Generan código que se ve como código correcto. Se basan en patrones de millones de repositorios para producir resultados que estadísticamente se asemejan a software de calidad. Pero asemejarse a la calidad y ser calidad son cosas diferentes.

El software de calidad es opinado. Toma decisiones que reflejan una comprensión profunda de quién lo usará, bajo qué condiciones, con qué restricciones. Linear no se ve como se ve porque alguien escribió el prompt "construye una herramienta de gestión de proyectos." Se ve así porque Karri Saarinen y su equipo tomaron miles de decisiones deliberadas sobre qué incluir, qué excluir y cómo cada píxel debería sentirse durante la interacción.

Esa palabra, "sentirse," es la que la IA no puede acceder. No todavía.

Las tres dimensiones de la calidad de software que la IA no puede garantizar

1. Adecuación contextual. ¿Es esta la solución correcta para este usuario específico en esta situación específica? La IA genera desde patrones generales. La calidad requiere conocimiento local. Las optimizaciones de checkout de Shopify funcionan específicamente porque los ingenieros entienden la curva de ansiedad de un comprador en los últimos segundos antes de la compra. Un modelo entrenado en todos los checkouts producirá un checkout mediano, no uno afinado para la audiencia de un merchant específico.

2. Coherencia a través del tiempo. ¿Esta funcionalidad se siente como si perteneciera al mismo producto que todo lo demás que hemos lanzado? La coherencia de producto es una propiedad emergente de un equipo que mantiene estándares, modismos y opiniones compartidas durante meses y años. Cada PR generado por IA parte de cero contexto sobre lo que el producto ya es.

3. Restricción intencional. ¿Qué decidimos NO hacer, y por qué? Las decisiones de calidad más difíciles son sustractivas. El panel de constraints de Figma podría hacer más. Los blocks de Notion podrían soportar más anidamiento. El dashboard de Vercel podría mostrar más métricas. La calidad vive en la contención.

Un product engineer sostiene las tres dimensiones simultáneamente. Es la capa de gusto y oficio entre la generación bruta y el producto que sale a producción.

El rol de guardián de calidad

Aquí es donde la industria se divide en dos campos. Un campo dice: la IA mejorará, los problemas de calidad son temporales, solo esperen al próximo modelo. El otro campo, que incluye a todas las empresas que producen software que la gente realmente ama usar, dice: la calidad es una responsabilidad humana que requiere juicio humano, independientemente de cómo se generó el código.

Estoy firmemente en el segundo campo. Después de años como Sr. Product Engineer en AWS, habiendo orientado a más de 12,000 ingenieros de diferentes niveles de madurez, y habiendo evaluado a más de 600 ingenieros en hiring loops, he notado un patrón consistente. Los ingenieros que producen resultados de calidad, aquellos cuyo código puedes reconocer por su claridad e intencionalidad, no son los que escriben más código. Son los que rechazan más borradores. Los que reescriben el primer intento. Los que miran el resultado generado e inmediatamente ven lo que falta.

Cuando fundé dos empresas, la lección más difícil no fue sobre lanzar rápido. Fue sobre mantener estándares bajo presión. El slop es seductor porque es rápido. Puedes lanzar cinco funcionalidades en el tiempo que toma lanzar una bien elaborada. A los inversores les gusta la velocidad. A los usuarios les gusta la calidad. La tensión entre estas dos fuerzas es donde la mayoría de los productos mueren silenciosamente.

El product engineer resuelve esta tensión redefiniendo qué significa "terminado." Terminado no es "funciona." Terminado es "funciona, se siente bien, maneja casos borde con gracia y no crea carga downstream."

Cómo se ve el guardianaje de calidad en el día a día

Alguien en este rol revisando código generado por IA hace preguntas diferentes a las de un code reviewer tradicional:

• ¿Esto coincide con los patrones de interacción existentes del producto? Si cada otra lista en nuestra app soporta navegación por teclado, esta nueva lista también debe hacerlo, aunque nadie lo mencionó en la especificación.
• ¿Qué pasa cuando esto falla? No "si" sino "cuando." La IA generó el happy path. ¿Qué hay del estado vacío? ¿El estado de permiso denegado? ¿El estado de timeout de red?
• ¿Estaría orgulloso de hacer una demo de esto? Una heurística sorprendentemente efectiva. Si no le mostrarías esto a otro ingeniero que respetas, no está terminado.
• ¿Esto genera preguntas para el usuario? Cada etiqueta ambigua, cada cambio de estado sin explicación, cada acción sin feedback claro es una pequeña falla de calidad que erosiona la confianza.

El espectro del slop y el estado de la calidad del código con IA

No todo el código generado por IA es slop. No todo el código escrito por humanos es de calidad. El problema es que la IA hace trivialmente fácil producir grandes volúmenes en el nivel de "técnicamente correcto pero sin inspiración," y la mayoría de las organizaciones carecen de mecanismos para empujar ese resultado hacia calidad genuina antes de que salga a producción.

Aquí hay un marco para pensar dónde cae el código en el espectro de calidad:

Nivel 1: Roto. No compila, tiene bugs obvios, falla tests. La IA rara vez produce esto hoy. Las verificaciones automatizadas lo atrapan. No es el problema interesante.

Nivel 2: Funcional. Funciona según lo especificado. Pasa tests. Sin bugs obvios. Aquí es donde aterriza el 80% del output de la IA. También es donde vive el slop, porque "funciona según lo especificado" no dice nada sobre si la especificación estaba completa o si la implementación consideró las mil cosas que las especificaciones nunca mencionan.

Nivel 3: Considerado. Funciona según lo especificado Y maneja casos borde, coincide con patrones existentes, usa abstracciones apropiadas, nombra las cosas claramente, falla con gracia. Esto requiere revisión humana e iteración. La IA puede llegar aquí con contexto fuerte y múltiples pasadas, pero solo cuando la guía alguien que sabe lo que "considerado" significa para este producto específico.

Nivel 4: Elaborado. Todo del Nivel 3, más el código refleja una visión genuina sobre el dominio del problema. Anticipa necesidades futuras sin sobre-ingeniería. Le enseña algo al siguiente desarrollador por ser legible. Hace que el producto se sienta cohesivo. Este nivel esencialmente requiere gusto humano.

Nivel 5: Elegante. Raro. Código que resuelve el problema de una manera que te sorprende con su claridad, que te hace pensar "por supuesto, ¿por qué lo harías de otra forma?" Este es el dominio de ingenieros senior que han internalizado el espacio del problema tan profundamente que la solución parece inevitable en retrospectiva.

La crisis del software infinito no es que la IA produzca código de Nivel 1. Es que la IA inunda el mundo con código de Nivel 2 mientras los productos que la gente ama requieren Nivel 3 y superior.

Cómo operan diferente las empresas que se preocupan por la calidad

Las organizaciones que producen el mejor software en 2026 comparten patrones comunes en cómo manejan el código generado por IA. Estos no son teóricos. Son prácticas observables.

Linear: la opinión como funcionalidad

Linear lanza rápido. Su changelog es implacable. Pero cada funcionalidad que lanzan lleva una opinión coherente sobre cómo debería sentirse el trabajo de ingeniería. Usan IA en su proceso de desarrollo, pero su resultado nunca se siente generado porque cada pieza pasa por un filtro de calidad que pregunta "¿esto se siente como Linear?"

Esa pregunta no se puede automatizar. Requiere personas que hayan internalizado lo que "sentirse como Linear" significa, personas que notarían si un tooltip usara una curva de animación ligeramente diferente o si un estado vacío usara copy correcto pero sin personalidad.

Vercel: la experiencia del desarrollador como oficio

El dashboard de Vercel podría ser una interfaz CRUD estándar. La funcionalidad subyacente, deployments, dominios, variables de entorno, no es exótica. Lo que lo hace software de calidad es la atención obsesiva al workflow del desarrollador. Preview deployments con URLs instantáneas. Entornos basados en branches que simplemente funcionan. Mensajes de error que te dicen exactamente qué salió mal y qué hacer al respecto.

Nada de esto sucede por accidente. Nada de esto emerge de "genera un dashboard de deployment." Emerge de ingenieros que entienden la frustración de un desarrollador intentando depurar un build fallido a las 11pm y diseñan cada interacción para reducir esa frustración.

Stripe: el diseño de API como decisión editorial

La API de Stripe es famosamente bien diseñada. Cada nombre de endpoint, cada parámetro, cada código de error refleja decisiones editoriales sobre qué importa. Cuando la IA genera una API basada en un modelo de datos, produce endpoints técnicamente correctos. Cuando un ingeniero con sentido de producto diseña una API, produce endpoints que se sienten naturales para el desarrollador que los llama, porque ha pensado en el contexto de uso, no solo en los datos que se transfieren.

Los procesos internos de Stripe reportadamente incluyen reuniones de "API review" que funcionan como consejos editoriales. La pregunta nunca es solo "¿esto funciona?" Es "¿un desarrollador que encuentre esto por primera vez entendería qué hace y por qué?"

Un marco para mantener la calidad a la velocidad de la IA

Producir software de calidad mientras se usan herramientas de IA no se trata de rechazar la IA. Se trata de construir procesos que traten el output de la IA como primer borrador, nunca como trabajo terminado. Aquí hay un marco que funciona.

El Quality Stack

El Quality Stack de product.engineer es un modelo de cinco capas para mantener la calidad del software cuando la IA se encarga de la generación. Cada capa requiere herramientas diferentes e involucramiento humano diferente:

1. Correctitud (automatizada). Tests, verificación de tipos, linting. La IA es excelente aquí. Automatizar completamente.

2. Consistencia (semi-automatizada). ¿Esto coincide con los patrones existentes? Las guías de estilo, registros de decisiones arquitectónicas y reglas de lint personalizadas pueden detectar algo de esto. Los product engineers detectan el resto durante la revisión.

3. Completitud (liderada por humanos). ¿Esto maneja todos los estados? Vacío, cargando, error, permiso denegado, rate-limited, usuario nuevo. Esto requiere alguien que piense en términos de journeys de usuario, no funciones.

4. Coherencia (requiere humanos). ¿Esto se siente como si perteneciera a nuestro producto? Solo alguien que conoce el producto profundamente puede responder esto.

5. Oficio (requiere humanos). ¿Es esta la mejor versión de sí mismo? ¿Podría la interacción ser más ajustada? ¿El copy más claro? ¿El feedback más rápido? Esto es gusto.

Las capas 1-2 del Quality Stack escalan con la IA. Las capas 3-5 escalan con personas que son dueñas del producto de extremo a extremo. Las organizaciones que invierten solo en las capas 1-2 lanzan slop. Las organizaciones que invierten en las cinco capas del Quality Stack lanzan productos que la gente ama.

La regla 30-30-30

La regla 30-30-30 de product.engineer es un marco de asignación de tiempo para desarrollo asistido por IA. Dedica 30% de tu tiempo a la especificación (definir qué construir y cómo se ve "terminado"), 30% a la generación e iteración (usar IA para producir y refinar código), y 30% a revisión y pulido (examinar el resultado con ojos frescos, probar casos borde, refinar detalles de interacción). El 10% restante es deployment, monitoreo y aprendizaje del comportamiento en producción.

La mayoría de los equipos actualmente dedican 10% a especificación, 70% a generación y 20% a todo lo demás. La regla 30-30-30 corrige este desequilibrio. El resultado de ignorarla es predecible: rápido, abundante y descuidado.

El product engineer como filtro final

Cada funcionalidad que se lanza pasa a través de una serie de filtros. Los requisitos filtran lo imposible. El diseño filtra lo incoherente. La ingeniería filtra lo roto. Pero en la era del código generado por IA, hay una nueva brecha entre "no está roto" y "realmente es bueno." El product engineer ocupa esa brecha.

Esto no es quality assurance en el sentido tradicional. QA pregunta "¿cumple con la especificación?" El product engineer pregunta "¿es la especificación lo suficientemente buena? Y aunque lo sea, ¿esta implementación capturó lo que la especificación intentaba expresar?"

En nuestra experiencia, las organizaciones con roles dedicados de product engineering (distintos de ingenieros puramente frontend o backend) producen consistentemente software con puntuaciones de satisfacción de usuario más altas y tasas de churn más bajas comparadas con organizaciones con separación de roles tradicional. La diferencia se reduce a la propiedad holística de la calidad desde el concepto hasta la entrega.

Esto coincide con lo que he visto en cada equipo que he orientado. Los ingenieros que son dueños de la calidad de extremo a extremo, que se sienten personalmente responsables de cómo se siente el software, no solo de si funciona, son los cuyos productos sobreviven el contacto con usuarios reales.

Qué pasa cuando nadie cuida la puerta

La alternativa a la calidad intencional es la deriva. Deriva lenta e invisible hacia la mediocridad. Sucede así:

Primer sprint: la IA genera una librería de componentes. Se ve limpia. Se lanza rápido. Todos están contentos.

Tercer sprint: nuevos componentes se generan en estilos ligeramente diferentes. Nadie lo nota porque cada PR se revisa en aislamiento.

Sexto sprint: la app tiene tres tamaños de botón diferentes que se suponía debían ser iguales, dos enfoques competidores para validación de formularios, y mensajes de error que van desde lo híper-técnico hasta lo condescendientemente simple dependiendo de qué sesión de IA los generó.

Doceavo sprint: un nuevo ingeniero se une y no puede distinguir qué es intencional versus accidental. Preguntan "¿esto es un patrón o un error?" y nadie puede responder con confianza. El codebase ha perdido su opinión. Se ha convertido en slop, no por malicia o incompetencia, sino por la ausencia de alguien que se preocupara lo suficiente para decir "no, así no."

Esta es la crisis del software infinito manifestándose al nivel del producto individual. Generación infinita sin juicio finito produce mediocridad infinita.

Desarrollar el músculo de la calidad de software en la era de la IA

La calidad del software en la era de la IA es una habilidad que se puede desarrollar. No es mística. No es "o tienes gusto o no lo tienes." Es un músculo que se construye con práctica deliberada.

Así es como los ingenieros senior desarrollan el instinto de calidad:

Estudiar lo mejor. Usar Linear, Figma, Notion, Arc, Raycast a diario. No solo como herramientas. Como casos de estudio. Notar cada micro-interacción. Preguntar "¿por qué lo hicieron así?" Las respuestas nunca son "porque la IA lo sugirió."

Mantener un registro de rechazos. Durante un mes, guardar cada output de IA que rechaces o reescribas sustancialmente. Categorizar las razones. Después de 30 días, tendrás un mapa claro de dónde falla la IA para tu contexto específico, y ese mapa es tu marco de calidad.

Practicar la página en blanco. Una vez por semana, construir algo pequeño sin asistencia de IA. No para probar que puedes. Para recordar cómo se siente la toma de decisiones intencional en cada nivel. Cuando cada decisión es tuya, notas cuáles importan.

Revisar con temporizador. Poner un temporizador de 15 minutos para cada revisión de PR. Si no puedes articular qué es bueno y qué es "apenas aceptable" en ese tiempo, tu instinto de calidad necesita afinarse.

Lanzar y observar. Hacer deploy de una funcionalidad y luego observar a tres usuarios reales interactuar con ella. La brecha entre lo que esperabas y lo que sucedió es tu educación en calidad.

El mercado recompensa el oficio

Hay un argumento tentador de que en un mundo de generación gratuita, la calidad no importa porque siempre puedes iterar. Lanzar rápido, medir, arreglar. El ciclo lean startup, ahora a 10x de velocidad.

El argumento falla porque los usuarios forman impresiones instantáneamente. Investigaciones del Nielsen Norman Group encontraron que los usuarios forman juicios de calidad sobre el software dentro de los primeros 50 milisegundos de interacción. Esos juicios son resistentes a la actualización, lo que significa que una mala primera impresión requiere aproximadamente 20 interacciones positivas para ser anulada. No tienes 20 oportunidades. Tienes una.

Las empresas que ganan en 2026 no son las que generan más funcionalidades. Son las que generan las funcionalidades más consideradas. El crecimiento reciente de Notion no ha venido del volumen de funcionalidades; ha venido de hacer que las funcionalidades existentes se sientan más pulidas. La posición de mercado de Vercel no se trata de tener más funcionalidades que Netlify; se trata de que cada funcionalidad se sienta deliberada.

El mercado no recompensa el slop, aunque el slop se lance más rápido. Los usuarios pueden sentir la diferencia entre software hecho por personas que se preocuparon y software ensamblado por máquinas sin supervisión. Puede que no lo articulen en esos términos. Dirán "simplemente se siente mejor" o "confío más en él." Pero debajo de ese sentimiento está el oficio: el efecto acumulativo de miles de decisiones de calidad tomadas por constructores que se negaron a dejar que "técnicamente funciona" fuera el estándar.

El imperativo de calidad

Llevamos 18 meses en la era de la generación gratuita. La fiebre del oro inicial, donde la velocidad era todo lo que importaba, está terminando. Las empresas que se adelantaron con pura velocidad ahora se ahogan en carga de mantenimiento, confusión de usuarios y la sensación progresiva de que su producto se siente como todo lo demás.

La siguiente fase pertenece a los constructores que tratan la IA como una máquina de primeros borradores y a sí mismos como editores en jefe. Que entienden que la parte más difícil de construir software nunca fue escribir el código. Fue saber cómo se ve lo bueno y negarse a lanzar algo inferior.

La calidad del software en la era de la IA no es una optimización. Es una estrategia de supervivencia. Construir con gusto. Lanzar con convicción. Rechazar el slop.

Puntos clave

• El slop es software que técnicamente funciona pero no lleva evidencia de que un ser humano pensante lo moldeó para otros seres humanos.
• Los usuarios forman juicios de calidad dentro de 50 milisegundos y requieren aproximadamente 20 interacciones positivas para anular una mala primera impresión.
• Los PRs generados por IA requieren 2.3x más commits de seguimiento dentro de 30 días debido a fallas sutiles de gusto, no bugs.
• La regla 30-30-30 de product.engineer demanda asignación de tiempo balanceada: 30% especificación, 30% generación, 30% revisión y pulido.
• El mercado recompensa el oficio porque cuando la generación es gratis, el juicio humano y el gusto se convierten en el único diferenciador.

FAQ

¿Qué es "slop" en ingeniería de software?

El slop se refiere a código o funcionalidades generadas por IA que son técnicamente funcionales pero carecen de decisiones de diseño intencionales, manejo adecuado de casos borde y pensamiento coherente de producto. El término se originó en la creación de contenido y fue adoptado por ingenieros en 2025 para describir software que funciona pero no muestra evidencia de juicio humano ni oficio.

¿Cómo mantienen los product engineers la calidad del software al usar herramientas de IA?

Los product engineers mantienen la calidad tratando el output de la IA como un primer borrador en lugar de trabajo terminado. Aplican el Quality Stack: automatizan las verificaciones de correctitud y consistencia, luego invierten juicio humano en completitud, coherencia y oficio. La práctica clave es preguntar "¿estaría orgulloso de hacer una demo de esto?" antes de marcar algo como terminado.

¿La calidad del software en la era de la IA requiere rechazar las herramientas de IA?

No. Los equipos de software de mayor calidad en 2026 usan IA extensamente. La diferencia está en el proceso. Invierten tiempo en especificación antes de la generación, revisan el output contra estándares de calidad a nivel de producto en lugar de solo correctitud técnica, y mantienen opiniones fuertes sobre cómo se ve "bueno" para su producto específico.

¿Cómo pueden los ingenieros desarrollar mejor gusto en calidad de software?

El gusto se desarrolla a través de práctica deliberada: estudiar productos conocidos por su calidad (Linear, Figma, Stripe), mantener un registro de rechazos del output de IA que reescribes, construir proyectos pequeños sin IA para practicar la toma de decisiones intencional, y observar usuarios reales interactuar con tus funcionalidades lanzadas. Es una habilidad, no un rasgo innato.

¿Por qué la calidad del software es más importante ahora que antes de la generación de código con IA?

Porque el volumen amplifica los diferenciales de calidad. Cuando todos pueden generar código a la misma velocidad, el código en sí ya no es una ventaja competitiva. La ventaja se desplaza hacia el juicio, el gusto y el oficio. Los usuarios pueden sentir la diferencia entre software considerado y software ensamblado. En un mercado inundado de herramientas funcionales pero genéricas, la calidad es lo que gana confianza, retención y disposición a pagar.

Lectura relacionada

• What Is a Product Engineer? La definición fundamental del rol responsable de la calidad desde el concepto hasta la entrega.
• The Infinite Software Crisis Por qué generar más código más rápido está creando más problemas de los que resuelve.
• Taste and Craft in Product Engineering Una exploración más profunda de cómo el juicio de calidad se desarrolla y escala a través de los equipos.
• The State of AI Code Quality Datos y análisis sobre cómo se ve realmente el código generado por IA en sistemas de producción.
• How to Become a Product Engineer El camino práctico para desarrollar las habilidades discutidas en este artículo.