La llamada casi siempre empieza igual: "Lo hicimos con IA, funcionaba, y ya no". Del otro lado hay una aplicación que hace unas semanas parecía terminada, un equipo que no entiende por qué falla ni cómo arreglarla, y una operación que ya depende de ella. Quien llama no pide un desarrollo nuevo, pide que alguien le devuelva algo que creía tener.
Nos pasa con frecuencia creciente, y tiene lógica: hoy una persona con una buena idea y una IA levanta en un fin de semana lo que antes tomaba meses, y ese superpoder es real. Lo que casi nadie les cuenta es dónde termina: llega hasta el prototipo, y de ahí en adelante el trabajo cambia de naturaleza.
Cuando el director de operaciones se sienta con nosotros, trae una aplicación que su equipo armó en un fin de semana. Tiene pantallas, guarda datos y hasta genera un reporte. Pide una cotización para "terminarla", con una expectativa clara: si la IA hizo lo difícil, lo que falta debe costar poco.
La expectativa es razonable, y en parte es correcta: escribir código se volvió mucho más barato. Pero entregar un sistema que una empresa pueda operar sin sobresaltos sigue costando casi lo mismo que antes, porque el código nunca fue la parte más cara.
La IA ya es una de las herramientas que más ha cambiado la velocidad del desarrollo de software, y esa ventaja es real y aprovechable. Este artículo trata de dónde quedó el costo cuando escribir código dejó de ser el cuello de botella, y de cómo presupuestarlo sin sorpresas.
Dónde se va realmente el costo de un software
Un proyecto de software reparte su esfuerzo en actividades que poco tienen que ver con escribir líneas:
• Entender qué construir: reglas de negocio, excepciones, quién usa qué y con qué permisos.
• Diseñar: modelo de datos, arquitectura, límites entre componentes.
• Integrar: conectar con los sistemas que ya existen, cada uno con sus propias rarezas.
• Probar: no solo que funcione el caso normal, sino que resista el anormal.
• Asegurar: credenciales, permisos, validación de datos, respaldo.
• Desplegar y operar: ambientes, monitoreo, qué pasa a las tres de la mañana cuando algo falla.
• Mantener: el costo que aparece al mes cuatro y dura años.
La IA abarata con claridad una porción de este mapa: la generación de código repetitivo, los borradores de pruebas, la documentación, la exploración de alternativas. Las demás actividades dependen de conocer el negocio, el entorno y las consecuencias de cada decisión. Ahí la IA ayuda a ejecutar, pero alguien tiene que saber qué ejecutar.
Qué pasa cuando se le pide a una IA que estime
Otro frente de la misma expectativa: pedirle a una IA que estime el proyecto. En nuestra experiencia, sus estimaciones suelen compartir tres rasgos.
Estiman con la vara de antes de la IA. Su referencia son los proyectos que equipos humanos ejecutaron sin ella, así que proponen esfuerzos más largos de los que el trabajo toma cuando se ejecuta con apoyo de agentes, sobre todo en tareas repetitivas y acotadas. Y estiman el sistema completo, con pruebas, seguridad y manejo de errores, mientras el cliente lo compara con un prototipo que no los tenía.
Estiman el proyecto típico, no el tuyo. No saben que tu sistema contable tiene una integración que responde por lotes, que la aprobación de un gasto pasa por cuatro personas o que un campo clave se llena distinto en cada sucursal. Lo que no se les cuenta, no existe.
No distinguen lo conocido de lo incierto. Entregan un número limpio donde un profesional entregaría un rango con supuestos explícitos.
El resultado es un tironeo entre dos números equivocados: el del cliente, que espera que casi todo lo resuelva la IA, y el de la IA, que estima con la vara de antes de la IA. Los humanos también estimamos mal. La diferencia es que una estimación hecha por una persona con experiencia viene con una pregunta incómoda previa y una lista de supuestos, y esa lista es lo más valioso del documento, porque dice dónde está el riesgo.
Lo que hay que revisar cuando parte del código lo generó una IA
Antes de comprometer un presupuesto sobre un desarrollo que ya existe y que fue construido total o parcialmente con IA, hay una revisión que casi nadie incluye y que cambia el número final. Es la misma que se le haría al código de cualquier persona. Con IA pesa más, porque produce mucho, rápido y con apariencia de solidez. Esto es lo que se examina:
1. Lógica de negocio. El código generado suele resolver bien el caso feliz. Hay que verificar qué hace con los casos límite: montos en cero, fechas fuera de rango, registros duplicados, usuarios sin permisos.
2. Manejo de errores. Qué ocurre cuando un servicio externo no responde, cuando llega un dato incompleto o cuando algo falla a mitad de un proceso. Es frecuente que simplemente no esté previsto.
3. Seguridad. Credenciales escritas dentro del código, datos de usuario sin validar, permisos amplios por comodidad, dependencias desactualizadas o que ni siquiera existen con ese nombre.
4. Modelo de datos. Una estructura que sirve para la demostración y se rompe con el volumen o con los reportes que vendrán después. Cambiarla con datos reales encima es una migración, no un ajuste.
5. Pruebas. Sin verificaciones automáticas, cada cambio futuro es una apuesta y el costo de mantenimiento sube desde el primer día.
6. Consistencia interna. Cuando el código se generó en varias sesiones, es común encontrar la misma lógica repetida de formas distintas y decisiones que se contradicen entre módulos.
7. Dependencias y licencias. Qué librerías usa, en qué versión y bajo qué condiciones, algo que importa cuando el sistema va a una operación comercial.
8. Despliegue y observabilidad. Si existe un ambiente de pruebas separado del real, si hay registros de lo que ocurre y si alguien se enteraría de una falla antes que el cliente.
9. Comprensión humana. La pregunta más reveladora: si la persona que lo generó se va mañana, ¿alguien puede explicar por qué el sistema hace lo que hace?
Un desarrollador humano deja huellas de duda: un comentario, una nota, una pregunta. El código generado por IA suele verse ordenado y seguro de sí mismo, y esa apariencia es lo que lleva a subestimar la revisión. Puede entregar con la misma limpieza una pieza sólida y una que no lo es.
El costo que nadie estima: leer código ajeno
Revisar cuesta más que escribir. Leer código que otro produjo exige reconstruir el razonamiento que hay detrás, y en el código generado por IA ese razonamiento no existe en ningún lugar: no hay una persona a quien preguntarle por qué se tomó cada decisión.
Por eso la revisión de un desarrollo previo no se presupuesta al final, como un ajuste. Es una etapa propia, acotada en el tiempo, que termina con una decisión entre tres caminos:
• Usar el código con mejoras puntuales, cuando la base es sólida. Es menos frecuente de lo que se espera en sistemas que van a producción.
• Refactorizar por partes, conservando lo que funciona y reescribiendo lo frágil.
• Reconstruir tomando el prototipo como especificación,que suele dar el mejor resultado cuando la base no resiste.
Elegir entre los tres antes de firmar un presupuesto es lo que separa una cotización realista de una que se desbordará a la mitad del proyecto.
¿Sirve entonces el prototipo que ya hicimos con IA?
Mucho. Un prototipo hecho con IA es una forma excelente de descubrir qué se necesita, ponerlo frente a usuarios y llegar a la conversación técnica con algo concreto en lugar de una idea vaga. Menos ambigüedad significa estimaciones más ajustadas. La distancia entre un prototipo que demuestra y un sistema que opera es, literalmente, la lista de revisión de la sección anterior.
Quien llega a pedir un presupuesto con un prototipo acelera mucho la conversación si trae cuatro cosas: qué hace hoy la aplicación y qué quedó pendiente; qué datos maneja y de dónde vienen; qué sistemas tendría que integrar; y qué partes se generaron con IA, con qué herramientas, y si se conservan las instrucciones usadas.
Cómo se ve un presupuesto honesto hoy
La IA ya cambió la forma de estimar, y un presupuesto serio lo refleja sin prometer más de lo que ocurre en la práctica. Los estudios publicados muestran reducciones considerables de tiempo en tareas acotadas, como generación de código, pruebas y documentación, y ganancias mucho menores en las de alta complejidad. También muestran que el ahorro por tarea no se traslada uno a uno al calendario del proyecto. Por eso un presupuesto honesto habla de rangos por tipo de tarea, no de un porcentaje único, y separa las partidas:
• Descubrimiento y diseño: entender el negocio y decidir con criterio. Se acelera poco, y es donde más errores se evitan.
• Construcción con apoyo de IA: la parte donde la aceleración es real y se traslada al cliente.• Revisión y pruebas humanas: la supervisión que asegura que lo generado hace lo que debe.• Integración, despliegue y puesta en marcha: dependen del entorno; la IA ayuda a escribir, pero no a decidir.
• Supuestos y rango: qué se asumió, qué podría cambiar el número y qué señal lo anunciaría.
Un presupuesto que muestra todo como "hecho por IA, por lo tanto barato" simplifica una realidad que el cliente descubre durante la ejecución, casi siempre en el peor momento. Y uno que no usa la IA en absoluto está cobrando por un tiempo que ya no hace falta.
El proceso que convierte código en un sistema confiable
Hoy casi cualquier empresa puede producir código con IA, con equipo propio o sin él. Lo que marca la diferencia es el proceso que lo convierte en un sistema confiable: alguien que entienda el negocio y fije requerimientos claros, decisiones de arquitectura pensadas para crecer, revisión donde un error cuesta caro, verificación hecha por alguien distinto de quien escribió el código y una persona que responda por el resultado.
Ese proceso puede vivir en un equipo interno o en un aliado, y en ambos casos permite aprovechar la velocidad de la IA con todo el rigor que un sistema en operación exige. Cómo se organiza un equipo híbrido que trabaja así, con agentes que ejecutan y personas que deciden, merece su propio artículo.
Nadie firma un contrato traducido por una máquina sin que alguien que domine el idioma lo lea antes. La traducción puede ser rápida, buena y correcta en casi todo; la firma, en cambio, compromete a la empresa. Con el software pasa igual: la IA puede escribir buena parte del código, y la firma sigue siendo de una persona.
En EmasT desarrollamos software y automatizaciones con equipos donde la IA acelera la ejecución y especialistas entienden tu negocio, dirigen el proceso y validan cada entrega. Así que, si estás por comprometer un presupuesto, con o sin un prototipo hecho con IA, esa es una buena conversación para empezar.