Agente de código na prática: um app Android do código à Google Play

Muito do que se escreve sobre agentes de código fala de produtividade em abstrato. Este artigo conta um caso concreto: o Diário do Professor, um app Android para professores controlarem chamada, notas e frequência das próprias turmas, construído com um agente de código e levado à Google Play, onde hoje está em teste fechado. O projeto tem 115 testes automatizados, funciona sem internet e já passou por cinco versões enviadas à loja.

Este artigo faz parte da trilha Aprenda IA construindo software. O objetivo não é mostrar que o agente faz tudo, e sim onde ele acelera, onde ele erra e onde o papel de quem revisa é insubstituível.

O ponto de partida: decisões que o agente não toma

Antes de qualquer código, vieram as decisões de produto. O app é uma ferramenta pessoal do professor, paralela ao diário oficial da escola. Funciona sempre offline, com tudo guardado em SQLite no aparelho, porque a queixa mais comum sobre os sistemas oficiais é lentidão e dependência da internet da escola. Não tem conta nem login, para o suporte ficar perto de zero.

Essas decisões foram escritas no arquivo de instruções do projeto como princípios que não podem ser violados. Isso importa: um agente, sem orientação, tende a acrescentar o que parece boa prática genérica, como sincronização em nuvem ou cadastro de usuário. Com os princípios escritos, ele passa a recusar essas sugestões por conta própria. O artigo sobre CLAUDE.md e AGENTS.md explica como montar esse arquivo.

O ciclo de trabalho

Cada funcionalidade passou pelo mesmo ciclo: descrever o que se quer, deixar o agente ler o código existente e propor um plano, revisar o plano, deixar o agente implementar e testar, revisar o resultado. A parte que mais rendeu foi separar o código em duas camadas. As regras de negócio, como cálculo de média, frequência e situação do aluno, ficam em módulos puros, sem React, sem banco e sem Expo. As telas e o acesso ao banco ficam em outra camada.

Essa separação permitiu testar as regras com o executor de testes nativo do Node, sem emulador, em segundos. E foi aí que o agente mais acelerou: escrever o teste de uma regra de recuperação ou de arredondamento de nota, rodar, ver falhar, corrigir. Ao final, 115 testes cobrem as regras de domínio, os relatórios exportados e a lógica de cobrança.

O que o agente fez bem

• Volume com consistência. Telas, migrações de banco, exportação de relatórios em PDF e planilha, backup e restauração, tudo seguindo o mesmo padrão de código do restante do projeto.
• Testes junto com o código. Cada regra nova chegava com testes, inclusive para casos de borda que costumam ficar de fora.
• Explicar a própria mudança. Cada alteração vinha com o porquê, o que facilitou a revisão e virou mensagem de commit.
• Preparar o que ainda não podia ser ligado. A cobrança por assinatura foi implementada inteira e deixada desligada por uma constante, à espera de uma pendência cadastral da conta na loja. O código está pronto e testado; ligar é mudar um valor.

Onde a revisão humana foi indispensável

Os dois erros mais caros do projeto tiveram a mesma natureza: não estavam no código que alguém escreveu, e sim no que as dependências acrescentaram sozinhas.

Primeiro: a câmera

Para o professor poder tirar a foto do aluno, o app passou a usar a câmera. A biblioteca acrescentou a permissão de câmera ao manifesto do Android. Para a Google Play, uma permissão de câmera sem a declaração de que o recurso é opcional significa que o aparelho precisa ter câmera. Resultado: a versão nova deixou de ser compatível com parte dos tablets. Nenhum teste pegou isso, porque nenhum teste olha para o manifesto final. Quem pegou foi a tabela de alterações nos dispositivos compatíveis, que a Play Console mostra antes de salvar uma versão.

Segundo: o microfone

Duas versões depois, já com a lição da câmera aprendida, aconteceu de novo por outro caminho. A biblioteca de escolha de imagem acrescentou, por padrão, a permissão de gravar áudio, pensando em quem grava vídeo. O app nunca grava vídeo. Mesmo assim, a permissão tornou o microfone obrigatório, e a versão perdeu compatibilidade com 6 modelos de telefone e 10 de tablet. De novo, todos os testes passavam. De novo, foi a tabela da Play Console que mostrou.

A correção foi uma linha de configuração para remover a permissão. A lição foi maior: depois de acrescentar qualquer dependência, conferir as permissões e os recursos de hardware do manifesto final antes de gerar o pacote. No Expo, o comando npx expo config --type introspect mostra o manifesto como ele vai ficar. Essa conferência virou regra escrita no arquivo de instruções do projeto, para nenhuma sessão futura repetir o erro.

O ponto aqui não é que o agente errou. Uma pessoa sem essa experiência teria errado igual. O ponto é que o agente acelera tanto a escrita de código que a etapa de revisão vira o gargalo, e é nela que estão os riscos que nenhum teste unitário cobre: o que vai para a loja, o que o usuário vê, o que as regras da plataforma exigem. O artigo sobre permissões no app React Native trata do tema em detalhe.

O que continuou sendo decisão humana

• O recorte do produto e o que fica de fora.
• O preço e o que é grátis para sempre.
• Conferir a tabela de dispositivos e a ficha da loja antes de cada envio.
• Commit, envio para revisão e publicação. O agente prepara; quem publica é o dono do app.
• Os textos de privacidade e o formulário de segurança dos dados da loja.

Erros comuns ao trabalhar com agente num app

• Confiar que teste passando significa pacote correto. O manifesto, os ícones, as permissões e a configuração de build ficam fora dos testes de unidade.
• Deixar o agente acrescentar dependência sem perguntar o que ela traz junto.
• Não escrever as lições. Sem o arquivo de instruções, o mesmo erro volta na próxima sessão.
• Revisar só o diff. Algumas mudanças só aparecem no artefato final, como o pacote gerado.

Checklist antes de enviar uma versão para a loja

• Testes e checagem de tipos passando.
• Manifesto final conferido: permissões e recursos de hardware exigidos.
• Número da versão incrementado.
• Pacote gerado com o perfil de produção certo. Veja ambientes e build profiles no app.
• Tabela de dispositivos compatíveis sem perdas inesperadas.
• Ficha da loja, privacidade e segurança dos dados coerentes com o que o app faz. Veja app review, privacidade e metadata.
• Lição nova registrada no arquivo de instruções, se houve alguma.

Para continuar

Se você vai trabalhar com agente no seu projeto, comece pelo arquivo de instruções. Para a revisão do que ele entrega, leia como revisar código gerado por IA antes do deploy. E para o panorama de produtividade e risco, IA no desenvolvimento: produtividade sem revisão vira risco.