Época de presupuesto, cuidado con la promesa de "hacerlo con IA"

Estamos en temporada de presupuesto en gran parte de las empresas y seguro ya escuchaste esta frase en alguna reunión: "ese sistema lo construimos internamente, con IA sale más barato". La propuesta parece obvia. El problema es que no siempre están calculando el costo correcto.

Con el avance de la IA, se volvió común usar Vibe Coding para construir sistemas rápidamente, sin pasar por un proceso formal de ingeniería de software. Y es exactamente ahí donde está el riesgo sobre el que quiero advertir en este artículo.

El riesgo de cambiar un SaaS por software construido en Vibe Coding

El Vibe Coding resuelve un problema específico: velocidad. La IA construye código rápido, pero el código es solo una parte de la construcción de un software. El proceso es lo que organiza las cosas, define los requisitos, la arquitectura, las capas de responsabilidad, las pruebas automatizadas, el versionado y la gestión de configuración.

Sin proceso, no tienes un sistema. Tienes un prototipo que funciona hoy y que difícilmente alguien puede explicar mañana.

El mayor costo no es construir, es mantener

Trabajo en proyectos de construcción y mantenimiento de sistemas desde hace más de 16 años y puedo afirmar: ese es el punto que más pesa en la decisión y el que menos aparece en la conversación de presupuesto. La mayor parte del esfuerzo y del dinero de un software no está en la construcción, está en el mantenimiento a lo largo de los años.

Cuando la dirección evalúa cambiar un SaaS por un sistema interno, normalmente compara el costo de la suscripción actual con el costo de construir. Esa cuenta está incompleta. Falta preguntar: ¿cuánto cuesta mantener ese nuevo software? ¿Quién va a corregir errores, actualizar dependencias, adaptarlo a sistemas que cambian, capacitar a quien llegue después? Como ya comenté sobre quién paga, quién compra y quién mantiene un sistema, cada uno de esos públicos exige una cuenta diferente, y quien termina pagando el precio del mantenimiento mal calculado es siempre el equipo que quedó fuera de esa decisión.

Sin un proceso de desarrollo bien definido en la construcción, mantener se vuelve más caro de lo que se imagina en el presupuesto.

Clonar el sistema actual no resuelve el problema

Otro error común en esta decisión es tratar el proyecto como una copia. La empresa quiere, en la práctica, duplicar el SaaS que ya usa, incluyendo funcionalidades que nunca usó de verdad y que se pensaron para otra realidad (vender al mayor número de clientes posible), otra empresa, otro contexto.

Esto no es construir un sistema nuevo. Es replicar propiedad intelectual de terceros y cargar hacia dentro de casa los mismos problemas que el sistema actual ya tenía, como requisitos y funcionalidades que aportan poco valor. El objetivo debería ser otro: pensar en qué necesita ser ese nuevo software para la realidad específica de tu empresa, no en lo que el proveedor de SaaS decidió construir. Es básicamente cuestionar las especificaciones antes de salir a copiar.

El camino que funciona: proceso, no solo código

Construir sobre un modelo sólido es lo que permite mantener y evolucionar el sistema durante años, porque la mayor parte del trabajo está en el mantenimiento, no en la construcción.

Esto no significa renunciar a la IA. Significa usarla dentro de un proceso. Los agentes de IA entran para ampliar la capacidad del ingeniero de software, y actúan dentro de un flujo que une la velocidad de la IA con el control del proceso. Los frameworks organizan el trabajo de esos agentes dentro del flujo de desarrollo. Y el contexto, los archivos, las reglas, las personas involucradas, es lo que mantiene a esos agentes actualizados y alineados con la realidad de la empresa.

Creo que esa es la combinación, proceso más IA, que sostiene un sistema a largo plazo. El Vibe Coding solo, sin proceso, entrega velocidad en cualquier dirección. Lo digo por experiencia propia: intenté sostener durante 3 meses un sistema construido sin bases, y el resultado fue obvio, descartarlo y empezar de la forma correcta.

La pregunta que queda antes de aprobar el presupuesto

Antes de cancelar ese SaaS pensando que vas a ahorrar, hazle esta pregunta al equipo: ¿estamos quitando un costo de un lado, pero qué costo estamos generando del otro? ¿Cuánto cuesta mantener ese nuevo software y qué necesitamos tener estructurado, arquitectura, versionado, configuración, proceso, para sostener ese mantenimiento en los próximos años? ¿Y si esa tecnología sale de la empresa? ¿Qué se puede hacer? ¿Cuál es el riesgo de este movimiento para el negocio?

Si esa respuesta no existe antes de la aprobación del presupuesto, el problema no es la tecnología. Es la decisión.

Un abrazo, Leandro | PMP | Gestor de Proyectos y PMO