DEV Community: Camilo Vera

De Dartmouth a ChatGPT: 66 años para llegar a una máquina que supiera charlar

Camilo Vera — Sat, 31 Oct 2026 11:36:34 +0000

Publicado originalmente en Technical Logbook.

66 años de historia, dos inviernos de fracaso público y la convergencia final de cuatro piezas dispersas: cómo llegamos, en 2022, a una máquina que por fin supo conversar.

por Camilo — Agosto 15 2026 · LinkedIn

Últimamente no hay reunión de trabajo que no termine mencionando "agentes", "tokens", "LLMs". Términos que manejamos con soltura —yo incluido— sin poder siempre explicar con precisión qué son ni cómo se relacionan entre sí. Se han vuelto vocabulario de oficina tan rápido que dimos por sentado que los entendíamos, cuando en realidad los estamos usando como sinónimos de algo mucho más amplio: "la IA", así, en singular y sin matices.

El problema es que "la IA" no es una cosa. Es un campo con 66 años de historia, dos fracasos públicos y sonoros, y una convergencia final de piezas que estuvieron dispersas durante décadas antes de encajar. Entender ese recorrido —de dónde viene cada palabra que usamos hoy— es lo que te permite, después, distinguir con precisión entre inteligencia artificial, machine learning, LLMs y las herramientas que armamos con ellos. Ese es el objetivo de esta serie. Empecemos por el principio.

La palabra que se inventó en un verano de 1956

En el verano de 1956, un grupo pequeño de matemáticos e ingenieros se reunió en Dartmouth College, en New Hampshire, convocados por un joven profesor llamado John McCarthy. El objetivo declarado del encuentro —ocho semanas de trabajo, financiadas por la Fundación Rockefeller— era ambicioso hasta rozar lo temerario: explorar la idea de que cualquier aspecto del aprendizaje o de la inteligencia pudiera describirse con tanta precisión que una máquina lograra simularlo.

Ahí, en esa propuesta, se usó por primera vez el término "inteligencia artificial". No fue un hallazgo técnico puntual; fue una apuesta filosófica con nombre propio. McCarthy y sus colegas —entre ellos Marvin Minsky, Claude Shannon y Nathaniel Rochester— no tenían todavía las herramientas para cumplir esa promesa. Tampoco imaginaban cuánto tiempo iba a tomar.

Ese desfasaje entre la ambición del nombre y la capacidad real de la tecnología es, en más de un sentido, el patrón que se repite durante las siguientes seis décadas.

Cuando el campo prometió de más, dos veces

La historia de la IA no es una línea ascendente. Es una historia de entusiasmo, promesa incumplida, y colapso de financiamiento — dos veces.

El primer episodio ocurrió a mediados de los años 70, cuando la Agencia de Proyectos de Investigación Avanzados de Defensa de Estados Unidos (DARPA, por sus siglas en inglés) retiró buena parte del financiamiento a la investigación general en IA, al no ver resultados militares concretos. Un informe británico crítico de la época, el llamado Informe Lighthill, terminó de sellar el desánimo. (Vale una aclaración honesta: entre historiadores del campo hay debate sobre si este "primer invierno" fue tan severo como se suele contar en retrospectiva, o si es una narrativa que se simplificó con el tiempo. El segundo episodio, en cambio, no admite discusión.)

Ese segundo invierno llegó a fines de los 80. La industria había apostado fuerte a los llamados "sistemas expertos" — programas que codificaban el conocimiento de un especialista humano en reglas del tipo "si pasa esto, entonces hacé aquello". Funcionaban, hasta que dejaban de funcionar: eran costosísimos de mantener, y una sola regla faltante podía romper el sistema entero. Cuando el hardware especializado que sostenía esa industria se volvió obsoleto frente a estaciones de trabajo genéricas mucho más baratas, el mercado colapsó casi de un día para el otro. Universidades enteras perdieron financiamiento. El término "inteligencia artificial" mismo cayó en desprestigio durante casi una década.

Es importante decir esto en voz alta: la IA no fue una marcha triunfal e ininterrumpida hacia el presente. Fue, dos veces, un campo que casi se extingue.

El otro camino: aprender de los datos en vez de programar reglas

Mientras los sistemas expertos se derrumbaban, un enfoque distinto venía tomando forma en paralelo, casi silenciosamente. En vez de programar reglas explícitas para cada situación, ¿y si un sistema pudiera aprender esas reglas por sí mismo, a partir de ejemplos?

Ese enfoque —el aprendizaje automático, o machine learning— no es sinónimo de inteligencia artificial. Es un subconjunto de ella: una familia específica de técnicas dentro del campo más amplio que se inauguró en Dartmouth. Y dentro del machine learning hay, a su vez, un subconjunto más específico todavía: el deep learning, o aprendizaje profundo, que usa redes neuronales de múltiples capas inspiradas —de forma bastante libre— en la estructura del cerebro.

Esta relación de contención (IA contiene a ML, que contiene a deep learning) no es un detalle técnico menor. Es, probablemente, la fuente número uno de confusión en cualquier charla de oficina sobre el tema. Cuando alguien dice "la IA hizo esto", casi siempre se está refiriendo a un modelo de deep learning específico — no al campo entero.

El problema del deep learning, durante décadas, fue que la teoría existía pero le faltaban dos cosas: datos suficientes para aprender patrones complejos, y poder de cómputo suficiente para procesarlos en un tiempo razonable. Esa carencia se resolvió recién en 2012.

Cuatro piezas que estaban dispersas

Ese año, un modelo llamado AlexNet ganó por una diferencia abrumadora una competencia de reconocimiento de imágenes llamada ImageNet. No ganó por poco: superó al segundo lugar por casi diez puntos porcentuales de precisión, algo inédito hasta ese momento. La clave no fue solo el diseño de la red neuronal, sino la combinación de dos factores que hasta entonces habían viajado por separado: un dataset masivo de imágenes etiquetadas y el uso de placas gráficas (GPUs) — hasta entonces pensadas para videojuegos, no para entrenar redes neuronales — para paralelizar el entrenamiento.

Ese fue el primer encastre. El segundo llegó cinco años después, y fue puramente arquitectónico. En 2017, un equipo de Google publicó un paper con un título casi provocador: Attention Is All You Need. Proponía una nueva forma de procesar secuencias de texto —el Transformer— que abandonaba el procesamiento palabra por palabra a favor de un mecanismo de atención que evalúa todas las palabras de una oración en simultáneo, en paralelo. Esa arquitectura es, hoy, el motor que corre por debajo de prácticamente cualquier modelo de lenguaje que uses: GPT, Claude, Gemini, Llama, todos.

El tercer encastre fue una constatación empírica. En 2020, investigadores de OpenAI publicaron evidencia de que la performance de un modelo de lenguaje mejora de forma predecible —siguiendo una ley de potencia— a medida que aumentás su tamaño, la cantidad de datos de entrenamiento y el cómputo disponible. Esto no era obvio de antemano. Antes de este hallazgo, escalar un modelo era una apuesta; después, se convirtió en una fórmula con resultados razonablemente predecibles. Esa confianza fue lo que justificó construir GPT-3, un modelo de 175 mil millones de parámetros que en 2020 validó esas leyes de escala a una magnitud sin precedentes.

Y sin embargo, GPT-3 —a pesar de todo ese poder— era torpe para conversar. Estaba entrenado para completar texto, no para responder preguntas ni seguir instrucciones. Ahí entra la cuarta pieza, la que casi nunca aparece cuando se cuenta esta historia en versión corta: una técnica llamada aprendizaje por refuerzo con retroalimentación humana (RLHF), que se usó para afinar el modelo a partir de ejemplos de conversaciones reales, evaluadas y corregidas por personas. Ese ajuste fue lo que en noviembre de 2022 se convirtió en ChatGPT: no un modelo más grande, sino un modelo por fin usable. Llegó a cien millones de usuarios en dos meses — a Instagram le había tomado más de dos años alcanzar esa cifra.

Lo que esta historia deja en claro

"La IA" que irrumpió en la conversación de oficina en 2022 no apareció de la nada. Es el resultado de 66 años de trabajo, dos colapsos de financiamiento que casi terminan con el campo entero, y una convergencia final de cuatro piezas —datos, cómputo, arquitectura y una técnica de alineación— que existieron por separado durante años antes de que alguien las juntara en un mismo producto.

Esa distancia entre "inteligencia artificial" (el campo completo, con 66 años de historia) y "ChatGPT" (una aplicación puntual de una técnica específica, ajustada con otra técnica específica) es exactamente la distancia que se pierde cuando usamos todos estos términos como si fueran intercambiables. Y es el punto de partida para la Parte 2: qué es realmente un LLM, dónde termina el modelo y empieza la herramienta, y por qué esa distinción no es solo semántica — cambia lo que podés esperar, razonablemente, de cada una.

¿Quién gobierna el desgobierno de la IA?

Camilo Vera — Sun, 25 Oct 2026 13:17:49 +0000

Publicado originalmente en Technical Logbook.

Tres equipos de ingeniería, el mismo patrón arquitectónico, y ningún plan en común — lo que eso revela sobre cómo las organizaciones están (o no están) gobernando sus sistemas de agentes.

por Camilo — Junio 16 2026 · LinkedIn

La escena

Hace unos meses, en una reunión que en principio iba a durar media hora, descubrimos algo incómodo.

Tres equipos de ingeniería, dentro de la misma área de la compañía, habían estado desarrollando sistemas de agentes de AI en paralelo. Sin coordinarse. Sin saber, del todo, lo que estaba haciendo el equipo de al lado. Cada uno había llegado a la misma conclusión arquitectónica — un agente orquestador que coordina a otros agentes especializados — y cada uno lo había implementado a su manera, para su dominio, con sus herramientas.

Dos de esos equipos trabajan en ingeniería cloud. Uno cubre AWS y Azure bajo un modelo de cuentas y suscripciones compartidas. El otro trabaja exclusivamente con Azure y aprovisiona infraestructura a través de módulos de Terraform que consumen otros equipos. Sus agentes corren de forma local, dentro del equipo, integrados con GitHub Copilot en VSCode y conectados a MCP servers locales. No hablan con el exterior.

El tercero es un equipo de arquitectura especializado en soluciones de AI. Sus agentes sí conectan con MCP externos y están diseñados desde una lógica más centralizada.

Tres sistemas. Un mismo patrón de base. Ningún plan en común.

La reunión duró dos horas.

Esto no es un caso aislado

Mi primera reacción fue pensar que habíamos cometido un error organizacional clásico — falta de comunicación, silos, la historia de siempre. Pero mientras más lo analizaba, menos me convencía esa explicación. No fue descuido. Fue algo más estructural: cada equipo resolvió un problema real, con sentido dentro de su dominio, usando las herramientas disponibles. El problema no estaba en cada decisión individual. Estaba en la ausencia de una conversación que nadie había convocado todavía.

Y resulta que eso es exactamente lo que está pasando en casi todas partes.

Un reporte de OutSystems publicado en 2026, basado en encuestas a casi 1.900 líderes de tecnología globales, encontró que el 96% de las organizaciones ya está usando agentes de AI en alguna capacidad. Al mismo tiempo, el 94% reporta preocupación por el agent sprawl — la proliferación descontrolada de agentes que incrementa la complejidad, la deuda técnica y el riesgo de seguridad. El dato más revelador: solo el 12% implementó una plataforma centralizada para gestionar ese sprawl.

El 88% restante está navegando a ojo.

Gartner proyecta que para finales de 2026, el 40% de las aplicaciones enterprise va a tener agentes de AI embebidos con tareas específicas. En 2025, ese número era menor al 5%. Un salto de ocho veces en un año.

Los agentes no van a esperar a que las organizaciones estén listas. Ya están adentro.

Lo que está en juego no es si vamos a tener agentes de AI en nuestros equipos de ingeniería — eso ya es un hecho consumado. Lo que está en juego es si vamos a tener la arquitectura para que esos agentes trabajen juntos, o si vamos a terminar con una colección de soluciones brillantes que no pueden hablar entre sí.

El patrón Orquestador: por qué todos llegamos al mismo lugar

Para entender por qué tres equipos tomaron la misma decisión de forma independiente, primero hay que entender por qué esa decisión tiene sentido.

El patrón orquestador es, en esencia, una división del trabajo. Un agente actúa como coordinador: recibe el objetivo, lo descompone en tareas, las delega a agentes especializados, y consolida los resultados. Esos agentes especializados no necesitan ver el cuadro completo — solo necesitan ser buenos en lo suyo. Uno produce código. Otro lo revisa. Otro lo testea. El orquestador es quien sabe cómo encajan las piezas.

Es un modelo intuitivo porque replica algo que ya conocemos: la forma en que trabajan los equipos humanos bien organizados.

Desde el punto de vista de ingeniería, tiene ventajas concretas. El flujo de control es trazable — siempre podés responder a la pregunta de qué agente hizo qué, en qué momento, y con qué resultado. El debugging es más manejable que en sistemas donde los agentes se coordinan entre sí sin un punto central de referencia. Y la superficie de complejidad inicial es menor: empezás con un orquestador y los agentes que necesitás, y crecés desde ahí.

No es sorprendente que los tres equipos convergieran en él de forma independiente. Es el punto de entrada natural, y funciona bien dentro de los límites de un equipo. El problema empieza cuando esos límites se multiplican.

Descentralización accidental: cuando nadie decide, igual se decide algo

Hay una diferencia importante entre elegir descentralizar y terminar descentralizado.

Elegir descentralizar es una decisión de arquitectura: definís dominios, establecés fronteras claras, diseñás los mecanismos de coordinación, y aceptás conscientemente el trade-off entre autonomía y complejidad de gobierno. Es un camino válido, y en ciertos contextos es el correcto.

Terminar descentralizado es otra cosa. Es lo que pasa cuando cada equipo resuelve su propio problema, con sus propias herramientas, sin que nadie haya convocado la conversación sobre cómo esos sistemas van a coexistir. No hubo una decisión de descentralizar — hubo una ausencia de decisión, y la descentralización fue el resultado.

Eso es lo que ocurrió con los tres equipos. Y lo interesante es que, mirado de cerca, cada decisión individual tenía lógica propia.

El equipo que cubre AWS y Azure con un modelo de cuentas compartidas tiene un dominio de conocimiento específico: entiende cómo se estructura la tenencia de múltiples equipos sobre infraestructura compartida, qué patrones de acceso y governance aplican, qué fricciones aparecen cuando varios app teams comparten una misma suscripción. Sus agentes reflejan ese conocimiento. Son buenos en lo que hacen porque el equipo que los construyó sabe exactamente para qué los está construyendo.

Lo mismo aplica al equipo de Azure con Terraform: sus agentes entienden el ciclo de vida del aprovisionamiento via módulos IaC, las convenciones de naming, los patrones de reutilización que los app teams esperan encontrar. Esa especificidad es un activo real, no un accidente.

El problema no es la especialización. El problema es que esa especialización ocurrió en un vacío, sin un marco compartido que permitiera a los tres sistemas interoperar, reutilizar capacidades comunes, o ser auditados desde un mismo lugar.

La industria ya vivió una versión anterior de este ciclo. Cuando el movimiento de microservicios tomó fuerza, los equipos descubrieron que descomponer un monolito en servicios pequeños y autónomos traía beneficios reales — y también una complejidad de operación que nadie había modelado del todo. La respuesta fue construir una capa encima: service meshes, API gateways, plataformas de observabilidad. No para revertir la descentralización, sino para gobernarla.

Con los agentes de AI, el mismo ciclo se está repitiendo — comprimido en meses en lugar de años.

El espectro: de la torre de control al enjambre

Una vez que tenés más de un sistema de agentes en tu organización, la pregunta arquitectónica central es cómo se relacionan entre sí. El debate de la industria se organiza alrededor de tres modelos, que conviene entender no como opciones binarias sino como puntos en un espectro.

En un extremo está la orquestación centralizada. Un único orquestador gobierna todos los agentes del sistema. Asigna tareas, monitorea la ejecución, toma las decisiones de coordinación. Es el modelo más simple de razonar y el más fácil de auditar — tenés un único punto desde donde ver qué está pasando. La contrapartida es obvia: ese punto central es también un cuello de botella y un punto único de falla. A escala, se vuelve un problema.

En el otro extremo está la orquestación descentralizada. Los agentes coordinan entre sí directamente, sin un controlador central. La coordinación emerge de los protocolos de comunicación y el estado compartido, no de instrucciones top-down. El sistema es más resiliente — no hay un único punto cuya caída lo tumba todo — y más flexible para escalar. Pero es significativamente más difícil de auditar, de depurar, y de gobernar con políticas consistentes.

En el medio — y acá es donde se está moviendo la conversación más interesante — está la orquestación federada. Múltiples orquestadores, cada uno con autoridad sobre su propio dominio, coordinándose entre sí a través de una capa compartida de políticas y protocolos. Ningún orquestador tiene autoridad sobre el sistema completo, pero cada dominio tiene control total dentro de sus fronteras. La capa de federation no reemplaza la autonomía de cada equipo — la conecta.

Si aplicamos ese modelo a la situación que describí al principio, el mapeo es casi natural. El equipo de AWS+Azure opera como orquestador de su dominio. El equipo de Azure+Terraform opera como orquestador del suyo. El equipo de arquitectura de AI no es un super-orquestador que absorbe a los otros dos — es la federation layer: el lugar donde se establece el catálogo de agentes, las políticas compartidas, los MCP externos que todos pueden consumir, y los mecanismos de coordinación entre dominios.

Nadie pierde autonomía. El sistema gana coherencia.

MCP y A2A: la infraestructura que hace posible la coordinación

Hasta hace relativamente poco, la orquestación federada era más una idea arquitectónica que una realidad implementable. Conectar agentes construidos por equipos distintos, con frameworks distintos, sobre plataformas distintas, requería cantidades significativas de código de integración custom. Cambiar un agente por otro significaba reescribir la capa de orquestación. La interoperabilidad era, en la práctica, un problema sin solución elegante.

Dos protocolos están cambiando eso.

El primero es MCP — Model Context Protocol, desarrollado por Anthropic. MCP estandariza la forma en que un agente se conecta a herramientas externas: bases de datos, APIs, sistemas de archivos, servicios. Podés pensarlo como el contrato estándar entre un agente y sus manos. Ya lo están usando los dos equipos de cloud engineering, aunque en su forma más local: MCP servers que corren dentro del entorno del equipo, sin exponer nada al exterior. El paso siguiente — y el que habilita la federation — es MCP servers compartidos que cualquier agente autorizado puede consumir.

El segundo es A2A — Agent-to-Agent Protocol, impulsado por Google. Si MCP resuelve la relación entre un agente y sus herramientas, A2A resuelve la relación entre agentes. Establece cómo un agente descubre a otro, cómo le delega una tarea, cómo recibe el resultado. Sin A2A, la coordinación entre el orquestador del Team 1 y un agente especializado del Team 2 requiere integración directa y acoplamiento fuerte. Con A2A, esa coordinación puede ocurrir a través de un protocolo estándar, independientemente de cómo esté implementado cada agente.

Vale mencionar algo que le da peso institucional a estos protocolos: desde diciembre de 2025, tanto MCP como A2A están bajo la gobernanza de la Linux Foundation — específicamente de la Agentic AI Foundation, fundada con la participación de OpenAI, Anthropic, Google, Microsoft, AWS y Block. Ninguna empresa controla sola la dirección de ninguno de los dos. Eso importa para la adopción enterprise, donde la neutralidad del proveedor es frecuentemente un requisito.

Una nota de honestidad, porque el tema lo merece: estos protocolos están madurando, pero todavía tienen problemas abiertos. La gestión de identidad de agentes a escala, los mecanismos de confianza entre agentes de distintas organizaciones, el discovery en sistemas complejos — son áreas donde la especificación existe pero las implementaciones robustas todavía están siendo construidas. El futuro que habilitan MCP y A2A es real. La distancia entre ese futuro y el estado actual de la industria también lo es.

El tercer equipo llegó tarde — y eso importa más de lo que parece

El equipo de arquitectura de AI está construyendo, en este momento, lo que debería haber existido desde el principio: una capa centralizada con conexión a MCP externos, diseñada con una lógica de gobierno. En el papel, es el componente que le faltaba al sistema. En la práctica, se enfrenta a un problema que es cualitativamente distinto al de los otros dos equipos.

Los equipos de cloud engineering construyeron sobre una hoja en blanco. Definieron sus agentes, sus flujos, sus convenciones, sin tener que negociar con nada que ya existiera. El equipo de arquitectura no tiene ese lujo. Tiene que gobernar sistemas que ya están en uso, que ya tienen dependencias, que ya tienen equipos que construyeron sobre ellos. Cualquier decisión de estandarización que tome va a rozar con algo que alguien ya construyó de otra manera.

Esto no es una crítica a ese equipo. Es una descripción de la condición más común en la que los equipos de arquitectura se encuentran cuando llegan a la conversación sobre agentes: siempre un poco tarde, siempre cargando más deuda de diseño de la que el problema original sugería.

Y hay una lección en eso que vale la pena nombrar explícitamente: el momento correcto para pensar en la arquitectura de agentes es antes de que el segundo equipo construya su primer agente. No cuando la conversación de arquitectura ya tiene que competir con sistemas en uso, con equipos que construyeron sobre ellos, y con inercia organizacional que ningún diseño retroactivo va a deshacer fácilmente.

Ese momento, en la mayoría de las organizaciones, ya pasó. Lo que no significa que sea tarde — significa que el punto de partida es diferente.

Qué haría diferente — o qué hacer si todavía estás a tiempo

No voy a proponer acá que se centralice todo bajo un único sistema de agentes. Eso no es realista, y probablemente tampoco sería deseable: la especialización de dominio que cada equipo trajo a sus agentes es genuinamente valiosa. El objetivo no es uniformidad — es coordinación.

Lo primero que haría es establecer un registro de agentes antes de que la proliferación lo haga imposible. No un sistema complejo de governance desde el día uno — simplemente un lugar donde quede documentado qué agentes existen, qué hacen, con qué herramientas conectan, y qué equipo los mantiene. Suena trivial hasta que intentás auditar un sistema donde nadie sabe con certeza cuántos agentes hay, qué permisos tienen, o si dos de ellos están haciendo exactamente lo mismo. El catálogo es la base de cualquier conversación de arquitectura que venga después.

Lo segundo es separar la autonomía de dominio de la governance compartida — y comunicar esa separación con claridad. Los equipos de cloud engineering no necesitan abandonar sus agentes ni sus convenciones para participar en una arquitectura federada. Lo que sí necesitan es acordar un conjunto mínimo de contratos: cómo se identifican los agentes, qué protocolos usan para coordinarse, qué MCP servers son compartidos y cuáles son locales. La capa de federation no les quita control sobre su dominio — les da la posibilidad de conectarse con los demás sin tener que reescribir todo.

Lo tercero es tratar los protocolos como infraestructura desde el principio, no como decisiones que se toman cuando el sistema ya es grande. MCP y A2A no son herramientas que se evalúan a posteriori. Son la base que determina si el sistema va a poder crecer sin convertirse en un problema de governance. Adoptarlos temprano, incluso cuando un equipo todavía no los necesita para coordinar con nadie más, es la diferencia entre construir sobre una fundación sólida o tener que hacer retrofitting después.

La pregunta que me llevo

Salí de aquella reunión con una certeza que no tenía antes: el problema no era que tres equipos habían construido sistemas de agentes en paralelo. El problema era que nadie había imaginado, todavía, que eso iba a pasar.

Y eso es comprensible. Los agentes de AI pasaron de ser una curiosidad técnica a ser una herramienta de productividad real en un período muy corto. Los equipos de ingeniería respondieron a esa velocidad haciendo lo que los equipos de ingeniería hacen: resolver el problema que tienen en frente, con las herramientas disponibles, lo más rápido posible.

La proliferación de agentes no es el resultado de malas decisiones. Es el resultado de buenas decisiones tomadas sin un marco compartido.

La pregunta que me quedo es una que creo que cualquier organización con más de un equipo de ingeniería debería hacerse ahora, antes de que la respuesta sea obvia: ¿sabemos exactamente cuántos agentes de AI están corriendo en nuestra empresa, quién los mantiene, y qué pueden hacer?

Si la respuesta es no — o si tarda más de lo esperado en llegar — ya tienen su punto de partida.

Fuentes

OutSystems — 2026 State of AI Development Report https://www.businesswire.com/news/home/20260407749542/en/Agentic-AI-Goes-Mainstream-in-the-Enterprise-but-94-Raise-Concern-About-Sprawl-OutSystems-Research-Finds
Gartner — Predicción de adopción de agentes embebidos (citado en múltiples fuentes, 2025–2026)
Lyzr — Agent Orchestration 101 https://www.lyzr.ai/blog/agent-orchestration/
IBM — What is AI Agent Orchestration? https://www.ibm.com/think/topics/ai-agent-orchestration
GitHub Resources — What is AI Agent Orchestration? https://github.com/resources/articles/what-is-ai-agent-orchestration
DEV Community — Multi-Agent Systems: How They Work, When to Use Them, and Which Architecture to Choose https://dev.to/agentsindex/multi-agent-systems-how-they-work-when-to-use-them-and-which-architecture-to-choose-flo
Gravitee — Google's A2A and Anthropic's MCP https://www.gravitee.io/blog/googles-agent-to-agent-a2a-and-anthropics-model-context-protocol-mcp
DEV Community — MCP vs A2A: The Complete Guide to AI Agent Protocols in 2026 https://dev.to/pockit_tools/mcp-vs-a2a-the-complete-guide-to-ai-agent-protocols-in-2026-30li
A2A Protocol — Official Site https://a2a-protocol.org/latest/
OneReach.ai — The Hidden Risk of AI Agent Sprawl https://onereach.ai/blog/why-companies-who-fail-to-control-ai-agent-sprawl-will-fall-behind-forever/

Arqueología de infraestructura: RE con un LLM de copiloto

Camilo Vera — Sat, 17 Oct 2026 13:14:56 +0000

Publicado originalmente en Technical Logbook.

Por qué conectar un LLM a una infraestructura sin documentar no es una práctica nueva, sino una disciplina de 35 años con una fuente de hipótesis distinta.

por Camilo — Octubre 17 2026 · LinkedIn

Vengo viendo este patrón cada vez con más frecuencia, así que dejame contarlo con un caso típico, no uno puntual.

Un Senior Tech Architect toma la conducción de un equipo de Cloud Engineering. La infraestructura que hereda es grande: cientos de aplicaciones corriendo sobre una base de Azure que lleva años en producción, operada por un equipo distinto al que la construyó. No está mal armada —todo lo contrario, está razonablemente desacoplada— pero tiene un problema crónico: cada módulo de Terraform tiene su README, hay cobertura de tests decente, y aun así nadie tiene en la cabeza una foto completa del sistema. La documentación existe. Lo que falta es la vista de conjunto.

Entonces hace lo que cualquiera haría hoy: conecta un LLM al repositorio, vía MCP, directo a Azure DevOps, y empieza a hacerle preguntas. Dependencias ocultas. Deuda técnica que nadie escribió en ningún lado. Decisiones de arquitectura tomadas hace tres años cuya lógica hay que reconstruir desde cero. No sigue ningún método. No hay un framework en la pantalla, ni un checklist. Solo intuición, experiencia, y un asistente que responde rápido.

Lo que no sabe —todavía— es que lo que está haciendo tiene nombre. Y ese nombre tiene 35 años.

Un nombre de hace 35 años para algo que parece nuevo

En 1990, dos investigadores llamados Elliot Chikofsky y James Cross se sentaron a poner orden en una discusión que ya era un lío: todo el mundo hablaba de "ingeniería inversa" para referirse a cosas distintas. Escribieron un paper corto, casi un glosario, que terminó siendo el texto fundacional del campo. Ahí definieron seis términos —de "forward engineering" a "reengineering"— y uno de ellos es el que nos interesa: la ingeniería inversa es el proceso de examinar un sistema para entender cómo está armado y generar una descripción de él en un nivel de abstracción más alto. La palabra clave es examinar. No cambiar. No reemplazar. Examinar.

Con esa definición en la mano, lo que hace nuestro arquitecto deja de ser un caso raro y pasa a ser un ejemplo de manual. Más todavía: hay un matiz específico dentro de esa definición, que los mismos autores llamaron "design recovery" —la parte de la ingeniería inversa donde no alcanza con mirar el código o la infraestructura; hace falta traer de vuelta el contexto, el conocimiento de dominio, el por qué de las decisiones. No solo qué hace el sistema, sino por qué se construyó así. Eso es exactamente lo que hace el arquitecto cada vez que tiene que parar, volver a una decisión de hace tres años, y reconstruir el contexto que la justificaba antes de aceptar o rechazar lo que el LLM le está sugiriendo.

Entonces la primera respuesta a la pregunta que titula esta nota ya está: no, no es una práctica nueva. Tiene nombre, tiene definición formal, y la definición —escrita mucho antes que existiera cualquier LLM— sigue aplicando sin forzar una sola palabra.

El mapa mental que ahora se arma de a dos

Pero decir "no es nada nuevo" sería quedarse corto. Porque si la definición no cambió, el proceso sí.

Desde los años 80 hay toda una línea de investigación sobre cómo un programador entiende un sistema que no escribió. Distintos modelos, distintos nombres, pero el núcleo es siempre el mismo: la comprensión de un sistema grande se arma como un mapa mental que se va completando de a poco, mezclando dos movimientos —ir de arriba hacia abajo, reconociendo patrones conocidos, e ir de abajo hacia arriba, leyendo detalle por detalle hasta que aparece la estructura. Ese mapa lo arma la cabeza de una sola persona. Siempre fue así. Ningún modelo de esa época contemplaba que hubiera una segunda fuente activa de hipótesis metida en el medio del proceso.

Hoy la hay. Y ahí está el cambio real, no en la definición sino en la mecánica.

El LLM no arma el mapa por el arquitecto. No podría, aunque quisiera: el mapa sigue siendo suyo, construido con su experiencia, su conocimiento del negocio, su memoria de decisiones pasadas. Lo que hace el LLM es tirar candidatos —"esto podría ser una dependencia oculta", "esta property parece estar ahí por compatibilidad hacia atrás", "esto no está documentado en ningún lado pero el patrón se repite en otros tres módulos"— y el arquitecto los valida, los refuta, o los deja en espera hasta poder chequearlos contra algo que solo él sabe. El trabajo cognitivo no desaparece. Se corre de lugar: antes era leer y sintetizar desde cero, ahora es generar hipótesis con ayuda y decidir en cuáles confiar.

Es una distinción sutil pero importante, y es la que explica por qué esta tarea sigue tomando semanas, no minutos, aunque haya un LLM de por medio.

La industria ya lo llama ingeniería inversa. La academia, todavía no.

Ahora, hay una parte de esta historia donde la teoría todavía no llegó, y vale la pena nombrarla porque es una oportunidad más que un problema.

Busqué qué se está escribiendo sobre LLMs aplicados a infraestructura como código, específicamente Terraform, y el patrón es clarísimo: casi todo lo que se publica es sobre generar infraestructura nueva a partir de una descripción en lenguaje natural. Papers enteros, benchmarks completos, todos apuntando en la misma dirección: escribir código nuevo más rápido. Lo que casi nadie está estudiando formalmente es el caso inverso —el de nuestro arquitecto— entender infraestructura que ya existe, que ya está en producción, que nadie terminó de documentar.

Lo interesante es que la práctica ya se adelantó a la teoría. Hay varios posts recientes de ingenieros contando, con lujo de detalle, cómo usaron un LLM para reconstruir infraestructura Terraform de sistemas heredados —y varios de ellos usan literalmente la frase "reverse engineering" para describir lo que hicieron. Uno de ellos cuenta el caso de un proyecto multi-región donde el estado de Terraform decía una cosa, el entorno real decía otra, y la configuración no coincidía con ninguna de las dos. Nadie tenía una foto confiable de qué estaba bajo control y qué no. La conclusión a la que llega, después de meses metido en esa maraña, es exactamente la misma que la nuestra: el LLM acelera muchísimo el trabajo mecánico, pero en ningún momento reemplaza el juicio de quien tiene que decidir.

Hay incluso evidencia más formal —trabajos recientes de recuperación de arquitectura con LLMs, evaluados por ingenieros senior contra sistemas reales, con resultados consistentemente mejores que las herramientas de referencia de la industria— que confirman que este enfoque funciona mejor cuando el modelo tiene acceso al ecosistema completo del sistema, no a fragmentos sueltos. Es, otra vez, el mismo principio que aplicó nuestro arquitecto sin saberlo: conectar el LLM a todo el repositorio, no a un archivo a la vez.

Lo que cambia y lo que no

Así que, ¿qué queda de todo esto?

Primero: la definición no cambió. Lo que hace un arquitecto conectando un LLM a su infraestructura sigue siendo, con nombre y apellido, ingeniería inversa —y más específicamente, design recovery. No hace falta inventar una etiqueta nueva.

Segundo: la forma de pensar sí necesita estirarse un poco. Los modelos que explican cómo entendemos sistemas complejos se escribieron pensando en una sola cabeza trabajando sola. Ahora hay una segunda fuente de hipótesis metida en el proceso, y eso cambia el tipo de esfuerzo que exige la tarea, aunque no la reemplace.

Tercero: las herramientas sí son genuinamente nuevas, y ahí está el verdadero salto. Lo que antes eran algoritmos de clustering estático, ciegos a cualquier lógica de negocio, hoy son sistemas capaces de sintetizar sentido a partir de miles de archivos. Eso es un salto real. Pero en ningún caso serio que encontré, ese salto viene acompañado de la promesa de reemplazar el criterio de quien tiene que poner la firma en la decisión final.

El arquitecto de nuestra historia terminó su ingeniería inversa sin saber, al principio, que estaba siguiendo un framework. Resulta que sí lo estaba siguiendo: el único framework que, 35 años después y con IA de por medio, la evidencia todavía confirma que sigue funcionando.

Si querés ver de dónde sale todo esto con más detalle académico —fuentes, matices y el desarrollo completo—, sigue disponible sin editar en mi repositorio de investigación.

El sprint cero: de oráculo a compilador de intención

Camilo Vera — Mon, 12 Oct 2026 18:38:07 +0000

Publicado originalmente en Technical Logbook.

Por qué la diferencia entre usar la IA como oráculo o como compilador de intención no es técnica: es un criterio de ingeniería tan viejo como el sprint cero.

por Camilo — Junio 21 2026 · LinkedIn
Hace unas semanas necesitaba un reporte. Nada glamoroso: un resumen de work items de Azure DevOps para entender en qué estaba parado un equipo. Abrí el chat, le pedí a la IA que se conectara a la organización a través de un MCP, trajera la data y armara el reporte. Treinta segundos después tenía exactamente lo que pedí.

Podría haber terminado ahí. Honestamente, casi lo hice.

Pero mientras miraba el reporte se me ocurrió que esa misma data servía para algo más permanente. Le pedí entonces que convirtiera la consulta en un script de PowerShell — algo que pudiera correr de nuevo sin repetir la conversación desde cero. Y de ahí, un paso más: una pequeña aplicación HTML estática, con templates, que generara el reporte de forma automática cada vez que alguien la corriera. Lo que arrancó como una pregunta de tres líneas terminó siendo una herramienta.

Ese recorrido — de la pregunta a la herramienta — es el tema de este artículo. Porque la diferencia entre quedarse en el primer resultado y construir algo durable no tiene que ver con cuánto sabe alguien de IA. Tiene que ver con un criterio mucho más viejo, que cualquier ingeniero de software reconoce apenas lo nombra.

El envión inicial no es el resultado — es el sprint cero

Hay una tentación de mirar el primer ejemplo y sacar la conclusión equivocada: que delegarle todo a la IA al principio es el problema. No lo es. Es, de hecho, donde la IA generativa rinde mejor: en la ideación, en el prototipado rápido, en sacar una idea de la cabeza y ponerla en una pantalla en minutos en lugar de horas. Ese envión inicial es real y vale la pena aprovecharlo sin culpa.

El error no está en usar la IA como oráculo al principio. Está en quedarse ahí.

Cualquiera que haya trabajado con metodologías ágiles conoce esta lógica de memoria: un sprint no busca el producto terminado, busca un incremento que se pueda evaluar y sobre el cual iterar. El primer prompt que te resuelve un problema es, en ese sentido, el sprint cero. Lo que separa a alguien que aprovecha la herramienta de alguien que la subutiliza no es la calidad de esa primera respuesta — es si la toma como punto de partida o como punto final.

Oráculo vs. compilador de intención

Volvamos al reporte de Azure DevOps, pero miremos con más atención qué cambió entre el primer pedido y el último.

En el primer pedido, yo era un usuario haciéndole una pregunta a un oráculo: "traeme esto, armame aquello". No tenía control sobre el cómo — solo sobre el qué. Funcionó, pero si quería el reporte de nuevo la semana siguiente, tenía que volver a pedirlo, y nada garantizaba que el resultado fuera idéntico.

Cuando pedí el script de PowerShell, y después la app HTML, el rol cambió. Ya no le estaba preguntando algo a la IA — le estaba diciendo cómo quería que el proceso funcionara, paso por paso, y la IA traducía cada paso a código ejecutable. Pasé de usar la IA como oráculo a usarla como compilador de intención. La diferencia no es de grado, es de naturaleza: en el primer caso, el conocimiento queda atrapado en una conversación que se evapora apenas cierro el chat. En el segundo, queda encapsulado en un artefacto que cualquiera puede correr, versionar y mejorar sin necesidad de repetir la conversación original.

Cuando lo que falta no está en el código

Este mismo patrón se vuelve más interesante — y más riesgoso — cuando el código en cuestión no es una aplicación, sino infraestructura.

Pensemos en un equipo de Cloud Engineering que mantiene un catálogo de módulos de Terraform en un registro privado. Otros equipos consumen esos módulos para provisionar su propia infraestructura de forma self-service. Hay pipelines que construyen y publican esos módulos, y repositorios que llevan el tracking de las variables de cada equipo más allá del propio estado de Terraform.

Ahora supongamos que hay que construir un módulo nuevo. Un enfoque posible es pedirle directamente a la IA que analice todo el codebase y genere el módulo desde cero, sin más contexto. La IA puede hacerlo — y probablemente lo haga razonablemente bien, leyendo patrones repetidos en los módulos existentes. Pero ahí está el problema: puede leer el patrón sin entender la arquitectura. Puede replicar la forma sin captar por qué esa forma es así.

Esa es la diferencia entre pattern matching y conocimiento de arquitectura. Un ingeniero senior del equipo no necesita que la IA le explique por qué el networking está separado del compute en submódulos distintos, o por qué existe una convención de naming que no figura en ningún README. Ya lo sabe. Por eso, en lugar de pedir "generá el módulo", pide algo mucho más quirúrgico: "armame el scaffolding, con el harness y los submódulos ya cableados según la arquitectura que ya tenemos". El resultado es un punto de partida que respeta reglas que ni siquiera estaban escritas en ningún lado — reglas que viven en la cabeza de quien diseñó el sistema, no en el código que la IA puede leer.

El riesgo de no tener ese contexto no es solo de tiempo o de tokens gastados de más. Un módulo generado sin ese conocimiento institucional puede ser técnicamente válido — pasa el plan, pasa el apply — y al mismo tiempo violar invariantes que no están en el código: convenciones de tagging para cost allocation, límites de seguridad entre módulos, reglas de versionado que el registro privado espera para no romper a los equipos que ya consumen ese catálogo. El error no se ve en el plan ni en el apply. Se ve después: cuando el módulo ya está publicado en el catálogo, otro equipo lo adopta dando por sentado que respeta las mismas convenciones que el resto, y recién ahí aparece el problema — en una auditoría de cost allocation, en un control de compliance automatizado, o en la inconsistencia que alguien nota al integrarlo con el resto de su infraestructura.

Una capa de abstracción sobre otra capa de abstracción

Hay algo casi recursivo en este último ejemplo que vale la pena nombrar. El catálogo de módulos de Terraform ya es, en sí mismo, una capa de abstracción: existe precisamente para que los equipos de desarrollo no tengan que pensar en los detalles crudos de la nube cada vez que necesitan infraestructura. El equipo de Cloud Engineering subió el nivel de abstracción una vez, hace tiempo, cuando construyó ese catálogo.

Lo que el ingeniero hace ahora, al usar la IA para generar el scaffolding en lugar de escribirlo a mano —pero con la disciplina de guiarla en lugar de delegarle todo— es subir el nivel de abstracción otra vez, esta vez sobre cómo se interactúa con la primera capa. La disciplina de elevar la abstracción no se aplica una sola vez y se termina. Se aplica también a la herramienta que usamos para seguir subiendo de nivel. Si no lo hacemos con el mismo criterio con el que diseñamos cualquier otra abstracción, terminamos con una herramienta poderosa usada de la forma menos eficiente posible.

El criterio que realmente importa

Si los dos ejemplos —el reporte y el módulo de Terraform— tienen algo en común, no es la tecnología de fondo. Es el momento en el que alguien decidió que algo dejaba de ser un experimento descartable y merecía convertirse en una herramienta durable.

Ese momento no se reconoce por conocimiento técnico. Cualquiera puede aprender la sintaxis de un script de PowerShell o la estructura de un módulo de Terraform; eso, hoy, también se lo puede pedir a la IA. Lo que distingue al ingeniero con experiencia es el criterio para reconocer cuándo conviene detenerse a construir algo reutilizable en lugar de seguir resolviendo todo desde cero, conversación por conversación. Es una decisión de diseño, no una decisión técnica — y es, probablemente, la habilidad menos discutida en toda esta conversación sobre IA generativa.

La pregunta que me queda dando vueltas, y que te dejo a vos: ¿en qué parte de tu propio trabajo seguís actuando como compilador manual de la IA —copiando, pegando, repitiendo la misma conversación una y otra vez— en lugar de diseñar, una sola vez, el flujo que la convierte en compilador de tu intención?

Si esta idea te resuena, hace un tiempo escribí sobre un tema relacionado — subir el nivel de abstracción como disciplina de ingeniería — en Raise the Level of Abstraction.

Raise the Level of Abstraction: Del Assembler a la Inteligencia Artificial Generativa

Camilo Vera — Sat, 15 Aug 2026 22:22:09 +0000

Publicado originalmente en Technical Logbook.

Un recorrido histórico de la abstracción en software, del Assembler a la IA generativa, y cómo construí una célula de agentes bajo Clean Architecture y TDD para probarlo.

por Camilo — Junio 15 2026 · LinkedIn

Introducción: De la Práctica Corporativa a la Memoria Colectiva

Últimamente estuve trabajando de manera más intensa y sistemática con las nuevas herramientas de IA. Luego de una serie de cursos mandatorios que tuve que hacer en la empresa en la que trabajo, comencé a utilizar Gemini para desarrollo. En mi caso, decidí hacer un proyecto para "aprender haciendo" (learn by doing), que es una de las formas en las que a mí mejor se me da aprender algo nuevo.

Ese proyecto es un módulo de Node.js, que fue la "excusa" que pensé para desarrollar un sistema de agentes que colaboran entre sí para construir software. Mientras avanzaba en esta Prueba de Concepto (POC - Proof of Concept), se me vino a la memoria un concepto que le escuché nombrar alguna vez al gran Ángel "Java" López. Para los que peinan canas como yo (guiño, guiño, jeje), estoy seguro de que alguna vez lo escucharon nombrar; y para los que no, les cuento que fue un gran desarrollador de software, brillante y muy activo en la comunidad de profesionales de la industria del software en Argentina y Latinoamérica.

El concepto que se me apareció de golpe fue el de "Raise the level of abstraction" (Elevar el nivel de abstracción). Y ahora les paso a comentar un poco de historia (para todos conocida, seguramente) que quiero "refrescar" para que nos ayude a pensar un poco el presente (¿y el futuro?) del desarrollador de software, del technical architect y el uso de herramientas de GenAI.

El Hilo Histórico de la Abstracción

Los Albores de la Computación y el Nivel Físico

En los inicios, programar requería una comprensión absoluta del hardware subyacente. Las computadoras pioneras se configuraban de manera puramente física y mecánica.

A este nivel, la innovación estaba severamente limitada por la capacidad cognitiva humana para gestionar la complejidad de los componentes físicos directos.

El Código Máquina y el Nacimiento del Assembler

El procesador solo entiende bits. Originalmente, los programas se escribían en secuencias puras de unos y ceros (código máquina), lo que hacía casi imposible levantar la vista del detalle para pensar en el diseño general del sistema.

Para aliviar esta carga, los científicos de la computación crearon los lenguajes de ensamblaje (Assembly). Por primera vez, se introdujo una representación simbólica (mnemónicos como MOV o ADD) que un programa llamado "ensamblador" traducía al lenguaje nativo del chip. Había nacido la primera gran capa de abstracción.

Los Lenguajes de Alto Nivel y la Revolución del Compilador

A mediados de la década de 1950, John Backus y su equipo en IBM revolucionaron la industria con FORTRAN (Formula Translator). Esto permitió a los programadores expresar intenciones matemáticas complejas de forma directa (como c = a + b), delegando en un "compilador" la tarea de generar las instrucciones primitivas de la máquina.

Con el tiempo, lenguajes como C, C++ y C# operaron a niveles progresivamente más altos, aislando los conceptos de negocio de la infraestructura del hardware. Como bien señala Bjarne Stroustrup (creador de C++): "Queremos lidiar con los problemas al mismo nivel en el que pensamos esos problemas. Cuando hacemos eso, no hay una brecha entre la forma en que entendemos los problemas y la forma en que implementamos sus soluciones. No tenemos que ser el compilador."

El Presente y el Futuro: GenAI como la Nueva Capa de Abstracción

Hoy nos encontramos ante un cambio de paradigma idéntico al paso del Assembler a los lenguajes estructurados. Las herramientas de Inteligencia Artificial Generativa y los sistemas de agentes autónomos están asumiendo el rol de un nuevo compilador moderno.

La IA generativa rompe la barrera de la sintaxis rígida al permitirnos interactuar mediante el lenguaje natural. El humano ya no actúa como el transcriptor de reglas gramaticales para la máquina, sino como el diseñador del sistema y el validador de la arquitectura. El código tradicional pasa a ser un output automatizado.

No obstante, como ingenieros de software y arquitectos técnicos, nos enfrentamos a una distinción crítica en este nuevo escenario, que a su vez abre la puerta para dar un salto evolutivo aún mayor:

Generación Probabilística (IA): Es extremadamente rápida, flexible y creativa para traducir intenciones abstractas desde el lenguaje natural, pero es intrínsecamente probabilística. Ante un mismo prompt, la IA puede entregarnos una implementación de código estructuralmente distinta cada vez.
Generación Determinista (Modelos de Sistema): Es explícita, predecible y repetible. Al basarse en modelos formales de arquitectura o datos, produce exactamente el mismo cableado de infraestructura y componentes en cada ejecución. Esto es indispensable para sistemas de larga vida que requieren ser auditables, estables y analizables en el tiempo.

El verdadero quiebre de paradigma: Esta distinción no significa que debamos elegir entre una u otra. El verdadero salto de abstracción ocurre cuando combinamos ambas fuerzas bajo el principio irrenunciable del humano en el centro del control (Human-in-the-Loop). El quiebre está en que el ingeniero diseña, construye y mantiene herramientas de Generación de Código Determinista, utilizando a la IA Generativa como un par, un asistente intelectual avanzado. En lugar de pedirle a la IA que tire líneas de código directas a producción de manera aleatoria, el humano eleva su propio rol un nivel más arriba: se apoya en la IA como un copiloto estratégico para acelerar el diseño de los modelos formales, estructurar los templates de infraestructura y refinar los compiladores específicos que luego garantizarán una salida determinista, controlada y predecible.

El Verdadero Objetivo del Rol Técnico

Elevar el nivel de abstracción con GenAI no significa el fin de la ingeniería de software; significa su evolución hacia el Pensamiento de Sistemas (Systems Thinking). Al automatizar el entramado mecánico del código rutinario, el foco se desplaza por completo hacia la ingeniería de requerimientos, el diseño de la resiliencia arquitectónica y la inspección meticulosa de las interacciones del sistema.

El código tradicional no se vuelve invisible ni se ignora; pasa a ser un artefacto derivado y automatizado bajo estricto control de ingeniería, de la misma manera que el código máquina queda abstraído cuando escribimos una aplicación en Node.js o configuramos un pipeline de infraestructura en la nube. El foco técnico no se diluye, sino que se eleva al nivel del diseño conceptual y arquitectónico, donde verdaderamente se resuelven los problemas de fondo.

Operando en el Siguiente Nivel: Frameworks de Agentes y Nuevos Flujos de Trabajo

Para entender el impacto real de este nuevo nivel de abstracción, no basta con mirar las herramientas aisladas; es necesario observar cómo está cambiando la práctica diaria de quienes moldean nuestra industria. Recientemente, el analista Gergely Orosz (The Pragmatic Engineer) entrevistó a dos figuras icónicas que representan los dos extremos del espectro del desarrollo de software: Anders Hejlsberg, el legendario diseñador de lenguajes detrás de Turbo Pascal, Delphi, C# y TypeScript; y David Heinemeier Hansson (DHH), el creador de Ruby on Rails y ferviente defensor del pragmatismo en el desarrollo de productos.

Viniendo de escuelas de pensamiento tan distintas, sus visiones del 2026 convergen en un punto de quiebre absoluto: el flujo de trabajo tradicional donde un desarrollador pasa horas picando código línea por línea está oficialmente obsoleto.

Por un lado, DHH describe un salto radical hacia un flujo de trabajo "Agent-First" (Agente Primero). Confiesa que ha dejado de escribir la gran mayoría del código a mano para operar en un "Modo Centauro", donde él lidera la estrategia y delega la ejecución mecánica a agentes autónomos en la terminal. DHH introduce un concepto fundamental para los arquitectos actuales: a medida que la IA democratiza la escritura de sintaxis, la ventaja competitiva del ingeniero senior ya no radica en su velocidad para tipear, sino en su criterio, su gusto, su sentido de la estética y sus implacables estándares de calidad.

Por el otro lado, Anders Hejlsberg valida este cambio desde la perspectiva del creador de herramientas. Alguien que dedicó su vida a construir compiladores tradicionales observa hoy que la IA actúa como el nuevo intérprete de la intención humana. Sin embargo, Anders aporta una claridad técnica indispensable: la IA no hace que los lenguajes formales desaparezcan; al contrario, los sistemas de tipado estricto y los compiladores que él ayudó a diseñar son hoy los "guardarraíles" matemáticos que permiten a la IA validar si lo que generó de forma probabilística es correcto y coherente.

A esta conversación sobre la redefinición de los flujos de trabajo se suma la perspectiva fundamental de Martin Fowler, quien coincide en que nos encontramos ante la transformación más profunda de la industria desde la histórica transición del lenguaje ensamblador a los primeros lenguajes de alto nivel como FORTRAN. Sin embargo, Fowler introduce una advertencia crucial para el rol técnico actual: el cambio medular con las LLMs no reside principalmente en un incremento en el nivel de abstracción formal, sino en el paso drástico de un paradigma puramente determinista a uno completamente no-determinista. Esta naturaleza probabilística desarma el concepto tradicional de la artesanía del software si se cae en el extremo del vibe coding descontrolado. Según Fowler, prescindir de la revisión del código generado rompe el bucle de aprendizaje técnico elemental. El código resultante adopta estructuras tan enrevesadas y caóticas que ante la menor necesidad de ajuste fino, el desarrollador pierde la capacidad de refactorizar de forma incremental, viéndose forzado a destruir la solución por completo para volver a empezar desde cero. El verdadero desafío de la ingeniería moderna no es programar a ciegas, sino domar ese no-determinismo mediante un riguroso andamiaje de pruebas automatizadas y un diseño consciente de las abstracciones.

La Transición del Ecosistema: De Oráculos a 'Pares' (¿?)

Esta convergencia entre Hejlsberg y DHH nos muestra el verdadero mapa del State of the Art: dejamos atrás la era de los plugins de chat básicos —donde usábamos a la IA como un "oráculo" para copiar y pegar fragmentos aislados— y entramos de lleno en la era de los Flujos de Trabajo Agénticos (Agentic Workflows).

Aquí es donde el diseño de software y la ingeniería de plataformas se encuentran operando en el siguiente nivel. Hoy, el trabajo real se divide entre:

Diseñar e implementar las arquitecturas donde correrán estos sistemas de agentes en producción (utilizando frameworks de backend como LangChain o LangGraph).
Liderar la orquestación del desarrollo desde entornos de desarrollo nativos de IA (como Antigravity), donde el ingeniero actúa como un revisor premium y director del sistema.

Cuatro Patrones de Diseño Agénticos

Para entender cómo operan estos nuevos flujos de trabajo sin caer en el hype, es fundamental revisar la teoría de ingeniería que los sustenta. Andrew Ng y el equipo de investigadores de DeepLearning.AI formalizaron que el verdadero salto en el rendimiento de la IA generativa no viene de agrandar los modelos, sino de implementar Patrones de Diseño Agénticos (Agentic Design Patterns).

Cuando dejamos de usar un LLM en modo Zero-Shot (una única pregunta y una única respuesta esperada) y lo obligamos a iterar a través de un flujo de trabajo, los resultados en tareas complejas como la programación se disparan. Esta teoría se divide en cuatro pilares fundamentales:

Reflexión (Reflection): En lugar de aceptar el primer código que genera el modelo, se implementa un bucle donde el agente evalúa su propia salida de forma crítica. Un agente genera el código y otro (o el mismo en un segundo paso) actúa como revisor, buscando bugs, ineficiencias o fallas de arquitectura, refinando el resultado de manera autónoma antes de entregarlo.
Uso de Herramientas (Tool Use): Los LLMs por sí solos no saben calcular con precisión matemática ni pueden validar si un código compila. Este patrón dota al agente de la capacidad de reconocer cuándo necesita ayuda externa y ejecutar herramientas reales: calculadoras, intérpretes de código, linters, APIs o terminales de ejecución. El agente ya no solo "piensa" de forma probabilística; opera de forma determinista sobre el entorno.
Planificación (Planning): Ante un requerimiento grande (como "escribí un módulo completo de Node.js"), un humano no empieza a tipear todo de corrido; primero planifica. Este patrón obliga al agente a descomponer una meta macro en una secuencia detallada de sub-pasos, prever dependencias y decidir el orden de ejecución antes de tocar una sola línea de código.
Colaboración Multi-Agente (Multi-Agent Collaboration): El límite de un solo agente con un prompt gigantesco es la satisfacción de su contexto. La solución de ingeniería es la división del trabajo: fragmentar el problema entre múltiples agentes especializados donde cada uno tiene un rol explícito (por ejemplo, un Arquitecto, un Programador y un Tester). Estos agentes conversan entre sí, se delegan subtareas y debaten la mejor solución, emulando la dinámica de un equipo de desarrollo de alto rendimiento.

Estructuras Organizacionales de la IA: Patrones Arquitectónicos de Industria

Para llevar la teoría de los agentes a la práctica corporativa, la industria de la ingeniería de software ha comenzado a consolidar patrones arquitectónicos repetibles. Ya no se trata de lanzar instrucciones aisladas a un modelo, sino de diseñar sistemas socio-técnicos donde múltiples agentes de IA operan bajo topologías y reglas estrictas, emulando las metodologías de los equipos de desarrollo de alto rendimiento.

A continuación, se describen tres patrones de diseño emergentes que están definiendo el estado del arte en la construcción de software asistido por IA:

1. El Patrón "Orquesta de Ingeniería" (Hierarchical Agent Teams)

MetaGPT: Este framework multi-agente destaca precisamente por inyectar metodologías operativas estandarizadas (SOPs) de la industria. Permite coordinar de forma jerárquica un equipo virtual compuesto por Product Managers, Architects (quienes diseñan contratos e interfaces antes de codificar) e Engineers.

Enlace al repositorio: GitHub - MetaGPT

ChatDev: El proyecto de referencia para simular una "empresa virtual de software". En este entorno, agentes con roles definidos (CEO, CTO, Programmer, Tester) colaboran de manera interactiva a través de seminarios funcionales para escribir, revisar y validar el código en un bucle colaborativo.

Enlace al repositorio: GitHub - ChatDev

2. Inyección de Blueprints Centralizados (Centralized Tooling Injection)

LangGraph (Ecosistema LangChain): Es el estándar de la industria para definir flujos de agentes cíclicos y deterministas basados en grafos. Permite estructurar e inyectar configuraciones de control estables, asegurando que los agentes sigan caminos de ejecución predecibles y alineados a estándares organizacionales.

Enlace al repositorio: LangGraph - Agentic Workflows

Microsoft AutoGen: Biblioteca pionera para la automatización e interconexión de sistemas multi-agente conversacionales. Su arquitectura permite definir agentes configurados de manera determinista mediante plantillas y archivos locales de reglas para resolver flujos complejos de ingeniería.

Enlace al repositorio: GitHub - Microsoft AutoGen

3. Ciclos de Vida Automatizados y Ejecución en Bucle Cerrado (REPL Agéntico)

Aider (AI Pair Programming Tool): Una herramienta agéntica por línea de comandos ampliamente respetada por desarrolladores senior. Se conecta directamente a repositorios Git locales, genera mapas de símbolos de la base de código (Repository Map), edita archivos en paralelo, realiza los commits automáticamente y ejecuta pruebas o linters en la terminal nativa para auto-corregirse si detecta errores.

Enlace al repositorio: GitHub - Aider

Claude Code / Anthropic Tools: Las guías y documentación de Anthropic sobre capacidades de ejecución de código y herramientas de desarrollo agéntico (Tool use). En ellas se detalla formalmente cómo los agentes avanzados utilizan herramientas de sistema (Bash tools, Text editor tools) para interactuar con entornos locales en bucles cerrados de desarrollo, leyendo los logs de error de la consola para refinar su salida de manera autónoma.

Enlace a la documentación: Anthropic - Claude API Documentation (Tool use)

De la Teoría a la Trinchera: El Nacimiento de json-mapper

Para entender cómo se entrelazan estos patrones arquitectónicos en la práctica, es necesario descender de la abstracción académica y observar la realidad de la trinchera técnica. Como mencioné al inicio, mi exploración con la Inteligencia Artificial Generativa no comenzó con sistemas complejos, sino con una necesidad mundana y cotidiana: configurar un entorno de desarrollo local.

Al igual que la gran mayoría de los ingenieros de software actuales, mi primer punto de contacto con estas tecnologías consistió en integrar los modelos de Gemini dentro de editores tradicionales mediante extensiones oficiales o conectores de API REST a través de Google AI Studio. En ese estadio inicial, el flujo de trabajo seguía respondiendo al paradigma lineal clásico: la IA operaba como un "autocompletar avanzado" en línea, ofreciendo bloques de sugerencias en gris que el desarrollador aceptaba con un tabulador, o como un panel de chat lateral al que se le hacían consultas aisladas en modo zero-shot.

Pronto, los límites de este enfoque se hicieron evidentes. Si bien la velocidad para generar funciones aisladas o estructuras repetitivas (boilerplate) aumentaba de forma no-trivial, el ingeniero seguía atrapado en el rol de "compilador manual": copiando fragmentos, resolviendo manualmente los errores sintácticos en la terminal local, gestionando el contexto del repositorio a fuerza de prompts kilométricos y asumiendo la carga cognitiva de mantener la coherencia arquitectónica del sistema. No estábamos elevando el nivel de abstracción; solo estábamos tipeando más rápido.

El verdadero salto evolutivo ocurrió cuando decidí utilizar el desarrollo de un módulo real de Node.js —un CLI utilitario de mapeo y transformación de estructuras de datos denominado json-mapper— como el laboratorio experimental para implementar una estrategia de desarrollo Agent-First.

Para resolver este desafío de ingeniería bajo estándares corporativos, el entorno de trabajo se mudó de los editores tradicionales hacia un espacio de trabajo nativo de IA (Antigravity IDE), y la interacción individual mutó hacia una célula de ingeniería compuesta por agentes especializados y coordinados bajo el patrón de la "Orquesta de Ingeniería". El objetivo ya no era pedirle a una IA que escribiera el mapeador; el objetivo era guiar a un equipo autónomo para que diseñara las interfaces, implementara la lógica y validara la integridad del módulo en un bucle cerrado determinista.

La Célula de Ingeniería Virtual: Configuración y Roles

Para que el desarrollo de json-mapper no cayera en un ejercicio desordenado de vibe coding, la arquitectura agéntica se estructuró bajo la filosofía de Configuration-as-Code. En lugar de interactuar con una ventana de chat mediante instrucciones volátiles, las directrices, responsabilidades, restricciones técnicas y la bibliografía académica de ingeniería se consolidaron en planos de configuración estables dentro del propio espacio de trabajo.

Este enfoque descentralizado permitió crear un repositorio de blueprints de ingeniería reutilizables que gobiernan las instancias locales de los agentes de manera determinista. Para la construcción del mapeador de JSON, la célula virtual se dividió en tres roles con fronteras operativas estrictas:

1. El Arquitecto Técnico (Lead Architect)

Este agente actúa como el guardián de la base de código. No escribe líneas de código rutinario; su función exclusiva es procesar los requerimientos del usuario, diseñar las interfaces de abstracción y realizar la auditoría de calidad cruzada (Code Review). Su razonamiento y toma de decisiones se anclaron explícitamente en tres fuentes fundamentales de la industria:

Clean Architecture: Para imponer la regla de dependencia interna, asegurando que las políticas comerciales centrales de transformación de datos estén completamente aisladas de los mecanismos periféricos de entrada/salida de archivos o CLI.
Principios S.O.L.I.D.: Especialmente el principio de Inversión de Dependencias (DIP) y de Responsabilidad Única (SRP) para regular cómo interactúan los módulos de la aplicación.
Design Patterns: Para estandarizar soluciones estructurales, favoreciendo la composición sobre la herencia e identificando patrones específicos (como Strategy o Adapter) para resolver mutaciones complejas de esquemas.

2. El Ingeniero Full-Stack (Execution Layer)

Ubicado en el nivel operativo dentro del sandbox persistente provisto por el entorno de desarrollo agéntico, este subagente traduce las especificaciones de diseño en código fuente de producción. Su comportamiento está rígidamente regido por:

Test-Driven Development: Ejecutando un bucle cerrado estricto de Red-Green-Refactor. El agente escribe primero una prueba unitaria fallida, codifica la solución mínima para que pase y finalmente limpia la sintaxis, validando la integridad técnica en la terminal interna antes de entregar la tarea.
Patrones de JavaScript Moderno: Utilizando estructuras modulares y limpias de acoplamiento.
Mecánica Avanzada de Runtimes: Para domar el motor de Node.js mediante el uso optimizado de clausuras (closures), contextos de ejecución y reducción eficiente para resolver accesos profundos de propiedades en objetos anidados.

3. El Redactor Técnico (Technical Writer)

Un especialista dedicado exclusivamente a la capa de documentación humana. Su perfil está gobernado por el Framework Diátaxis y los estándares Docs-as-Code de GitHub, eliminando verbos de relleno o mercadotecnia ("fácilmente", "simplemente") para construir guías de instalación, diagnósticos copiables y manuales de abordaje rápido.

La Barrera de Dominio: El Flujo Operativo Cíclico

El verdadero poder de esta topología jerárquica no reside en la genialidad de sus componentes aislados, sino en la interacción regulada por el protocolo del entorno. Para evitar que la lógica del mapeador se mezclara de forma accidental con las librerías del sistema operativo, el flujo se diseñó en fases secuenciales:

[Idea de Negocio] ──► [Lead Architect: Fase de Dominio] ──► Especificación de Dominio
        │
        ▼
[Aprobación Humana] ◄── [Lead Architect: Diseño Técnico] ◄── Plan de Arquitectura
        │
        ▼
[Subagente Full-Stack] ──► [Bucle Cerrado TDD (Red-Green-Refactor)] ──► [Tests Pass]
        │
        ▼
[Auditoría de Calidad del Arquitecto] ──► [Entrega Controlada]

Fase de Dominio Puro (Functional Domain Assessment): Ante un requerimiento, el Arquitecto modela el problema de forma agnóstica como un puro algoritmo matemático. Define los esquemas contractuales y las reglas de transformación recursiva ante rutas con notación de punto (ej. propiedad3.propiedad3_1), ignorando por completo comandos de terminal, argumentos CLI o la librería fs de Node.js.
Fase de Diseño Técnico (Technical Specification): El Arquitecto toma las reglas puras del dominio y diseña la arquitectura física del software bajo el principio de menor privilegio, definiendo la estructura de capas y contratos lógicos del sistema.
Fase de Ejecución Determinista (TDD Sandbox Loop): Una vez aprobado el plan por el humano en el centro del control (Human-in-the-Loop), se invoca dinámicamente al subagente Full-Stack. Este se encierra en la terminal del sandbox, inicializa el proyecto, escribe los tests, levanta el test runner y no sale del ciclo hasta que la suite de pruebas unitarias pasa al 100%.
Fase de Control de Calidad: El ejecutor se apaga y el Arquitecto Técnico despierta de nuevo para auditar el diff de código generado antes de presentárselo al usuario, asegurando que ninguna dependencia de infraestructura haya contaminado el núcleo del negocio.

La Trinchera de la Versión 2: Integración, Telemetría y Desafíos de Entorno

El verdadero examen para nuestra célula de ingeniería virtual ocurrió durante la transición de json-mapper hacia su Versión 2. El desafío ya no era escribir algoritmos aislados en Vanilla JS, sino evolucionar el sistema integrando módulos del ecosistema de producción de Node.js —específicamente commander para la gestión de comandos por consola y pino para el registro de logs estructurados— sin corromper los límites limpios de nuestra arquitectura.

Siguiendo el flujo regulado, el Arquitecto diseñó la estrategia de integración aplicando de forma estricta el principio de Inversión de Dependencias (DIP). En lugar de permitir que el ejecutor inyectara la librería de logs de forma directa en el núcleo de transformación, definió una interfaz abstracta o puerto dentro de la capa de Casos de Uso. En la periferia de la infraestructura, se construyó un adaptador específico encargado de traducir las llamadas abstractas del sistema a la estructura de JSON nativa de Pino. Con este desacoplamiento, si en el futuro se decide sustituir Pino por cualquier otra solución, el núcleo comercial del mapeador permanecerá 100% intacto.

Una vez validada la especificación, el programador Full-Stack profesional asumió el control del sandbox de ejecución mediante ciclos rigurosos de TDD. Para medir métricas críticas de rendimiento —como el tiempo total de ejecución calculado con microsegundos mediante performance.now() y el conteo exacto de registros transformados—, el agente prescindió de frameworks externos de simulación, modelando stubs limpios directamente en el entorno de pruebas y verificando de forma determinista la salida técnica en la terminal interna.

No obstante, esta experiencia en la trinchera agéntica también desveló las fricciones operativas reales que ocurren cuando se trabaja con herramientas probabilísticas sobre sistemas de archivos físicos. Durante el sprint, el entorno se enfrentó al clásico dolor de cabeza de Git: la carpeta node_modules/ seguía siendo rastreada y expuesta en el panel de control a pesar de figurar explícitamente dentro del archivo .gitignore. Tras varios intentos fallidos de limpieza de caché indexada, la auditoría interna de los agentes descubrió el verdadero origen del fallo, un sutil error de entorno que a menudo confunde a desarrolladores seniors humanos: el archivo .gitignore había sido creado en un notebook de Windows mediante comandos de redirección de PowerShell que forzaron una codificación en UTF-16LE. Dado que Git requiere estrictamente codificaciones en UTF-8 para procesar los patrones de exclusión, interpretaba el archivo como un bloque binario corrupto e ignoraba las reglas. La resolución del bug —reescribir el archivo en UTF-8 nativo— devolvió la limpieza al workspace, permitiendo que la suite completa de pruebas unitarias y de integración pasara limpiamente y se consolidara el release en GitHub.

Conclusión: El Futuro del Ingeniero de Sistemas en la Era Agéntica

Elevar el nivel de abstracción mediante el uso de Inteligencia Artificial Generativa y entornos agénticos no representa la automatización del ingenio humano, sino la liberación de su verdadero potencial. Al delegar la micro-sintaxis rígida, el cableado repetitivo de infraestructura y la corrección de errores triviales de la terminal a una célula virtual jerárquica y determinista, el rol del desarrollador no desaparece; se transforma profundamente. Pasamos de ser transcriptores de código a diseñadores de intenciones lógicas, guardianes de la Clean Architecture y arquitectos de sistemas complejos orientados al pensamiento de sistemas (Systems Thinking).

La clave de este cambio de paradigma es comprender que la IA no es un reemplazo de la artesanía del software, sino un multiplicador intelectual. El control, los estándares de calidad y la responsabilidad de la coherencia técnica siguen estando bajo el dominio irrenunciable del humano en el centro del control (Human-in-the-Loop). Al domar el no-determinismo probabilístico de los modelos con guardarraíles matemáticos, suites de pruebas rigurosas y una sólida base de principios de diseño tradicionales, la ingeniería de software evoluciona hacia una disciplina mucho más estratégica, abstracta y creativa.

Si te interesa profundizar en los detalles técnicos de esta implementación o explorar de primera mano cómo interactúa este flujo agéntico, podés acceder al repositorio público del proyecto:

👉 GitHub - json-mapper

Nota del autor: Si bien este módulo nació como una Prueba de Concepto (POC) artesanal bajo la premisa de "aprender haciendo" (learn by doing), el repositorio es completamente abierto. Te invito a clonarlo, auditar sus capas de abstracción e incluso evolucionar tu propia versión si querés llevar este laboratorio experimental al siguiente nivel.

Fuentes de Referencia

Shih, Willy C. / Harvard Business School. Increasing the Level of Abstraction as a Strategy for Accelerating the Adoption of Complex Technologies. Strategy Science 6, no. 1 (2021): 54–61. Texto completo en PDF - HBS
Stroustrup, Bjarne. Abstraction and Efficiency. Entrevista por Bill Venners para Artima. Artima - Abstraction and Efficiency
Wilson, Mark. Why UML is a Bad Abstraction Mechanism y Many Systems Are Built at the Wrong Level of Abstraction. Markv Tech Blog. \"Why UML is a Bad Abstraction Mechanism\" | \"Many Systems Are Built at the Wrong Level of Abstraction\"
Garros, Damien. AI Is the New Compiler. OpsMill Blog. OpsMill - AI Is the New Compiler
López, Ángel "Java". Raise the Level of Abstraction (Part 1: Introduction). Ángel "Java" López - Blog Histórico
Ng, Andrew / DeepLearning.AI. Agentic Design Patterns (The Batch technical series). DeepLearning.AI - How Agents Can Improve LLM Performance
Fowler, Martin. How AI will change software engineering. Entrevista por Gergely Orosz para The Pragmatic Engineer Podcast.
MetaGPT. Framework multi-agente jerárquico basado en Procedimientos Operativos Estándar (SOPs). GitHub - MetaGPT.
ChatDev. Entorno de desarrollo de software virtual basado en comunicación multi-agente colaborativa. GitHub - ChatDev.
LangGraph (Ecosistema LangChain). Documentación de flujos de trabajo cíclicos y sistemas agénticos basados en grafos. LangGraph - Agentic Workflows.
Microsoft AutoGen. Ecosistema e infraestructura para la automatización de conversaciones multi-agente deterministas. GitHub - Microsoft AutoGen.
Aider. Herramienta agéntica de programación en pareja por línea de comandos y mapeo de espacios de trabajo locales (Repository Map). GitHub - Aider.
Anthropic API. Documentación técnica sobre el uso de herramientas de sistema y ejecución local de agentes avanzados (Tool Use). Anthropic - Claude API Documentation (Tool use).