En 2026 cualquiera con una idea y una tarjeta de crédito puede producir algo que parece una aplicación funcionando para la hora del almuerzo. Los modelos arman un storefront Next.js. Escriben un backend Django pasable. Si se les pide, hasta esbozan un pipeline de deploy y un schema Postgres. El artefacto al final es real, ejecutable e impresionante.
Lo que NO es, en casi cada caso, es production-grade. El gap entre "esto funciona en mi laptop frente a una audiencia amistosa" y "esto funciona a las 11pm un sábado cuando un usuario real con la codificación equivocada en su email intenta loguearse" sigue siendo enorme. La IA estrechó muchas partes de la ingeniería de software. Esta parte la estrechó menos.
Llevamos el último año tomando codebases generados por IA y MVPs vibecoded a producción para clientes. La lista de cosas que consistentemente necesitan arreglarse antes del launch es casi la misma cada vez. Esta es esa lista — y por qué seguimos haciendo este trabajo a mano.
1. Autenticación que es realmente segura
Un modelo te dará un formulario de login funcionando. Probablemente usará una librería reputada. Quizás hasta maneje password hashing correctamente. Lo que casi nunca hace bien la primera vez:
- Invalidación de sesión al cambiar password.
- Rate-limiting en login y reset, con la semántica correcta fail-open vs fail-closed.
- Prevención de email enumeration en signup y reset.
- Tokens CSRF scope'ados a las operaciones correctas.
- Modelo de permisos consistente en lugar de checks ad-hoc por ruta.
- Aislamiento multi-tenant enforce'ado a nivel DB, no en código de aplicación.
Cada uno es una búsqueda de una línea en OWASP y un fix de varios días en codebase real. La IA puede parchear uno a uno cuando se le pide, pero no los flag proactivamente.
2. Un schema de base de datos que sobrevive a la segunda feature
El failure mode más consistente de sistemas generados por IA: schemas que parecen razonables para los tres use-cases del prototipo y se vuelven inviables el momento que llega el cuarto.
Lo que típicamente reconstruimos:
- Foreign keys en lugar de "joinearemos en código".
- Constraints reales —
NOT NULL,CHECK,UNIQUE— en lugar de vibes. - Índices diseñados contra los patrones de query reales, no la suposición del modelo.
- Migraciones que corren limpias forward y backward, incluyendo data migrations.
- Honest accounting de qué guardan las columnas JSON y plan para evolucionarlas.
El costo de hacer bien el schema antes del launch es ~una semana de ingeniería. El costo de hacerlo mal son seis meses de pain incremental después de los primeros 100 clientes.
3. Observabilidad para debuggear a las 2am
Un prototipo se debuggea agregando print() y re-running local. Un sistema production se debuggea leyendo dashboards desde un teléfono en mitad de la noche.
Casi ningún codebase generado por IA viene con:
- Structured logs con request ID propagado end-to-end.
- Métricas sobre lo que realmente importa (latency p95/p99, error rate por endpoint, queue depth, slow queries).
- Trazas distribuidas que linkeen un 500 user-facing a la query de DB responsable.
- Alerts wireados a un canal que un humano realmente leerá.
Construimos esto by default. Trabajo poco glamoroso, toma ~una semana, y es la inversión más apalancada en production-readiness que cualquier sistema puede hacer.
4. Deploys rutinarios y reversibles
El Dockerfile generado por IA probablemente funcionará. Lo que no te dirá:
- Cómo rollback en dos minutos cuando el siguiente release rompa.
- Cómo hacer migración de DB segura para deploy multi-instance.
- Cómo manejar secrets sin commitearlos.
- Cómo mantener dev / staging / prod consistentes lo suficiente para que "funciona en staging" signifique algo.
- Cómo manejar el caso friday-deploy cuando quieres desplegar pero es feriado público en tu región AWS.
El gap entre "el container arranca" y "deployamos a producción un martes por la tarde sin que nadie aguante la respiración" son seis meses de madurez operacional. Lo comprimimos a ~dos semanas de trabajo enfocado.
5. Autenticación real para las propias features de IA
Para apps con IA hay una capa extra de riesgo que la IA misma raramente surface: las features de IA son ahora parte de la superficie de ataque.
- Prompt injection via documentos subidos por usuarios.
- Leak cross-tenant a través de embeddings compartidos.
- Cost denial-of-service por queries sin límites.
- Outputs alucinados con confianza sobre información safety-critical.
- Falta de audit trail de qué hizo el agente y por qué.
No son edge cases. Production AI features necesitan trazabilidad, scoping, comportamiento de refusal, evaluación y techos de costo — nada de lo cual el prototipo usualmente tiene.
6. Performance budgets y la disciplina para mantenerlos
Un prototipo es rápido porque nadie lo usa. Un sistema production que no mide p95 latency, query plans y Core Web Vitals se degradará silenciosamente hasta que los usuarios empiecen a irse.
Fixes reales en sistemas heredados generados por IA que hemos visto incluyen:
- Reemplazar queries
SELECT *con projections explícitas. - Agregar índices que el prototipo no necesitaba porque había diez filas.
- Sacar patrones N+1 ORM de hot paths.
- Agregar HTTP caching apropiado para endpoints read-mostly.
- Pre-renderizar contenido que no necesita ser dinámico.
Nada de esto es intelectualmente difícil. Todo requiere atención sostenida y baseline de medición. La IA no provee ni una ni otra por default.
Qué hacemos realmente
Cuando un cliente viene con codebase generado por IA o vibecoded que necesita volverse producto real, el engagement luce algo así:
Semana 1 — auditoría. Leemos código, lo corremos, lo medimos. Catalogamos gaps contra las categorías de arriba y los rankeamos por riesgo.
Semanas 2-6 — cerrando gaps más peligrosos. Autenticación, schema DB, observabilidad, deploys. El trabajo que nadie markea pero todos necesitan.
Semanas 6+ — feature work junto a foundation. El producto puede crecer ahora sin pudrirse debajo. Continuamos shipping features a full speed mientras los foundations mejoran constantemente.
Siempre — mantenimiento es opción, no impuesto. La mayoría de clientes elige retainer mensual para el año post-launch. Lo usamos para mejoras continuas, performance work y on-call. El sistema mejora con el tiempo, no empeora.
Lo que NO estamos argumentando
NO argumentamos que el código generado por IA es malo. Lo opuesto: es lo suficientemente bueno que el bottleneck se movió de "¿puede alguien escribir el código?" a "¿puede alguien hacer que este código dure en producción?". Esa segunda pregunta es la interesante ahora.
NO argumentamos que el trabajo que hacemos es glamoroso. No lo es. Es leer reportes de auditoría, tightening migraciones, agregando índices, escribiendo runbooks. La razón por la que estamos felices haciéndolo es que es precisamente el trabajo que la IA no ha desplazado — y probablemente no desplace, mientras sistemas de producción necesiten humanos on-call cuando se rompen.
NO argumentamos que cada proyecto necesita pasar por esto. Si tu prototipo generado por IA solo servirá a 30 usuarios en una herramienta interna, no necesita el mismo tratamiento que una plataforma customer-facing. Right-size la ingeniería al goal.
Argumentamos esto: la parte fácil de construir software se volvió dramáticamente más fácil. La parte difícil siguió exactamente igual de difícil, y el gap entre las dos se amplió. Cerrarlo es trabajo para un equipo con experiencia. Nosotros somos ese equipo. Si tu app generada por IA está empezando a crujir, ahí es donde entramos.