He estado investigando qué decisiones de un agente de programación merecen una llamada generativa y cuáles pueden resolverse con un mecanismo más pequeño. Elegir una herramienta, comprobar una afirmación o escalar una tarea son problemas diferentes de escribir el parche que la resuelve. Mi propuesta es repartir ese trabajo entre código, clasificadores, modelos de decisión y LLM, y medir si esa separación mejora el resultado.

Quiero empezar a automatizar cosas con agentes y poder reutilizarlos en proyectos distintos. Un agente que investigue incidencias, otro que examine repositorios, otro que prepare documentación. Y que puedan colaborar cuando el trabajo lo requiera.

La oferta de frameworks crece tan rápido que elegir uno parece haberse convertido en el primer paso obligatorio. Mi duda empieza antes: ¿cómo se diseña un agente al que otros puedan encontrar, encargar trabajo y pedir cuentas del resultado?

Eso me lleva a pensar en servicios, contratos y sistemas distribuidos. El framework que ejecute cada agente será una decisión dentro de esa arquitectura.

He pasado suficiente tiempo alternando entre terminales, ramas y pull requests como para saber que ejecutar varios agentes de código no es simplemente una versión más grande de ejecutar uno. Es un problema de coordinación. Agent Orchestrator (AO) es una aplicación de escritorio creada para resolverlo, y la estoy usando para coordinar el trabajo en esta web.

He estado trabajando en mastra-azure-ai-search, un proveedor de vector store de Azure AI Search para Mastra.

El motivo es sencillo: abrí el trabajo de integración en Mastra, pero la PR todavía no ha sido aprobada. En vez de dejar el adaptador bloqueado dentro de una pull request pendiente, he decidido publicarlo como paquete independiente para poder usarlo, probarlo y mejorarlo ya.

Arquitectura de cartón piedra: cuando el código parece limpio, pero no hay quien lo entienda​

Hay proyectos que, al abrirlos, dan muy buena impresión:

• Carpetas bien puestas: core, domain, infrastructure, services, helpers…
• Clases con nombres serios: UserService, OrderManager, PaymentHandler…
• Documentación extensa, diagramas, README detallado…

Y sin embargo, cuando intentas seguir cómo funciona realmente el sistema, te encuentras con algo muy distinto: métodos que llaman a otros métodos que llaman a otros métodos, capas que solo delegan, lógica de negocio repartida por todo el repositorio… y tú pensando:

“Esto parece muy arquitectónico, pero entenderlo es un dolor.”

A eso es a lo que me gusta llamar arquitectura de cartón piedra: por fuera parece sólida, pero por dentro no sostiene bien el peso del negocio.

Resumen: Comparativa entre Mastra (framework TypeScript) y Microsoft Agent Framework + Azure AI Foundry.

En los últimos años he visto dos extremos igual de dañinos en muchos equipos de desarrollo: el de la sobre-ingeniería y el de la PoC eterna. Este post va de por qué ambos extremos son una mala práctica de ingeniería y de cómo encontrar un punto medio razonable.

¡Hola y bienvenido a mi blog personal! 👋

Este es el primer post de muchos que vienen. Aquí compartiré mis experiencias, aprendizajes y reflexiones sobre tecnología, desarrollo de software y todo lo que me apasiona.