A IA pode escrever o código. Não pode responder por ele.

Os agentes de programação podem preparar código, testes e documentação. A equipe ainda precisa entender as mudanças e decidir se elas devem entrar no produto. Na Sophilabs, usamos ferramentas de IA junto com especificações escritas, revisão de engenharia e verificações automatizadas.
O modelo e o contexto que ele recebe influenciam o resultado. As permissões concedidas e a forma de revisar o trabalho também influenciam.
O que precisa de revisão
Um agente pode usar uma API que não existe, escrever um teste que repete uma premissa incorreta ou alterar arquivos fora do escopo previsto. São motivos para revisar o trabalho com base nos requisitos. A orientação do GitHub sobre agentes de programação também recomenda revisar e validar os resultados.
O que se mantém
A especificação vem primeiro e fica no repositório. Registre o comportamento esperado, os casos-limite relevantes e os critérios de aceitação. “Adicione exportação para CSV” deixa decisões sobre dados, acesso e erros em aberto. Mantenha a especificação versionada junto ao código para que a intenção e a implementação sejam revisadas juntas.
Um engenheiro revisa a mudança. Verifique o que o código faz, as premissas que ele usa e os arquivos que altera. A revisão deve acompanhar o risco: uma mudança na autorização exige uma atenção diferente de uma correção de texto. Mantenha as mudanças pequenas o suficiente para que a pessoa que as revisa consiga entendê-las.
Os testes verificam os requisitos. Um agente pode preparar casos de teste; um engenheiro revisa os resultados esperados e o que ficou sem cobertura. Inclua casos de falha e comportamentos que a implementação pode tratar incorretamente. Uma suíte aprovada só informa sobre as verificações que executou.
As verificações rodam no pipeline de entrega. Combine os testes, as verificações de tipos, os linters e as análises de segurança de que o projeto precisa e quais resultados bloqueiam um merge ou um deploy. Deixe os resultados disponíveis para quem revisa. As verificações automatizadas ajudam a encontrar problemas; elas não resolvem todas as decisões de publicação.
A observabilidade começa no plano de entrega. Defina quais erros e comportamentos precisam de monitoramento, quais dados podem ser registrados e quem investiga os alertas. Documente como identificar a versão publicada e se recuperar de uma mudança que falhou. A detecção e a resposta dependem desses acordos.
As verificações de licença e procedência continuam necessárias. Sugestões geradas podem coincidir com código de repositórios públicos. Ferramentas como as referências de código do Copilot podem mostrar correspondências e informações de licença disponíveis. Revise a fonte e os requisitos de licença aplicáveis conforme as políticas do projeto.
As permissões fazem parte do escopo. Combine quais arquivos, comandos, dados e serviços externos o agente pode usar. Defina quais ações exigem aprovação, incluindo merge e deploy. Ferramentas como o Claude Code oferecem controles de permissão; a configuração precisa refletir as regras acordadas para o projeto.
Um nome em cada entrega. Registre quem revisa e aprova a mudança, quem faz o deploy e quem atende aos problemas em produção. Essas responsabilidades são das pessoas que trabalham no sistema.
Como isso funciona na prática
Considere um exemplo ilustrativo: exportar para CSV um relatório de um cliente. A especificação define as colunas, quais registros o usuário pode exportar e o que acontece se o resultado estiver vazio ou o acesso for negado.
Um agente prepara a mudança em uma branch e executa os testes permitidos. Um engenheiro revisa a exportação e seus controles de acesso. Os testes incluem uma solicitação que deve ser rejeitada porque os registros pertencem a outro cliente. As verificações acordadas rodam antes de integrar a mudança. O deploy segue o processo de aprovação da equipe.
Também é preciso combinar para onde o código e os dados podem ir. Já usamos a Sophilabs Inference em um projeto de cliente. Para outro projeto, revisamos a adequação do modelo, os fluxos de dados permitidos, os controles de acesso e as necessidades de operação antes de escolher um ambiente. Isso inclui verificar os endpoints, os registros, a retenção e as condições de uso dos dados.
As permissões e a revisão são acordadas para cada tipo de mudança. Os resultados de trabalhos anteriores podem contribuir para essa conversa. Alterar as regras exige uma decisão explícita da equipe responsável pelo sistema.