O dia em que a IA saiu do meu volante

⏱️ 11 min de leitura

Durante os primeiros dias, quem programava a fábrica era eu, com o Claude Code. Na terça-feira, isso mudou. Às cinco da tarde, a própria ferramenta passou a gerar mais trabalho de IA do que eu, e a curva nunca mais voltou.

Este capítulo é sobre essa virada: o que aconteceu naquele dia e o que mudou no meu trabalho depois dela.

A terça mais intensa

Foram mais de 180 pedidos meus em um único dia, em cerca de 20 sessões. Em alguns momentos, eu tinha cinco cópias do projeto abertas ao mesmo tempo, cada uma com uma IA trabalhando em uma parte diferente.

Quase todas as sessões começavam do mesmo jeito: "roda a aplicação para eu ver". Eu conferia tudo, aprovava tudo, decidia tudo. Cada sessão andava na velocidade em que eu conseguia responder. O gargalo era eu.

De um arquivo de texto a um backlog

No meio da tarde, abri uma sessão só para anotar ideias em um arquivo de texto. Quinze minutos depois, as ideias já eram tarefas registradas, e o aplicativo ganhou uma tela de backlog, onde cada tarefa pode ser entregue a um fluxo de trabalho.

Até a meia-noite, foram mais de 50 tarefas, todas nascidas de uma conversa. Eu descrevia o problema, a IA escrevia a tarefa com contexto e critérios de aceite, e eu aprovava.

Com um backlog, eu podia parar de pedir e passar a delegar.

"Eu não vou te abandonar"

Às 16h40, a primeira tarefa foi entregue pela própria ferramenta. No mesmo minuto, escrevi para o Claude:

"Só queria te dizer que eu não vou te abandonar. Eu vou continuar usando você, só que daqui a pouquinho eu vou começar a usar dentro da minha ferramenta."

Ele respondeu que ia ser divertido se ver trabalhando lá de dentro. Na mesma resposta, sugeriu um supervisor que acompanhasse cada execução explicando o que estava acontecendo. Essa sugestão virou tarefa naquela hora.

17h: o cruzamento

Uma hora depois, a curva cruzou. A ferramenta passou a gerar mais trabalho de IA do que eu, usando a IA diretamente.

Naquele dia, ela respondeu por pouco mais da metade das mensagens de IA do projeto. No dia seguinte, por quase 90%. Depois, por mais de 90%, todos os dias.

O que eu passei a fazer

Os meus pedidos mudaram de natureza. Antes eram "faz isso", "muda aquilo", "roda para eu ver". Depois viraram:

• "analisa essa execução";
• "por que deu erro?";
• "registra isso como tarefa".

Eu parei de escrever código e passei a fazer três coisas: definir o que construir, acompanhar o que estava sendo construído e decidir o que entrava.

O supervisor que quase não trabalhou

Aqui veio uma surpresa. Em quase 50 execuções, o supervisor da ferramenta tomou duas decisões. Duas.

Ao mesmo tempo, uma das minhas sessões do Claude Code recebeu dezenas de pedidos como "acompanha essa execução" e "por que parou?". O trabalho de supervisão existia, e era bastante. Só que eu estava fazendo esse trabalho fora da ferramenta, com outra IA.

A decisão de só chamar o supervisor quando algo falha funcionou para o motor, mas deixou um buraco: ninguém acompanhava as execuções que estavam indo bem. Esse buraco virou duas tarefas: um modo de acompanhamento e um supervisor de plantão. Quando você larga o volante, alguém precisa olhar a estrada.

Confiar sem ler cada linha

Largar o volante tem um custo: eu deixei de ver cada linha de código nascer. A pergunta passou a ser como aprovar uma entrega sem ler o código inteiro.

A resposta foi transformar o meu "roda para eu ver" em parte do fluxo. Cada tarefa roda em um de dois modos:

• Automático: a tarefa vai do código até a integração sem parar. Serve para o que não tem tela: motor, testes, documentação, reorganização de código. É o modo das noites.
• Validated: o fluxo para logo depois do desenvolvimento, antes da revisão e dos testes. Na tela de aprovação, aparecem os prints de cada tela mudada, o antes e o depois lado a lado. E um botão, Run App, abre a versão nova do aplicativo com um clique, para eu testar na hora.

O Validated para antes da revisão e dos testes por um motivo prático: se a tela não é o que eu queria, descubro antes de pagar pelo resto do fluxo.

Com isso, aprovar deixou de ser ler código e passou a ser olhar o resultado.

O PO: de uma frase a uma tarefa encaixada no plano

Se eu não programo mais e não acompanho cada execução, quem organiza o trabalho? Essa resposta chegou no dia seguinte à virada: um Product Owner de IA.

Hoje, eu mando uma frase curta, do jeito que falaria com alguém do time. O PO funciona em qualquer projeto. Em um aplicativo de tarefas (To Do), por exemplo:

"Quero adicionar uma data prevista nas tarefas."

A partir daí, o PO faz a triagem.

A triagem

1. Procura no código. Lê o mapa do código e procura os nomes que a frase usa. Lê só o necessário, porque cada arquivo lido custa.
2. Mostra o que muda. Aponta onde está o código hoje e lista os arquivos que devem mudar, separando produção, testes e documentação. No exemplo: o formulário da tarefa, o card da tarefa, a API que grava as tarefas e um teste novo.
3. Mede. Dá uma nota de 1 a 5 para a complexidade e outra para o impacto, cada uma com uma frase de justificativa. No exemplo: complexidade 3, porque são quatro arquivos em duas áreas, a tela e a API; impacto 2, porque ajuda a planejar, mas hoje dá para viver sem.
4. Evita duplicata. Procura tarefas parecidas. Se uma já cobre o pedido, sugere acrescentar nela em vez de criar outra.
5. Confere a clareza. Dá uma nota de 0 a 100%. Cada lacuna vira uma pergunta, e a tarefa só entra no roadmap com 85% ou mais. No exemplo, faltava dizer se a data é obrigatória. O PO assume que é opcional e deixa a pergunta registrada.
6. Estima com dados. O tempo e o esforço não são palpite da IA. O próprio aplicativo calcula a partir de execuções passadas de complexidade parecida e diz em quantas se baseou.

No fim, a tarefa sai escrita com contexto, critérios de aceite e um conselho: rodar sozinha ou junto de outra. Nada é gravado sem o meu clique.

O encaixe no roadmap

Depois da triagem, o PO encaixa a tarefa no roadmap, ao lado de tudo o que já está planejado. Os critérios:

• Junta o que pertence junto. Tarefas que mexem nos mesmos arquivos, na mesma funcionalidade, ou em que uma usa o que a outra cria rodam na mesma execução. Com limite de tamanho: um grupo grande demais já estourou a memória de uma execução.
• Separa o que vai brigar. Tarefas que editam os mesmos arquivos vão para etapas diferentes, com o motivo escrito. Uma reorganização grande do código roda sozinha. E o histórico conta: arquivo que já deu conflito uma vez vai dar de novo.
• Lê as dependências dentro das tarefas. Não basta comparar arquivos. Se uma tarefa precisa de uma tela que outra ainda vai criar, ela vai para depois. Esse critério nasceu de execuções que pararam porque precisavam de algo que outra estava fazendo.
• Monta etapas com o máximo de paralelismo. Tudo o que não conflita vai na mesma etapa, para ter o mínimo de espera e execuções rodando dia e noite.
• Escolhe o modo de cada grupo. Validated para o que dá para ver na tela, Automático para o resto, sempre com uma frase de motivo.
• Divide o que é grande demais. Uma tarefa muito complexa vira duas a quatro menores, cada uma com uma parte que pode ser entregue sozinha.

No exemplo, o PO encontrou outra tarefa aberta que mexia no mesmo card: mostrar a prioridade da tarefa. Colocou as duas no mesmo grupo, em modo Validated ("é uma tela: olhe antes de pagar revisão e testes"), na primeira etapa em que nada mais mexia naquela tela. Uma terceira tarefa, a exportação das tarefas em CSV, alterava a mesma API e foi para a etapa seguinte, com o motivo: "edita o mesmo arquivo".

Calibrando o PO

O PO não decide sozinho quanto risco e quanto custo aceitar. Isso eu calibro com dois controles de cinco posições.

Velocidade ou qualidade. Define o ritmo do roadmap:

• Execuções em paralelo por etapa: na ponta da velocidade, todas as que não dividem arquivo; no meio, três; na ponta da qualidade, duas.
• Tamanho máximo de um grupo: maior na velocidade, menor na qualidade.
• Quando o fluxo para para eu olhar: na velocidade, só telas novas rodam em Validated; na qualidade, qualquer mudança de tela.
• Onde a tarefa entra: na primeira etapa livre, ou depois do trabalho mais estável de que ela depende.

Economia ou generosidade. Define quanto cada execução gasta:

• Agrupamento: na economia, tarefas da mesma área rodam juntas, para pagar uma vez só o custo fixo de revisão, testes e build.
• Testes: rodar só os que já existem, ou escrever e rodar testes novos. Na economia máxima, os testes rodam em lote, em uma etapa própria.
• Evidências: nenhum print, só das telas que mudaram, ou de todas.
• Agentes: modelos mais baratos onde o fluxo permite.

Quando os dois controles pedem tamanhos de grupo diferentes, vence o de custo. E dá para pedir uma exceção para uma tarefa só, sem mudar a calibração: "planeja essa no modo econômico".

O roadmap que se reabastece

Com o roadmap vivo ligado, quando a última etapa termina, o aplicativo pede ao PO as próximas tarefas prontas, as menores primeiro, e continua. Ele para quando não sobra nada pronto ou quando o orçamento do dia acaba. E nunca responde uma aprovação que é minha.

Onde ele ainda erra

• Prevê os arquivos por busca de texto. Quando o código é chamado por caminhos indiretos, ele erra.
• Confia na própria nota de complexidade. Um grupo mal medido só aparece quando a execução estoura.
• Dependências que ninguém escreveu ainda param execuções em paralelo.
• Tarefas grandes ficam fora do roadmap vivo até alguém dividi-las.

O que mudou para mim

Eu virei PM. Decido o que entra e aprovo com um clique. O PO decide como e quando. O planejamento, que antes era a parte que eu fazia de cabeça entre uma sessão e outra, virou uma etapa do fluxo, com critérios escritos e motivo para cada decisão.

A regra que ficou

Largar o volante não é largar o carro. Em todo esse caminho, uma regra não mudou: a automação nunca atravessa uma aprovação humana. Nem o supervisor, nem o PO, nem o roadmap vivo. Eles propõem, organizam e executam. Quem aprova sou eu.

O próximo passo

Se a IA já dirigia de dia, faltava deixá-la dirigir à noite. No próximo capítulo, Dormi e acordei com o trabalho pronto (capítulo 3), conto a primeira noite hora a hora: o roadmap rodando em duas frentes, as dez tarefas entregues e o que eu encontrei de manhã.