Como validar código de IA com Django e CI

Introdução

Para otimizar o desenvolvimento de sistemas utilizando IA, precisamos tomar alguns cuidados. Em meus estudos, percebo que ferramentas e modelos de inteligência artificial recebem grandes atualizações em pouco tempo. Atualmente estou testando o modelo GPT Luna 6 no modo xhigh. Minha impressão até agora é que um modelo com preço bastante agressivo (barato) tem apresentado excelentes resultados.

Criar aplicações com IA ganha robustez quando combinamos a ferramenta com metodologias e frameworks já conhecidos no mercado. Django e PostgreSQL são ecossistemas maduros e ajudam a resolver problemas comuns, mas ainda é preciso cuidar do código, das configurações e das regras de negócio.

A IA pode validar o próprio código?

A IA traz flexibilidade para decidir como uma função será criada, mas não garante que vai seguir um fluxo preestabelecido, como executar uma validação depois da implementação.

Um pedido como “valide se está tudo certo” não define o que significa “certo”. A IA pode interpretar que o código atende ao pedido e retornar uma validação positiva mesmo quando algo está errado. Essa resposta é uma interpretação do modelo; se estiver errada, pode ser a própria fonte do problema. Por isso, prompts desse tipo geralmente acabam virando meme.

Para reduzir essa incerteza, precisamos transformar o comportamento esperado em critérios que possam ser conferidos. Se uma função deve rejeitar uma entrada inválida, respeitar uma permissão e alterar um registro, esses casos precisam aparecer em testes ou em outras verificações executáveis.

Django, PostgreSQL e ferramentas de segurança

Frameworks consolidados ajudam, mas não resolvem todos os problemas de segurança da aplicação. O Django tem proteções para situações comuns, como consultas do ORM parametrizadas e proteção contra CSRF quando o middleware está configurado. Ainda assim, consultas SQL escritas manualmente, configurações de implantação e regras de acesso precisam de atenção. A documentação de segurança do Django explica essas proteções e seus limites.

O PostgreSQL permite controlar os privilégios associados a cada role. Isso ajuda a limitar o que uma conexão pode fazer, desde que a aplicação não use uma conta com permissões maiores do que precisa. A documentação de privilégios do PostgreSQL descreve como conceder e revogar esses acessos.

Algumas ferramentas que podem fazer parte do fluxo:

• Testes do Django (python manage.py test) verificam comportamentos descritos nos testes. Quando apropriado, podemos escrever os testes antes da implementação, como propõe o TDD. O teste precisa representar a regra certa e cobrir os casos importantes; passar não prova que todo o sistema está correto. A documentação do Django explica como escrever e executar esses testes.
• python manage.py check --deploy executa verificações de implantação do Django. Rode-o com as configurações de produção carregadas, como orienta a lista de implantação.
• Ruff ajuda a encontrar problemas estáticos e aplicar regras de lint no Python. Bandit procura padrões de código que podem indicar riscos de segurança. Semgrep permite usar regras prontas ou criar regras para padrões específicos do projeto.
• pip-audit procura vulnerabilidades conhecidas nas dependências Python. Ele não analisa a lógica da aplicação.
• ESLint analisa JavaScript de acordo com as regras configuradas, e npm audit verifica avisos conhecidos nas dependências npm. São úteis quando o projeto também tem código JavaScript; não analisam o código Django.

Cada ferramenta cobre uma parte do problema. Um teste verifica os cenários que foram escritos; um linter não executa a aplicação; e uma auditoria de dependências não encontra falhas nas regras de negócio. Os resultados precisam ser conferidos por alguém que conheça o projeto.

Do teste à revisão da alteração

Antes de pedir uma implementação, defina o comportamento esperado e os casos que precisam continuar funcionando. Depois, confira se os testes cobrem esses critérios e se falhariam caso a alteração pedida não estivesse implementada.

Quando a IA terminar, leia o diff completo. Compare os arquivos alterados com o pedido, observe mudanças em permissões, contratos e dependências e veja se os testes foram removidos ou enfraquecidos. Uma revisão feita por outro modelo pode apontar algo que passou despercebido, mas os achados ainda precisam ser conferidos no código.

Regras duradouras do repositório, como preservar um contrato ou não registrar certos dados, podem ser documentadas para o agente. No artigo Instruções para agentes de IA no projeto, explico como organizar esse contexto. Essas instruções ajudam a orientar o trabalho; os testes e as verificações executadas é que mostram se os critérios definidos foram atendidos.

MCP, harness e integração contínua

Nos meus estudos, ainda é difícil estruturar um fluxo determinístico que garanta que uma função será validada depois de criada. Definir o fluxo por MCP tem apresentado bons resultados para sinalizar ao harness quais operações executar. O MCP permite que servidores exponham ferramentas que modelos podem descobrir e chamar. A especificação atual descreve essas ferramentas como controladas pelo modelo; por isso, o protocolo sozinho não obriga uma sequência a ser executada depois de cada alteração.

Para mim, o ganho pode estar em unificar o harness com a pipeline e definir com cuidado o que precisa ser avaliado. As verificações podem ficar disponíveis ao agente durante o desenvolvimento e rodar novamente na integração contínua. Assim, a IA recebe retorno enquanto trabalha, e a pipeline executa os mesmos testes e análises antes de permitir a integração. No GitHub, por exemplo, é possível exigir que status checks passem antes do merge.

As ferramentas conectadas a dados ou capazes de alterar registros também precisam validar as entradas e aplicar controle de acesso no servidor. O modelo não deve decidir sozinho quem pode consultar uma informação ou executar uma operação.

Se um teste ou scanner falhar, a alteração não deve avançar até que alguém entenda o resultado. Isso dá previsibilidade ao processo sem tratar a resposta da IA como prova de que tudo está correto.

Conclusão

Combinar IA com Django, PostgreSQL, testes e ferramentas de análise pode ajudar no desenvolvimento, desde que cada ferramenta seja usada para o que consegue verificar. O modelo pode contribuir com a implementação, mas a equipe ainda precisa definir o comportamento esperado, revisar a alteração e manter critérios objetivos de validação.

Talvez o profissional passe a dedicar mais tempo a garantir que o código esteja bem implementado, inclusive na camada de integração contínua. Nos meus estudos, esse fluxo parece mais confiável quando o harness orienta as operações e a pipeline executa as verificações que não podem ser ignoradas.

Referências

• Django: Security in Django, Writing and running tests e Deployment checklist. Consultadas em 16 out. 2026.
• PostgreSQL: Privileges. Consultada em 16 out. 2026.
• Astral: Ruff Linter. Consultada em 16 out. 2026.
• PyCQA: Bandit. Consultada em 16 out. 2026.
• Semgrep: Rule ideas. Consultada em 16 out. 2026.
• Python Packaging Authority: pip-audit. Consultada em 16 out. 2026.
• ESLint: About ESLint. npm: npm audit. Consultadas em 16 out. 2026.
• Model Context Protocol: Tools e Security Best Practices. Consultadas em 16 out. 2026.
• GitHub Docs: About protected branches and required status checks. Consultada em 16 out. 2026.