El pasado ha sido una montaña rusa absoluta (o alegría) de tecnologías generativas de IA generativas en rápida evolución. En los veinticinco años que he contado a mí mismo un desarrollador de software, no puedo recordar un cambio tectónico de una magnitud similar, uno que ya está cambiando fundamentalmente cómo se está escribiendo software.
Sin embargo, sería miope creer que esta revolución se detiene simplemente para generar código. Con los agentes de inteligencia artificial y el ecosistema que se abre a nuevas integraciones, las bases de cómo monitoreamos, entendemos y optimizamos el software también se están volcando. Las herramientas que nos sirvieron bien en un mundo centrado en el ser humano, construidos en torno a conceptos como alertas manuales, datacríes y paneles, se están volviendo irrelevantes y obsoletos. Las plataformas de monitoreo de rendimiento de la aplicación (APM) y, en particular, cómo aprovechan los registros, las métricas y las trazas, deberán reconocer que el usuario humano que posee los recursos de tiempo requeridos para navegar, filtrar y establecer umbrales ya no está disponible, el equipo ya ha delegado gran parte de ese trabajo a IA.
Los agentes inteligentes se están volviendo integrales al SDLC (ciclo de vida de desarrollo de software), analizando, diagnosticando y mejorando de forma autónoma en tiempo real. Este paradigma emergente requiere una nueva versión de un viejo problema. Para que los datos de observabilidad se incorporen para hacer que los agentes y los equipos sean más productivos, debe estructurarse para máquinas, no para humanos. Una tecnología reciente que hace que esto sea posible también es una que ha recibido un montón de rumores últimamente, el Protocolo de contexto modelo (MCP).
McPs en pocas palabras
Inicialmente introducido por Antrópicoel Protocolo de contexto del modelo (MCP) representa un nivel de comunicación entre los agentes de IA y otras aplicaciones, lo que permite a los agentes acceder a fuentes de datos adicionales y realizar acciones como mejor les parezca. Más importante aún, los MCP abren nuevos horizontes para que el agente elija inteligentemente actuar más allá de su alcance inmediato y, por lo tanto, amplíe la gama de casos de uso que puede abordar.
La tecnología no es nueva, pero el ecosistema lo es. En mi opinión, es el equivalente a evolucionar desde el desarrollo de aplicaciones móviles personalizadas hasta tener una tienda de aplicaciones. No es por casualidad que esté experimentando un crecimiento de las proporciones cámbricas, ya que simplemente tener un ecosistema rico y estandarizado abre el mercado para nuevas oportunidades. En términos más generales, los MCP representan un modelo centrado en el agente para crear nuevos productos que puedan transformar la forma en que se construyen las aplicaciones y la forma en que entregan valor a los usuarios finales.
Las limitaciones de un modelo centrado en el ser humano
La mayoría de las aplicaciones de software se basan en los humanos como sus principales usuarios. En términos generales, un proveedor decide invertir en el desarrollo de ciertas características del producto, lo que cree que será una buena coincidencia para los requisitos y necesidades de los usuarios finales. Luego, los usuarios intentan utilizar ese conjunto de características dado para tratar de satisfacer sus necesidades específicas.
Hay tres limitaciones principales para este enfoque, que se están convirtiendo en un impedimento más a medida que los equipos adoptan agentes de IA para racionalizar sus procesos:
- Interfaz fija– Los gerentes de productos deben anticipar y generalizar el caso de uso para crear las interfaces correctas en la aplicación. El conjunto de UI o API se fija y no puede adaptarse a cada necesidad única. En consecuencia, los usuarios pueden encontrar que algunas características son completamente inútiles para sus requisitos específicos. Otras veces, incluso con una combinación de características, el usuario no puede obtener todo lo que necesita.
- Carga cognitiva – El proceso de interactuar con los datos de la aplicación para obtener la información que el usuario necesita requiere esfuerzo manual, recursos y, a veces, experiencia. Tomar APM como ejemplo, comprender la causa raíz de un problema de rendimiento y solucionarlo podría tomar alguna investigación, ya que cada problema es diferente. La falta de automatización y dependencia de procesos manuales voluntarios a menudo significa que los datos no se utilizan en absoluto.
- Alcance limitado – Cada producto a menudo solo contiene una parte de la imagen necesaria para resolver el requisito específico. Por ejemplo, el APM podría tener los datos de rastreo, pero no hay acceso al código, el historial de GitHub, las tendencias JIRA, los datos de infraestructura o los boletos de los clientes. El usuario se deja en el usuario utilizando múltiples fuentes para llegar a la raíz de cada problema.
MCPS centrado en el agente: la aplicación invertida
Con el advenimiento de MCPS, los desarrolladores de software ahora tienen la opción de adoptar un modelo diferente para desarrollar software. En lugar de centrarse en un caso de uso específico, tratando de clavar los elementos de interfaz de usuario correctos para los patrones de uso codificado, las aplicaciones pueden transformarse en un recurso para procesos impulsados por la IA. Esto describe un cambio de apoyar un puñado de interacciones predefinidas a apoyar numerosos emergente casos de uso. En lugar de invertir en una característica específica, una aplicación ahora puede optar por prestar su experiencia en el dominio al agente de IA a través de datos y comportamiento Eso puede usarse de manera oportunista cada vez que sean relevantes, aunque sea indirectamente.
A medida que este modelo escala, el agente puede consolidar a la perfección datos y acciones de diferentes aplicaciones y dominios, como GitHub, JIRA, plataformas de observabilidad, herramientas de análisis y la propia base. El agente puede automatizar el proceso de análisis en sí mismo como parte de sintetización los datos, eliminando los pasos manuales y la necesidad de experiencia especializada.
La observabilidad no es una aplicación web; Es experiencia en datos
Echemos un vistazo a un ejemplo práctico que puede ilustrar cómo un modelo centrado en el agente abre nuevas vías neuronales en el proceso de ingeniería.
Todo desarrollador sabe revisiones de código requiere mucho esfuerzo; Para empeorar las cosas, el revisor a menudo se ajusta el contexto de sus otras tareas, drenando aún más la productividad del equipo. En la superficie, esto parecería una oportunidad para que las aplicaciones de observabilidad brille. Después de todo, el código bajo revisión ya ha acumulado datos significativos que se ejecutan en entornos de prueba y preproducción. Teóricamente, esta información puede ayudar a descifrar más sobre los cambios, lo que están impactando y cómo posiblemente han alterado el comportamiento del sistema. Desafortunadamente, el alto costo de dar sentido a todos esos datos en múltiples aplicaciones y flujo de datos lo hace inútil.
Sin embargo, en un flujo centrado en el agente, cada vez que un ingeniero le pide a un agente de IA que ayude a revisar el nuevo código, ese proceso completo se vuelve completamente autónomo. En el fondo, el agente orquestará los pasos de investigación en múltiples aplicaciones y MCP, incluidas las herramientas de observabilidad, para recuperar información procesable sobre los cambios en el código. El agente puede acceder a datos de tiempo de ejecución relevantes (por ejemplo, trazas y registros de las ejecuciones de puesta en escena), análisis en el uso de funciones, metadatos de confirmación de GitHub e incluso el historial de boletos JIRA. Luego correlaciona la diferencia con los tramos de tiempo de ejecución relevantes, las regresiones de latencia de los indicadores o las interacciones fallidas, y señala incidentes recientes que podrían relacionarse con el código modificado.
En este escenario, el desarrollador no necesita examinar diferentes herramientas o pestañas o pasar tiempo tratando de conectar los puntos: el agente lo reúne todo detrás de escena, identificando problemas, así como posibles soluciones. A medida que la respuesta en sí misma se genera dinámicamente: puede comenzar con un resumen textual conciso, expandirse a una tabla que muestra métricas con el tiempo, incluir un enlace al archivo afectado en GitHub con cambios resaltados e incluso incrustar una tabla que visualiza la línea de tiempo de los errores antes y después de la liberación.
Si bien el flujo de trabajo anterior fue producido orgánicamente por un agente, algunos clientes de IA permitirán al usuario consolidar los flujos de trabajo deseados agregando reglas a la memoria del agente. Por ejemplo, este es un archivo de memoria que estoy actualizando con el cursor para garantizar que todas las indicaciones de revisión del código activen los cheques constantemente al entorno de prueba y verifiquen el uso en función de la producción.
Muerte por mil casos de uso
El escenario de revisión del código es solo uno de muchos emergente Casos de uso que demuestren cómo AI puede utilizar silenciosamente los datos relevantes de MCP para ayudar al usuario a lograr sus objetivos. Más importante aún, el usuario no necesita estar al tanto de las aplicaciones que el agente usaba de forma autónoma. Desde la perspectiva del usuario, solo necesitan describir su necesidad.
Los casos de uso emergentes pueden mejorar la productividad del usuario en todos los ámbitos con datos que no se pueden hacer accesibles de otra manera. Aquí hay algunos otros ejemplos en los que los datos de observabilidad pueden marcar una gran diferencia, sin que nadie tenga que visitar una sola página web de APM:
- Generación de pruebas Basado en el uso real
- Seleccionar las áreas correctas para refactor Basado en los problemas de código que afectan el rendimiento más
- Prevenir cambios de ruptura Cuando el código aún se revisa
- Detector código no utilizado
Los productos deben cambiar
Sin embargo, hacer que la observabilidad sea útil para el agente es un poco más involucrada que abofetear en un adaptador MCP a un APM. De hecho, muchas de las herramientas de generación actuales, en apresurarse para apoyar la nueva tecnología, tomó esa misma ruta, sin tener en cuenta que los agentes de IA también tienen sus limitaciones.
Si bien es inteligente y potente, los agentes no pueden reemplazar instantáneamente ninguna aplicación que interactúe con ningún dato, bajo demanda. En su iteración actual, al menos, están sujetos al tamaño del conjunto de datos y no se pueden aplicar algoritmos ML más complejos o incluso matemáticas de orden superior. Si la herramienta de observabilidad se convertirá en un proveedor de datos efectivo para el agente, debe preparar los datos por adelantado en lugar de estas limitaciones. En términos más generales, esto define el papel de los productos en la era de la IA, proporcionando islas de experiencia en dominio no trivial que se utilizará en un proceso impulsado por la IA.
Hay muchas publicaciones sobre el tema sobre la mejor manera de preparar los datos para el uso de agentes generativos de IA, y he incluido algunos enlaces al final de esta publicación. Sin embargo, podemos describir algunos de los requisitos de una buena salida de MCP en trazos amplios:
- Estructurado (entidades mecanografiadas con esquema consistentes)
- Preprocesado (agregado, deduplicado, etiquetado)
- Contextualizado (agrupado por sesión, ciclo de vida o intención)
- Vinculado (Referencias entre los tramos de código, registros, compromisos y boletos)
En lugar de surgir telemetría cruda y MCP debe alimentar una narrativa de datos coherente al agente, después del análisis. El agente no es solo una vista del tablero a ser representada. Al mismo tiempo, también debe hacer el importante Datos en bruto disponibles bajo demanda para permitir una mayor investigación, para respaldar las acciones de razonamiento autónomas del agente.
Dado el acceso simple a los datos sin procesar, sería casi imposible que un agente identifique un problema que se manifiesta en el rastreo interno de solo el 5% de los millones de trazas disponibles, y mucho menos priorizar ese problema en función de su impacto en el sistema, o hacer la determinación de si ese patrón es anómalo.
Para cerrar esa brecha, muchos productos probablemente evolucionarán hacia ‘prepossores de IA’, presentando procesos ML dedicados y análisis estadísticos de alto nivel, así como experiencia en el dominio.
Despedida a los APMS
En última instancia, los APM no son herramientas heredadas: son representativos de un mentalidad heredada Eso se está reemplazando lenta pero seguramente. Puede tomar más tiempo para que la industria realine se realine, pero finalmente afectará muchos de los productos que usamos actualmente, especialmente en la industria del software, que está compitiendo para adoptar IA generativa.
A medida que la IA se vuelve más dominante en el desarrollo del software, ya no se limitará a las interacciones iniciadas por los humanos. El razonamiento generativo de IA se utilizará como parte del proceso de CI, y en algunos casos, incluso se ejecuta indefinidamente como procesos de fondo verificando continuamente los datos y las acciones de realización. Con eso en mente, cada vez más herramientas encontrarán su complemento modelo centrado en el agente y, a veces, reemplazarán su enfoque directo a humano, o se arriesgarán a quedarse fuera de sus clientes la nueva pila AI SLDC.
Enlaces y recursos
- Airbyte: La normalización es clave: la consistencia del esquema y el enlace relacional mejoran el razonamiento de fuente cruzada.
- Harrison Clarke: El preprocesamiento debe alcanzar el punto óptimo, lo suficientemente rico como para inferencia, lo suficientemente estructurado para precisión.
- Digitalocean: La agregación por límites semánticos (sesiones de usuario, flujos) desbloquea mejores fragmentos y razonamiento basado en la historia.
¿Quieres conectarte?Puedes comunicarme conmigo en Twitter en @Doppleware o vía LinkedIn .
Seguir mi MCPPara el análisis de código dinámico utilizando la observabilidad en https://github.com/digma-ai/digma-mcp-server