Sobre vibe coding, deuda técnica invisible y disciplina de ingeniería para sistemas basados en IA

Documento de posición Asimov Consultores sobre vibe coding, deuda técnica invisible y disciplina de ingeniería para sistemas basados en IA.

El uso de inteligencia artificial para construir software ya no es una promesa futura, es una realidad. Hoy permite crear prototipos, interfaces, integraciones y aplicaciones funcionales a una velocidad que hace pocos años habría parecido imposible.

Eso no es un problema. Al contrario: es una ventaja competitiva.

En Asimov usamos IA para programar, prototipar, analizar alternativas y acelerar el desarrollo. No miramos este fenómeno desde afuera ni desde una posición conservadora. La IA ya es parte de la forma en que se construye software moderno.

Pero usar IA para escribir código no elimina la necesidad de ingeniería de software. La desplaza hacia otro lugar: hacia la capacidad de definir bien el problema, diseñar la arquitectura, establecer límites, revisar decisiones, controlar dependencias, probar comportamientos y responder técnicamente por lo que se entrega.

El verdadero riesgo no está en que una aplicación haya sido construida con ayuda de IA. El riesgo aparece cuando el equipo pasa de dirigir técnicamente la construcción a simplemente aceptar resultados que “parecen funcionar”, sin entender completamente cómo están hechos, qué supuestos contienen, qué dependencias incorporan ni cómo se comportarán cuando fallen.

A eso lo denominamos deuda de comprensión: la distancia entre tener un sistema que funciona en una demo y tener un sistema que puede ser explicado, mantenido, corregido, auditado y escalado.

Esta deuda se vuelve crítica cuando un prototipo empieza a manejar datos reales, usuarios reales, procesos reales, dinero real o decisiones que afectan a personas. En ese momento, ya no basta con que la aplicación “funcione”. Debe poder sostenerse.

Para abordar correctamente este problema es necesario separar dos situaciones que suelen confundirse, pero que tienen riesgos distintos:

Software generado con IA: aplicaciones cuyo código fue producido total o parcialmente con herramientas de inteligencia artificial.
Software que ejecuta IA: sistemas que usan modelos de lenguaje u otros modelos probabilísticos en tiempo real para analizar, responder, clasificar, recomendar o decidir.

Ambos casos requieren disciplina técnica. Pero no requieren exactamente la misma disciplina.

1. Software generado con IA: el riesgo de perder el modelo mental del sistema

Cuando se usa IA para generar código, el resultado final puede ser perfectamente determinista. Es decir, una vez escrito el código, ese código se ejecuta como cualquier otro software tradicional: frente al mismo estado, las mismas reglas y los mismos datos, debería comportarse de manera consistente.

Por eso el problema principal del software generado con IA no es que sea probabilístico. El problema es otro: muchas veces el equipo que lo construyó no entiende realmente cómo quedó construido.

La IA puede generar en segundos cientos o miles de líneas de código, crear componentes, conectar servicios, instalar dependencias, definir estructuras de datos, resolver errores y proponer soluciones aparentemente funcionales. Pero si ese proceso ocurre sin suficiente dirección técnica, el resultado puede ser una aplicación que corre, pero cuya arquitectura nadie domina.

El equipo puede saber qué pidió y qué resultado obtuvo, pero no necesariamente cómo está organizado el sistema por dentro.

Ese es el punto donde nace la deuda de comprensión.

1.1 De constructor a aprobador superficial

En el desarrollo tradicional, incluso con problemas de calidad, el equipo suele construir progresivamente un modelo mental del sistema. Sabe dónde vive la lógica principal, qué módulos son críticos, qué dependencias existen, qué partes son frágiles y qué consecuencias puede tener un cambio.

Con el desarrollo asistido por IA, ese modelo mental puede perderse si la persona deja de actuar como arquitecto o desarrollador responsable y pasa a comportarse solo como aprobador superficial del resultado.

El flujo se vuelve algo así:

“Pídele a la IA que lo haga, mira si funciona, corrige el error visible, sigue adelante.”

Ese flujo sirve para prototipar. Pero es muy peligroso si se transforma en la forma de construir producción.

Porque cuando el sistema se cae, genera un resultado incorrecto, rompe una integración o empieza a comportarse de manera inesperada, ya no basta con saber que “antes funcionaba”. Alguien debe entender qué está pasando.

Y ahí aparece el problema, hay código, pero no hay comprensión suficiente del código.

1.2 Arquitectura accidental

Uno de los mayores riesgos del software generado con IA es terminar con una arquitectura accidental.

Esto ocurre cuando el sistema no responde a decisiones conscientes de diseño, sino a una acumulación de respuestas generadas por IA en distintos momentos, con distintos niveles de contexto y distintos objetivos parciales.

La aplicación puede terminar funcionando, pero con problemas estructurales como:

lógica de negocio duplicada en varios lugares;
componentes que hacen más cosas de las que deberían;
dependencias incorporadas sin evaluación técnica;
manejo inconsistente de errores;
validaciones repartidas entre frontend, backend y base de datos sin criterio claro;
ausencia de contratos explícitos entre módulos;
nombres, patrones y estructuras inconsistentes;
decisiones tomadas para resolver un error puntual, pero que generan fragilidad futura.

El problema no es que la IA genere mal código por definición. El problema es que la IA responde al contexto que recibe. Si el contexto es pobre, ambiguo o incompleto, el resultado puede ser técnicamente débil aunque parezca correcto en la superficie.

Mientras más sabe el equipo de desarrollo, mejor contexto puede entregar. Y mientras mejor contexto entrega, mejores resultados obtiene.

La calidad del software generado con IA no depende solo del prompt. Depende del criterio técnico de quien dirige el proceso.

1.3 La IA como copiloto, no como arquitecto invisible

La forma correcta de usar IA en desarrollo no es delegarle el sistema completo. Es usarla como copiloto dentro de una dirección técnica clara.

Eso significa que el equipo humano debe seguir tomando las decisiones estructurales:

qué módulos existen;
dónde vive la lógica de negocio;
qué dependencias se permiten;
qué contratos existen entre componentes;
qué datos son fuente de verdad;
cómo se manejan errores;
cómo se gestionan transacciones;
qué debe probarse antes de pasar a producción;
qué partes pueden seguir siendo prototipo y qué partes requieren desarrollo técnico.

La IA puede implementar, sugerir, refactorizar, documentar y acelerar. Pero no debería ser quien, por acumulación de respuestas, quien define silenciosamente la arquitectura del sistema.

La diferencia es fundamental.

Un equipo que usa IA con disciplina puede construir más rápido sin perder control. Un equipo que usa IA sin disciplina puede avanzar rápido hacia un sistema que nadie entiende.

1.4 Qué proponemos para software generado con IA

Nuestra intervención no consiste en prohibir el uso de IA ni en reescribir todo desde cero. Consiste en instalar la disciplina mínima para que el sistema pueda sostenerse.

En esta primera dimensión, el trabajo se enfoca en reducir la deuda de comprensión:

a. Diagnóstico técnico del sistema

Revisamos cómo está construido el software, qué partes fueron generadas con IA, qué módulos son críticos, qué dependencias existen, dónde vive la lógica de negocio y qué zonas presentan mayor riesgo de mantenibilidad.

La pregunta central no es solo “¿funciona?”, sino:

“¿El equipo puede explicar cómo funciona y hacerse responsable de mantenerlo?”

b. Reconstrucción del modelo mental

Documentamos la estructura real del sistema: módulos, flujos principales, dependencias, datos críticos, integraciones, responsabilidades y puntos de falla.

Esto permite que el cliente, su equipo o Asimov puedan entender el sistema sin depender exclusivamente de la memoria de quien lo construyó originalmente.

c. Separación entre prototipo y producción

No todo necesita el mismo nivel de rigor. Algunas funcionalidades pueden seguir iterándose rápidamente con IA. Pero las partes críticas deben tener estándares más altos.

Clasificamos el sistema entre:

funcionalidades exploratorias;
funcionalidades de soporte;
funcionalidades críticas de negocio;
funcionalidades que manejan datos sensibles, pagos, permisos, seguridad o cumplimiento normativo.

Cada categoría requiere un nivel distinto de revisión, pruebas y control.

d. Refactorización selectiva

No proponemos reescribir todo. Proponemos intervenir donde el riesgo lo justifica.

Eso puede significar ordenar módulos, eliminar duplicaciones, aislar lógica crítica, reducir dependencias innecesarias, mejorar manejo de errores, documentar contratos o reforzar pruebas.

El objetivo no es “perfeccionar” el sistema. Es hacerlo comprensible, mantenible y corregible.

e. Gobernanza liviana del desarrollo con IA

Instalamos prácticas simples:

versionado del código en repositorio GIT;
registro de decisiones técnicas relevantes;
revisión humana de cambios críticos;
checklist antes de despliegues;
convenciones mínimas de arquitectura;
documentación breve de módulos principales;
pruebas mínimas para flujos críticos.

Esto permite seguir usando IA, pero con control técnico.

2. Software que ejecuta IA: el riesgo de tratar un modelo probabilístico como si fuera una regla exacta

Esta segunda situación es distinta: sistemas que no solo fueron construidos con IA, sino que además ejecutan IA como parte de su funcionamiento.

Aquí hablamos de aplicaciones que usan modelos de lenguaje u otros modelos probabilísticos para analizar documentos, responder preguntas, clasificar información, generar recomendaciones, resumir antecedentes, asignar puntajes o apoyar decisiones.

En este caso, el riesgo sí tiene que ver con la naturaleza probabilística del modelo.

Un sistema tradicional ejecuta reglas definidas. Un sistema que usa IA genera respuestas a partir de probabilidades, contexto, instrucciones, datos disponibles y parámetros del modelo. Eso significa que el mismo prompt, con la misma información, puede producir respuestas distintas en distintas ejecuciones.

No necesariamente respuestas completamente contradictorias, pero sí variaciones en énfasis, interpretación, formato, criterios o conclusión.

Eso cambia la forma de diseñar, probar y gobernar estos sistemas.

2.1 El error de tratar la respuesta de la IA como verdad exacta

Uno de los errores más comunes es usar la salida de un modelo como si fuera una decisión objetiva, estable y completamente reproducible.

Por ejemplo, si un sistema analiza una licitación y le asigna una nota de 1 a 7, esa nota no puede ser tratada como una verdad matemática. Puede ser una señal útil, pero no debería convertirse automáticamente en una decisión ciega del tipo:

“Si la nota es sobre 6, participamos; si es bajo 6, descartamos.”

Ese uso es riesgoso porque el modelo no está aplicando una ciencia exacta. Está aproximando una evaluación en función del contexto que recibió, del prompt, del modelo, de los datos y de sus propios patrones probabilísticos.

La IA puede ser muy útil para apoyar el análisis. Pero no reemplaza el juicio experto cuando la decisión tiene consecuencias reales.

2.2 La ilusión de que el modelo “piensa igual” cada vez

Los modelos de lenguaje generan una ilusión de consistencia humana. Como responden con fluidez, argumentan y parecen razonar, tendemos a tratarlos como si fueran personas con criterio estable.

Pero no funcionan así.

Un modelo no “piensa” en el sentido humano. Genera una respuesta probable dado el contexto que recibe. Si el contexto es incompleto, ambiguo o mal entregado, la respuesta puede ser débil. Si el prompt cambia levemente, puede cambiar el resultado. Si cambia la versión del modelo, también puede cambiar el comportamiento.

Incluso usando el mismo modelo, el mismo prompt y la misma información, puede haber variaciones.

Por eso, cuando una aplicación ejecuta IA, no basta con probar que “respondió bien una vez”. Hay que evaluar su comportamiento en múltiples casos, revisar consistencia, definir umbrales, registrar versiones y establecer supervisión humana donde corresponda.

2.3 Cuándo el uso de IA requiere mayor control

No todo uso de IA tiene el mismo nivel de riesgo.

Un asistente que ayuda a redactar textos internos no requiere el mismo control que un sistema que recomienda adjudicar, rechazar, aprobar, pagar, fiscalizar o priorizar casos.

El nivel de gobernanza debe aumentar cuando la IA:

maneja datos personales o información sensible;
influye en decisiones que afectan a personas;
asigna puntajes o clasificaciones;
recomienda acciones comerciales, legales, financieras o administrativas;
interactúa directamente con usuarios finales;
opera en procesos sujetos a regulación;
reemplaza o reduce revisión humana;
genera información que será usada como antecedente formal.

En esos casos, el problema no es solo técnico. También es operacional, legal, reputacional y ético.

2.4 Qué proponemos para software que ejecuta IA

Cuando una aplicación usa IA en tiempo real, la disciplina necesaria no se limita al código. También debe gobernarse el comportamiento del modelo.

a. Registro de prompts, modelos y contexto

Se debe saber qué instrucciones recibió el modelo, qué versión se usó, con qué parámetros, qué información se le entregó y qué respuesta generó.

Sin ese registro, es muy difícil investigar errores, comparar resultados o explicar por qué el sistema respondió de cierta manera.

b. Casos de evaluación

No basta con probar manualmente algunos ejemplos. Es necesario construir un conjunto de casos representativos para evaluar el comportamiento del sistema.

Estos casos deben incluir:

situaciones normales;
casos límite;
datos incompletos;
instrucciones ambiguas;
documentos extensos;
información contradictoria;
escenarios donde la IA debería abstenerse o pedir revisión humana.

El objetivo no es exigir perfección absoluta, sino medir desempeño, consistencia y riesgo.

c. Umbrales y criterios de aceptación

En sistemas probabilísticos, muchas veces no corresponde hablar solo de “pasa” o “falla”. Puede ser más realista definir umbrales de aceptación.

Por ejemplo:

porcentaje mínimo de respuestas aceptables;
nivel de consistencia entre ejecuciones;
cantidad máxima de errores críticos tolerables;
casos donde el sistema debe derivar a revisión humana;
criterios para bloquear una respuesta o advertir incertidumbre.

Esto permite evaluar el sistema de manera más honesta que una prueba aislada en una demo.

d. Revisión humana en decisiones de alto impacto

Cuando el error tiene costo real, la IA no debe operar como autoridad final sin supervisión.

Puede priorizar, resumir, sugerir, clasificar o recomendar. Pero en decisiones críticas debe existir revisión humana, especialmente cuando hay efectos sobre personas, cumplimiento normativo, seguridad, pagos, derechos, beneficios, sanciones o comunicaciones sensibles.

La IA debe ser tratada como apoyo experto, no como juez automático.

e. Monitoreo y mejora continua

El comportamiento de un sistema basado en IA puede cambiar por múltiples razones: cambios de modelo, cambios en los datos, cambios en los usuarios, cambios en los documentos analizados o cambios en el contexto del negocio.

Por eso se requiere monitoreo continuo:

revisión de respuestas;
análisis de errores frecuentes;
comparación entre versiones de modelo;
ajustes controlados de prompts;
revisión de métricas de calidad;
mecanismos de retroalimentación humana.

La gobernanza de IA no es un documento estático. Es una práctica operacional que debemos estar supervisando.

Conclusión, más IA, pero con más ingeniería

La discusión no debería ser si usar o no usar IA para construir software. Esa discusión ya quedó atrás.

La pregunta correcta es bajo qué disciplina se usa.

La IA permite avanzar más rápido, reducir tiempos de desarrollo y abrir posibilidades que antes eran inviables para muchos equipos. Pero esa velocidad no reemplaza la ingeniería. La hace más necesaria.

En el software generado con IA, el principal riesgo es la deuda de comprensión, sistemas que funcionan, pero que nadie entiende lo suficiente como para mantener, corregir o escalar.

En el software que ejecuta IA, el principal riesgo es tratar resultados probabilísticos como si fueran verdades exactas, sin revisión, trazabilidad ni gobernanza.

Ambos riesgos tienen solución. No se trata de frenar la innovación ni de volver a procesos pesados. Se trata de instalar la disciplina mínima para que lo que hoy funciona pueda seguir funcionando mañana.

Esa es la posición de Asimov, utilizamos la IA para construir más rápido, pero sin renunciar a la responsabilidad técnica de entender, sostener y responder por lo que construimos.