Construindo em Público #05 — O que aprendemos deixando a IA escrever código em produção

A IA escreve código de verdade no ClubPetro. Não como demonstração, não como brinquedo — código que roda em produção, que toca dado de cliente, que sobe no deploy da semana. Isso não é bravata nem manifesto; é só como a gente trabalha. E como qualquer forma de trabalhar, tem onde brilha e onde falha feio. Este post é a versão honesta, sem hype e sem pânico, do que a gente aprendeu.

O workflow, na prática

A IA aqui não é um autocomplete e não é um oráculo. É um par que faz o primeiro rascunho. O fluxo típico:

A pessoa define o problema e a forma. O que a feature faz, que camadas toca, onde vive a regra de negócio. Isso é decisão humana, sempre.
A IA gera o rascunho. A procedure tRPC nova, o mapeamento Drizzle, a estrutura da tela, os tipos Zod. O encanamento repetitivo que ela faz rápido e correto.
A pessoa revisa como se fosse código de outra pessoa. Porque é. A revisão não é opcional e não é diferente do rigor que a gente aplicaria a um PR de um colega.
Os quality checks e o CI seguram o resto. Lint, typecheck, build, mais uma revisão de código feita por IA em português no PR. A máquina revisa a máquina, e o humano decide.

O ponto central: a IA acelera a produção, ela não assume a responsabilidade. Quem faz merge é dono do que fez merge, tenha escrito cada linha à mão ou não.

Onde ela brilha

Sendo justo com a ferramenta, ela é boa de verdade em algumas coisas:

Boilerplate. Uma procedure tRPC nova segue um padrão. O mapeamento de uma tabela para tipos segue um padrão. A IA reproduz padrão sem cansar e sem errar de digitação. É onde ela mais poupa tempo.
O primeiro rascunho de uma tela. Ela monta o esqueleto de um componente rápido, o que deixa a pessoa focar no que importa — o comportamento, os estados, o fluxo — em vez de posicionar div.
Exploração. "Que jeitos existem de resolver isso?" Ela cospe três abordagens em segundos, e ver as opções lado a lado ajuda a decidir melhor do que partir direto para a primeira ideia.
Trabalho mecânico em escala. Renomear um conceito, aplicar um padrão em muitos arquivos, traduzir uma estrutura de um formato para outro. Tédio para humano, trivial para IA.

Nessas frentes, deixar a IA fazer o primeiro passe é ganho puro.

Onde ela falha

E aqui a honestidade importa, porque é onde time inexperiente se machuca:

Contexto que não está no arquivo. A IA não sabe que aquela tabela tem drift entre o schema TypeScript e o banco real. Ela confia no tipo gerado, escreve a query "correta", e a query volta vazia em produção. O conhecimento que mora na cabeça do time, não no código, ela não tem.
Casos de borda. Ela escreve o caminho feliz lindamente. O que acontece quando o dado vem nulo, quando a rede não tem health score ainda, quando duas coisas competem pelo mesmo recurso — é aí que ela chuta com confiança, e é aí que software quebra.
Gosto. Ela sugere dez colunas quando quatro bastam. Ela usa cor Tailwind crua em vez do token semântico. Ela adora over-engineering: uma abstração elegante para um problema que não existe. Saber o que cortar é julgamento, e julgamento ela não tem.
Efeito colateral perigoso. Deixada solta perto de operações destrutivas — uma migration, um db:push, um comando que apaga dado — ela executa com a mesma calma com que renomeia uma variável. É por isso que essas fronteiras têm supervisão humana obrigatória, sempre.

O padrão é claro: a IA é forte onde o problema é padrão e o contexto está no texto; ela é fraca onde o problema exige conhecimento tácito, faro, ou noção de consequência.

Como a gente fica no controle

A resposta não é "usar menos IA" nem "confiar mais na IA". É desenhar o sistema para que o erro dela seja barato e visível:

Domínio como função pura. Quando a lógica de negócio não tem I/O, uma mudança da IA não tem efeito colateral escondido. O raio de dano é pequeno.
Camadas com fronteira clara. A IA mexe numa procedure sem poder, por acidente, corromper o design system ou o acesso a dados.
Revisão como se fosse de humano. Nenhum código entra sem alguém dono dele ter olhado e entendido.
CI que não perdoa. Typecheck, lint, build e revisão automática pegam a classe de erro que a IA mais comete: a mudança que parece certa e não é.

A lição de fundo é que a IA muda quem escreve o rascunho, não quem responde pelo resultado. A responsabilidade continua sendo humana, e o trabalho de julgamento — o que cortar, do que desconfiar, o que jamais deixar automatizado — fica mais importante, não menos.

O builder que prospera aqui não é o que teme a IA nem o que a idolatra. É o que a trata como o que ela é: uma alavanca poderosa que amplifica tanto o bom julgamento quanto o ruim. Se o seu julgamento é bom, ela te deixa voar. E cuidar desse julgamento vira, no fim, o trabalho mais humano de todos.