A cada dois meses eu recebo uma versão da mesma ligação. Um CTO liberou o Claude Code ou o Cursor para o time de engenharia, pagou as licenças, rodou um treinamento e, três meses depois, ninguém consegue apontar um número que mostre que o investimento se pagou. A pergunta é sempre a mesma: o que deu errado?
O que deu errado é a premissa embutida no rollout. “Adotar IA” está sendo tratado como uma decisão de compra: escolher um fornecedor, comprar assentos, mandar o e-mail e ver a produtividade subir. Os fornecedores incentivam essa leitura porque vendem licenças, não redesenho organizacional. O CTO comprou o que estava à venda.
O trabalho de verdade é organizacional. Leva no mínimo seis meses, tem fases que precisam acontecer em ordem e se parece muito mais com implantar um novo modelo operacional do que uma nova ferramenta. Os times que estão saindo na frente em 2026 não são os que têm mais licenças: são os que fizeram isso mais devagar, em escala menor e na sequência certa.
Os números não mentem, e a maioria das empresas está lendo errado
Três pesquisas públicas chegam à mesma conclusão por caminhos diferentes.
A Writer’s 2026 Enterprise AI Adoption Survey entrevistou 1.200 executivos de C-level e 1.200 profissionais de áreas não técnicas. 97% dos executivos afirmam que a empresa colocou agentes de IA para rodar nos últimos 12 meses. 29% enxergam ROI significativo com IA generativa, e 23% com agentes especificamente. A frase mais forte do relatório: 54% dos líderes de C-level dizem que adotar IA está “despedaçando a empresa”.
O relatório de novembro da McKinsey, 2025 State of AI, chega ao mesmo desenho pelo lado operacional. 88% das organizações já usam IA em pelo menos uma função de negócio, contra 78% em 2024. 39% atribuem algum nível de impacto no EBIT à IA.
Cerca de 6% se qualificam como high performers, ou seja, impacto no EBIT acima de 5%. A variável que mais se correlaciona com esse status é o redesenho de workflows, e apenas 21% das organizações fizeram isso.
O DORA 2025 Accelerate State of DevOps Report acrescenta um terceiro ângulo. 90% dos profissionais de software usam IA no dia a dia, com mediana de duas horas diárias em ferramentas de IA, e 80% relatam ganhos de produtividade. Mas a conclusão principal é esta: a IA amplifica o que já existe. Práticas maduras de DevOps convertem os ganhos de IA em performance de entrega. Práticas fracas são amplificadas na direção oposta, às vezes com resultados mensuravelmente piores depois da adoção.
Três lentes, uma conclusão: o modelo não é o gargalo, as licenças não são a alavanca, e o trabalho está em tudo o que cerca o modelo.
Para um ponto de partida prático, nosso AI Readiness Assessment ajuda a mapear onde a sua organização realmente está antes de você se comprometer com um caminho de rollout.
Redefinindo o ponto de partida
Antes do playbook, a definição, porque todo rollout que eu vi desandar desandou justamente por pular essa etapa.
Cultura de IA não é comprar licença para todo mundo, rodar um treinamento de uma hora ou tratar IA como uma ferramenta isolada de produtividade para engenharia. Também não é substituir engenheiros por agentes, nem velocidade a qualquer custo.
O que ela é: engenheiros e builders trabalhando mais perto uns dos outros, com uma distância menor entre a intenção e o código entregue. Investimento no harness como prática contínua, não como projeto pontual. Engenheiros subindo uma camada, de digitar código para orquestrar agentes. Velocidade com qualidade, porque os gates e os judges mantêm o piso alto. Decisões tomadas com dados de produção consultados por agentes via MCPs, em vez de chutadas no sprint planning.
A versão honesta de “temos uma cultura de IA” é o engenheiro que roda cinco agentes em paralelo antes do almoço, consulta dados de produção enquanto decide o que entregar, conversa direto com o PM e o designer à tarde e, na manhã seguinte, escreve uma spec que um agente implementa durante outra reunião.
Esse é outro modelo operacional, e ele não aparece porque alguém comprou licenças. Ele aparece porque o harness, o desenho dos papéis, o organograma e as métricas foram todos reconstruídos em torno da nova camada.
Fase 1: os champions (meses 1 e 2)
De duas a quatro pessoas, e não “todo mundo que tiver interesse”. Especificamente: um product manager já curioso sobre IA, um tech lead receptivo, um engenheiro que já tem o instinto de Product Engineer ou Forward Deployed Engineer, e alguém de plataforma ou infraestrutura capaz de construir o harness inicial. Os champions são recompensados com tempo, autonomia e voz, nessa ordem.
Ao longo desses dois meses, os champions fazem três coisas: constroem o próprio setup até ele ficar sólido, escrevem as duas ou três primeiras skills compartilhadas e identificam qual squad (ou quais dois) deve ser o piloto. O output deles não são features: são os trilhos que o resto da organização vai usar.
Fase 2: o piloto (meses 3 e 4)
Um ou dois squads. Escolha com critério: um com projeto novo e sem dívida de legado, outro com refatoração já planejada. Não escolha o squad que está apagando incêndio em produção neste trimestre, nem o squad com o tech lead resistente a mudança, nem o squad que se voluntariou só para brincar com ferramenta nova. Escolha os squads em que o trabalho encaixa no novo modelo operacional e em que as pessoas serão honestas sobre o que funciona e o que não funciona.
Os squads piloto usam o que os champions construíram, escrevem mais skills e criam os templates de spec que o resto da organização vai herdar. As medições que importam aqui são cycle time por feature, taxa de retrabalho e eNPS dos desenvolvedores, não tokens consumidos. Gasto de token é métrica de vaidade. A pergunta real é se você entregou mais rápido, com menos retrabalho, e se os engenheiros gostaram mais do processo.
Vale ter em mente a regra 10-20-70 do BCG nessa fase: 10% do valor vem da tecnologia, 20% de dados e processo, 70% de pessoas e processo. As fases de champions e de piloto existem justamente porque os 70% não acontecem comprando tecnologia.
Fase 3: o harness (meses 5 e 6)
É aqui que o trabalho dos champions e dos squads piloto vira infraestrutura para toda a engenharia, e também onde a maioria dos times desiste, porque é um trabalho pouco glamouroso. São cinco peças que valem investimento, e você não vai terminar as cinco em dois meses. Escolha uma ou duas.
Code review automatizado, por t-shirt size. PRs pequenos são aprovados automaticamente depois da pré-análise do agente. PRs médios vão para review humano com os achados do agente anexados. PRs grandes exigem par mais agente. O roteamento é o que resolve: sem t-shirt sizing, todo PR passa pelo mesmo portão e você cria um gargalo no review dos seniores.
Templates de spec padronizados. A forma como o seu time registra features vira o input padrão de todo agente. As specs ficam no repositório em docs/specs/, versionadas como código, com o mesmo template em toda a organização. A variação que você elimina padronizando vale mais do que a flexibilidade que você preserva deixando tudo solto. Veja nossa visão prática de IA para desenvolvimento de software para entender como isso se encaixa em um workflow mais amplo.
MCP central com governança. Um servidor MCP auditado para acesso ao banco de produção, um para o Datadog, um para o Sentry, com acesso controlado, logs auditados e secrets escaneados. Sem isso, cada engenheiro monta o seu e você tem um problema de segurança e compliance esperando para aparecer.
Loops de auto-recuperação. Um agente que abre o próprio PR para corrigir um bug detectado. O Sentry dispara, um MCP roteia o erro para um agente de triagem, esse agente cria a issue, um agente worker pega a issue e abre um PR com a correção e os testes. Isso é avançado (não comece por aqui), mas é onde o harness mais acumula ganho ao longo do tempo.
Skills do time versionadas. Todas as skills compartilhadas commitadas em um único repositório, revisadas em code review e tagueadas. Essa é a camada de conhecimento institucional: quando alguém sai, a skill fica; quando alguém entra, as skills são o onboarding.
Duas dessas peças bem feitas rendem mais do que cinco malfeitas. Escolha as duas de maior alavancagem para o seu time e trabalhe nelas de forma aberta.
Leia mais: Plan Mode é decisivo: por que codar em modo direto com agentes desperdiça tokens
Antes de escalar: a governança que realmente importa
Governança é onde a maioria dos rollouts que acompanhei falhou, então aqui vai o que travar antes de abrir para a empresa inteira.
CLAUDE.md Enterprise como gate de política. A Anthropic suporta quatro níveis de hierarquia no CLAUDE.md: Enterprise, User, Project e Directory. O nível Enterprise é onde entram as políticas válidas para toda a empresa: o que é permitido nos prompts, o que é proibido e o que passa por scan. Trave isso antes de escalar.
Controles de ferramentas e de orçamento no CI. O –allowedTools restringe quais ferramentas os agentes podem invocar em execuções automatizadas. O –max-budget-usd limita o gasto por execução. Nenhum dos dois é exótico, e os dois são fáceis de esquecer até a conta do seu CI triplicar em um mês.
Allow-lists de MCP e logs de auditoria. Todo servidor MCP conectado a algo sensível deve estar em uma allow-list revisada, com cada chamada auditada. Se o seu MCP central de banco de produção não consegue responder “o que o agente X leu da tabela de usuários na terça passada”, você não está pronto para escalar.
Defesa contra prompt injection. Se um MCP devolve dados que um atacante consegue influenciar (uma nota de CRM, um ticket de suporte, uma página pública na web), esses dados podem conter payloads de prompt injection. A defesa é em camadas: sanitizar a entrada, restringir as ferramentas que o agente pode chamar depois de ler dados não confiáveis e rodar o agente em sandbox nas operações não confiáveis. Não pule a modelagem de ameaças.
Residência de dados e BAA, com precisão. A Anthropic oferece Business Associate Agreement na API direta via time comercial. O Zero Data Retention está disponível para clientes enterprise elegíveis mediante aprovação, com exceções: Batch API, Files API, Skills API, execução de código e chamadas de conectores MCP ficam fora do escopo. Residência de dados na União Europeia não vem por padrão no Claude Enterprise; processamento estritamente europeu passa pelo AWS Bedrock em Frankfurt ou pelas regiões europeias do Google Vertex AI. Conte a versão precisa para o seu time de compliance antes de assinar, não depois.
A pergunta sobre contratação que todo CTO acaba fazendo
A pirâmide achata. Menos juniores puros escrevendo boilerplate, mais generalistas plenos e sêniores que assumem resultados de ponta a ponta. A escada do “júnior implementa, sênior revisa” é comprimida porque a etapa de implementação agora é majoritariamente agêntica. Os papéis que sobrevivem e crescem são os que exigem julgamento em cenários ambíguos.
A entrevista muda junto: menos LeetCode, mais taste, escrita de spec, julgamento e capacidade de arquitetar workflows agênticos. Boris Cherny, da Anthropic, descreveu o filtro de contratação da empresa como “side quests”: engenheiros com projetos de fim de semana, repertório em produto, design e infraestrutura, evidência de que constroem coisas fora do trabalho.
Esse filtro está se espalhando. O engenheiro com uma única stack e dez anos de fábrica de features é o perfil sob maior pressão. O engenheiro com um side project, opinião sobre produto e conforto para atuar em toda a stack é o perfil que compõe valor ao longo do tempo.
Leia mais: Harness Engineering: por que “pronto” não é o agente dizer que está pronto
A sequência de seis meses no calendário
- Meses 1 e 2: champions e ferramental. Workshop, setup individual, champions identificados por nome, as duas primeiras skills compartilhadas commitadas. O output dessa fase não são features: é um grupo de trabalho de duas a quatro pessoas que usam as ferramentas com fluência e já começaram a construir o harness inicial.
- Meses 3 e 4: pods piloto. Um ou dois squads adotam o novo workflow em trabalho real. Primeiros templates de spec commitados, primeiras retros do harness realizadas, medições com baseline definida em cycle time, taxa de retrabalho e eNPS.
- Meses 5 e 6: camada de harness. Automação de code review, um MCP central, skills versionadas e tagueadas, governança travada. O harness vira algo que o resto da organização adota sem precisar aprender do zero.
- Mês 7 em diante: rollout. Toda a engenharia migra para o novo workflow. Governança formal no lugar, métricas em um dashboard e o flywheel cultural começa a girar, porque a distância entre os early adopters e o resto da organização cai de seis meses para uma semana.
A tentação em toda conversa é comprimir isso: pular o piloto e treinar todo mundo de uma vez; pular o harness, porque os engenheiros vão se virar; pular a governança, porque o jurídico corre atrás depois. Toda vez que um time tentou, gastou três meses a mais se recuperando das consequências do que economizou pulando etapas. A sequência é o playbook, e maturidade não é velocidade.
Quatro coisas para fazer antes de segunda-feira
- Escolha de dois a quatro champions até sexta. Mande um recado curto: “Vocês são o grupo de trabalho que vai descobrir como a gente adota IA por aqui. Tempo, autonomia e voz. Me tragam um plano em quatro semanas.” Depois, saia da frente.
- Escolha o squad piloto e o projeto piloto antes do fim do mês, e comece o piloto em duas a quatro semanas. Não rode um terceiro piloto: dois é o máximo.
- Commite o primeiro template de spec e a primeira skill compartilhada no repositório. Não cinco: um de cada. O ponto é estabelecer que é assim que a sua empresa registra conhecimento agora.
- Escolha uma métrica e acompanhe por seis meses: custo por feature, cycle time por feature ou taxa de retrabalho. Coloque em um dashboard e olhe a cada duas semanas. A maioria dos rollouts falha porque ninguém segurava um número que dissesse se aquilo estava funcionando.
As empresas que vão parecer visionárias daqui a três anos não serão as que compraram mais licenças. Serão as que trataram a adoção de IA como o redesenho organizacional que ela realmente é: champions antes dos pods, pods antes do harness, harness antes do rollout, e medição o tempo todo. Se o seu time está em algum ponto entre a fase de champions e a fase de harness e se pergunta como é o mês três na prática, fale com a gente. O diagnóstico costuma ser mais rápido do que a conversa sobre fazer ou não o diagnóstico.
