Este artículo fue escrito en coautoría por Reya Vir y Rahul Vir.
ha cambiado fundamentalmente en la era GenAI. Con la ubicuidad de las herramientas de codificación vibe y los IDE de agente primero como Antigravity de Google, el desarrollo de nuevas aplicaciones nunca ha sido tan rápido. Además, los poderosos conceptos inspirados en marcos virales de código abierto como OpenClaw están permitiendo la creación de sistemas autónomos. Podemos colocar agentes en arneses seguros, proporcionarles habilidades de Python ejecutables y definir sus personas del sistema en archivos Markdown simples. Usamos el bucle agente recursivo (Observar-Pensar-Actuar) para la ejecución, configuramos puertas de enlace sin cabeza para conectarlas a través de aplicaciones de chat y confiamos en Molt State para conservar la memoria durante los reinicios a medida que los agentes se mejoran a sí mismos. Incluso les damos un token de no respuesta para que puedan emitir silencio en lugar de su habitual naturaleza conversadora.
Crear agentes autónomos ha sido muy sencillo. Pero la pregunta sigue siendo: si hoy en día la construcción es tan sencilla, ¿por qué las empresas están viendo una avalancha de prototipos y una fracción notablemente pequeña de ellos se gradúan hacia productos reales?
1. La ilusión del éxito:
En mis conversaciones con líderes empresariales, veo innumerables prototipos desarrollados entre equipos, lo que demuestra que existe un inmenso interés desde abajo en transformar aplicaciones de software rígidas y cansadas en agentes de asistencia y totalmente automatizados. Sin embargo, este éxito inicial es engañoso. Un agente puede desempeñarse de manera brillante en una computadora portátil Jupyter o en una demostración en escena, generando suficiente entusiasmo para mostrar su experiencia en ingeniería y obtener financiamiento, pero rara vez sobrevive en el mundo real.
Esto se debe en gran medida a un aumento repentino en la codificación de vibraciones que prioriza la experimentación rápida sobre la ingeniería rigurosa. Estas herramientas son excelentes para desarrollar demostraciones, pero sin una disciplina estructural, el código resultante carece de la capacidad y confiabilidad para construir un producto de nivel de producción. [Why Vibe Coding Fails]. Una vez que los ingenieros regresan a sus trabajos diarios, el prototipo se abandona y comienza a deteriorarse, al igual que el software sin mantenimiento.
De hecho, el problema de la mantenibilidad es más profundo. Si bien los humanos son perfectamente capaces de adaptarse a la evolución natural de los flujos de trabajo, los agentes no lo son. Un cambio sutil en el proceso de negocio o un cambio de modelo subyacente pueden inutilizar al agente.
Un ejemplo de atención médica: digamos que tenemos un agente de admisión de pacientes diseñado para clasificar a los pacientes, verificar el seguro y programar citas. En una demostración codificada por vibración, maneja perfectamente los chequeos estándar. Utilizando un Gateway, chatea con los pacientes mediante mensajes de texto. Utiliza habilidades básicas para acceder a la API de seguros y su System Persona establece un tono clínico y cortés. Pero en una clínica en vivo, el ambiente es lleno de estado y desordenado. Si un paciente menciona dolor en el pecho a mitad de una ingesta de rutina, el bucle agente del agente debe reconocer instantáneamente la urgencia, abandonar el flujo de programación y desencadenar una escalada de seguridad. Debería utilizar el token de no respuesta para suprimir las conversaciones sobre reservas mientras envía el contexto a una enfermera humana. La mayoría de los prototipos fracasan espectacularmente en esta prueba.
Hoy en día, una gran mayoría de iniciativas prometedoras persiguen un “prototipo de espejismo”, un flujo interminable de agentes de prueba de concepto que parecen productivos en las primeras pruebas pero que se desvanecen cuando se enfrentan a la realidad del entorno de producción.
2. Definición del prototipo de espejismo
El Prototype Mirage es un fenómeno en el que las empresas miden el éxito basándose en el éxito de las demostraciones y las primeras pruebas, solo para verlas fallar en la producción debido a problemas de confiabilidad, alta latencia, costos inmanejables y una falta fundamental de confianza. Sin embargo, esto no es un error que pueda corregirse, sino una falla sistémica de la arquitectura.
Los síntomas clave incluyen:
Fiabilidad desconocida: la mayoría de los agentes no cumplen con las estrictas demandas de uso empresarial de los acuerdos de nivel de servicio (SLA). A medida que los errores dentro de los sistemas de uno o varios agentes se agravan con cada acción (también conocido como decaimiento estocástico), los desarrolladores limitan su agencia. Ejemplo: si el agente de admisión de pacientes depende de un libro de estado compartido para coordinar entre un “subagente de programación” y un “subagente de seguros”, una alucinación en el paso 12 de un proceso de verificación de seguros de 15 pasos descarrila todo el flujo de trabajo. Un estudio reciente muestra que el 68% de los agentes de producción se limitan deliberadamente a 10 pasos o menos para evitar descarrilamientos. Fragilidad de la evaluación: la confiabilidad sigue siendo una variable desconocida porque el 74% de los agentes dependen de la evaluación humana en el circuito (HITL). Si bien este es un punto de partida razonable considerando el uso de agentes en estos dominios altamente especializados donde los puntos de referencia públicos son insuficientes, el enfoque no es escalable ni mantenible. Pasar a evaluaciones estructuradas y LLM-as-a-Judge es el único camino sostenible a seguir (Pan et al., 2025). Deriva del contexto: los agentes a menudo se crean para capturar flujos de trabajo humanos heredados. Sin embargo, los procesos comerciales cambian de forma natural. Ejemplo: si el hospital actualiza sus niveles aceptados de Medicaid, el agente carece de Introspección o Bucle Metacognitivo para analizar sus propios registros de fallas y adaptarse. Sus rígidas cadenas de avisos se rompen tan pronto como el entorno se desvía del contexto de entrenamiento, dejando al agente obsoleto.
3. Alineación con los OKR empresariales
Cada empresa opera con un conjunto de objetivos y resultados clave (OKR) definidos. Para romper con esta ilusión, debemos ver a estos agentes como entidades autorizadas para optimizar métricas comerciales específicas.
A medida que aspiramos a una mayor autonomía, permitiendo a los agentes comprender el entorno y adaptarse continuamente para abordar los desafíos sin una intervención humana constante, deben ser direccionalmente conscientes del verdadero objetivo de optimización.
Los OKR proporcionan un objetivo superior a alcanzar (p. ej., reducir los tiempos de espera de los pacientes críticos en un 20 %) en lugar de una métrica de objetivo intermedia (p. ej., procesar 50 formularios de admisión por hora). Al comprender el OKR, nuestro agente de admisión de pacientes puede ver de manera proactiva señales que van en contra del objetivo de tiempo de espera del paciente y abordarlas con una mínima participación humana.
Una investigación reciente de Berkeley CMR enmarca esto en la teoría del agente principal. El “Principal” es la parte interesada responsable del OKR. El éxito depende de delegar autoridad al agente de una manera que alinee los incentivos, asegurando que actúe en interés del Principal incluso cuando funcione sin ser observado.
Sin embargo, la autonomía se gana, no se otorga desde el primer día. El éxito sigue un modelo de autonomía guiada:
Conocido: comience con casos de uso capacitados con barreras de seguridad estrictas (por ejemplo, el agente solo maneja exámenes físicos de rutina y verificación básica de seguros). Escalamiento: el agente reconoce casos extremos (p. ej., síntomas contradictorios) y los escala a enfermeras de clasificación humana en lugar de adivinar. Evolución: a medida que el agente obtiene un mejor linaje de datos y demuestra alineación con los OKR, se le otorga una mayor agencia (por ejemplo, manejo de referencias de especialistas).
4. Camino a seguir
Una cuidadosa estrategia a largo plazo es esencial para transformar estos prototipos en verdaderos productos que evolucionen con el tiempo. Tenemos que entender que las aplicaciones agentes deben desarrollarse, evolucionar y mantenerse para pasar de meros asistentes a entidades autónomas, al igual que las aplicaciones de software. Los espejismos codificados por vibraciones no son productos y no debes confiar en nadie que diga lo contrario. Son simplemente pruebas de conceptos para una retroalimentación temprana.
Para escapar de esta ilusión y lograr un éxito real, debemos aportar alineación de productos y disciplina de ingeniería al desarrollo de estos agentes. Tenemos que construir sistemas para combatir las formas específicas en que estos modelos luchan, como los identificados en nueve patrones de falla críticos.
Durante las próximas semanas, esta serie lo guiará a través de los pilares técnicos necesarios para transformar su empresa.
Confiabilidad: pasar de “Vibes” a conjuntos de datos dorados y LLM como juez (para que nuestro agente de admisión de pacientes pueda probarse continuamente con miles de historias complejas de pacientes simuladas). Economía: Dominar la economía de tokens para optimizar el costo de los flujos de trabajo agentes. Seguridad: Implementación de Seguridad Agentic a través del linaje de datos y control de flujo. Rendimiento: lograr el rendimiento de los agentes a escala para mejorar la productividad.
El viaje desde un “prototipo” hasta “implementado” no se trata de corregir errores; se trata de construir una arquitectura fundamentalmente mejor.
Referencias
Vir, R., Ma J., Sahni R., Chilton L., Wu, E., Yu Z., Columbia DAPLab. (2026, 7 de enero). Por qué falla la codificación de Vibe y cómo solucionarlo. Laboratorio de Datos, Agentes y Procesos, Universidad de Columbia. https://daplab.cs.columbia.edu/general/2026/01/07/why-vibe-coding-fails-and-how-to-fix-it.html Pan, MZ, Arabzadeh, N., Cogo, R., Zhu, Y., Xiong, A., Agrawal, LA,… & Ellis, M. (2025). Agentes de Medición en la Producción. arXiv. https://arxiv.org/abs/2512.04123 Jarrahi, MH y Ritala, P. (23 de julio de 2025). Repensar a los agentes de IA: una perspectiva de agente principal. Revisión de la gestión de Berkeley California. https://cmr.berkeley.edu/2025/07/rethinking-ai-agents-a-principal-agent-perspective/ Vir, R., Columbia DAPLab. (2026, 8 de enero). 9 patrones de falla crítica de los agentes codificadores. Laboratorio de Datos, Agentes y Procesos, Universidad de Columbia. https://daplab.cs.columbia.edu/general/2026/01/08/9-critical-failure-patterns-of-coding-agents.html
Todas las imágenes generadas por Nano Banana 2