La verdad incómoda sobre las herramientas de IA para programar

Cuando un producto creado con "vibe coding" se vende a Wix por 80 millones de dólares apenas seis meses después de lanzarse, es fácil concluir que las herramientas de IA para programar son simplemente un negocio redondo. La realidad es más matizada y mucho más interesante: son una victoria neta en un tipo de trabajo específico y un coste neto en otro tipo de trabajo diferente. Los equipos que entienden esta distinción son los que avanzan rápido sin acumular deuda técnica oculta.

El problema de la sensación

Un estudio reciente de METR puso a desarrolladores experimentados frente a problemas reales en sus propios codebases grandes y midió el tiempo real con y sin asistencia de IA. Antes de empezar, los participantes estimaron que las herramientas de IA los hacían aproximadamente un 24% más rápidos. Después de terminar el trabajo, estimaron un 20% más rápidos. La medición real mostró que fueron un 19% más lentos con asistencia de IA.

Esa brecha entre percepción y realidad es el hallazgo más importante en la investigación sobre IA para programación. La asistencia de IA hace que la fase de escritura sea más rápida y la fase de revisión sea más lenta, y los humanos son terriblemente malos notando el coste de la revisión porque se siente como trabajo normal. Los 15 minutos que ahorraste en el scaffolding parecen una victoria. Los 25 minutos que pasaste depurando la salida "casi correcta" que produjo no se siente como una pérdida: se siente como tu trabajo.

Donde el ahorro de tiempo sí existe

El consenso de la investigación apunta claramente a una categoría: código nuevo en territorio desconocido. El estudio controlado de GitHub encontró que los desarrolladores construyeron un servidor web desde cero un 55% más rápido con Copilot. Experimentos de campo en múltiples empresas encontraron un 26% más de tareas completadas, con desarrolladores junior ganando entre un 27% y un 39% más de producción en tareas de corta duración. El trabajo de laboratorio de McKinsey muestra que la documentación y el código greenfield llegan en aproximadamente la mitad del tiempo.

Ese es el perfil del MVP. Un proyecto en blanco, un stack que estás aprendiendo, boilerplate que mayormente se copia a sí mismo, o una funcionalidad que puedes definir en un prompt corto. En ese trabajo, las herramientas hacen exactamente lo que dice el marketing. La clave es reconocer que eso no es todo el desarrollo de software.

Donde el retraso se cuela

El slowdown de METR ocurrió precisamente donde esperarías: desarrolladores experimentados manteniendo codebases que ellos mismos habían escrito durante años. El modelo produjo código que parecía plausible para un sistema que no entendía, el desarrollador pasó tiempo evaluando si era correcto, y ese coste de evaluación fue más alto que simplemente escribir la función habría sido.

A escala, aquí es donde los equipos se meten en problemas. Una startup que se apoya fuerte en IA para programar su MVP encuentra su product-market fit, empieza a crecer, y descubre tres meses después que el "código que funciona" incluye comprobaciones de seguridad a nivel de fila que están comentadas, un panel de administración accesible para cualquier usuario autenticado, y claves de API que terminaron en el bundle del lado del cliente. La IA escribió rápido. La IA también introdujo una revisión de seguridad que nadie programó.

La investigación de Faros AI, que midió a más de 10,000 desarrolladores en equipos reales, encontró que la asistencia de IA realmente ralentizó a los equipos en un 20-40% de los escenarios, particularmente en codebases de más de 100,000 líneas donde la ventana de contexto no puede contener toda la imagen. Ese es el problema del brownfield, y es donde la mayoría de los equipos establecidos vive la mayor parte del tiempo.

La factura de seguridad que nadie menciona

Cada semana trae otra historia: el código generado por IA de una startup expuso datos de usuarios, o un despliegue asistido por IA dejó un puerto de base de datos abierto, o una inyección de prompt encontró su camino hacia un sistema en producción. Estos no son casos aislados exóticos. Son la salida predecible de apuntar una herramienta optimizada para código plausible hacia trabajo sensible a seguridad sin que un experto en seguridad revise el resultado.

El patrón es consistente. Las herramientas de IA para programar se entrenan con código disponible públicamente, lo cual incluye mucho código con vulnerabilidades conocidas, permisos mal configurados y secretos hardcodeados. Cuando le pides a una de estas herramientas que construya un sistema de autenticación de usuarios o una integración de pagos, a menudo estás obteniendo una versión plausible de cómo eso se ve, que puede o no ser una versión segura.

Para startups que se mueven rápido, este es el riesgo crítico. No estás solo construyendo un MVP; estás construyendo una reputación y una superficie de cumplimiento. Una brecha de datos en tu primer año no es un problema técnico. Es un problema que puede terminar con tu empresa.

El marco práctico

La investigación apunta a un modelo operativo claro:

Usa IA agresivamente para trabajo greenfield. Nuevos proyectos, prototipos, scaffolding, stacks desconocidos y funcionalidades bien definidas son donde el ahorro de tiempo es real y grande. Esto es la mayor parte de lo que pone un MVP en vivo, y es donde estas herramientas ganan su coste de suscripción.

Usa IA selectivamente para trabajo brownfield. En un codebase que conoces bien, o en cualquier cosa que toque autenticación, pagos o datos de usuarios, trata la salida de IA como un primer borrador que necesita una revisión de seguridad. El tiempo que presupuestes para esa revisión es el coste real de la herramienta en ese trabajo. No dejes que la señal de "se siente más rápido" te convenza de saltártelo.

Envía pequeño, con tests. La inestabilidad en la salida de IA se muestra más en cambios grandes y complejos. Cambios incrementales pequeños con cobertura de tests real atrapan los errores sutiles que pasan la revisión y causan incidentes en producción. Esta es buena práctica en general, pero se vuelve crítica cuando la IA está en el ciclo.

Refuerza antes de que los usuarios lo toquen. Activa las comprobaciones de seguridad a nivel de fila. Elimina los secretos del código del lado del cliente. No apuntes un agente de IA a una base de datos de producción. Estas no son medidas de seguridad exóticas: son la línea base para cualquier sistema que maneje datos reales de usuarios. La IA para programar no cambia esa línea base; solo hace más fácil pasarla por alto.

La línea de fondo

Las herramientas de IA para programar son genuinamente útiles. También introducen costes que son reales, predecibles y casi nunca mencionados en los materiales de marketing. Los equipos que avanzan más rápido no son los que usan IA para todo: son los que la usan estratégicamente, donde el ahorro de tiempo es real, mientras protegen las partes de su sistema donde la corrección importa más que la velocidad.

Si estás construyendo un MVP en Vibe Hosting, usa herramientas de IA para moverte rápido en las partes que pueden cambiar. Úsalas con cuidado en las partes que tienen que estar bien. Y si no estás seguro de cuál es cuál, esa probablemente es tu siguiente pregunta.