O plano por dentro: como estamos tocando a virada AI-first

Eu já dei a palestra bonita sobre isso. Contei o incômodo que me trouxe até aqui, depois o que é um harness e por último o novo papel de cada profissão em tech. Palco, slide, história redonda. O que não cabe numa apresentação é o que vem depois que a gente desce dela: o plano de verdade, com entregável pela metade e uma lista de coisa pra fazer que não acaba.

É isso que eu vim abrir aqui. Não o porquê, que já está contado, nem o conceito, que também já está. O de dentro: a meta que a gente escreveu pro fim do ano, os grandes blocos de trabalho que a gente separou pra chegar lá, como isso é tocado no dia a dia sem virar teatro de status, e o rito que segura a coisa de pé. Com o que já ficou pronto e, principalmente, com o tanto que ainda falta.

A meta que a gente escreveu pro fim do ano

A gente definiu um estado final pra não ficar remando pra todo lado, e o centro dele não é “usar mais IA”: é a IA fazendo o trabalho pesado de ponta a ponta, com um humano decidindo o que vira verdade em cada portão. Essa distinção é o artigo inteiro. Um fluxo que roda sozinho qualquer um monta com um script de CI; o que a gente quer é o agente escrevendo o código, os testes e abrindo o PR, e a gente entrando pra dirigir e aprovar, não pra digitar.

Cabe em duas frases. Até o fim do ano, o caminho que vai da descoberta de um produto até o pull request roda local, ponta a ponta, com o agente fazendo e uma pessoa disparando e revisando. E o conserto de um bug que chega do cliente acontece com o agente sozinho na fila: ele reproduz, investiga, corrige e abre o PR, e a gente entra só quando o risco pede.

O desenho inteiro é esse. Clica em cada etapa pra ver o que ela faz, e repara de quem é a mão em cada uma:

Se essa sopa de sigla te perdeu, um segundo pra traduzir. PDY é o nosso Product Discovery no Jira, o board onde toda ideia entra e é priorizada antes de virar problema. Problem Statement é o problema escrito como hipótese, não como verdade dada, enquadrado por dois métodos: JTBD (jobs to be done, o trabalho que o cliente quer ver feito) e HMW (how might we, a pergunta “como a gente poderia…” que abre espaço pra solução em vez de já cravar uma). PRD é o documento que fecha o que vai ser entregue. E o handoff é o pacote (problema, PRD e cenários de teste) que passa de produto e design pra engenharia sem ninguém reescrever nada.

Olha o que muda de figura. Em quase toda etapa quem executa é a IA: a skill prioriza a demanda, gera protótipo, decompõe o épico, coda, escreve o teste, abre o PR. O humano entra entre uma etapa e outra, revisando e liberando a próxima, e os losangos marcam a passagem de bastão quando o trabalho troca de área. É isso que separa AI-first de “automatizei um pedaço”: a máquina não está seguindo um roteiro fixo, ela está fazendo o trabalho que era nosso, e a gente virou o crítico que aprova. A gente para de ser a cola entre as etapas e passa a ser o critério no fim.

E tem um princípio embaixo disso que eu bati o pé pra valer: um sistema só, não dez iniciativas soltas. Toda tarefa passa pelo mesmo caminho; o que muda de uma pra outra é o quanto de humano ela pede. Uma funcionalidade complexa, como o inventário de pneus ou a parametrização de eixo suspenso, cada uma cheia de regra de negócio com exceção, puxa muito mais gente no meio do que um ajuste bobo, que pode rodar quase inteiro sozinho. Mesmo trilho, freios diferentes. É mais chato de montar assim, porque dá coceira de sair resolvendo cada caso do seu jeito, mas foi a decisão: começar local, com uma versão zero meia-boca, e deixar ela ir aprendendo em cima de tarefa de verdade, em vez de espalhar experimento solto por todo canto e não juntar nada depois.

E por que local, e não uma máquina remota chique disparando tudo sozinha desde já? Porque o objetivo agora é aprender o loop, não impressionar ninguém. Rodar local, com um humano apertando o play, é o jeito barato de ver onde o fluxo trava, onde o agente viaja e onde falta contexto, antes de confiar nele pra rodar sem ninguém olhando. A ferramenta de execução remota a gente decide depois, quando o fluxo local já estiver de pé, e escolha ela qual for tem uma regra que não muda: o Jira continua sendo a fonte da verdade das tarefas, então o que a gente plugar tem que atualizar ele, não competir com ele. Trocar a fonte da verdade no meio de uma virada dessas é tirar o chão do time inteiro de uma vez.

Como a gente confia no merge automático

Se o agente coda e abre o PR sozinho, a pergunta óbvia é: como deixar isso entrar em produção sem um humano lendo cada linha? A resposta são dois portões automáticos que todo PR atravessa, nos dois modos.

O primeiro portão são os testes: eles travam o merge, e num bugfix o teste tem que falhar sem a correção, pra provar que ele pega o bug e não só cobre a linha. O segundo é o review de código por IA, que comenta cada PR. Só que tem uma decisão que a máquina não toma sozinha: o que é crítico. Mexeu em dinheiro, em dado que não dá pra refazer, em acesso e segurança, em integração de hardware ou em dependência? Aí é crítico, e um humano aprova antes de entrar. O resto entra sozinho, com os dois portões verdes.

Isso vale nos dois jeitos de a engenharia trabalhar. Na sustentação autônoma, o agente fica sozinho na fila, triando e consertando bug sem dev conduzindo; na entrega dirigida, o dev conduz o agente do handoff até o merge. Em cada um, repara onde um humano ainda precisa colocar a mão:

Oito frentes, não uma pilha de tarefa

Pra sair da meta e cair no dia a dia, a gente separou o trabalho em oito frentes, que somam 236 tarefas e subtarefas no nosso ClickUp. Jogar essa montanha de tarefinha aqui no meio do texto vira ruído, então deixei o backlog cru num apêndice no fim, pra quem quiser descer nele; no corpo, o que importa é o grande entregável de cada frente e em que pé ele está. Não saiu de organograma bonito: saiu do jeito que o trabalho se agrupou quando a gente escreveu tudo que precisava virar ao mesmo tempo pra tech ficar AI-first sem criar um gargalo novo mais na frente.

Te aviso por e-mail sempre que sai conteúdo novo. Sem spam.

Avisar

Vou passar por elas, e vou ser honesto sobre onde cada uma está.

1. A base no Claude Code. O primeiro entregável era o mais concreto: colocar todo mundo trabalhando na mesma ferramenta de IA, e não só engenharia, também produto, design e operações. Essa parte já rodou. O que falta é o mais chato e menos visível, que é ter contexto compartilhado de verdade entre as pessoas e a gente conseguir enxergar quanto de recurso cada time consome, pra não descobrir tarde demais que alguém estourou o limite no meio de uma entrega.

2. Review, QA e teste. É a frente que mais dói, porque é ela que segura a qualidade quando o código passa a sair rápido demais. A primeira ferramenta de review por IA que a gente colocou não aguentou o nosso volume, então estamos trocando de ferramenta no meio do caminho. Junto disso vem montar o review humano obrigatório pros pontos sensíveis, abrir uma vaga de QA (que a gente nunca teve dedicado) e medir cobertura de teste produto a produto. Nada disso é glamouroso, e é o que evita a gente colocar em produção rápido e errado.

3. O Design System. É a frente mais madura de longe, e virou o nosso melhor exemplo de como a coisa deve andar. A gente já fechou o diagnóstico e a fundação, com centenas de tokens organizados de um jeito que a IA consegue ler e usar sozinha. Agora está no meio da aplicação disso nos componentes de verdade, com a migração de duas plataformas rolando ao mesmo tempo. É o pedaço onde a máquina já se parece com o que a gente prometeu no papel, e por isso ele puxa o resto.

4. O fluxo de upstream. Aqui mora o começo daquele caminho da meta: a descoberta, o problem statement, o PRD, o repositório que vira a fonte da verdade de um produto. O grande entregável é fazer esse pedaço rodar com a IA no meio, e não só a engenharia lá na ponta. É uma das frentes que ainda tem mais trabalho pela frente, e faz sentido, porque redesenhar como a gente descobre e especifica produto mexe em muita gente.

5. Dados como dono da verdade. Essa é a virada mais silenciosa de todas. O time de dados deixa de só entregar relatório sob demanda e passa a ser o curador da nossa fonte única, o que garante que a IA enxergue dado certo e não saia delirando em cima de coisa velha ou contraditória. Ainda está mais no plano do que no chão, mas sem isso o resto trava, porque agente nenhum rende bem em cima de contexto bagunçado.

6. A operação do time. É a frente das pessoas, e a mais lenta de propósito. Entra aqui os primeiros pods montados pra tocar uma entrega ponta a ponta com IA (o de inventário de pneus e o de eixo suspenso foram os dois primeiros), o pareamento pra galera aprender na mão, o curso de onboarding que eu mesmo estou gravando e o desenho de como a carreira muda daqui pra frente. Os pares não são fixos, eles rodam, pra o que um aprendeu não ficar preso dentro de uma dupla só. Mexer em como o time trabalha é o que mais gera desconforto, então a gente vai devagar e ouvindo.

7. Governança e segurança. A parte que ninguém quer fazer e que é a que mais pode explodir. Um agente com acesso de administrador no lugar errado é estrago que não tem volta, então tem frente dedicada só pra revisar permissão de banco, política de dado sensível e governança de quem pode criar e rodar o quê. Entra aqui também a comunicação pra empresa toda, porque essa virada não pode ficar só na cabeça de quem começou.

8. A infra por baixo. É o alicerce que quase ninguém vê: um repositório único pra dar mais contexto pra IA, um backend de dados próprio no lugar da ferramenta velha, os ambientes pra homologar com segurança. O grande entregável dessa frente já andou bastante, e é ele que deixa todo o resto possível. Sem alicerce, o prédio não sobe.

Onde a gente está de verdade

Se você juntar as oito frentes e olhar sem filtro, a foto é essa: uns poucos blocos já fecharam, alguns estão no meio, e a maior parte ainda nem começou direito. Fechou o diagnóstico, a base no Claude Code, a fundação do Design System, os indicadores com o painel e boa parte da infra de dados. Está no meio o review com IA, o Design System nos componentes, o upstream e os primeiros pods. E ainda é promessa a esteira de teste redesenhada, a governança, a comunicação pra empresa e a virada do time de dados.

Ou seja: a maior parte do plano ainda não aconteceu. E eu escrevi esse texto justamente agora, com o plano nesse ponto, de propósito. Dava pra esperar tudo ficar mais bonito, com mais bloco verde, pra contar a história com final feliz. Só que aí não seria mais a real, seria propaganda. A gente está no comecinho de uma virada que vai levar o ano inteiro, com o time construindo enquanto a estrutura ainda está sendo montada, e mostrar isso pela metade é o ponto. Quem só conta a parte pronta está vendendo.

E tem uma parte disso mais difícil de engolir do que a lista de bloco vermelho: o pedaço que anda mais devagar é o das pessoas, não o da tecnologia. Colocar todo mundo no Claude Code foi rápido. Fazer um time que passou dez anos com orgulho de escrever cada linha na mão aceitar dirigir um agente em vez de digitar, isso é o que leva tempo, e é o que eu menos resolvo com marco e painel. É onde eu mais estou tendo que aprender a ter paciência.

Como a gente gerencia isso sem virar teatro

Um plano desse tamanho morre fácil de dois jeitos: ou vira uma lista que ninguém abre, ou vira reunião de status onde todo mundo finge que está tudo no verde. A gente tentou escapar dos dois com quatro coisas simples.

Uma é trabalhar com marco, não com tarefa solta. O Design System é o melhor exemplo: ele está fatiado em marcos numerados, do diagnóstico até a aplicação completa, e dá pra dizer com honestidade em qual deles a gente está. Marco fechado é marco fechado, sem “quase”.

Outra foi colocar dono de verdade nas entregas grandes de IA, em vez de pulverizar tudo nas squads e ninguém puxar. Quando a coisa é de todo mundo, costuma não ser de ninguém.

A terceira eu resumiria em medir pouco, mas medir. A gente jogou tudo num painel só, sete indicadores, cada um respondendo uma pergunta boba e difícil, porque a tentação de acompanhar vinte números e não olhar nenhum é enorme. Quanto a gente entrega por semana em PR e task, quanto do review já é a IA e não a gente, quanto de bug escapa pra produção, quanto do código tem teste pra segurar a IA soltando rápido, quanto do código já sai da própria IA, como o time se sente usando isso, e quanto a gente demora pra validar e colocar no ar. Se um deles piora enquanto os outros melhoram, é sinal de que a gente só empurrou o gargalo pro lado.

E a quarta é mais rendição do que tática: aceitar que o gargalo agora é a gente, não a máquina. A IA já constrói rápido, o que trava é redesenhar o trabalho, treinar, revisar e decidir, e é por isso que metade dessas frentes é sobre gente e processo, não sobre ferramenta. Ferramenta a gente troca numa semana. Hábito de uma década leva bem mais.

O rito: um follow a cada duas semanas

O que segura tudo isso de pé é modesto: um follow a cada duas semanas. Não é com as squads inteiras. É um grupo pequeno, umas sete ou oito pessoas, com representantes de produto, engenharia e design. Eu conduzo, e a gente foi ajustando a cadência até virar quinzenal, quando viu que intervalo mais curto só gerava reunião sem novidade real pra trazer.

O follow não é vitrine. A ideia é ouvir a dificuldade de verdade (a ferramenta que travou, o limite que estourou no meio de uma spec longa, a insegurança de quem está com medo do próprio trabalho mudar) e transformar isso no foco das próximas duas semanas. Metade do valor está nos comentários que não cabem num card, no “isso aqui não está funcionando” dito na cara. Um plano desse tamanho não sobrevive sem um lugar fixo pra verdade aparecer.

E o que sai desses encontros não morre na ata. A dificuldade que aparece vira o foco das duas semanas seguintes, e boa parte dela vira treinamento: alguém do time pareia com quem está travado, e eu estou gravando um curso de onboarding de IA pra que pessoa nova já entre jogando, em vez de descobrir tudo na tentativa e erro como a gente descobriu. É sempre gente sentando junto, errando junto e passando adiante o que aprendeu.

Uma vitória que não estava no roteiro

Nem tudo é dashboard e processo, e a entrega que mais me animou até agora não foi nenhuma das que eu esperava. Um problema de firmware numa versão nova que a gente está produzindo pra um dos nossos aparelhos, a retenção de ar de um hardware novo que nem o nosso fornecedor de firmware tinha destravado, foi resolvido pela IA, só em código. Resolveu na versão 5 do firmware, e daí vai pra todos os aparelhos. Não é o tipo de coisa que passava pela minha cabeça quando comecei a falar de agente em engenharia, e foi o que mais me convenceu de que essa virada é mais larga do que só escrever tela de aplicativo mais rápido.

Vitória assim é bom guardar. Num plano cheio de bloco vermelho, a que aparece de lado, fora do previsto, é o que lembra a gente de que o caminho está certo mesmo quando o painel ainda está feio.

O que eu levo dessa parte da virada

Escrever isso aqui foi meio desconfortável, e é justamente por isso que eu escrevi. É bem mais fácil publicar o conceito redondo do que o plano com a maior parte dos blocos ainda em aberto. Só que o conceito qualquer um lê num artigo da OpenAI; o que é nosso, e o que talvez sirva pra você que também está no meio disso, é o plano imperfeito rodando de verdade.

Se eu tivesse que resumir o que essa fase me ensinou, seria isto: abrir o plano inteiro, sem esconder o tanto que falta, é o que me impede de enganar a mim mesmo sobre onde a gente está. No dia que essas frentes ficaram todas à vista, pro time e pra mim, com o verde e o vermelho lado a lado, ficou bem mais difícil vender ilusão pra dentro de casa. Vou continuar contando como for indo, com o número feio quando ele for feio.

Apêndice: o backlog inteiro, frente por frente

Aqui é o cru, pra quem quiser ver o tamanho real da coisa. As oito frentes somam 236 tarefas e subtarefas no nosso ClickUp; abaixo estão os grandes blocos de cada uma, com uma linha do que é. O que está dentro de cada bloco muda toda semana, então trate como foto do momento, não como lista fechada.

1. A base no Claude Code

• Concluir a migração da engenharia pro Claude Code Teams. Toda a engenharia na mesma ferramenta.
• Expandir o Claude Code pra Produto, Design e Ops. Sair de engenharia e alcançar o resto de tech.
• Estruturar o contexto compartilhado da organização. Contexto comum, não cada um no seu chat.
• Monitorar consumo e custo do Claude pós-expansão. Enxergar uso e custo por time.
• Centralizar commands, skills e agents no nível da organização. Biblioteca comum, sem cada um reinventar.
• Definir a pessoa dedicada pra cuidar de IA na engenharia. Um dono pra puxar isso.

2. Review, QA e teste

• POC das ferramentas de code review. Testar e escolher a ferramenta de review por IA.
• Montar o trio das regras de review humano obrigatório. Definir quando um humano tem que revisar.
• Contratar 1 QA cross-squad. O QA dedicado que a gente nunca teve.
• Definir metas de cobertura por plataforma e módulo. Quanto de teste cada produto precisa.
• Redesenhar a esteira de testes. A esteira que roda os testes de ponta a ponta.
• Iniciar a esteira contínua de implementação de testes. Voltar nos produtos e cobrir o que ficou sem teste.

3. O Design System

• Endereçar os problemas estruturais do Design System. Dos marcos de tokens até a aplicação nos componentes (React, Flutter, Widget Book).
• Decidir o caminho do Design System. Fazer interno, comprar ou terceirizar.

4. O fluxo de upstream

• Upstream System: habilitar Produto e Design AI-first. A descoberta, o problem statement e o PRD com a IA no meio.
• Criar, centralizar e evangelizar as skills dos processos. As skills que o time dispara no dia a dia, começando pelos processos de engenharia.

5. Dados como dono da verdade

• Habilitar Dados pra operar como curador da fonte única. Dados deixa de fazer BI sob demanda e passa a curar a verdade.

6. A operação do time

• Desenhar e lançar o AI-Native Pod de Inovação. O time enxuto pra entregas engargaladas (pneus e eixo suspenso foram os dois primeiros).
• Rodar os pilotos de microtimes. Quebrar um time por entrega em pares mais IA.
• Fazer pair com devs pra treinar no Claude Code. Pareamento pra galera aprender na mão.
• Estruturar o onboarding formal sobre Claude. O curso que eu estou gravando.
• Atualizar o onboarding de novos contratados. Quem entra já entra jogando.
• Atualizar os critérios de performance e o career path. Como a carreira muda daqui pra frente.
• Realizar um Hackathon de IA. Um empurrão coletivo.
• Criar o ritual de trocas quinzenais entre squads. Uma reunião pras squads trocarem entre si o que estão fazendo com IA, o que está dando certo e o que está dando errado.
• Implementar Documentation-Driven Design. Documentar antes, pra IA e pra gente ler.

7. Governança e segurança

• Revisar as permissões de usuários de banco em todas as aplicações. Agente com acesso demais é estrago que não tem volta.
• Organizar os usuários de banco por projeto e permissão mínima. Cada um só o que precisa.
• Definir a política de dados sensíveis em IA. O que pode e o que não pode ir pra IA.
• Definir a governança de skills, agents e MCPs internos. Quem cria e quem roda o quê.
• Comunicar pra empresa inteira o movimento de IA em tech. Não deixar isso só na cabeça de quem começou.
• Comunicar abertamente as 4 cobranças do time. O que muda pra cada um.

8. A infra por baixo

• Iniciar o brainstorm técnico do monolito modular. Débito técnico: o monolito é grande demais e sem modularização, então pra IA também é grande demais, ela se perde e queima muito token. Repensar a arquitetura pra ela navegar melhor.
• Migrar do Notion pra uma ferramenta open source. Legibilidade e MCP pra IA (fomos pro Outline, na versão cloud dele, que tem busca por IA).
• Juntar os repos do Intralog num único monorepo. Mais contexto num lugar só.
• Subir um serviço de backend de analytics pro Intralog. Dados próprios no lugar da ferramenta velha.
• MCP do Intralog. Plugar a plataforma interna na IA.
• ProBot mais completo pra perguntas via Discord. O assistente interno respondendo direto.
• Permitir múltiplos ambientes de homologação. Homologar com segurança, no Intralog e no Prolog.

Medição (atravessa todas as frentes)

• Definir os KPIs da reestruturação AI-Native. Throughput, review humano vs IA, bug escape, cobertura de teste, % de código por IA, NPS interno de IA e tempo em homologação.
• Montar o dashboard único da iniciativa. Tudo num painel só.