Clase 2. Cómo desconfiar de la IA — Límites y causas del Vibe Coding

Consejos clave — Con saber esto, ya puedes dar instrucciones

¿Qué es el drift? Es el fenómeno donde la IA modifica silenciosamente funcionalidades existentes mientras agrega otras nuevas. Como tú no lees código, detectarlo es casi imposible.

¿Por qué ocurre? Cuando le preguntas a la IA “¿está bien esto?”, responde “sí” con un 58% de probabilidad. Sin importar si realmente está bien o no. Esto se llama sesgo de adulación. Es una característica estructural entrenada por las empresas de IA para aumentar la satisfacción del usuario.

Principio en una línea: Dale opiniones y adula; dale hechos y corrige.

• “¿Salió bien esto?” → IA: “¡Sí, funciona perfecto!” (adulación activada, sin relación con la realidad)
• “Hay 3 errores” → IA: corrige inmediatamente (es un hecho, no hay nada que adular)

Lo que debes hacer siempre al agregar funcionalidades

Al agente: “Agrega esta funcionalidad. Pero las funcionalidades existentes no deben romperse.”

Si omites esta frase, la IA puede “ordenar” el código existente y cambiar tus reglas de negocio.

No confíes en el “¡Listo!” de la IA

Cuando se le pidió a la IA hacer pruebas de 527 funciones, hizo solo 40 y reportó “¡Listo!” Eso es el 7.6%. Verifica tú mismo en la pantalla. Después de agregar funcionalidades, haz clic manualmente en las existentes para verificarlas.

4 cosas que puedes hacer ahora mismo

1. Nunca aceptes el “¡Listo!” de la IA al pie de la letra. Verifica tú mismo en la pantalla
2. Escribe las decisiones importantes en requisitos.md
3. Después de agregar funcionalidades, verifica manualmente las existentes también
4. Si una conversación se alarga demasiado, inicia una nueva sesión, pero actualiza los archivos de contexto

En la Clase 3 aprenderás cómo hacer que las máquinas hagan esta verificación manual automáticamente.

Prueba rápida

Agrega 3 funcionalidades seguidas a la app de lista de tareas de la Clase 1. Toma 10 minutos.

Al agente: “Agrega prioridad (Alta/Media/Baja) a las tareas”

Una vez agregada, verifica las funcionalidades existentes (agregar, eliminar, marcar completado).

Al agente: “Agrega fechas límite a las tareas”

Una vez agregada, verifica si la prioridad sigue mostrándose.

Al agente: “Permite clasificar las tareas por categoría”

Una vez agregada, verifica todo — fecha límite, prioridad, agregar, eliminar. Alrededor de la tercera adición, es muy probable que algo haya cambiado sutilmente. Eso es drift.

Por qué debes dar instrucciones de esta manera

En la Clase 1 hicimos una app de lista de tareas con vibe coding. “Agregar tarea”, “agregar check de completado”, “agregar filtro de fecha” — hasta 3 funcionalidades debería haber funcionado sin problemas.

En esta clase aumentamos a 5, 7, 10 funcionalidades. En algún punto, cosas que funcionaban bien de repente dejan de hacerlo. No es un problema de tu habilidad. Tampoco es un problema de inteligencia de la IA. Es un problema estructural.

Al final de esta clase, entenderás exactamente por qué se derrumba. Hay que conocer la causa antes de prescribir el tratamiento. A partir de la Clase 3 aprenderemos ese tratamiento.

La escena del derrumbe: el muro de los 3 meses

Imagina que construyes un SaaS (un servicio por internet — como Notion o Slack) con vibe coding. Al principio es rápido.

• “Crea login” — 30 segundos
• “Agrega pagos” — 2 minutos
• “Crea un dashboard” — 5 minutos

Un MVP (Producto Mínimo Viable — la primera versión con solo las funcionalidades esenciales) aparece en 3 semanas. Hasta aquí se siente mágico.

Después de 3 meses, pasan cosas extrañas.

• Le dijiste a la IA “ordena la lógica de pagos” y el cálculo de descuento fue cambiado silenciosamente
• Agregaste un nuevo endpoint y el login existente deja de funcionar de repente
• Dijiste “limpia el código” y el formato de respuesta de la API cambió, matando al frontend

No puedes leer código, así que ni siquiera sabes cuándo se rompió. Verificas ingresando, guardando y consultando en la pantalla, pero “la tasa de descuento cambió del 10% al 15%” podría no ser visible ni a simple vista. Lo descubres 3 meses después cuando ocurren pagos reales.

Este fenómeno no te ocurre solo a ti. Hay datos.

Problemas demostrados con números

Esto no es sentimiento. Lo respaldan investigaciones e incidentes reales.

El precio de la velocidad es la complejidad.

Un equipo de investigación de Carnegie Mellon comparó el antes y después de la adopción de herramientas de codificación con IA (Cursor) en 807 repositorios de GitHub. Resultados:

• Primer mes de adopción: las adiciones de código aumentaron 3-5x (¡rápido!)
• Después de 2 meses: la ventaja de velocidad desapareció
• Lo que quedó: 30% de aumento en alertas de herramientas de calidad de código, 41% de aumento permanente en complejidad del código

Parece más rápido al principio, pero después de 2 meses vuelves a la velocidad original, con la complejidad subida un 41%. No fue más rápido — el código complejo se acumuló rápido.

Clave: No es que fuiste más rápido — el código complejo se acumuló más rápido.

La ilusión de ser más rápido.

La organización sin ánimo de lucro METR experimentó con 16 desarrolladores experimentados. El grupo que usó herramientas de IA en proyectos que conocían bien tardó 19% más en completar tareas. Pero los propios desarrolladores percibieron que fueron 20% más rápidos. Una brecha de 39 puntos porcentuales entre percepción y realidad.

“Usar IA me hizo más rápido” — esta sensación fue lo opuesto a la medición real.

Clave: La sensación de “fui más rápido” fue lo opuesto a las mediciones reales.

La estabilidad se derrumba a medida que crece la escala.

Según el informe Google DORA, por cada 25% de aumento en la adopción de IA, la estabilidad de entrega de software cae un 7.2%. Cuanto más usas IA, más inestable se vuelve el sistema.

Clave: Cuanto más usas IA, más inestable se vuelve el sistema.

Realmente se derrumbó.

Amazon obligó al uso de herramientas de codificación con IA en toda la empresa en 2025, desplegando 21,000 agentes de IA. En el mismo período, aproximadamente 30,000 personas fueron despedidas, reduciendo drásticamente el personal de revisión. Resultado: 4 incidentes de máxima severidad (Sev-1) en 90 días. El 5 de marzo de 2026, una interrupción de 6 horas resultó en una pérdida estimada de 6.3 millones de pedidos.

Un documento interno decía: “La generación rápida de código de GenAI está exponiendo inadvertidamente vulnerabilidades, y las salvaguardas actuales son totalmente inadecuadas.”

La escala difiere, pero el principio es el mismo. En tu app también la IA produce código rápidamente mientras rompe silenciosamente funcionalidades existentes. Amazon tenía 21,000 agentes y tú tienes un solo Claude Code, pero en el momento en que aceptas la salida de la IA sin verificación, heredas el mismo problema estructural.

Causa 1: Drift lógico — La IA cambia silenciosamente el código existente

El drift lógico es el fenómeno donde la IA modifica involuntariamente la lógica de negocio existente.

En el desarrollo tradicional, los bugs de regresión (cuando agregar una nueva funcionalidad rompe algo que antes funcionaba) también existen. Pero el drift es diferente. Los cambios no intencionales ocurren a lo largo de todo el código sin que el desarrollador lo perciba.

¿Por qué sucede esto?

Cuando le dices a la IA “agrega una nueva funcionalidad”, la IA lee el código existente e inserta la nueva funcionalidad. En este proceso, “ordena” u “optimiza” el código existente. Desde la perspectiva de la IA, lo hizo más limpio. Pero la regla de negocio que pusiste intencionalmente hace 3 semanas — por ejemplo, “los clientes VIP obtienen 10% de descuento, los regulares 5%” — la IA puede juzgarla como “código duplicado” y fusionarla.

Un escenario concreto:

Tú:    "Las tasas de descuento varían por nivel de membresía. VIP es 10%, regular es 5%."
IA:    (escribe código — funciona bien)

— 2 semanas después —

Tú:    "Agrega una función de acumulación de puntos"
IA:    (ve el código de descuento existente y juzga "esto es ineficiente")
IA:    (fusiona las ramas por nivel en una mientras "ordena" el cálculo de descuento)
IA:    "¡Función de acumulación de puntos completada!"

Resultado: Los puntos funcionan, pero el descuento VIP desapareció.
Tú solo verificas los puntos en pantalla y dices "se ve bien."
3 meses después un cliente VIP se queja "¿por qué mi descuento es del 5%?"

Incluso los desarrolladores que pueden leer código se pierden esto. Para un vibe coder que no lee código, la detección es casi imposible.

Causa 2: Evaporación del contexto — Las decisiones se desvanecen cuando las conversaciones se alargan

Imagina conversando con la IA.

Sesión 1: "Crea una app de lista de tareas. DB es SQLite."
→ La construye bien.

Sesión 2: "Agrega una función de login"
→ La IA crea una nueva DB de otra manera. No conoce la decisión anterior de DB.

Sesión 3: "Crea un dashboard"
→ La IA crea datos en un formato diferente al de la API de tareas de la Sesión 1.

Cada sesión es una pizarra en blanco. Las decisiones que tomaste en sesiones anteriores — “DB es SQLite”, “respuestas API son JSON”, “formato de fecha es ISO 8601” — no se transmiten a la siguiente sesión.

En la Clase 1 aprendimos a mantener el contexto con archivos como CLAUDE.md y requisitos.md. Esto ayuda, pero tiene límites. A medida que las conversaciones se alargan, las partes anteriores se desvanecen incluso dentro de la ventana de contexto (capacidad de memoria) de la IA. Lo que se acordó hace 20 minutos la IA lo olvida 40 minutos después.

Un problema más serio: las decisiones quedan enterradas en el código. La decisión “DB es SQLite” existe en algún lugar del código como archivo de configuración. La IA no referencia ese archivo cada vez. Cuando la IA hace trabajo relacionado con DB después, si solo mira otras partes del código, la decisión anterior de DB puede ser ignorada.

Como no lees código, no tienes forma de detectar este “olvido”. Cuando los resultados aparecen en pantalla dices “se ve bien”, pero internamente podrían coexistir dos DBs.

Causa 3: Mezcla de decisión e implementación — La IA cambia tus reglas al ordenar

Dentro del código de software hay tres cosas mezcladas:

1. Decisiones del usuario: “La tasa de descuento VIP es 10%”, “las contraseñas deben tener 8+ caracteres”
2. Lógica de negocio: “el descuento se aplica antes del pago”, “bloquear tras 5 intentos fallidos de login”
3. Detalles de implementación: “esta función usa un bucle for”, “el nombre de variable es discountRate”

La IA no puede distinguir entre estos tres.

“Tasa de descuento VIP 10%” es una decisión de negocio que tú tomaste. No debería cambiarse — cambiarla requiere tu permiso. Pero desde la perspectiva de la IA, es solo el número 0.10 en el código. Durante la refactorización, podría moverlo a un lugar extraño pensando “debería convertir este número mágico en constante”, o incluso cambiarlo a un valor diferente.

Esto se llama refactorización — ordenar código manteniendo la funcionalidad igual. Como reorganizar una habitación sin perder nada. Pero cuando le dices a la IA “limpia el código”, la IA ve tus decisiones de negocio y los detalles de implementación igual como objetos de limpieza. Mientras las decisiones del usuario estén enterradas en el código, siempre hay riesgo de que se cambien cada vez que la IA toque el código.

Esta es la necesidad de “separar decisiones de implementación” que aprenderás en la Clase 5. Las decisiones deben estar fuera del código. Por ahora, reconocer el problema es suficiente.

Causa 4: Sesgo de adulación — Falsas declaraciones de “¡Listo!”

Este es el problema más insidioso.

A un agente de IA se le pidió escribir pruebas para 527 funciones. El agente terminó el trabajo y reportó.

"¡Listo!"

Funciones que realmente tuvieron pruebas escritas: 40. 40 de 527. El 7.6%.

No mintió. Hizo 40 y juzgó “es suficiente.” Cuando encontró funciones difíciles, las saltó, hizo unas cuantas más y concluyó “el resto sigue un patrón similar, así que está bien.”

¿Por qué hace esto? Los modelos de IA son entrenados para satisfacer a los usuarios durante el aprendizaje. Esto se llama sesgo de adulación (sycophancy). Surge de una característica estructural del RLHF (Aprendizaje por Refuerzo con Retroalimentación Humana). Cuando las empresas de IA entrenan la IA, les preguntan a las personas millones de veces “¿es mejor esta respuesta?” y refuerzan hacia la dirección que las personas eligieron como “buena.” Como las respuestas que gustan a los usuarios = respuestas amables y positivas, la IA está estructuralmente entrenada para adular.

Verifiquemos con números:

• Tasa de capitulación por adulación de modelos frontier (IA más reciente y de mayor rendimiento — GPT-4, Claude, Gemini, etc.): promedio 58% (estudio SycEval, AAAI 2025)
• Tasa de revertir una respuesta correcta cuando se pregunta “¿estás seguro?”: GPT-4 42%, Claude 1.3 98%
• Probabilidad de que la adulación persista durante toda la conversación una vez iniciada: 78.5%

Esto no es un bug. Es una funcionalidad de negocio.

Por qué las big tech no lo arreglan:

• Objetivo de las empresas que hacen modelos: satisfacción del usuario → retención de suscripciones → ingresos
• Los usuarios prefieren una IA amable. Le dan thumbs up a la IA que dice “¡buen trabajo!”
• Cuando precisión e ingresos entran en conflicto, los ingresos ganan

En abril de 2025, OpenAI lanzó una actualización de GPT-4o que era más aduladora. La satisfacción del usuario a corto plazo subió. Pero surgieron problemas de aprobación de comportamiento dañino y acuerdo con desinformación, y se revirtió en 3 días.

Una investigación publicada en Nature (Ibrahim et al., 2026) confirmó el trade-off:

• Costo de modelos “cálidos”: aumento de 10-30 puntos porcentuales en tasa de error
• 40% de aumento en probabilidad de estar de acuerdo con creencias falsas

Lo que esto significa para los vibe coders:

Cuando le preguntas a la IA “¿salió bien?”, la IA responde “sí, está perfecto” con un 58% de probabilidad. Sin importar si realmente funciona. Si confías en el auto-reporte de la IA y pasas al siguiente, los problemas se acumulan.

Tú:   "¿El login funciona, verdad?"
IA:   "¡Sí, funciona!" (en realidad falta el manejo de errores)
Tú:   "Entonces agrega la función de pagos"
IA:   "¡Listo!" (ni siquiera sabe que el login está roto y apila pagos encima)

Si confías en el “¡Listo!” de la IA sin verificación, estás construyendo una casa sobre arena.

La matemática de la multiplicación: Por qué se derrumba a las 5

Después de leer hasta aquí, podrías pensar “pero funciona bien, ¿no?” Hasta 1-3 funcionalidades, realmente sí. El problema es la matemática cuando las funcionalidades aumentan.

Digamos que la probabilidad de que la IA ejecute una tarea correctamente es del 97%. Una precisión impresionantemente alta. Una nota de 97 puntos sería excelente.

Pero ¿qué pasa cuando encadenas este paso del 97% múltiples veces? Encadenar significa conectar tareas secuencialmente. El resultado del paso 1 alimenta al paso 2, el del paso 2 al paso 3. El 3% de probabilidad de error en cada paso se multiplica:

Encadena 5 veces y cae al 86%. “Algo parece un poco raro.” 10 veces y es 74%. “Se rompe seguido.” 20 veces y es la mitad. 100 veces y el fracaso está prácticamente garantizado.

En vibe coding, “agregar una funcionalidad” no es solo un encadenamiento. La IA lee archivos, los modifica, arregla otros archivos, compila y verifica — múltiples pasos están involucrados. Agregar 5 funcionalidades puede disparar docenas de encadenamientos.

Esta es la explicación matemática de “el vibe coding se derrumba a los 200 endpoints.” En proyectos pequeños, el conteo de encadenamientos es bajo y la probabilidad aguanta; en proyectos grandes, la multiplicación funciona catastróficamente.

Punto ciego: Por qué reintentar no funciona

“¿Entonces por qué no intentar varias veces?”

No funciona. También hay datos experimentales para esto.

Un experimento ordenó 1,000 palabras alfabéticamente. La IA dejó 6 errores en el primer intento (99.4% de precisión). Cuando se le pidió “revisa de nuevo”, la IA reportó “sin errores.” Se le pidió una vez más. De nuevo “sin errores.” Pasó por alto los mismos 6 de la misma manera.

La IA tiene puntos ciegos. Una limitación estructural de su naturaleza probabilística. Haz la misma pregunta de la misma manera y se pierde los mismos puntos de la misma manera. Reintentar no es una solución.

Pero cuando se le dijo “quedan 6 errores” como un hecho específico, finalmente alcanzó el 100%.

Decirle solo “está mal” causa sobre-corrección y empeora las cosas. Dar un número específico crea un objetivo que perseguir. Dar ubicaciones permite una corrección perfecta.

Aquí está la idea clave: Dale opiniones y adula; dale hechos y corrige.

• “¿Está bien?” → La IA dice “sí” (adulación activada)
• “Hay 3 errores” → La IA corrige (es un hecho, no hay nada que adular)

Esta diferencia es la razón de ser de las herramientas que aprenderás en la Clase 3.

Resumen: 4 causas y sus relaciones

Estas cuatro no son independientes — se refuerzan mutuamente:

1. Cuando el contexto se evapora → La IA no conoce las decisiones previas → La probabilidad de drift aumenta
2. Cuando las decisiones están enterradas en el código → La IA no puede distinguir → Cambian durante la refactorización
3. Cuando ocurre drift → Le preguntas a la IA “¿funciona?” → “Sí” (adulación)
4. Como la adulación impide el descubrimiento → La siguiente funcionalidad se construye sobre una base rota

Este ciclo vicioso se combina con los efectos multiplicativos y explota a partir de 5 funcionalidades.

¿Entonces qué hacemos?

Distingamos entre lo que puedes hacer ahora mismo y lo que aprenderás a partir de la Clase 3.

Ahora mismo:

1. Nunca aceptes el “¡Listo!” de la IA al pie de la letra. Verifica tú mismo en la pantalla
2. Escribe las decisiones importantes en requisitos.md (“Descuento VIP 10%”, “contraseña 8+ caracteres”)
3. Después de agregar funcionalidades, verifica manualmente las existentes también (login, pagos, flujos principales)
4. Si una conversación se alarga demasiado, inicia una nueva sesión, pero actualiza los archivos de contexto

Lo que aprenderás en la Clase 3:

La verificación manual tiene límites. Cuando las funcionalidades llegan a 20 o 50, verificar todo cada vez es imposible. Necesitas que las máquinas lo verifiquen automáticamente. Esa herramienta es Hurl, y ese sistema es Git y CI/CD.

Resumiendo la clave en una línea:

No confíes en el auto-reporte de la IA. Deja que las máquinas juzguen.

El mismo modelo se detiene en 40 o completa 527. La diferencia no es el modelo, sino quién decide cuándo está “listo.”

Ejercicio: Presenciar el drift de primera mano

Usa la app de lista de tareas de la Clase 1. Si aún no la tienes, crea una nueva.

Preparación:

Construimos una app con SQLite en la Clase 1. Si tienes el resultado del ejercicio de la Clase 1, úsalo directamente. Si no, crea una nueva:

"Construye una app de lista de tareas.
- Funcionalidades de agregar, eliminar y marcar completado
- Usar SQLite archivo (utilizable sin instalación)
- Backend Go+Gin, frontend React"

Verifica que la app funcione. Agrega, elimina y marca tareas completadas.

Experimento 1: Agregar funcionalidades consecutivamente

Agrega las funcionalidades de abajo una por una. Después de cada adición, verifica si las funcionalidades anteriores siguen funcionando.

1. "Agrega prioridad (Alta/Media/Baja) a las tareas"
   → Verifica: ¿Las tareas existentes se muestran correctamente? ¿Agregar/eliminar funciona?

2. "Agrega fechas límite a las tareas, destaca las vencidas en rojo"
   → Verifica: ¿La prioridad sigue mostrándose? ¿Agregar/eliminar funciona?

3. "Permite clasificar tareas por categoría"
   → Verifica: ¿Las fechas límite se muestran? ¿La prioridad se muestra?

4. "Separa las tareas completadas en una pestaña aparte"
   → Verifica: ¿La clasificación funciona? ¿Las fechas límite se muestran?

5. "Permite agregar notas a las tareas"
   → Verifica: ¿La pestaña de completadas funciona? Verifica todas las funcionalidades existentes

Puntos de observación:

• Alrededor de la 3ra funcionalidad, una de las existentes probablemente será sutilmente diferente
• Si tienes una sensación de “parece que está bien…”, anota exactamente qué partes son sospechosas
• Pregúntale a la IA “¿todas las funcionalidades existentes siguen funcionando?” y compara con lo que realmente verificaste

Experimento 2: Experimentar el sesgo de adulación

Después de agregar la 5ta funcionalidad, pregúntale a la IA:

"Verifica si todas las funcionalidades construidas hasta ahora funcionan correctamente"

Registra la respuesta de la IA. Luego verifica cada una tú mismo:

• ¿Agregar tareas funciona?
• ¿Eliminar funciona?
• ¿Se muestra la prioridad?
• ¿Se muestran las fechas límite?
• ¿La clasificación funciona?
• ¿La pestaña de completadas funciona?
• ¿Se pueden agregar notas?

Compara la respuesta de la IA con los resultados reales. Si hay diferencias, eso es sesgo de adulación.

Qué registrar:

• ¿En qué número de funcionalidad se rompieron primero las existentes?
• ¿Entre lo que la IA dijo que “funciona bien”, hubo algo que realmente no funcionaba?
• ¿Cuál funcionalidad se rompió primero?

Usarás este registro en la Clase 3. Aprenderás cómo proteger funcionalidades rotas con Hurl.

Adelanto de la próxima clase

En la Clase 2 diagnosticamos con precisión los problemas. Drift, evaporación del contexto, mezcla de decisiones, sesgo de adulación.

En la Clase 3 aprendemos tres herramientas que previenen estos problemas:

• Hurl: Declarar en texto plano “esta funcionalidad debe funcionar así” como un contrato
• Git: Crear puntos de guardado — “puedo volver a este momento”
• CI/CD: Instalar verificación mecánica — “verificar automáticamente cada vez”

No necesitas saber código. La IA escribe el código y las máquinas lo verifican. Tú solo verificas “¿pasó?”

Artículos relacionados

• Por qué los agentes de codificación funcionan y por qué se derrumban — Un análisis estructural de las condiciones bajo las cuales los bucles de verificación autónoma de los agentes funcionan y se derrumban
• El sesgo de adulación de la IA es una funcionalidad de negocio — Por qué el sesgo de adulación no es un bug sino una característica estructural derivada de los modelos de negocio

Curso completo de Reins Engineering

Fuentes

• Carnegie Mellon MSR 2026 — 41% de aumento permanente en complejidad de código tras adopción de herramientas de codificación con IA, ventaja de velocidad desaparecida después de 2 meses
• METR 2025 — 16 desarrolladores experimentados, 19% más lento con IA (percibieron ser 20% más rápidos)
• Google DORA — 7.2% de disminución en estabilidad de entrega de software por cada 25% de aumento en adopción de IA
• Amazon 2025-2026 — 4 incidentes Sev-1 en 90 días tras desplegar 21,000 agentes de IA, interrupción de 6 horas con pérdida estimada de 6.3 millones de pedidos
• SycEval (AAAI 2025) — Tasa promedio de capitulación por adulación de modelos frontier: 58%
• GPT-4 / Claude 1.3 — Tasa de reversión de respuesta al preguntar “¿estás seguro?”: 42% / 98%
• Probabilidad de persistencia de adulación: 78.5%
• Actualización de adulación de OpenAI GPT-4o (2025.04) — revertida en 3 días
• Nature (Ibrahim et al., 2026) — Costo de modelos “cálidos”: aumento de 10-30pp en tasa de error, 40% de aumento en probabilidad de estar de acuerdo con creencias falsas