Ex-fundador tecnológico da Meta partilha três coisas que todos os CTO têm de fazer antes de tocar em IA

James Everingham liderou a engenharia em algumas das empresas mais avançadas do mundo, incluindo a Meta. Atualmente, é CEO e cofundador da Guild.ai, um plano de controlo para agentes de IA, que oferece às organizações um único local para implementar, governar, observar e otimizar todos os agentes em produção.

Sentámo-nos com James para compreender como a IA está a transformar os fluxos de trabalho de engenharia — e o que as equipas de engenharia precisam de mudar antes de a IA poder ser integrada de forma eficaz. Foi isto que nos disse.

Da Meta a uma startup de IA

Sou CEO e cofundador da Guild.ai, o plano de controlo para agentes de IA, que oferece às organizações um único local para implementar, governar, observar e otimizar todos os agentes em produção. Angariámos $44M — uma ronda de Série A liderada pela Google Ventures, com a participação da NFX, Acrew, Scribble Ventures, Khosla Ventures e Webb Investment Network. Somos uma equipa de cerca de 35 pessoas, sediada em São Francisco.

Antes disso, fui Vice-Presidente de Engenharia na Meta DevInfra, onde construí e geri as ferramentas, os serviços e as plataformas essenciais para programadores que sustentam os produtos da Meta. A minha equipa construiu o primeiro agente de IA interno da Meta, com um impacto imediato na forma como os engenheiros da Meta utilizavam as ferramentas de IA. Durante o meu período na Meta, também fui co-criador da Diem e desempenhei funções como Diretor de Engenharia do Instagram.

Ao longo de uma carreira de 40 anos como gestor, empreendedor e criador de tecnologia, liderei inúmeras equipas de engenharia de classe mundial. Na Yahoo, fui Vice-Presidente de Engenharia das propriedades de comunicação social da Yahoo, depois de a empresa ter adquirido a Luminate, uma empresa de tecnologia de imagem interativa que fundei. Antes disso, liderei equipas na Oracle, na Netscape Communications, na Tellme (adquirida pela Microsoft) e em várias empresas minhas.

Como a IA ajudou a eliminar o congelamento anual de código da Meta

Quando estava na Meta, utilizámos um modelo de risco de IA para eliminar o congelamento anual de código.

Anteriormente, a Meta congelava a sua base de código todos os anos, desde meados de dezembro até janeiro, porque esse é o período de maior tráfego dos seus produtos. Durante anos, para evitar incidentes em produção nas semanas de maior risco, ninguém fazia implementações. Isto era seguro, mas também paralisava a produtividade de toda a empresa durante mais de um mês.

A minha equipa criou e disponibilizou como código aberto o Diff Risk Score, um sistema baseado num LLM que avalia a probabilidade de uma diferença de código provocar uma falha em produção. Em vez de tratar todas as alterações como igualmente perigosas durante o período de congelamento, o modelo fazia uma triagem de risco. Atribuía uma pontuação de risco contínua a cada diferença, ajustada para uma elevada revocação — por exemplo, assinalando 10% das diferenças e, ao mesmo tempo, detetando 60% das alterações que efetivamente causam incidentes. O modelo permitia que as diferenças de baixo risco fossem integradas mesmo durante o congelamento, mas retinha as que assinalava como arriscadas.

Como resultado, o congelamento deixou de ser uma decisão tudo ou nada. E o Diff Risk Score está a permitir que a Meta comece a eliminar completamente o congelamento de código — os engenheiros estão a recuperar semanas do seu calendário que antes eram tempo improdutivo, sem sacrificar a rede de segurança proporcionada pelo congelamento.

Este é um bom exemplo da minha filosofia mais abrangente: não imponham aos engenheiros um mandato de IA de cima para baixo; deem-lhes infraestrutura — uma plataforma centralizada, um sinal de risco, um plano de controlo — e deixem-nos descobrir por si próprios onde podem obter maior vantagem.

Porque é que os humanos têm de conseguir explicar o código antes de este entrar em produção

Se não consegue explicá-lo, não pode implementá-lo.

Utilizo intensivamente ferramentas de IA para acelerar o trabalho, mas aconselho os engenheiros a exigirem sempre validação antes de qualquer coisa chegar à produção. A IA não substitui o discernimento de engenharia; dá aos engenheiros maior capacidade para aplicarem esse discernimento em escala.

A IA informa agora o trabalho na avaliação de riscos, bem como na descoberta de ferramentas e fluxos de trabalho.

Onde os humanos são melhores:

• Governação e limites de controlo em torno dos próprios agentes: Quando as equipas integram modelos de raciocínio e agentes profundamente na infraestrutura, apercebem-se rapidamente das falhas de governação — os agentes multiplicam-se mais depressa do que alguém esperava e os orçamentos desaparecem de um dia para o outro. É necessária a mesma camada de governação em torno de agentes não determinísticos que colocaria em torno de seres humanos que utilizam essa infraestrutura — o que significa que os seres humanos continuam a definir limites orçamentais, fronteiras de acesso e requisitos de auditoria.
• Estratégia de adoção: Não se deve impor a adoção de ferramentas de IA — a utilização conquistada supera a utilização imposta, uma vez que as imposições produzem uma adoção superficial. Decidir como integrar a IA no fluxo de trabalho de uma equipa é claramente uma decisão humana de liderança e cultura — a ferramenta pode provar o seu valor, mas a decisão de adoção não pode ser automatizada.

Porque é que as equipas de engenharia têm de repensar a sua arquitetura

A computação começou com um computador central partilhado por todos e evoluiu depois para bastidores de servidores que executavam serviços especializados. Os agentes estão a seguir o mesmo percurso.

A antiga suposição era criar um punhado de agentes de uso geral e centralizar a utilização em torno deles, tal como se centralizava a computação. Mas as empresas apercebem-se de que a sua realidade não consiste num punhado de ferramentas partilhadas — está mais próxima de um ecossistema de agentes especializados e concebidos para fins específicos. Isto obriga a repensar o que significa realmente “arquitetura” para uma base de código: menos um monólito com extensões e mais um mundo de microsserviços, com a diferença de que os serviços são agentes em vez de pontos de acesso.

O instinto da maioria das organizações é tratar um agente como qualquer outro componente de software — escrever a especificação, lançá-lo e esperar resultados consistentes. Abandonei essa abordagem, substituindo-a por um modelo mental baseado numa força de trabalho. Isto reformula as questões de conceção organizacional — quem aprova o quê, quem gere o orçamento, quem é responsável quando algo avaria — como questões de gestão e não de implementação. É uma forma diferente de estruturar a relação de uma equipa com as suas ferramentas.

Porque é que a governação tem de estar implementada antes de a adoção da IA arrancar

Nas minhas funções anteriores, gostaria que tivéssemos criado a camada de governação antes de a adoção arrancar, e não depois.

Quando estava na Meta, os engenheiros começaram a criar e a publicar os seus próprios agentes na plataforma interna; os agentes multiplicaram-se rapidamente e a equipa de infraestrutura viu-se subitamente a tentar acompanhar a procura — literalmente, a tentar encontrar dezenas de milhares de servidores livres.

Olhando para trás, isto poderia ter sido evitado. Se partirmos do princípio de que a adoção pode tornar-se viral internamente, criamos os controlos de custos e as fronteiras de acesso como parte da plataforma desde o primeiro dia, e não como uma resposta de emergência.

Os CTO têm de redesenhar a fronteira entre “onde vive a IA” e “aquilo em que a IA pode tocar” — retirando-a do editor e colocando-a na sua infraestrutura, porque é nessa camada que o risco tem origem e onde a governação deve residir.

James partilha

\u003cstrong\u003eOs CTO têm de redesenhar a fronteira entre \u0022\u003cem\u003eonde vive a IA\u003c/em\u003e\u0022 e \u0022o que a IA pode tocar\u003c/em\u003e\u0022 — retirando-a do editor e colocando-a na sua infraestrutura, porque é nessa camada que o risco tem origem e onde a governação deve residir.\u003c/strong\u003e

Porque é que as organizações têm de dispor de um local centralizado onde os agentes possam ser clonados

Enquanto engenheiro, era melhor a roubar do que a programar. Encontrava algo que satisfazia parcialmente as minhas necessidades, adaptava-o ao meu objetivo específico e aprendia ao longo do processo.

O primeiro passo do fluxo de trabalho não é “dar um comando a um modelo”; é consultar um local centralizado para ver que agentes já existem para essa tarefa e clonar um deles, em vez de começar do zero. As organizações têm de criar processos que permitam copiar agentes facilmente.

Três recomendações para CTO que integram a IA em organizações técnicas

Eis os meus conselhos:

1. Não a imponha — conquiste-a. A utilização obrigatória da IA para aumentar a produtividade frustra-me, porque conduz a uma adoção superficial — as melhores ferramentas para programadores conquistam a sua utilização, e os programadores são suficientemente inteligentes para resistir quando lhes dizem de que ferramentas devem gostar. Os CTO devem apresentar à organização desafios empresariais de uma ordem de grandeza — problemas tão grandes que a IA seja a única solução realista. Depois, deixem que os engenheiros que os resolvem se tornem defensores espontâneos. 
2. Deixe de tratar a IA como uma ferramenta de autoria e comece a tratá-la como infraestrutura. 2025 foi o ano em que ferramentas de programação como o Cursor e o Copilot se generalizaram; agora, os modelos de raciocínio e os agentes de várias etapas deixam de ser plug-ins do editor e passam, em vez disso, a fazer parte da infraestrutura das empresas — submetendo código, executando testes, integrando novos engenheiros e gerindo o comportamento em produção. Se a sua estratégia de IA ainda é «que plug-in de IDE devemos comprar?», está a resolver um problema antigo.
3. Governe os agentes como governaria uma força de trabalho, não como governaria software. Os agentes alimentados por modelos de raciocínio são não determinísticos — dê duas vezes a mesma entrada ao mesmo agente e poderá obter resultados diferentes. Isto não é um erro a corrigir; é a natureza fundamental desta tecnologia. Os CTO já gerem diariamente sistemas não determinísticos com funcionários. É necessário aplicar aos agentes alguns dos mesmos mecanismos de proteção que aplica à sua força de trabalho. Não dê a um agente acesso irrestrito à produção, credenciais de root ou um orçamento ilimitado na nuvem logo no primeiro dia, tal como não daria essas permissões a um novo contratado.

Acompanhe

Pode acompanhar o trabalho de James Everingham no X e no LinkedIn.

Haverá mais entrevistas com especialistas no The CTO Club!