Lo que aprendimos en el London AIE Summit 2026: caos de agentes, el debate velocidad vs. calidad, la muerte del IDE, paradojas de MCP, y por qué la IA nos hizo trabajar más duro.
Se suponía que el London AI Engineer Summit 2026 sería una celebración del progreso. En su lugar, se sintió como un espejo sostenido ante una profesión en medio de un colapso nervioso.
Durante tres días a principios de abril, cientos de ingenieros de IA, constructores de plataformas e investigadores se reunieron para compartir lo que habían aprendido. Lo que emergió fue un patrón: todos están construyendo con agentes, nadie ha descubierto cómo controlarlos, la industria está dividida entre moverse rápido o pensar con cuidado, y toda la premisa de que la IA nos haría más productivos se ha invertido hacia algo más oscuro.
Esto es lo que realmente aprendimos.
La conversación más honesta de la cumbre sucedió en un pasillo, no en el escenario. Un ingeniero de una fintech mediana describió el problema así: “Inicio un prompt y, tres horas después, mi agente ha reescrito la mitad del código, añadido funciones que no pedí y consumido 800 £ en cómputo. No puedo dejar mi escritorio.”
Esto es FOMAT: Fear of Missing Attention Time. No es una broma: es la ansiedad definitoria de la ingeniería de IA de 2026.
Todos en la cumbre estaban usando agentes. GitHub Copilot, Claude, frameworks agénticos personalizados: las herramientas han madurado. Pero la orquestación no. La brecha entre “tengo un agente” y “mi agente hace lo que pretendía y nada más” es enorme.
El problema se manifiesta de tres formas:
Fuga de tokens. Los agentes no tienen puntos de parada naturales. Sin barreras explícitas, siguen iterando. “Solo un refactor más,” piensa el agente, y de repente has quemado tu presupuesto mensual.
Expansión del alcance. Una petición para “mejorar el manejo de errores” se convierte en “reescribir todo el sistema de manejo de errores, añadir observabilidad, refactorizar la capa de logging e implementar tracing distribuido”. El agente no estaba equivocado: fue exhaustivo. Pero no era lo que pediste.
Latencia impredecible. No puedes saber cuánto tardará una tarea agéntica. Depende de cuántas subtareas decida generar el agente, cuántos fallos encuentre y si decide reintentar o pivotar. Esto hace imposible planificar flujos de trabajo dirigidos por agentes en sistemas de producción.
No hubo consenso sobre soluciones. Algunos equipos usan límites duros de tokens. Otros implementan “checkpoints de agente”: forzar a los agentes a pausar y pedir permiso antes de continuar. Unos cuantos se mueven hacia sistemas jerárquicos de agentes donde un “agente manager” supervisa a los agentes trabajadores y puede interrumpirlos.
El enfoque de FlowHunt —definiciones explícitas de flujo de trabajo con nodos de agente, manejadores de errores y lógica de ramificación— fue mencionado varias veces como patrón potencial. La idea: no dejes que los agentes decidan la estructura del flujo de trabajo. Defínela de antemano y deja que los agentes ejecuten los pasos individuales.
Pero incluso eso se sintió como un parche. El problema real es que el comportamiento del agente es inherentemente probabilístico. Puedes reducir la varianza, pero no eliminarla.
El lunes por la mañana, Ryan Lopopolo de OpenAI subió al escenario y dio una keynote que podría resumirse así: Deja de leer código. Conviértete en un multimillonario de tokens.
Su argumento: En un mundo agéntico, el volumen de código es la métrica que importa. Tu agente debería generar miles de líneas al día. Tu trabajo es definir la especificación del output y dejar que el agente maximice el rendimiento. Leer y entender cada línea es un cuello de botella. Confía en los tests. Confía en el agente. Muévete rápido.
Para el miércoles, Mario Zechner de Anthropic dio la contra-keynote: Ve más despacio y lee el maldito código.
Su argumento: La velocidad es una trampa. Cada línea de código que escribe tu agente es una responsabilidad. Necesitas entenderla, razonar sobre ella y poder mantenerla. Los equipos que ganarán en cinco años son los que priorizan claridad e intención sobre velocidad. Los agentes deberían ser herramientas para pensar, no para generar código sin reflexión.
La cumbre se dividió aproximadamente en tres campos:
| Posición | Defensores | Enfoque | Riesgo |
|---|---|---|---|
| Maximalista de tokens | OpenAI, algunos ingenieros de scale-ups | Dejar que los agentes generen agresivamente; centrarse en la calidad del output vía tests | Bases de código inmantenibles, deuda de seguridad, fragilidad técnica |
| Medio intencional | La mayoría de ingenieros empresariales | Usar agentes para andamiaje; los humanos aportan arquitectura y gusto | Velocidad más lenta, pero sistemas más estables |
| Code-First | Anthropic, algunos ingenieros de investigación | Los agentes amplían el pensamiento humano; los humanos escriben la mayor parte del código | Menor rendimiento, pero mayor calidad de código |
Ningún bando está equivocado. El desacuerdo es sobre cómo se ve el fracaso. Lopopolo optimiza para la velocidad de iteración. Zechner optimiza para la sostenibilidad. En 2026, los equipos aprenden que no puedes optimizar para ambos.
Una consecuencia concreta: la contratación está rota. Si eres maximalista de tokens, no te importa si un candidato sabe programar: te importa si sabe promptear eficazmente y evaluar el output del agente. Si eres code-first, quieres ver razonamiento técnico profundo.
Así, cuando un candidato entra a una entrevista, ni el entrevistador ni el candidato saben con qué marco se les evalúa. Un asistente de la cumbre lo describió como “entrevistar en la niebla”.
Comienza tu prueba gratuita hoy y ve resultados en días.
GitHub reportó un aumento de 15x en el tráfico interanual. Cloudflare reportó picos similares. Mientras tanto, los IDE tradicionales —VS Code, JetBrains, Sublime— están viendo un uso decreciente entre equipos AI-nativos.
Esto parece contradictorio hasta que entiendes qué está pasando realmente.
Un IDE fue diseñado para que un solo desarrollador escribiera código localmente. Tenía resaltado de sintaxis, autocompletado, herramientas de depuración y un árbol de archivos. Era un entorno autocontenido.
Ese modelo se rompe cuando tu “desarrollador” es un agente. Un agente no necesita resaltado de sintaxis. No necesita un depurador. Necesita:
Todo eso vive en el navegador ahora. GitHub Codespaces, VS Code Web y herramientas similares están reemplazando a los IDE locales.
El aumento del tráfico de GitHub no son desarrolladores escribiendo código en el navegador. Son desarrolladores revisando, comentando y fusionando código generado por agentes. Es la capa de colaboración la que explota, no la capa de edición.
Por eso Cloudflare también ve picos de tráfico: los desarrolladores usan infraestructura en la nube para ejecutar agentes y orquestar flujos de trabajo. El modelo “IDE local + entorno de desarrollo local” está siendo reemplazado por “orquestación de agentes nativa en la nube + revisión basada en navegador”.
Una sesión se tituló exactamente así. El punto: la noción romántica del ingeniero brillante, solo ante su teclado, escribiendo código elegante, se acabó. El código es ahora un output colaborativo entre humano y agente. Las habilidades que importan son:
Escribir código elegante ya no es una habilidad principal. Es algo que hacen los agentes. Los humanos hacen todo lo demás.
Este fue el debate más confuso de la cumbre.
Por un lado, los AIEs individuales y los mantenedores de frameworks de agentes decían: “MCP está muerto. No lo necesitamos. Nuestros agentes pueden llamar APIs directamente.”
Por otro lado, los arquitectos empresariales y los equipos de seguridad decían: “La adopción de MCP se acelera más rápido de lo que podemos construir herramientas para él.”
Ambas afirmaciones son verdaderas. Describen poblaciones distintas.
Para un desarrollador en solitario construyendo un agente simple, MCP añade fricción. Necesitas:
Es más fácil dar al agente acceso directo a la API y dejarle que descubra el resto.
Para una organización que ejecuta agentes en producción, MCP se vuelve de repente esencial. Aquí está por qué:
Aislamiento de seguridad. No quieres que los agentes tengan acceso directo a tu base de datos, sistema de pagos o datos de clientes. MCP te permite crear una interfaz controlada que los agentes pueden llamar sin exponer los sistemas subyacentes.
Auditabilidad. Cada acción del agente pasa por el servidor MCP, que la registra. Tienes un registro completo de lo que hizo el agente y por qué.
Gestión de credenciales. En lugar de incrustar claves API en prompts de agentes o variables de entorno, los servidores MCP gestionan credenciales de forma segura.
Rate limiting y aplicación de cuotas. Puedes controlar cuánto recurso puede consumir un agente.
Según CData Software, el 80 % de las empresas Fortune 500 están evaluando o implementando MCP a principios de 2026, principalmente por estas razones.
El consenso de la cumbre: MCP no está muerto. Simplemente no es relevante para el 80 % del desarrollo de IA que es experimental y en solitario. Pero para el 20 % que es de producción y multi-equipo, MCP se está convirtiendo en algo imprescindible.
Por eso proliferan las MCP Apps. Anthropic, OpenAI y proveedores externos están construyendo servidores MCP preconstruidos para herramientas comunes (Salesforce, Slack, Jira, bases de datos). Las empresas pueden adoptarlos sin construir servidores personalizados.
Obtén los últimos consejos, tendencias y ofertas gratis.
Aquí fue donde la cumbre se oscureció.
Se suponía que la IA sería un multiplicador de fuerza. Pasarías menos tiempo en tareas rutinarias y más en pensamiento estratégico. La productividad se dispararía.
En su lugar, la productividad sí se disparó, y también las expectativas de carga de trabajo.
La paradoja de Jevons, aplicada originalmente al consumo de carbón, afirma: Cuando un recurso se vuelve más eficiente, el consumo total aumenta porque el recurso se vuelve más barato y atractivo.
En términos de IA: los agentes hicieron la generación de código más barata y rápida, así que los gerentes ahora esperan que cada ingeniero:
Las ganancias de productividad fueron consumidas por expectativas infladas.
Un ingeniero de una startup londinense: “Antes escribía 500 líneas de código al día y me sentía productivo. Ahora escribo 5.000 líneas al día —generadas por agentes— y estoy agotado porque tengo que revisarlo todo, testearlo, documentarlo y explicárselo a los stakeholders. Trabajo 60 horas a la semana.”
Otro: “Mi manager dice: ‘Ahora tienes un agente, así que deberías poder gestionar el doble de proyectos.‘ No soy más productivo. Solo estoy más ocupado.”
Un investigador: “Los agentes son buenos generando código. No son buenos decidiendo qué código generar. Esa carga de decisión se ha desplazado completamente a los humanos. No estamos automatizando la parte difícil; automatizamos la parte fácil y hacemos que los humanos piensen más.”
La California Management Review de UC Berkeley publicó una investigación en enero de 2026 documentando este fenómeno. La idea clave: El despliegue de la IA no reduce el trabajo; cambia la naturaleza del trabajo.
Trabajo antiguo: Escribir código. Trabajo nuevo: Dirigir agentes, evaluar output, mantener calidad, gestionar la expansión del alcance.
El nuevo trabajo es cognitivamente más duro, aunque haya menos tecleo.
La cumbre tuvo un contingente europeo fuerte, y su mensaje fue consistente: Europa no se mueve tan rápido como EE. UU. en la adopción de ingeniería de IA.
La Ley de IA de la UE aún se está implementando. Las empresas tienen incertidumbre sobre la responsabilidad. Si un agente de IA toma una decisión que perjudica a un cliente, ¿quién es responsable? ¿La empresa? ¿El proveedor del modelo? ¿El ingeniero?
Esa incertidumbre paraliza. Muchas empresas europeas están esperando a ver cómo se desarrollan los primeros litigios antes de construir sistemas agénticos serios.
Los ingenieros de software tradicionales en Europa no se están convirtiendo en ingenieros de IA al mismo ritmo que en EE. UU. Hay escepticismo sobre si las habilidades se transfieren. Muchos ingenieros europeos esperan para ver si la ingeniería de IA es una carrera real o un ciclo de moda.
Europa también es más cautelosa con el manejo de datos. Los agentes necesitan acceso a datos para ser útiles. Pero las empresas europeas dudan en dar a los agentes acceso a datos de clientes, incluso con salvaguardas MCP.
Los ingenieros europeos de la cumbre no eran anti-IA. Eran pro-cautela. El sentimiento: “EE. UU. se mueve rápido y rompe cosas. Nosotros iremos más despacio y trataremos de no romper tanto. En cinco años veremos quién tenía razón.”
Al final de la cumbre, emergió un patrón: los roles tradicionales de ingeniería de software están siendo vaciados y reemplazados por tres nuevos arquetipos.
| Rol | Responsabilidad | Habilidades |
|---|---|---|
| AI PM | Definir comportamiento del agente, métricas de éxito, restricciones | Pensamiento de producto, diseño de prompts, frameworks de evaluación |
| Niñera de agentes | Monitorizar ejecución, detectar errores, intervenir cuando sea necesario | Depuración, observabilidad, manejo de errores, respuesta a incidentes |
| Arbitro de gusto | Evaluar calidad del output, dar feedback, guiar el refinamiento | Revisión de código, pensamiento arquitectónico, juicio estético |
Ninguno de estos roles implica escribir código en el sentido tradicional. Todos implican dirigir, evaluar y refinar el comportamiento del agente.
Los roles de “ingeniero junior” se están comprimiendo. Ya no hay un camino claro desde “puedo escribir código simple” hasta “puedo arquitectar sistemas”. Los pasos intermedios se están automatizando.
Esto crea un acantilado de habilidades: o eres bueno con prompts y evaluación (en cuyo caso eres valioso), o no lo eres (en cuyo caso compites con agentes).
Los roles que requieren gusto, juicio y pensamiento arquitectónico están creciendo. También los que requieren experiencia profunda en un dominio (porque los agentes necesitan humanos para evaluar si están resolviendo el problema correcto).
La cumbre no tuvo consenso sobre si esto es bueno o malo. Algunos lo vieron como liberación de la programación rutinaria. Otros como una amenaza para la profesión.
Una sección de la cumbre se dedicó a un punto de inflexión específico: algo cambió en el ecosistema de agentes de IA alrededor del año nuevo.
OpenClaw y frameworks similares empezaron a permitir que los agentes mejorasen iterativamente sus propios outputs sin prompting humano constante. En lugar de “agente, escribe una función que calcule X”, se convirtió en “agente, escribe una función que calcule X y sigue mejorándola hasta que pase todas las pruebas y maneje casos extremos.”
La idea clave, articulada por varios investigadores: Deja de pedir a los agentes consejos triviales.
En lugar de pedir a un agente que “mejore esta función”, pídele “haz esta función a prueba de balas.” Deja que decida qué significa eso. El agente:
Todo sin que se le pida cada paso.
Esto cambió el modelo mental de “agente como herramienta” a “agente como contribuyente autónomo”. Y cambió la dinámica de la carga de trabajo: en lugar de que los agentes redujeran el trabajo humano, lo aumentaron (porque los humanos ahora tenían que evaluar outputs de agentes mucho más sofisticados).
La cumbre terminó sin resolución, lo que se sintió honesto. Aquí están las contradicciones que definen la ingeniería de IA en abril de 2026:
Contradicción 1: Los agentes son lo bastante potentes para ser peligrosos (FOMAT es real), pero no lo bastante para ser confiados sin supervisión.
Contradicción 2: La velocidad y la calidad se tratan como opuestas, pero ambas son necesarias.
Contradicción 3: MCP está simultáneamente muerto (para individuos) y floreciendo (para empresas).
Contradicción 4: La IA nos hizo más productivos, pero también más sobrecargados.
Contradicción 5: Todos están construyendo con agentes, pero nadie ha descubierto cómo construir bien con ellos.
Contradicción 6: La ingeniería de IA es una carrera real, pero las habilidades que creíamos que importarían (escribir código) ya no lo hacen.
Estos no son problemas a resolver. Son tensiones a gestionar. Los equipos que ganarán en 2026 son los que reconocen estas contradicciones en lugar de fingir que no existen.
La cumbre de Londres fue una instantánea de una profesión en transición. La ingeniería de IA es real, pero no es lo que pensábamos. Es más caótica, más contradictoria y más dependiente del humano de lo que sugería la moda.
Los mejores ingenieros en la cumbre no eran los de agentes más sofisticados. Eran los que entendieron que los agentes son una herramienta para pensar, no un reemplazo del pensamiento. Eran los que habían construido procesos para gestionar el comportamiento del agente, evaluar el output y mantener la calidad. Eran los que habían aceptado que las ganancias de productividad vienen con nuevos tipos de trabajo, no con menos trabajo.
Si estás construyendo sistemas de IA en 2026, las lecciones de la cumbre son claras:
La orquestación importa más que la capacidad del agente. Un agente mediocre con buena orquestación supera a un agente brillante sin controles.
La claridad es más valiosa que la velocidad. Moverse rápido y romper cosas funciona hasta que no. A escala, no funciona.
La adopción empresarial es real, pero la adopción individual sigue siendo experimental. Si eres un desarrollador en solitario, puedes ir rápido. Si eres un equipo, necesitas barreras.
Las habilidades que importan han cambiado. Prompt engineering, evaluación de output y pensamiento arquitectónico son las nuevas competencias clave.
Espera trabajar más duro, no más fácil. La IA es un multiplicador de productividad, pero las ganancias están siendo consumidas por expectativas más altas. Planifica en consecuencia.
La cumbre no respondió a la pregunta “¿Cómo se ve la ingeniería de IA?” Nos mostró la respuesta: se ve como nosotros, intentando descubrirlo en tiempo real.
{{ cta-dark-panel heading=“Deja de orquestar agentes manualmente” description=“El creador de flujos de trabajo de FlowHunt te permite definir el comportamiento del agente, establecer barreras y automatizar tareas de IA multipaso. Sin más FOMAT. Sin más adivinanzas sobre lo que hacen tus agentes.” ctaPrimaryText=“Prueba FlowHunt gratis” ctaPrimaryURL=“https://app.flowhunt.io/sign-in" ctaSecondaryText=“Reserva una demo” ctaSecondaryURL=“https://www.flowhunt.io/demo/" gradientStartColor="#667eea” gradientEndColor="#764ba2” gradientId=“aie-summit-cta” }}
Arshia es ingeniera de flujos de trabajo de IA en FlowHunt. Con formación en ciencias de la computación y una pasión por la IA, se especializa en crear flujos de trabajo eficientes que integran herramientas de IA en las tareas cotidianas, mejorando la productividad y la creatividad.
Deja de orquestar agentes manualmente. El creador de flujos de trabajo de FlowHunt gestiona el encadenamiento de agentes, la recuperación de errores y las tareas de IA multipaso, para que puedas centrarte en qué deben hacer los agentes, no en cómo controlarlos.
Comparamos los 8 mejores frameworks de agentes de IA en 2026 — LangChain, CrewAI, AutoGen, LlamaIndex, Dify, Haystack, Semantic Kernel y FlowHunt. ¿Cuál es el a...
Clasificación y análisis de las 12 mejores herramientas de agentes de IA en 2026. Desde constructores sin código hasta frameworks de código abierto — encuentra ...
Explora los principales creadores de agentes de IA en 2026, desde plataformas sin código hasta frameworks de nivel empresarial. Descubre qué herramientas son la...
Consentimiento de Cookies
Usamos cookies para mejorar tu experiencia de navegación y analizar nuestro tráfico. See our privacy policy.
