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.
¿Por qué los ingenieros de IA programan con agentes que no pueden controlar?
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.
El cuello de botella de la orquestación
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.
Cuál fue (y no fue) el consenso de la cumbre
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.
¿Cómo reformó la división OpenAI-Anthropic lo que significa “buen código”?
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.
El espectro
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.
El problema de la entrevista
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”.
¿Listo para hacer crecer tu negocio?
Comienza tu prueba gratuita hoy y ve resultados en días.
¿Por qué mueren los IDE mientras explota el tráfico de GitHub?
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.
El IDE era una herramienta local para pensar
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:
- Acceso a varios archivos simultáneamente
- La capacidad de ejecutar código y ver resultados
- Integración con control de versiones
- Funcionalidades de colaboración (porque el agente y el humano trabajan juntos)
Todo eso vive en el navegador ahora. GitHub Codespaces, VS Code Web y herramientas similares están reemplazando a los IDE locales.
Qué está creciendo realmente
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”.
L33T C0d3 ha muerto
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:
- Prompt engineering (cómo especificar lo que quieres)
- Evaluación del output (¿es bueno el código del agente?)
- Pensamiento arquitectónico (¿qué estructura debería usar el agente?)
- Integración (¿cómo encaja el código generado por agentes en sistemas existentes?)
Escribir código elegante ya no es una habilidad principal. Es algo que hacen los agentes. Los humanos hacen todo lo demás.
¿Qué pasa realmente con MCP, muerto o floreciendo?
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.
Por qué los AIEs piensan que MCP está muerto
Para un desarrollador en solitario construyendo un agente simple, MCP añade fricción. Necesitas:
- Definir servidores MCP para tus herramientas
- Gestionar la sobrecarga del protocolo
- Gestionar autenticación y autorización
- Desplegar y mantener los servidores
Es más fácil dar al agente acceso directo a la API y dejarle que descubra el resto.
Por qué las empresas adoptan MCP rápidamente
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.
La resolución
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.
Únete a nuestro boletín
Obtén los últimos consejos, tendencias y ofertas gratis.
¿La IA nos hace más productivos o solo más sobrecargados de trabajo?
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 en tiempo real
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:
- Entregue 10x más output
- Escriba documentación exhaustiva
- Construya suites completas de pruebas
- Soporte internacionalización (i18n)
- Maneje casos extremos
- Lo haga todo en solitario
Las ganancias de productividad fueron consumidas por expectativas infladas.
Qué dijeron los ingenieros
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.”
El punto ciego de la productividad
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.
¿Por qué Europa está tan dubitativa sobre la ingeniería de IA?
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.
El lastre regulatorio
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.
La brecha de habilidades
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.
Preocupaciones de privacidad
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.
El camino hacia adelante
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.”
¿Cómo están cambiando realmente los roles de ingeniería de IA?
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.
Los tres roles
| 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.
Qué está desapareciendo
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).
Qué está creciendo
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.
¿Qué cambió entre diciembre de 2025 y febrero de 2026?
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.
El software que se automejora se hizo real
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:
- Escribirá pruebas
- Encontrará casos extremos
- Refactorizará para mayor claridad
- Añadirá manejo de errores
- Documentará la lógica
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).
Las contradicciones con las que vivimos
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.
Preguntas frecuentes
Lo que nos llevamos
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” }}
