Codificaste por vibración tu MVP. Ahora estás estancado.

Construiste algo real. Abriste Lovable o Bolt.new, describiste tu idea en un inglés sencillo y viste aparecer una aplicación funcional en minutos. Hiciste clic en las pantallas. Se lo mostraste a tus amigos. Lo publicaste en X y recibiste tus primeras respuestas de "esto es enfermizo". Eso es impresionante y deberías sentirte bien por ello.

Pero ya han pasado tres semanas y el impulso se ha detenido. Pasas más tiempo reparando funciones defectuosas que creando otras nuevas. Su panel de Supabase tiene tablas que no comprende completamente. Su autenticación funciona en el escritorio pero falla en el móvil. Necesita la integración de Stripe y cada mensaje que intenta produce código que entra en conflicto con lo que ya existe.

Te has topado con la pared. Y no estás solo.

El muro 80/20: donde la codificación de vibraciones se rompe

Las herramientas de codificación de Vibe como Lovable, Bolt.new, Replit Agent y v0 son extraordinarias en el primer 80% de un producto. Generan componentes de interfaz de usuario, conectan bases de datos, crean flujos de autenticación y producen algo que parece una aplicación real. Para la creación de prototipos y la validación, son el camino más rápido desde la idea hasta la demostración que jamás haya existido.

El problema es el último 20%. Ahí es donde viven los casos extremos. Ahí es donde el procesamiento de pagos debe manejar cargos fallidos, reembolsos parciales y reintentos de webhook. Ahí es donde su formulario de varios pasos debe guardar el progreso, validar todos los pasos y recuperarse de fallas del navegador. Ahí es donde su aplicación debe funcionar cuando dos usuarios editan el mismo registro al mismo tiempo.

La IA maneja el camino feliz de manera brillante. Lucha con los caminos infelices, y el software de producción tiene un 80% de caminos infelices. ¿Qué sucede cuando la red cae a mitad de una transacción? ¿Cuando un usuario envía un formulario dos veces? ¿Cuando la consulta de su base de datos devuelve 50.000 filas en lugar de 50? Estas son las preguntas que separan una demostración de un producto, y son las preguntas que las herramientas de codificación de vibe no pueden responder con un solo mensaje.

Los desarrolladores lo llaman el muro 80/20. El primer 80% supone el 20% del esfuerzo. El último 20% supone el 80% del esfuerzo. Las herramientas de codificación de Vibe comprimen ese primer 80% de semanas a horas. Pero no comprimen en absoluto el último 20%. Lo hacen más difícil porque el código que generaron no fue diseñado para manejarlo.

El problema de seguridad del que nadie habla

Esta es la parte que debería mantenerte despierto por la noche. Un análisis de seguridad de las aplicaciones generadas por Lovable encontró queEl 10,3% tenía fallas críticas de seguridad a nivel de fila (RLS)en sus bases de datos Supabase. Eso significa que una de cada diez aplicaciones tenía tablas de bases de datos donde cualquier usuario autenticado podía leer, modificar o eliminar los datos de otros usuarios. No es un riesgo teórico. Una hazaña funcional.

Esto no se limita a Lovable. Un análisis de CodeRabbit de 470 solicitudes de extracción encontró que el código generado por IA tieneTasas de vulnerabilidad de seguridad 2,74 veces más altasen comparación con el código escrito por humanos. El mismo análisis encontró1,7 veces más problemas importantesen general. La IA escribe código que funciona. No escribe código que sea seguro.

Las consecuencias en el mundo real ya están aquí. Moltbook, una red social construida con inteligencia artificial, se lanzó con su base de datos Supabase de acceso público. El resultado:1,5 millones de claves API y 35.000 correos electrónicos de usuarios expuestos. Una auditoría independiente encontró queEl 11% de las URL de lanzamiento independientes exponen las credenciales de Supabase en su código de interfaz.. Estos no son casos extremos. Son patrones.

Las herramientas de codificación de Vibe no le explican la seguridad porque no preguntó sobre la seguridad. Solicitó un formulario de registro de usuario y lo obtuvo. No preguntaste "asegúrate de que los usuarios no puedan acceder a los datos de los demás a través de llamadas API directas", por lo que la herramienta no configuró eso. Políticas RLS, alcance de claves API, desinfección de entradas, limitación de velocidad; Estas son cosas que los ingenieros experimentados añaden de forma predeterminada porque han visto lo que sucede cuando no lo haces.

La trampa de la quema de crédito

Las herramientas de codificación de Vibe se cobran por créditos, tokens o tiempo de cálculo. El discurso es simple: describe lo que quieres, obtén el código funcional, itera. La realidad es diferente.

Informe de usuarios adorablesquemando 400 créditos en menos de una horaal depurar una característica compleja. Los nuevos usuarios de Bolt.new describen haber quedado atrapadosbucles de error sin findonde la IA rompe una cosa mientras arregla otra. En todas las plataformas, los usuarios informan sobre sus gastos30-40% de sus indicaciones solucionan cosas que la IA rompióen indicaciones anteriores.

Piense en esa proporción. Por cada tres indicaciones que hacen avanzar su producto, una o dos indicaciones sirven para deshacer el daño. Estás pagando para progresar y pagando nuevamente para limpiar el desorden. La herramienta que se suponía que le ahorraría dinero ahora es un costo recurrente con rendimientos decrecientes.

La quema de crédito se acelera a medida que crece su base de código. Para la IA es fácil razonar sobre una aplicación de 500 líneas. Una aplicación de 5000 líneas con varias páginas, estado compartido, rutas API y migraciones de bases de datos no lo es. La IA comienza a perder contexto. Reescribe los componentes que ya arregló. Introduce patrones que entran en conflicto con patrones que utilizó hace tres indicaciones. Gastas más créditos por menos progreso y la brecha se amplía con cada sesión.

La espiral de la calidad del código

Las bases de código generadas por IA comparten un conjunto específico de problemas que se agravan con el tiempo.

Duplicación de código.El análisis de proyectos codificados por vibraciones muestra unaAumento de 8 veces en la duplicación de códigoen comparación con proyectos diseñados por humanos. La IA no recuerda que ya escribió una función de formato de fecha hace tres archivos. Escribe uno nuevo. Luego otro. Luego uno ligeramente diferente. Ahora tiene cuatro formateadores de fecha, cada uno con un comportamiento diferente, y cambiar la visualización de la fecha en su aplicación significa encontrar y actualizar los cuatro.

Patrones inconsistentes.El desarrollo paso a paso produce código sin coherencia arquitectónica. Una página obtiene datos en un gancho useEffect. Otro utiliza renderizado del lado del servidor. Un tercero llama a la API directamente desde un controlador onClick. Ninguno de estos enfoques es incorrecto por sí solo, pero mezclar los tres en una sola aplicación crea una base de código sobre la que nadie puede razonar; ni la IA, ni un desarrollador humano que contrates más tarde.

Falta manejo de errores.El código generado por IA maneja el caso de éxito. Representa los datos cuando la API devuelve 200. No maneja lo que sucede cuando la API devuelve 500, o se agota el tiempo de espera o devuelve JSON con formato incorrecto. Los usuarios de producción activan estos modos de falla diariamente. Sin manejo de errores, su aplicación muestra pantallas en blanco, controles giratorios infinitos o mensajes de error crípticos que envían a los usuarios directamente a su competidor.

Sin pruebas.Las herramientas de codificación de Vibe rara vez generan pruebas a menos que usted lo solicite específicamente. Y cuando preguntas, las pruebas tienden a probar que el código hace lo que hace (pruebas tautológicas) en lugar de probar la lógica empresarial y los casos extremos. Cuando necesites cambiar una característica más adelante, no tendrás red de seguridad. Todo cambio es una apuesta.

Estos problemas se agravan. El código duplicado hace que los errores sean más difíciles de encontrar. Los patrones inconsistentes hacen que los cambios sean riesgosos. La falta de manejo de errores crea fallas de cara al usuario. La falta de pruebas significa que no se puede refactorizar de forma segura. Cada problema amplifica a los demás hasta que el código base llega a un punto en el que las agencias consideran que es necesarioMás tiempo para arreglar el código de vibración existente que para empezar desde cero..

Cuándo dejar de codificar Vibe y contratar ingenieros

No todos los proyectos codificados por vibraciones necesitan ser rescatados. Algunos prototipos validan una idea y se desechan. Está bien. Pero si su respuesta es "sí" a tres o más de estas preguntas, es hora de contratar ingenieros:

• Pasas más tiempo depurando que creando nuevas funciones
• Estás manejando datos reales del usuario (correos electrónicos, pagos, información personal)
• Necesita procesamiento de pagos, facturación de suscripciones o transacciones financieras
• Su aplicación debe funcionar de manera confiable para más de 100 usuarios simultáneos
• Te estás integrando con API de terceros que requieren webhooks u OAuth
• Ha consumido su presupuesto de crédito dos veces y su lista de funciones no ha cambiado
• No puede responder con seguridad "¿quién puede acceder a estos datos?" para cada tabla en su base de datos
• Está planeando recaudar fondos y los inversores le preguntarán sobre su arquitectura técnica.
• Has encontrado un error que no puedes solucionar después de más de 20 indicaciones

El punto de transición no se trata de fracaso. Se trata de reconocer dónde las herramientas de IA dejan de ser la herramienta adecuada y los ingenieros experimentados empiezan a ser la herramienta adecuada. Un fundador que codificó un MVP y validó la demanda hizo algo que la mayoría de los consejos de startups le dicen que haga: realizar envíos rápidos, aprender rápido. El siguiente paso es convertir ese prototipo validado en software de producción.

Qué hace una agencia de manera diferente

Una reacción común ante el muro 80/20 es "aprenderé a codificar y lo arreglaré yo mismo". Respeta esa energía, pero considera las matemáticas. Aprender lo suficiente sobre React, diseño de bases de datos, autenticación e implementación para terminar una aplicación de producción requiere de 6 a 12 meses de estudio enfocado. Contratar a un ingeniero senior para terminarlo lleva de 3 a 6 semanas. Si su startup tiene una ventana de mercado, la ruta de aprendizaje de 6 meses cierra esa ventana.

En Savi, nuestros ingenieros superiores también utilizan herramientas de inteligencia artificial. Usamos Cursor, Claude y Copilot a diario. La diferencia es que los utilizamos como aceleradores además de 5 a 10 años de experiencia en ingeniería, no como sustitutos de la misma. Sabemos qué solicitar y, lo que es más importante, qué revisar en el resultado. Detectamos las configuraciones erróneas de RLS, los límites de error faltantes, los vectores de inyección de SQL y las condiciones de carrera antes de que lleguen a sus usuarios.

Así es como se ve el proceso cuando un fundador nos trae un prototipo codificado por vibración:

Auditoría (1-2 días).Revisamos su base de código, esquema de base de datos e infraestructura existentes. Identificamos vulnerabilidades de seguridad, problemas arquitectónicos y código que necesita ser reemplazado. Le ofrecemos una evaluación honesta: ¿se puede solucionar esto o deberíamos empezar de nuevo? A veces, una aplicación codificada en vibración tiene componentes de interfaz de usuario sólidos y un esquema de base de datos razonable, y podemos construir sobre él. Otras veces, los cimientos tienen demasiados problemas estructurales y comenzar de cero es más rápido y económico.

Arquitectura (2-3 días).Diseñamos la arquitectura de producción. Esquema de base de datos con índices adecuados, políticas RLS y estrategia de migración. Capa API con autenticación, limitación de velocidad y manejo de errores. Estructura de interfaz con patrones consistentes de obtención de datos, gestión de estado y organización de componentes. Este es el ambiente de trabajo que las herramientas de codificación omiten por completo.

Construir (2-5 semanas).Escribimos código de producción. Cada función obtiene manejo de errores, estados de carga y cobertura de casos extremos. Cada tabla de base de datos obtiene políticas RLS. Cada ruta API obtiene validación de entrada. Escribimos pruebas de lógica empresarial. Configuramos canalizaciones de CI/CD que detectan las regresiones antes de la implementación. Habla directamente con el ingeniero que construye su producto; ni gerentes de proyecto transmitiendo mensajes, ni llamadas de estado semanales que podrían haber sido un mensaje de Slack.

Lanzamiento y traspaso.Implementamos en producción, monitoreamos la primera semana para detectar problemas y le entregamos un código base con documentación que puede llevar a cualquier ingeniero del mundo. Sin dependencia del proveedor. Sin marcos propietarios. Herramientas estándar, código limpio, su repositorio, su infraestructura.

Ofrecemos cotizaciones de precio fijo. Conoce el costo antes de que escribamos una línea de código. No hay facturación por horas que se dispara cuando la depuración lleva más tiempo de lo esperado. No hay recargos por "solicitud de cambio" cuando aclaras una característica a mitad de compilación.

El prototipo fue la parte difícil. Terminar es la parte inteligente.

Hiciste algo que la mayoría de la gente nunca hace: tomaste una idea, abriste una herramienta y creaste algo que podías mostrar a personas reales. Ese prototipo demostró que tu idea tiene piernas. Demostró que tiene el gusto y el impulso para crear un producto.

El siguiente paso no es más motivador. Es ingeniería. Es el refuerzo de la seguridad, el manejo de casos extremos, la optimización del rendimiento y las decisiones de infraestructura lo que convierte un prototipo en software por el que la gente paga y confía sus datos.

No es necesario convertirse en ingeniero para crear una empresa de software. Debe contratar a alguien que sepa cuándo usar IA y cuándo escribir el código a mano. Esa es la diferencia entre una demostración y un producto.

Preguntas frecuentes