O London AI Engineer Summit 2026 deveria ser uma celebração do progresso. Em vez disso, pareceu um espelho colocado diante de uma profissão em meio a um colapso nervoso.
Por três dias no início de abril, centenas de engenheiros de IA, construtores de plataformas e pesquisadores se reuniram para compartilhar o que aprenderam. O que emergiu foi um padrão: todos estão construindo com agentes, ninguém descobriu como controlá-los, a indústria está dividida sobre se deve mover-se rápido ou pensar com cuidado, e toda a premissa de que a IA nos tornaria mais produtivos foi invertida em algo mais sombrio.
Isto é o que realmente aprendemos.
Por que engenheiros de IA estão codificando com agentes que não conseguem controlar?
A conversa mais honesta do summit aconteceu num corredor, não no palco. Um engenheiro de uma fintech de médio porte descreveu o problema assim: “Eu inicio um prompt, e três horas depois meu agente reescreveu metade do codebase, adicionou features que eu não pedi e consumiu £800 em computação. Não posso sair da minha mesa.”
Isto é o FOMAT: Fear of Missing Attention Time. Não é piada — é a ansiedade definidora da engenharia de IA em 2026.
O gargalo da orquestração
Todos no summit estavam usando agentes. GitHub Copilot, Claude, frameworks agentic personalizados — as ferramentas amadureceram. Mas a orquestração não. A lacuna entre “Eu tenho um agente” e “meu agente faz o que eu pretendia e nada mais” é enorme.
O problema se manifesta de três maneiras:
Descontrole de tokens. Os agentes não têm pontos naturais de parada. Sem proteções explícitas, eles continuam iterando. “Só mais uma refatoração”, pensa o agente, e de repente você queimou o orçamento mensal.
Expansão de escopo. Um pedido para “melhorar o tratamento de erros” vira “reescrever todo o sistema de tratamento de erros, adicionar observabilidade, refatorar a camada de logging e implementar tracing distribuído.” O agente não estava errado — estava sendo completo. Mas não era o que você pediu.
Latência imprevisível. Não dá para saber quanto tempo uma tarefa agentic vai levar. Depende de quantas subtarefas o agente decide gerar, quantas falhas ele encontra e se decide tentar novamente ou mudar de rumo. Isso torna os fluxos de trabalho orientados por agentes impossíveis de agendar em sistemas de produção.
Qual foi (e qual não foi) o consenso do summit
Não houve consenso sobre soluções. Algumas equipes estão usando limites rígidos de tokens. Outras estão implementando “pontos de verificação do agente” — forçando os agentes a pausar e pedir permissão antes de prosseguir. Algumas estão se movendo em direção a sistemas hierárquicos de agentes, onde um “agente gerente” supervisiona agentes trabalhadores e pode interrompê-los.
A abordagem da FlowHunt — definições explícitas de fluxos de trabalho com nós de agentes, handlers de erro e lógica de ramificação — foi mencionada várias vezes como um padrão potencial. A ideia: não deixe os agentes decidirem a estrutura do fluxo de trabalho. Defina-a com antecedência, então deixe os agentes executarem as etapas individuais.
Mas mesmo isso parecia um curativo. O problema real é que o comportamento do agente é inerentemente probabilístico. Você pode reduzir a variância, mas não pode eliminá-la.
Como a divisão OpenAI-Anthropic remodelou o que “bom código” significa?
Na manhã de segunda-feira, Ryan Lopopolo da OpenAI subiu ao palco e fez uma keynote que poderia ser resumida como: Pare de ler código. Torne-se um bilionário de tokens.
Seu argumento: Num mundo agentic, o volume de código é a métrica que importa. Seu agente deveria estar gerando milhares de linhas por dia. Seu trabalho é definir a especificação do resultado e deixar o agente maximizar a taxa de transferência. Ler e entender cada linha é um gargalo. Confie nos testes. Confie no agente. Mova-se rápido.
Na quarta-feira, Mario Zechner da Anthropic fez a contra-keynote: Vá mais devagar e leia a porra do código.
Seu argumento: A velocidade é uma armadilha. Cada linha de código que seu agente escreve é um passivo. Você precisa entendê-la, raciocinar sobre ela e ser capaz de mantê-la. As equipes que vão ganhar em cinco anos são aquelas que priorizam a clareza e a intenção sobre a velocidade. Os agentes devem ser ferramentas para pensar, não para gerar código sem pensar.
O espectro
O summit se dividiu aproximadamente em três campos:
| Posição | Defensores | Abordagem | Risco |
|---|---|---|---|
| Maximalista de tokens | OpenAI, alguns engenheiros de scale-up | Deixe os agentes gerarem agressivamente; foque na qualidade do resultado via testes | Codebases insustentáveis, dívida de segurança, fragilidade técnica |
| Meio intencional | A maioria dos engenheiros corporativos | Use agentes para scaffolding; humanos fornecem arquitetura e gosto | Velocidade mais lenta, mas sistemas mais estáveis |
| Código-primeiro | Anthropic, alguns engenheiros de pesquisa | Agentes aumentam o pensamento humano; humanos escrevem a maior parte do código | Menor taxa de transferência, mas maior qualidade de código |
Nenhum dos lados está errado. A discordância é sobre como é o fracasso. Lopopolo está otimizando para velocidade de iteração. Zechner está otimizando para sustentabilidade. Em 2026, as equipes estão aprendendo que não dá para otimizar para os dois.
O problema das entrevistas
Uma consequência concreta: a contratação está quebrada. Se você é um maximalista de tokens, não se importa se o candidato sabe codificar — você se importa se ele sabe fazer prompts efetivamente e avaliar o resultado do agente. Se você é código-primeiro, quer ver raciocínio técnico profundo.
Então quando um candidato entra numa entrevista, nem o entrevistador nem o candidato sabem contra qual framework estão sendo avaliados. Um participante do summit descreveu como “entrevistando na neblina.”
Pronto para expandir seu negócio?
Comece seu teste gratuito hoje e veja resultados em dias.
Por que as IDEs estão morrendo enquanto o tráfego do GitHub explode?
O GitHub reportou um aumento de 15x no tráfego ano a ano. A Cloudflare reportou picos semelhantes. Enquanto isso, IDEs tradicionais — VS Code, JetBrains, Sublime — estão vendo uso decrescente entre equipes AI-native.
Isso parece contraditório até você entender o que realmente está acontecendo.
A IDE era uma ferramenta local de pensamento
Uma IDE foi projetada para um único desenvolvedor escrever código localmente. Tinha destaque de sintaxe, autocomplete, ferramentas de debug e uma árvore de arquivos. Era um ambiente autocontido.
Esse modelo se quebra quando seu “desenvolvedor” é um agente. Um agente não precisa de destaque de sintaxe. Não precisa de debugger. Ele precisa:
- Acesso a múltiplos arquivos simultaneamente
- Capacidade de executar código e ver resultados
- Integração com controle de versão
- Recursos de colaboração (porque agente e humano estão trabalhando juntos)
Tudo isso vive no navegador agora. GitHub Codespaces, VS Code Web e ferramentas similares estão substituindo as IDEs locais.
O que realmente está crescendo
O surto de tráfego do GitHub não são desenvolvedores escrevendo código no navegador. São desenvolvedores revisando, comentando e mergeando código gerado por agentes. É a camada de colaboração que está explodindo, não a camada de edição.
É por isso que a Cloudflare também está vendo picos de tráfego — desenvolvedores estão usando infraestrutura em nuvem para rodar agentes e orquestrar fluxos de trabalho. O modelo “IDE local + ambiente de desenvolvimento local” está sendo substituído por “orquestração de agentes cloud-native + revisão baseada em navegador.”
L33T C0d3 morreu
Uma sessão tinha exatamente esse título. A questão: a noção romântica do engenheiro brilhante, sozinho no teclado, criando código elegante — isso acabou. Código agora é um produto colaborativo entre humano e agente. As habilidades que importam são:
- Prompt engineering (como especificar o que você quer)
- Avaliação de resultado (o código do agente é bom?)
- Pensamento arquitetural (em que estrutura o agente deve trabalhar?)
- Integração (como o código gerado pelo agente se encaixa nos sistemas existentes?)
Escrever código elegante não é mais uma habilidade primária. É algo que os agentes fazem. Humanos fazem todo o resto.
O que está realmente acontecendo com o MCP — morto ou prosperando?
Este foi o debate mais confuso do summit.
De um lado, AIEs individuais e mantenedores de frameworks de agentes diziam: “O MCP está morto. Não precisamos dele. Nossos agentes podem simplesmente chamar APIs diretamente.”
Do outro lado, arquitetos corporativos e equipes de segurança diziam: “A adoção do MCP está acelerando mais rápido do que conseguimos construir ferramentas para ele.”
Ambas as afirmações são verdadeiras. Estão descrevendo populações diferentes.
Por que os AIEs acham que o MCP está morto
Para um desenvolvedor solo construindo um agente simples, o MCP adiciona atrito. Você precisa:
- Definir servidores MCP para suas ferramentas
- Gerenciar a sobrecarga do protocolo
- Lidar com autenticação e autorização
- Implantar e manter os servidores
É mais fácil simplesmente dar ao seu agente acesso direto à API e deixá-lo descobrir o resto.
Por que as empresas estão adotando o MCP rapidamente
Para uma organização rodando agentes em produção, o MCP de repente é essencial. Aqui está o porquê:
Isolamento de segurança. Você não quer que os agentes tenham acesso direto ao seu banco de dados, sistema de pagamento ou dados de clientes. O MCP permite criar uma interface controlada que os agentes podem chamar sem expor os sistemas subjacentes.
Auditabilidade. Cada ação do agente passa pelo servidor MCP, que a registra. Você tem um registro completo do que o agente fez e por quê.
Gerenciamento de credenciais. Em vez de embutir chaves de API em prompts de agentes ou variáveis de ambiente, os servidores MCP gerenciam credenciais com segurança.
Limitação de taxa e aplicação de cotas. Você pode controlar quanto de um recurso um agente pode consumir.
De acordo com a CData Software, 80% das empresas da Fortune 500 estão avaliando ou implementando o MCP no início de 2026, principalmente por essas razões.
A resolução
O consenso do summit: o MCP não está morto. Só não é relevante para os 80% do desenvolvimento de IA que é experimental e solo. Mas para os 20% que é produção e multi-equipe, o MCP está se tornando uma aposta básica.
É por isso que os MCP Apps estão proliferando. Anthropic, OpenAI e fornecedores terceirizados estão construindo servidores MCP pré-fabricados para ferramentas comuns (Salesforce, Slack, Jira, bancos de dados). As empresas podem adotá-los sem construir servidores personalizados.
Junte-se à nossa newsletter
Receba gratuitamente as últimas dicas, tendências e ofertas.
A IA está nos tornando mais produtivos, ou apenas mais sobrecarregados?
Aqui o summit ficou sombrio.
A IA deveria ser um multiplicador de força. Você passaria menos tempo em tarefas rotineiras e mais tempo em pensamento estratégico. A produtividade dispararia.
Em vez disso, a produtividade disparou — e as expectativas de carga de trabalho também.
O Paradoxo de Jevons em tempo real
O Paradoxo de Jevons, originalmente aplicado ao consumo de carvão, afirma: Quando um recurso se torna mais eficiente, o consumo total aumenta porque o recurso se torna mais barato e mais atraente.
Em termos de IA: Os agentes tornaram a geração de código mais barata e rápida, então os gerentes agora esperam que cada engenheiro:
- Entregue 10x mais resultado
- Escreva documentação abrangente
- Construa suítes de teste completas
- Suporte internacionalização (i18n)
- Lide com casos extremos
- Faça tudo sozinho
Os ganhos de produtividade foram consumidos por expectativas infladas.
O que os engenheiros disseram
Um engenheiro de uma startup baseada em Londres: “Eu costumava escrever 500 linhas de código por dia e me sentir produtivo. Agora escrevo 5.000 linhas por dia — geradas por agentes — e estou exausto porque tenho que revisar tudo, testar, documentar e explicar aos stakeholders. Estou trabalhando 60 horas por semana.”
Outro: “Meu gerente diz: ‘Você tem um agente agora, então deveria conseguir lidar com o dobro de projetos.’ Não sou mais produtivo. Só estou mais ocupado.”
Um pesquisador: “Os agentes são bons em gerar código. Não são bons em decidir qual código gerar. Esse fardo de decisão mudou inteiramente para os humanos. Não estamos automatizando a parte difícil; estamos automatizando a parte fácil e fazendo os humanos pensarem mais.”
O ponto cego da produtividade
A California Management Review da UC Berkeley publicou pesquisa em janeiro de 2026 documentando esse fenômeno. O insight-chave: O deployment de IA não reduz o trabalho; muda a natureza do trabalho.
Trabalho antigo: escrever código. Novo trabalho: direcionar agentes, avaliar resultados, manter qualidade, gerenciar expansão de escopo.
O novo trabalho é cognitivamente mais difícil, mesmo que seja menos digitação.
Por que a Europa está tão hesitante sobre Engenharia de IA?
O summit teve uma forte contingente europeia, e sua mensagem foi consistente: a Europa não está se movendo tão rápido quanto os EUA na adoção da engenharia de IA.
A sobrecarga regulatória
O EU AI Act ainda está sendo implementado. As empresas estão incertas sobre responsabilidade. Se um agente de IA toma uma decisão que prejudica um cliente, quem é responsável? A empresa? O fornecedor do modelo? O engenheiro?
Essa incerteza é paralisante. Muitas empresas europeias estão esperando para ver como os primeiros processos judiciais se desenrolam antes de construir sistemas agentic sérios.
A lacuna de habilidades
Engenheiros de software tradicionais na Europa não estão se tornando engenheiros de IA na mesma taxa que nos EUA. Há ceticismo sobre se as habilidades são transferíveis. Muitos engenheiros europeus estão esperando para ver se a engenharia de IA é um caminho real de carreira ou um ciclo de hype.
Preocupações com privacidade
A Europa também é mais cautelosa com o tratamento de dados. Os agentes precisam de acesso aos dados para serem úteis. Mas as empresas europeias hesitam em dar aos agentes acesso a dados de clientes, mesmo com salvaguardas do MCP em vigor.
O caminho à frente
Engenheiros europeus no summit não eram anti-IA. Eram pró-cautela. O sentimento: “Os EUA estão se movendo rápido e quebrando coisas. Nós vamos mais devagar e tentamos não quebrar tanto. Em cinco anos, veremos quem estava certo.”
Como os papéis em Engenharia de IA estão realmente mudando?
No final do summit, um padrão surgiu: Os papéis tradicionais de engenharia de software estão sendo esvaziados e substituídos por três novos arquétipos.
Os três papéis
| Papel | Responsabilidade | Habilidades |
|---|---|---|
| AI PM | Definir comportamento do agente, métricas de sucesso, restrições | Pensamento de produto, design de prompts, frameworks de avaliação |
| Babá de Agente | Monitorar execução, capturar erros, intervir quando necessário | Debugging, observabilidade, tratamento de erros, resposta a incidentes |
| Definidor de Gosto | Avaliar qualidade do resultado, fornecer feedback, guiar refinamento | Code review, pensamento arquitetural, julgamento estético |
Nenhum desses papéis envolve escrever código no sentido tradicional. Todos envolvem direcionar, avaliar e refinar o comportamento do agente.
O que está desaparecendo
Os papéis de “engenheiro júnior” estão sendo comprimidos. Não existe mais um caminho claro de “Eu sei escrever código simples” para “Eu sei arquitetar sistemas.” Os passos intermediários estão sendo automatizados.
Isso cria um precipício de habilidades: ou você é bom em prompt e avaliação (neste caso você é valioso), ou não é (neste caso você está competindo com agentes).
O que está crescendo
Papéis que requerem gosto, julgamento e pensamento arquitetural estão crescendo. Assim como papéis que requerem expertise profunda de domínio (porque os agentes precisam de humanos para avaliar se estão resolvendo o problema certo).
O summit não teve consenso sobre se isso é bom ou ruim. Alguns viam como libertação do código rotineiro. Outros viam como uma ameaça à profissão.
O que mudou entre dezembro de 2025 e fevereiro de 2026?
Uma seção do summit foi dedicada a um ponto de inflexão específico: algo mudou no ecossistema de agentes de IA perto do ano novo.
Software que se aprimora sozinho se tornou real
O OpenClaw e frameworks semelhantes começaram a permitir que os agentes melhorassem iterativamente seus próprios resultados sem prompting humano constante. Em vez de “agente, escreva uma função para calcular X,” tornou-se “agente, escreva uma função para calcular X e continue melhorando até que passe em todos os testes e lide com casos extremos.”
O insight-chave, articulado por vários pesquisadores: Parem de pedir conselhos triviais aos agentes.
Em vez de pedir a um agente para “melhorar esta função,” peça para “tornar esta função à prova de balas.” Deixe ele decidir o que isso significa. O agente irá:
- Escrever testes
- Encontrar casos extremos
- Refatorar para clareza
- Adicionar tratamento de erros
- Documentar a lógica
Tudo sem pedir em cada passo.
Isso mudou o modelo mental de “agente como ferramenta” para “agente como colaborador autônomo.” E mudou a dinâmica de carga de trabalho: em vez dos agentes reduzirem o trabalho humano, eles o aumentaram (porque os humanos agora tinham que avaliar resultados de agente muito mais sofisticados).
As contradições com as quais vivemos
O summit terminou sem resolução, o que pareceu honesto. Aqui estão as contradições que definem a engenharia de IA em abril de 2026:
Contradição 1: Os agentes são poderosos o suficiente para serem perigosos (o FOMAT é real), mas não poderosos o suficiente para serem confiáveis sem supervisão.
Contradição 2: Velocidade e qualidade estão sendo tratadas como opostos, mas ambas são necessárias.
Contradição 3: O MCP está simultaneamente morto (para indivíduos) e prosperando (para empresas).
Contradição 4: A IA nos tornou mais produtivos, mas também mais sobrecarregados.
Contradição 5: Todos estão construindo com agentes, mas ninguém descobriu como construir bem com eles.
Contradição 6: A engenharia de IA é um caminho real de carreira, mas as habilidades que pensávamos que importariam (escrever código) não importam mais.
Estes não são problemas a serem resolvidos. São tensões a serem gerenciadas. As equipes que vão ganhar em 2026 são aquelas que reconhecem essas contradições em vez de fingir que não existem.
Perguntas Frequentes
O que estamos levando
O summit de Londres foi um retrato de uma profissão em transição. A engenharia de IA é real, mas não é o que pensávamos que seria. É mais bagunçada, mais contraditória e mais dependente de humanos do que o hype sugeria.
Os melhores engenheiros no summit não eram aqueles com os agentes mais sofisticados. Eram aqueles que entendiam que os agentes são uma ferramenta para pensar, não um substituto para isso. Eram aqueles que haviam construído processos para gerenciar o comportamento do agente, avaliar resultados e manter a qualidade. Eram aqueles que haviam aceitado que os ganhos de produtividade vêm com novos tipos de trabalho, não menos trabalho.
Se você está construindo sistemas de IA em 2026, as lições do summit são claras:
A orquestração importa mais do que a capacidade do agente. Um agente medíocre com boa orquestração bate um agente brilhante sem controles.
Clareza é mais valiosa que velocidade. Mover-se rápido e quebrar coisas funciona até não funcionar mais. Em escala, não funciona.
A adoção empresarial é real, mas a adoção individual ainda é experimental. Se você é um desenvolvedor solo, pode se mover rápido. Se você é uma equipe, precisa de proteções.
As habilidades que importam mudaram. Prompt engineering, avaliação de resultado e pensamento arquitetural são as novas competências centrais.
Espere trabalhar mais duro, não mais fácil. A IA é um multiplicador de produtividade, mas os ganhos estão sendo consumidos por expectativas mais altas. Planeje adequadamente.
O summit não respondeu à pergunta “Como é a engenharia de IA?” Ele nos mostrou a resposta: parece com a gente, tentando descobrir em tempo real.
{{ cta-dark-panel heading=“Pare de orquestrar agentes manualmente” description=“O construtor de fluxos de trabalho da FlowHunt permite definir o comportamento do agente, estabelecer proteções e automatizar tarefas de IA em várias etapas. Sem mais FOMAT. Sem mais adivinhação sobre o que seus agentes estão fazendo.” ctaPrimaryText=“Experimente o FlowHunt grátis” ctaPrimaryURL=“https://app.flowhunt.io/sign-in" ctaSecondaryText=“Agende uma demonstração” ctaSecondaryURL=“https://www.flowhunt.io/demo/" gradientStartColor="#667eea” gradientEndColor="#764ba2” gradientId=“aie-summit-cta” }}
