Vibe coding vs ingeniería real: cuándo se rompe el código generado por IA

Un fundador nos dijo el mes pasado: “Ya no necesitamos ingenieros. Cursor escribe el 90% de nuestro código”. Dos semanas después llamó de vuelta porque su flow de auth estaba filtrando tokens de sesión al fragmento de URL, su pool de conexiones de Postgres se agotaba bajo carga real, y sus webhooks de Stripe estaban procesando pagos dos veces en los retries. Los tres bugs estaban en código que “se veía bien” y pasaba los tests que la IA también escribió.

Este no es un post anti-IA. Usamos IA todos los días. Es un post sobre la diferencia entre vibe coding e ingeniería con IA como herramienta, y por qué la segunda es la única que sobrevive a producción.

Definiendo vibe coding

El término lo acuñó Andrej Karpathy a principios de 2025 para describir un workflow donde le hablas a un LLM, aceptas lo que devuelve, y shippeas sin leerlo con cuidado. Las vibes son buenas. El código se siente bien. Los tests pasan. Ship it.

En 2026 la práctica se expandió mucho más allá del framing original semi-irónico de Karpathy. Hemos visto startups Series A con 30% de su backend committeado por un ingeniero junior apretando tab en Cursor sin revisión senior en el PR. Hemos visto fundadores construyendo MVPs enteros en Bolt y Lovable y luego entregando el codebase a un contractor con “haz que esto escale a 10K usuarios”. El contractor cotiza una reescritura completa. El fundador se sorprende.

Vibe coding produce código que funciona para el happy path en que el modelo estaba pensando. Eso es todo. Todo lo demás está sin verificar.

Dónde funciona realmente el vibe coding

No somos anti-IA. Aquí es donde el workflow está genuinamente bien:

• Scripts desechables. Limpieza de data one-off, parseo de logs, una herramienta de migración rápida que correrás una sola vez. El costo de un bug es “córrelo de nuevo”.
• Prototipos que no van a shippear. Demos internos, design tests, apps de prueba de concepto que vas a botar la próxima semana.
• UI scaffolding. Generar una página de settings, un formulario, una vista de lista. El feedback visual es inmediato; UI roto es obvio.
• Boilerplate. Routes, CRUD básico, definiciones de tipos, fixtures de test simples. Los patrones están suficientemente trillados como para que el modelo rara vez invente.
• Descripciones de PR, docs, changelogs. Donde sea que el output sea texto revisable por humanos, no código ejecutable por máquina.

En los cinco casos, el costo de falla es bajo y la falla es ruidosa. Vibea tranquilo.

Dónde el vibe coding falla silenciosamente

La categoría peligrosa es código que corre, pasa tests, y está mal. Cinco lugares donde lo vemos consistentemente:

1. Race conditions y concurrencia

Los LLMs son modelos estadísticos entrenados en código como texto. Los bugs de concurrencia normalmente no aparecen en el texto — aparecen en el comportamiento en runtime. Un modelo va a escribir feliz un “contador lock-free” que tiene una data race sutil porque vio patrones que se ven similares en su training data.

Ejemplo real de un codebase de cliente el quarter pasado: un procesador de jobs background hecho con vibes que polleaba una cola de Postgres sin SELECT ... FOR UPDATE SKIP LOCKED. Dos workers tomaron el mismo job. El cobro de Stripe corrió dos veces. El cliente disputó. Los “tests” solo tenían un worker.

2. Fronteras de seguridad

El modelo sabe suficiente para agregar bcrypt y llamarlo auth. No sabe suficiente para pensar en:

• Session fixation vs regeneración de sesión en login
• Las implicaciones de CSRF del framework específico que estás usando
• Si tu JWT secret se lee al load del módulo y queda cacheado de una forma que rompe rotación
• Las 14 formas en que tu endpoint de file upload puede convertirse en un SSRF

Auditamos 22 codebases vibe coded en los últimos 9 meses. Cada uno tenía al menos una vulnerabilidad OWASP Top 10 en código shipping a producción. La mediana fue 4.

3. Edge cases que el modelo no pensó en testear

Un modelo escribe una función. El modelo escribe tests. Los tests cubren lo que el modelo estaba pensando. No hay adversario en el loop. El usuario que pone '; DROP TABLE users;-- como primer nombre, el entero que overflowea en mes 13, la network call que timeoutea a la mitad, la zona horaria que está 30 minutos off de UTC — nada de esto estaba en el contexto del modelo, así que nada está testeado.

No atrapas lo que no piensas en buscar. Los ingenieros senior tienen tejido cicatricial de outages previos que los vuelve paranoicos en los lugares correctos. Los modelos no.

4. Sistemas distribuidos y consistencia

La categoría más dura. El modelo va a escribir confiado código que “guarda en la base de datos y luego envía una notificación”. Eso es un dual-write problem. Si el servicio de notificaciones está caído, la DB se actualiza y la notificación se pierde. Si la DB se cae después de la notificación, al usuario le dicen que pasó algo que no pasó.

La ingeniería real involucra patrones outbox, idempotency keys, sagas, transacciones compensatorias. El modelo no va a alcanzar estos a menos que le hagas prompt específicamente, y aún así frecuentemente produce una versión medio correcta que se rompe de formas sutiles bajo falla parcial.

5. Performance bajo carga realista

A los LLMs les encanta Promise.all con 10,000 items. Les encantan los queries N+1 vestidos como cadenas elegantes de .map(). Les encanta cargar la tabla entera de usuarios en memoria porque “es limpio”.

Estos problemas no aparecen en ningún test. Aparecen cuando tu cliente con 200K filas en su cuenta abre el dashboard y espera 8 segundos.

El costo de limpiar código vibe coded en producción

Vemos esto mucho. Un fundador shippea rápido con vibe coding, gana tracción, luego se da cuenta de que el codebase no puede tomar un segundo ingeniero porque nadie puede razonar sobre él. Nos llama.

Costo promedio de un engagement de vibe-cleanup para un codebase de 30K LOC: $30K-$70K y 6-10 semanas. Costo promedio de haber escrito ese mismo codebase con disciplina de ingeniería desde la semana uno: $25K-$50K y 8-12 semanas.

El camino vibe se ve más barato al comienzo. Es casi siempre más caro en 18 meses una vez que cuentas el cleanup, los bugs customer-facing en el ínterin, y el tiempo del cofounder gastado debugueando en vez de vendiendo.

Los 5 guardrails que sí funcionan

Si vas a usar IA para código de producción (deberías), aquí están los cinco guardrails que usamos en cada engagement.

Guardrail 1 — Code review no es negociable

Cada PR generado por IA recibe revisión de un ingeniero humano que puede leerlo línea por línea y razonar sobre él. No “scan por vibes”. Leer.

Esto significa que la IA es un multiplicador de productividad en gente que ya sabe escribir buen código. No es reemplazo de alguien que sabe qué es buen código.

Si tu reviewer también está vibe coding, colapsaste el guardrail. Dos LLMs asintiéndose mutuamente.

Guardrail 2 — Requerimientos de test coverage, pero los correctos

No midas porcentaje raw de coverage. Mide: ¿tienes un test para cada frontera externa (API, DB, third party), cada path de auth, cada transición de state machine, cada rama de retry/error?

Usamos un “boundary test budget” en vez de targets de coverage. El coverage se gamea con tests que existen para subir el número. Los boundary tests chequean las cosas que efectivamente se rompen.

Guardrail 3 — Eval pipelines, no solo unit tests

Para cualquier feature asistida por IA que involucre lógica de negocio, mantenemos un eval suite: un set de inputs reales representativos (incluyendo los adversarios) que corre en cada PR. Esto atrapa el bug clase “el modelo regeneró esta función y ahora falla en el caso X”.

Los evals son baratos. Nunca nos arrepentimos de tenerlos. Nos arrepentimos muchas veces de no tenerlos.

Guardrail 4 — Autonomía con scope

Los agentes IA y sesiones Claude/Cursor reciben permisos con scope, no acceso completo al repo. Específicamente:

• No pueden pushear a main directo
• No pueden correr migraciones contra producción
• No pueden hacer deploy
• No pueden leer ni escribir secrets
• Pueden leer código, sugerir cambios, abrir PRs

El blast radius de un vibe está acotado por lo que la IA puede efectivamente hacer.

Guardrail 5 — Workflow paired engineer-IA

Nuestro modelo estándar: un ingeniero senior maneja, la IA asiste. El ingeniero sostiene el modelo mental del sistema, la IA acelera la tipeada y el lookup. No al revés.

El anti-patrón: un junior o no-ingeniero le da prompt a la IA, y la IA sostiene el modelo mental. Nadie en el equipo puede debuguear el resultado porque nadie en el equipo lo entiende.

Bugs reales de codebases reales (anonimizados)

Una pequeña colección de los últimos 90 días:

• Webhooks de Stripe procesados dos veces. Falta de chequeo de idempotency key. La IA escribió el handler, no incluyó la tabla de idempotency.
• Token de auth filtrado en URL fragment. La IA generó un callback OAuth que ponía el access token en el hash de URL. Cookies habrían sido la movida correcta.
• Pool de conexiones Postgres agotado en 50 usuarios concurrentes. La IA usó un pool nuevo por request en vez de uno compartido. Funcionaba bien en test.
• Cron job corrió 24 veces en vez de una. La IA configuró el cron a nivel de aplicación y en Kubernetes, ambos corriendo.
• Request GDPR de derecho de eliminación falló silenciosamente. La IA borró de la tabla users pero no de las 6 tablas join. Sin error. Se vio exitoso.

Ninguno de estos lo atrapó un test. Todos los atrapó code review senior.

Dónde se sitúa Softronic

Usamos IA todos los días. Cada ingeniero senior del equipo tiene Claude Code o Cursor abierto durante el trabajo. Committeamos más rápido que antes.

También revisamos cada línea que shippea a producción. Hacemos pair programming. Escribimos evals. Mantenemos humanos en el loop arquitectónico. El output es más rápido que ingeniería 2023 y más confiable que vibe coding.

Si shippeaste un producto en vibe coding y quieres un equipo de ingeniería real para endurecerlo, eso lo hacemos. Si empiezas desde cero y lo quieres bien construido la primera vez, eso también lo hacemos.

¿Listo para shippear código que no se rompe en producción?

Builds custom desde $15K, 6-14 semanas, precio fijo después de la semana uno. Ingenieros senior, IA como herramienta, no reemplazo.

Lee más sobre cómo construimos en software a medida o nuestros servicios completos.