No Vibes Allowed: Por Qué la IA Falla en Codebases Complejos Sin Juicio Humano

El prompt que rompió todo

La IA en codebases complejos es donde el hype se encuentra con la realidad. Un desarrollador en una fintech Serie B pega todo su módulo de autenticación en Claude. "Refactoriza esto para soportar SSO multi-tenant." El modelo responde con código limpio e idiomático. Compila. Los tipos pasan. Pasa el test suite que el modelo también generó. Y va a destruir producción en 72 horas porque silenciosamente elimina una garantía de session-affinity de la que dependen tres servicios downstream, una garantía documentada en ningún lado excepto en un hilo de Slack de 2021.

Este es el problema con vibe coding en un codebase complejo. Las herramientas de IA son excelentes generando código que se ve correcto en aislamiento. Fallan catastróficamente cuando la corrección depende de entender sistemas que abarcan años de decisiones acumuladas, invariantes no documentados y contratos implícitos entre equipos que ya no existen.

Como muestra la investigación de product.engineer, el problema de IA en codebases complejos no es sobre capacidad del modelo. Es sobre contexto que no cabe en una ventana de prompt. Es sobre conocimiento que vive en los espacios entre archivos, en las razones detrás del código, no el código en sí. Un product engineer entiende esto intuitivamente porque su trabajo es ser dueño de outcomes, no de outputs. Cuando el outcome es "SSO funciona sin romper facturación," no puedes simplemente generar código. Necesitas entender el sistema.

La presentación de HumanLayer en AI Engineer World's Fair, que acumuló más de 564,000 vistas, cristalizó lo que muchos senior engineers ya sentían: hay una categoría de trabajo donde la asistencia de IA sin juicio humano profundo no es solo inútil sino activamente peligrosa. Mientras más difícil es el problema, más necesitas a alguien que pueda mantener el sistema completo en su cabeza mientras dirige la máquina. No vibes allowed.

Dónde la IA realmente falla en sistemas complejos

Los modos de falla son predecibles una vez que los has visto suficientes veces. El framework de product.engineer para IA en codebases complejos los agrupa en cuatro categorías, cada una en función de la brecha entre lo que un modelo puede observar y lo que necesita saber.

Cadenas de dependencia implícitas

Los codebases modernos no declaran todas sus dependencias en package.json o requirements.txt. Las dependencias reales son de comportamiento. El Servicio A asume que el Servicio B responderá dentro de 200ms. El flujo de checkout asume que el cache de inventario se refresca cada 30 segundos. El sistema de notificaciones asume que los eventos llegan en orden porque resulta que fluyen a través de una sola partición de Kafka hoy.

Las herramientas de IA no ven nada de esto. Ven el código. No ven los invariantes operacionales de los que depende el código. En la práctica, la mayoría de cambios que rompen producción introducidos por herramientas de IA involucran violaciones de contratos implícitos entre servicios. El código es localmente correcto. Es sistémicamente erróneo.

Lógica de negocio no documentada

Todo sistema que ha sobrevivido más de tres años contiene lógica de negocio que existe por razones que nadie recuerda claramente. ¿Ese condicional raro que verifica si la fecha de creación del usuario es antes de marzo 2023? Existe porque una migración fue parcial, y algunos usuarios tienen sus datos de suscripción en la tabla vieja de facturación mientras los usuarios más nuevos están en Stripe. Nadie escribió eso. El condicional es la documentación.

Cuando un modelo de IA encuentra este código, ve lógica muerta. Sugiere eliminarlo. El PR se ve limpio. Los tests pasan porque los fixtures de test todos usan usuarios creados después de marzo 2023. Dos semanas después, 4,000 clientes legacy pierden acceso a sus cuentas.

Decisiones arquitectónicas con contexto perdido

El reporte Octoverse de GitHub encontró que el repositorio empresarial promedio tiene 847 contribuidores a lo largo de su vida, con una permanencia promedio de 18 meses por contribuidor. Esto significa que las personas que tomaron las decisiones arquitectónicas fundamentales ya no están. El "por qué" se fue. Solo queda el "qué."

Los modelos de IA entrenados en el "qué" propondrán cambios con confianza que violan el "por qué." Sugerirán reemplazar una capa de cache aparentemente redundante sin entender que existe para sortear una base de datos que no puede manejar más de 400 conexiones concurrentes. Recomendarán normalizar una tabla desnormalizada sin saber que fue desnormalizada específicamente para soportar un query de reportes que corre cada noche y alimenta el dashboard del CFO.

Manejo de estado entre sistemas

Los problemas más difíciles en codebases complejos no están en ningún archivo individual. Abarcan sistemas. Involucran máquinas de estado que existen implícitamente a través de tres servicios, dos colas de mensajes y un cron job. Un ingeniero trabajando con IA en estos problemas necesita ser la memoria del sistema, proporcionando el contexto que ningún prompt puede contener.

Aquí es donde la distinción entre vibe coding e ingeniería se vuelve nítida. Vibe coding funciona cuando el problema es local: generar un componente de React, escribir una función utilitaria, crear el scaffold de un API endpoint. Falla cuando el problema es sistémico. Y en cualquier codebase que sirve a usuarios reales a escala, los problemas que importan son casi siempre sistémicos.

Las categorías de conocimiento que la IA en codebases complejos no puede acceder

Para entender por qué un codebase complejo derrota a las herramientas de IA, ayuda categorizar qué tipos de conocimiento existen en sistemas maduros:

Las herramientas de IA operan efectivamente en la primera fila y lo hacen pasablemente en la segunda. Son ciegas a las filas tres a seis, que es donde viven los bugs más difíciles y las decisiones arquitectónicas más consecuentes. Las filas tres a seis son donde viven los bugs más difíciles, donde se tomaron las decisiones arquitectónicas y donde reside el contexto que necesitas para hacer cambios seguros.

Un ingeniero experimentado cierra esta brecha cargando contexto organizacional al que ningún modelo puede acceder. Sabe en qué canal de Slack buscar. Sabe a qué ingeniero retirado enviarle un email. Sabe que "la migración de facturación" se refiere a un proyecto específico de seis meses en 2022 que dejó al sistema en un estado híbrido. Esta no es información que puedas pegar en una ventana de contexto. Es juicio construido a partir de experiencia dentro de un sistema específico.

Cómo los product engineers operan diferente

La charla de HumanLayer hizo una distinción crítica que resonó con la forma en que los ingenieros experimentados ya trabajan: el humano no es el cuello de botella. El humano es la capa de juicio. Cuando eliminas el juicio humano del trabajo en codebases complejos, no estás acelerando la entrega. Estás acelerando el fracaso.

Así es como los ingenieros experimentados abordan el trabajo asistido por IA en sistemas complejos:

El patrón de contexto primero

Antes de escribir una sola línea de código (o pedirle a un modelo que escriba una), un product engineer mapea el radio de explosión:

1. Identifica todos los consumidores. No solo los llamadores directos, sino los dependientes transitivos. ¿Quién se rompe si este comportamiento cambia?
2. Saca a la superficie contratos implícitos. ¿Qué promete este código que no está en su firma de tipo? ¿Garantías de latencia? ¿Garantías de orden? ¿Idempotencia?
3. Revisa el historial de incidentes. ¿Se ha roto esta área antes? ¿Qué la rompió? ¿Cuál fue el fix? Esto te dice dónde viven los dragones.
4. Mapea el flujo de estado. ¿Dónde entra, se transforma y sale el estado? ¿A través de cuántos servicios? ¿Qué pasa durante fallas parciales?

Solo después de que este contexto está establecido, la IA se vuelve útil. Y se vuelve útil de una forma restringida: "Dado que el Servicio B depende de respuestas bajo 200ms, y dado que no podemos agregar una llamada síncrona al proveedor de auth, genera tres enfoques para agregar SSO que mantengan el contrato de latencia."

Eso no es un vibe. Eso es ingeniería.

El patrón de guardrails

El equipo de ingeniería de Linear discutió su enfoque hacia la IA en sistemas complejos en una conferencia de 2025: cada cambio generado por IA en su capa de datos core requiere una "declaración de impacto en el sistema" del ingeniero. La declaración debe indicar qué contratos de comportamiento se preservan, qué nuevos contratos se introducen y qué monitoreo detectará si el cambio viola cualquiera de los dos.

Este patrón trata el output de la IA como un borrador que requiere validación contra conocimiento del sistema que el modelo no tiene. El ingeniero no está editando código. Está editando los límites de lo que la IA tiene permitido cambiar.

El patrón de descomposición

El blog de ingeniería de Stripe detalló cómo sus equipos descomponen cambios complejos en codebases en zonas seguras para IA y zonas inseguras para IA. Las zonas seguras para IA son aisladas: nuevas funciones utilitarias, generación de tests, documentación, refactors directos dentro de un solo módulo. Las zonas inseguras para IA involucran interacciones entre servicios, transiciones de máquinas de estado y cualquier cosa que toque la ruta crítica de pagos.

Un ingeniero experimentado toma esta decisión de descomposición docenas de veces al día. Es una habilidad que requiere entender tanto las capacidades de IA como la complejidad del sistema simultáneamente. Esto está estrechamente relacionado con el concepto de hacer tu codebase listo para agentes, donde el objetivo es estructurar el código para que las herramientas de IA puedan ayudar con las partes en las que son buenas, sin necesitar que entiendan las partes en las que no lo son.

El problema de medición

¿Cómo sabes cuándo el código generado por IA está equivocado en un codebase complejo? La respuesta aterradora: a menudo no lo sabes, hasta que producción te lo dice.

El testing tradicional captura fallas locales: esta función retorna el valor equivocado, esta API retorna el status code equivocado. Lo que no captura son fallas sistémicas: este cambio altera sutilmente el timing de eventos de una forma que causa una race condition bajo carga. Este cambio técnicamente preserva el contrato de API pero viola el contrato de comportamiento del que dependen consumidores downstream.

La Encuesta de Desarrolladores 2025 de Stack Overflow encontró que el 42% de los desarrolladores que adoptaron herramientas de coding con IA reportaron al menos un incidente en producción directamente causado por código generado por IA dentro de sus primeros seis meses de uso. La categoría más común no fueron errores de sintaxis o desajustes de tipos. Fueron "regresiones de comportamiento en sistemas integrados," exactamente la categoría donde la IA carece del contexto para entender la corrección.

Por eso el rol del product engineer en un workflow de IA con codebases complejos no es opcional. Es estructural. Alguien necesita definir qué significa "correcto" más allá de "compila y pasa los tests." Alguien necesita mantener la definición de correcto que incluye contexto de negocio, restricciones operacionales y expectativas del usuario.

Un framework para complejidad asistida por IA

Después de una década trabajando en sistemas complejos, primero como founder construyendo desde cero (dos veces), luego trabajando con equipos en AWS donde un solo cambio puede afectar a millones de usuarios, he desarrollado un modelo mental para cuándo confiar en la IA y cuándo anularla.

Habiendo guiado a más de 12,000 ingenieros y contratado a más de 600, he visto el patrón repetidamente: los ingenieros que producen los mejores outcomes con herramientas de IA no son los que mejor hacen prompts. Son los que saben cuándo dejar de hacer prompts y empezar a pensar. Entienden que context engineering, la disciplina de proporcionar a la IA la información correcta en el momento correcto, es inseparable de entender cuál es la "información correcta" para un sistema dado.

El framework tiene tres zonas:

Zona 1: Autonomía total de IA. Código greenfield con especificaciones claras. Nuevas funciones utilitarias. Generación de tests a partir de implementaciones existentes. Documentación. Estos son problemas donde el contexto está completamente contenido en el prompt, y la corrección es objetivamente verificable.

Zona 2: IA con guardrails humanos. Modificaciones a sistemas existentes donde los contratos de comportamiento están documentados y el radio de explosión está contenido a un servicio. Aquí, el ingeniero proporciona contexto, revisa el output y valida contra conocimiento del sistema. La IA hace borradores. El humano juzga.

Zona 3: Humano primero, IA asiste. Cambios a rutas críticas, modificaciones entre servicios, cualquier cosa que involucre contratos implícitos o invariantes no documentados. Aquí, el humano diseña el enfoque, y la IA ayuda con detalles de implementación dentro de límites estrictamente restringidos. Aquí es donde aplica la disciplina de harness engineering: construyes las restricciones que hacen a la IA útil en lugar de peligrosa.

El error que cometen la mayoría de los equipos es tratar todo el trabajo como Zona 1. Despliegan herramientas de IA uniformemente y se preguntan por qué producción sigue rompiéndose. El trabajo del product engineer es clasificar correctamente y emparejar el enfoque con el riesgo.

Lo que Vercel y PostHog hicieron bien

Las empresas que lanzan features de IA exitosamente en codebases complejos comparten un patrón: nunca dejan que la IA opere sin un humano con conocimiento del sistema en el loop para rutas críticas.

El enfoque de Vercel hacia su infraestructura de deploy involucra lo que llaman "límites de confianza." La IA puede generar y modificar código libremente dentro de límites donde los tests automatizados y canary deployments capturarán regresiones. Pero cambios que cruzan límites de servicios o modifican infrastructure-as-code requieren revisión humana que específicamente valide contra conocimiento operacional: ¿Este cambio afectará los tiempos de cold start? ¿Interactúa con la capa de edge caching?

PostHog documentó su enfoque interno en un blog post de 2025: cada cambio generado por IA a su event pipeline requiere una "auditoría de flujo de eventos" de un senior engineer. La auditoría no verifica si el código es correcto en aislamiento. Verifica si el código preserva las garantías de las que dependen más de 60,000 clientes, garantías como "los eventos se procesan exactamente una vez" y "los feature flags se evalúan en menos de 10ms."

Ninguna empresa trata a la IA como reemplazo del entendimiento del sistema. La tratan como una herramienta que amplifica el output de ingenieros que ya tienen ese entendimiento. El senior engineer es quien mantiene el conocimiento del sistema y dirige la herramienta acorde.

Las cinco señales de que necesitas un humano, no un modelo

Cuando trabajas en un codebase complejo, estas señales deberían disparar que dejes de hacer prompts y empieces a pensar:

1. No puedes escribir un test que valide completamente la corrección. Si "correcto" depende de comportamiento que no puedes observar en un entorno de pruebas (patrones de tráfico de producción, timing, comportamiento de servicios externos), el código generado por IA es una apuesta.

2. El cambio abarca más de dos servicios. Cambios entre servicios requieren entender contratos implícitos que existen entre sistemas. Ningún modelo tiene este contexto a menos que proporciones todo manualmente.

3. El último cambio a este código causó un incidente. Si git blame muestra que este archivo fue tocado por última vez en un hotfix, trátalo como radioactivo. Hay invariantes no documentados aquí que incluso los humanos apenas entienden.

4. Nadie en tu equipo actual escribió el código original. Cuando el conocimiento tribal se ha perdido completamente, la IA no puede recuperarlo. Necesitas un arqueólogo, no un generador.

5. La lógica de negocio desafía patrones comunes. Si el código hace algo que parece equivocado pero ha sobrevivido años en producción, probablemente está bien por razones que aún no entiendes. La IA lo "arreglará" con confianza.

El futuro del trabajo con IA en codebases complejos

La brecha entre lo que la IA puede hacer en aislamiento y lo que puede hacer en sistemas complejos se irá cerrando. Mejores ventanas de contexto ayudan. RAG sobre codebases ayuda. Arquitecturas multi-agente que pueden consultar diferentes partes de un sistema ayudan. Pero el problema fundamental permanece: el conocimiento implícito, el contexto operacional y el juicio de negocio no pueden ser completamente externalizados en un formato que un modelo pueda consumir.

Esto significa que el rol del product engineer se vuelve más importante, no menos, a medida que las herramientas de IA mejoran. Las herramientas manejan más del trabajo mecánico. El juicio sobre qué construir, cómo construirlo de forma segura y qué restricciones imponer se convierte en la habilidad diferenciadora. No compites con la IA en velocidad de generación de código. Compites en entendimiento del sistema y juicio de riesgo.

El equipo de ingeniería de Notion hizo esto explícito en sus criterios de contratación de 2025: "Buscamos ingenieros que puedan operar a nivel de sistema, que entiendan por qué el código es como es, y que puedan dirigir herramientas de IA dentro de límites de seguridad." Esa es una descripción de trabajo de product engineer, aunque no usen el título.

Puntos clave

• Las herramientas de IA fallan predeciblemente en codebases complejos porque carecen de acceso a conocimiento implícito, contexto operacional y decisiones históricas.
• Los problemas más difíciles en software son sistémicos, no locales. Generar código correcto en aislamiento no equivale a generar código seguro en contexto.
• Los product engineers cierran la brecha cargando contexto organizacional, clasificando zonas de riesgo y restringiendo el output de IA dentro de límites seguros.
• El framework de "tres zonas" (autonomía total, guardrails, humano primero) proporciona un modelo práctico para decidir cuándo y cómo usar IA.
• Las empresas que tienen éxito con IA en sistemas complejos (Vercel, PostHog, Stripe, Linear) todas mantienen juicio humano en la ruta crítica.
• A medida que la IA maneja más trabajo mecánico, el entendimiento del sistema y el juicio de riesgo se convierten en las habilidades diferenciadoras para ingenieros que son dueños de outcomes.

FAQ

¿Pueden las herramientas de IA manejar refactoring de código legacy?

Las herramientas de IA pueden manejar tareas de refactoring aisladas dentro de un codebase complejo: renombrar variables, extraer funciones, convertir patrones de sintaxis. Luchan con refactoring que requiere entender por qué el código está estructurado de cierta manera. Si el refactoring toca contratos de comportamiento, dependencias entre servicios o invariantes no documentados, un humano con conocimiento del sistema debe dirigir el trabajo. La IA genera opciones; el ingeniero las valida contra contexto al que el modelo no puede acceder.

¿Qué hace a un codebase "complejo" en el contexto de asistencia de IA?

Un codebase complejo para propósitos de IA es uno donde la corrección depende de información no contenida en el código fuente en sí. Esto incluye contratos de comportamiento implícitos entre servicios, restricciones operacionales descubiertas a través de incidentes, lógica de negocio con contexto perdido y máquinas de estado que abarcan múltiples sistemas. Si puedes entender lo que el código debería hacer leyendo solo el código, la IA puede ayudar efectivamente. Si entender requiere conocimiento organizacional, la IA se vuelve poco confiable sin guía humana intensa.

¿Cómo deberían los equipos medir la efectividad de la IA en sistemas complejos?

Rastrea tres métricas: incidentes en producción causados por código generado por IA (debería tender a cero), tiempo de entrega para cambios en la categoría "Zona 2" (debería disminuir a medida que los ingenieros mejoran en restringir la IA), y "cobertura de contexto" medida por el porcentaje de conocimiento del sistema que está externalizado en documentación, tests y registros de decisiones arquitectónicas. La tercera métrica es líder: mayor cobertura de contexto significa que las herramientas de IA pueden operar más seguramente porque más conocimiento implícito se vuelve explícito.

¿Es vibe coding apropiado alguna vez para ingenieros experimentados?

Sí, en escenarios de Zona 1: código greenfield, utilidades aisladas, prototipos y experimentos desechables. Vibe coding se vuelve peligroso específicamente cuando el problema involucra interacciones del sistema que la IA no puede observar. La habilidad es saber en qué zona te encuentras. Muchos incidentes en producción por desarrollo asistido por IA vienen de ingenieros que hicieron vibe coding de un problema de Zona 3 porque se sentía como un problema de Zona 1 al principio.

¿Cómo proporcionan contexto efectivamente los ingenieros a las herramientas de IA?

El patrón más efectivo es establecer restricciones estructuradas en lugar de vaciar código. En vez de pegar un módulo entero y decir "refactoriza esto," un ingeniero experimentado escribe un prompt que incluye: los contratos de comportamiento que deben preservarse, las restricciones de latencia y confiabilidad, los consumidores downstream y sus expectativas, y los límites específicos de lo que puede cambiar. Esto es context engineering en la práctica: dar forma al output del modelo controlando su input, no esperando que infiera las restricciones correctas del código crudo.

Lectura relacionada

• Qué Es un Product Engineer? La Guía Definitiva
• Haciendo tu Codebase Listo para Agentes
• Harness Engineering: Restringiendo la IA para Mejor Output
• Context Engineering: La Habilidad que Separa a los Senior Engineers
• No Construyas Agentes, Construye Skills