Deuda técnica del vibe coding: qué es y cuándo pagarla

La deuda técnica es el trabajo extra que vas a tener que hacer más adelante por los atajos que tomas hoy. En las apps hechas con vibe coding crece rápido, porque cada prompt resuelve el problema visible sin limpiar lo que había antes. Conviene pagarla cuando empieza a frenar cada cambio, a romper funciones que no tienen nada que ver o a poner en riesgo los datos de tus usuarios; mientras tanto, algo de deuda es un precio razonable por lanzar rápido.

En esta guía verás cómo se ve esa deuda en una app hecha con IA, cómo medirla sin ser desarrollador, cuál pagar primero y cómo evitar que vuelva a acumularse.

¿Cómo se ve la deuda técnica en una app hecha con IA?

Casi nunca es un solo error grande. Son muchos pequeños que se suman:

• Lógica duplicada. El mismo cálculo de precio vive en tres componentes, y dejan de coincidir cuando cambias uno.
• Código muerto. Versiones viejas de funciones que la IA reemplazó pero nunca borró, que siguen importadas y a veces hasta se ejecutan.
• Lógica en el navegador que debería estar en el servidor. Descuentos, permisos o límites que solo se validan en el frontend, donde cualquiera puede cambiarlos.
• Un archivo gigante. Un solo componente de página con cientos de líneas que pide datos, maneja estado, arma el diseño y aplica reglas de negocio a la vez.
• Valores escritos a mano. URLs de APIs, nombres de planes y correos metidos directo en el código en vez de en la configuración.
• Cero pruebas. Nada te avisa que un cambio rompió el registro hasta que un usuario se queja.
• Dependencias sin control. Paquetes instalados para un experimento que nunca se quitaron, algunos ya desactualizados.

¿Cómo sabes que la deuda ya es un problema?

La deuda es un costo, no un pecado. Estas son las señales de que los intereses ya pesan demasiado:

1. Cada cambio rompe algo que no tiene relación. Arreglas el panel y deja de cargar la página de facturas.
2. La herramienta de IA da vueltas en círculo. "Arregla" un error, mete otro y luego deshace el primer arreglo. Al modelo también le cuesta razonar sobre código grande y enredado.
3. Las funciones simples tardan días. Agregar un campo a un formulario toca ocho archivos.
4. Te da miedo publicar. Los despliegues se hacen de noche, con alguien listo para volver atrás.
5. La gente nueva no se ubica. Un desarrollador necesita días solo para entender dónde está cada cosa.

Si se cumplen dos o más, la deuda ya te está costando más de lo que costaría pagarla.

¿Cómo la mides sin leer código?

No necesitas entender el código para juntar números útiles:

• Anota cuántas veces un cambio provoca un error nuevo. Una lista simple durante un mes: cada cambio y si se rompió otra cosa.
• Cuenta créditos o prompts por función. Si las funciones pequeñas necesitan cada vez más intentos, el código está peleando con la herramienta.
• Pide un informe de dependencias y tamaño. Un desarrollador puede decirte en minutos cuántos paquetes tienes, cuántos están desactualizados y qué archivos son más grandes.
• Revisa los registros de errores. Un flujo constante de los mismos errores en producción es la deuda dando la cara.

¿Qué deuda pagas primero?

No toda la deuda pesa igual. Págala en este orden:

La última fila importa. El código que funciona y nadie toca puede quedarse desordenado. Refactorizarlo solo te trae riesgo.

¿Cómo la pagas sin frenar el trabajo nuevo?

Los grandes "sprints de limpieza" suelen quedarse a medias. Funcionan mejor estos hábitos:

1. Arregla la base una sola vez. Pon el proyecto en control de versiones, arma un entorno de pruebas (staging) y haz que el despliegue sea repetible. Es una inversión única.
2. Deja cada zona mejor de como la encontraste. Cuando construyas una función, quita también el código muerto y los duplicados que la rodean. Reserva una parte de cada tarea para eso.
3. Escribe una prueba antes de corregir un error. Una prueba que lo reproduzca, y después el arreglo. Así el error no vuelve en silencio.
4. Lleva las reglas al servidor de una en una. Empieza por lo que controla dinero o acceso.
5. Reemplaza en vez de reescribir. Si un módulo no tiene arreglo, rehaz ese módulo detrás de la misma interfaz, no la app entera. Nuestra guía sobre si reescribir o arreglar tu app trata esa decisión.

¿Cómo evitas que la deuda regrese?

La mayor parte de la deuda nueva viene de cómo se usa la herramienta, no de la herramienta:

• Pide cambios pequeños y concretos, y revisa qué cambió antes de aceptarlo.
• Escribe reglas del proyecto (reglas de Cursor, el archivo de conocimiento de Lovable o algo parecido) que describan tu estructura: dónde vive la lógica de negocio, qué componentes reutilizar, qué no tocar.
• Pídele a la IA que borre además de agregar. "Elimina la versión vieja" es un prompt válido.
• Haz commits seguido, con un mensaje corto, para poder volver al último estado bueno.
• Que alguien revise el código con regularidad, aunque sea rápido. Nuestra guía para revisar código generado por IA dice qué buscar.

Respuestas rápidas

¿Toda la deuda técnica es mala? No. Endeudarte para probar una idea rápido es un buen intercambio. El problema es seguir pagando intereses mucho después de que la idea ya funcionó.

¿La herramienta de IA puede limpiar su propia deuda? En parte. Puede quitar duplicados y dividir archivos grandes si se lo pides con precisión, pero alguien tiene que decidir cómo debe quedar la estructura.

¿Cuánto tiempo debo dedicar a pagarla? No hay un número universal. Empieza por la base y luego reserva una parte fija de cada tarea para limpiar la zona en la que trabajas.

¿A los inversionistas les importa la deuda técnica? Les importan los riesgos que genera: seguridad, capacidad de crecer y qué tan rápido puede entregar el equipo.

¿Quieres ayuda con la deuda de tu app?

Empieza con el chequeo gratuito de tu app para ver lo que se nota desde afuera. Si la deuda ya te frena, nuestros planes de mantenimiento de software cubren la limpieza y los arreglos continuos, y si hay que rehacer un módulo, mira el desarrollo de MVP. También puedes contarnos qué pasa.