Los costos ocultos del vibe coding y porqué un proyecto barato puede terminar saliendo caro
Gastón Rocha
El vibe coding puede acelerar el desarrollo, sí. Pero cuando se usa sin criterio técnico, sin arquitectura y sin control real de calidad, deja de ser eficiencia y empieza a convertirse en un problema financiero. A veces, arreglar el producto termina costando más que lo que se cobró por construirlo. Y eso no es un accidente: es el resultado predecible de cotizar mal, pensar poco y confiar en que la velocidad va a tapar los agujeros.
Durante un tiempo, el vibe coding se empezó a vender como si fuera el gran cambio de paradigma en el desarrollo de software. Más velocidad, menos fricción, menos tiempo perdido, más entregables en menos semanas. Todos en LinkedIn lo celebraban. Los videos de YouTube lo romantizaban. Y más de una empresa de desarrollo lo adoptó sin hacerse demasiadas preguntas.
Eso fue un error.
No porque la idea sea mala. Sino porque en muchos casos se interpretó de la peor manera posible y dió falsa confianza a personas sin las bases técnicas, lo que permitió que la gente use el vibe coding como una excusa para tirar código rápido, cobrar barato, cerrar contratos y dejar que los problemas estructurales aparecieran después. Y cuando llegaron, llegaron con factura incluida.
Porque una cosa es usar IA para acelerar un proceso que ya tiene estructura, criterio y responsabilidad técnica detrás. Otra muy distinta es usarla para producir software sin arquitectura, sin revisión seria, sin estimación honesta y sin una idea clara de cuánto cuesta sostener lo que se entrega. Cuando eso pasa, el desarrollo deja de ser una discusión técnica y se convierte en una discusión financiera. Y las finanzas no nos perdonan.
La velocidad no es el problema. El criterio sí.
Programar rápido no tiene nada de malo. De hecho, bien usado, es una ventaja brutal. El problema aparece cuando la velocidad reemplaza al criterio. Cuando se confunde escribir más código con construir mejor producto. Cuando se entrega algo que funciona en demo pero que por debajo está mal estructurado, mal pensado, acoplado sin razón y condenado a volverse caro en cuanto el cliente pide cambios, aparecen bugs o el sistema empieza a operar a escala real. Ahí el vibe coding deja de parecer una herramienta de productividad y empieza a parecer como un "regalo griego".
El desastre empieza antes del primer commit
Pero lo más grave, lo que pocas veces se dice en voz alta, es que el desastre muchas veces empieza antes. Empieza en la cotización.
Se vende barato para cerrar rápido. Se promete agilidad sin entender el alcance real. Se asume que la IA va a compensar la falta de análisis previo. Se recortan horas de arquitectura, QA, revisión y diseño técnico para que el número entre dentro del presupuesto del cliente. Se firma. Se cobra. Se empieza. Y desde ese momento, el proyecto ya viene herido de origen.
Porque si el precio fue definido desde el optimismo, desde el apuro o desde la fantasía de que "después se arregla", lo que realmente se hizo no fue una venta inteligente. Fue hipotecar el margen futuro a cambio de cerrar una operación hoy. Y las hipotecas siempre se terminan pagando.
Un ejemplo con números que no mienten
Los números son simples y no tienen ningún misterio. Un programador que trabaja 170 horas al mes y gana 2.500 dólares tiene un costo directo de 14,71 dólares por hora. Un sistema que toma 300 horas de desarrollo y se vende por 6.000 dólares genera un costo directo total de 4.411,76 dólares, dejando un margen bruto aparente de 1.588,24 dólares.
Aparente, porque ese cálculo ignora por completo las reuniones con el cliente, el levantamiento de requerimientos, el seguimiento, la gestión de proyecto, el QA, las correcciones, las validaciones, el soporte post-entrega, la administración y el costo comercial de haber conseguido ese proyecto. Es decir, el proyecto solo parece rentable si hacemos de cuenta que el resto de la operación no existe.
Eso no es un proyecto. Es una fantasía.
Y cuando encima el sistema nació con problemas estructurales, lo que viene después no es mantenimiento. Es rescate. Significa rehacer módulos enteros, reordenar una arquitectura que nunca fue pensada para escalar, reescribir lógica que fue improvisada en el camino, corregir decisiones de base de datos que parecían razonables al principio y que ahora son un cuello de botella.
Muchas veces lo que terminas pagando ya no es desarrollo,sino es el costo de haber cotizado mal.
Si después de la entrega ese sistema necesita 150 horas adicionales de correcciones y retrabajo, el costo directo por eso es de 2.205,88 dólares. El costo directo acumulado de todo el proyecto sube a 6.617,64 dólares, que ya superan los 6.000 dólares cobrados por el proyecto entero.
El software barato no es barato
Solo está subsidiado por el margen que se va a perder después. Lo que parece eficiencia es en realidad un diferimiento del costo si no está bien enfocado. Mientras el equipo intenta rescatar un sistema, dejó de tomar otros proyectos, retrasó entregas y consumió capacidad operativa que podría haber estado generando ingresos reales.
Eso es lo que muchas empresas descubren tarde y nos llegó a pasar. Que el supuesto ahorro del desarrollo acelerado y sin estructura termina convertido en retrabajo, en pérdida de rentabilidad y en proyectos que financieramente nunca debieron venderse bajo esas condiciones.
Entonces, ¿el vibe coding es una mala práctica?
No. El problema no es la herramienta. El problema es cómo se usa y, sobre todo, quién decide cómo usarla.
Cuando hay seniors que definen la arquitectura y los límites, cuando el código generado por IA pasa por revisión técnica real y no por una aprobación automática disfrazada de confianza, cuando existe QA, cuando los estándares están claros, cuando el proyecto fue bien cotizado y no depende de un milagro para conservar margen, ahí sí el vibe coding suma. Ahí sí la velocidad tiene sentido. Ahí sí la IA acelera valor y no acelera el costo del error.
Pero cuando se usa para pensar menos, para cotizar más barato y para dejar que el retrabajo se coma el margen después, no es innovación. Es mala gestión con interfaz moderna.
El diferencial real ya no está en quién produce más código más rápido. Está en quién puede entregar algo que funcione, que se mantenga, que escale y que no destruya la rentabilidad en el camino. Porque hoy escribir código puede ser más barato que antes. Pero sostener software malo sigue siendo brutalmente caro.
Cómo lo vemos en BoringSoft
En BoringSoft no estamos en contra de usar IA para desarrollar más rápido. Sería ridículo estarlo. Lo que sí tenemos claro es que la velocidad por sí sola, no protege un proyecto. Lo que lo protege es el criterio técnico, una arquitectura que aguante la realidad y una estimación financieramente defendible. La IA puede acelerar mucho. Pero si se usa sin estructura, no acelera el valor. Acelera el costo del error.
Por eso no nos interesa vender velocidad vacía. Nos interesa construir software útil, mantenible y rentable. Porque un proyecto no es bueno solo porque salió rápido. Es bueno cuando funciona, cuando se puede sostener y cuando no se convierte en una fuga de margen apenas entra a operación real.
El vibe coding no es el enemigo, nosotros lo amamos. La improvisación sí. Y la improvisación que se vende como agilidad es de lejos la peor de todas.
Si quieres ver cuánto te está costando realmente desarrollar así, agenda una llamada gratuita con nosotros. Te mostramos, con tus datos y tus procesos, dónde se está yendo tu el margen, qué parte del problema es técnico y qué parte ya se convirtió en un problema financiero.