por Danilo Silva
Contexto
Começamos pelo uso mais simples possível: pedir um trecho de código à IA, ler o que voltava e corrigir à mão o que não servia. Aprendemos com os erros e os acertos, o que nos permitiu evoluir as regras de funcionamento dos agentes e dos workflows. Assim, o processo amadureceu aos poucos, até chegar ao fluxo que usamos hoje.
O contexto pesa. O trabalho envolve dados sensíveis, e, nesse terreno, um vazamento não é um defeito a corrigir na próxima versão; é uma quebra de confiança que nenhuma versão seguinte desfaz. Por isso, a pergunta que me interessava nunca foi se a IA escreve código mais depressa. A pergunta era se ela consegue trabalhar dentro de controles de segurança rígidos, e quanto custa garantir que trabalhe.
Este texto não é um benchmark nem uma recomendação de ferramenta. É o registro de uma experiência, com o que funcionou, o que falhou e o que ainda não sei responder. Detalhes do projeto e nomes de sistemas e servidores ficaram de fora de propósito.
Como o processo amadureceu
No início, a divisão era simples: a IA escrevia e nós revisávamos. Aos poucos, o caminho foi ganhando etapas: especificações antes do código, revisores automatizados no meio e pontos fixos em que só uma pessoa decide. Hoje a IA escreve a maior parte do código e dos documentos, mas quase nada chega ao repositório sem percorrer esse caminho inteiro. Os números ajudam a dar a escala:
O fluxo atual se apoia em quatro práticas, que não nasceram juntas; foram entrando uma a uma, quase sempre depois de algum tropeço:
- Especificação antes do código. Cada entrega começa por um documento com requisitos, critérios de aceite e decisões registradas. Quando há conflito, a especificação aceita vale mais do que qualquer outro texto, inclusive o arquivo de contexto que a IA lê ao começar cada sessão.
- Agentes especializados. Um agente planeja, outro implementa em C#, outros revisam segurança, qualidade, desempenho e testes. Cada um tem papel, ferramentas e limites escritos.
- Modelo por tipo de tarefa. O modelo maior faz o plano; o intermediário escreve e revisa o código; o menor faz edições mecânicas em documentos. O motivo é custo de uso da IA, e a versão de cada modelo fica fixa para o comportamento não mudar sozinho.
- Paralelismo com isolamento. Tarefas independentes correm ao mesmo tempo, cada agente na sua própria cópia do repositório e com uma fronteira explícita de arquivos. Nenhum agente faz commit: a integração, a suíte completa de testes e as revisões acontecem no fim, na sessão principal.
Vale ler o fluxo em duas linhas. Na de cima, os agentes de IA trabalham; na de baixo, a entrega é conferida e liberada.
- Especificação aprovada. Nenhum código começa sem um documento de requisitos e critérios de aceite aprovado por uma pessoa.
- Plano e segunda opinião. Um agente transforma a especificação em passos, e uma segunda opinião, que descrevo adiante, aponta riscos e lacunas antes que qualquer linha seja escrita.
- Implementação em cópias isoladas. Cada agente trabalha na sua própria cópia do repositório, sem alcançar o trabalho dos outros e sem permissão para commit.
- Revisões de segurança. Agentes revisores, distintos de quem escreveu, procuram vulnerabilidades e problemas de qualidade. O que encontram volta para a implementação (a seta “achados corrigidos”) até não restar achado relevante.
- Integração e suíte completa. A sessão principal junta o trabalho das cópias e roda todos os testes de uma vez, porque partes que passam sozinhas podem falhar quando o código é unificado.
- Decisão humana. Uma pessoa lê o resultado, os achados e os riscos que sobraram, e aprova ou devolve. É o único ponto do fluxo que nenhum agente pode contornar.
- Commit e push. Só acontecem depois da aprovação.
- Homologação. O build é disparado à mão, a análise estática de segurança (SAST, a leitura automática do código em busca de vulnerabilidades) e de qualidade roda na esteira, e a entrega é testada no ambiente real.
A segunda opinião
Ajustamos o fluxo para consultar uma segunda opinião em alguns pontos específicos: antes do plano, antes da implementação e antes da entrega. Ela vem de um tipo diferente de modelo, e é justamente essa diferença que a torna útil. Em vez de conversar ou redigir, ele responde a perguntas fechadas com números:
- Sim ou não: a probabilidade de a resposta ser sim.
- Escolha: um peso para cada opção de uma lista.
- Nota: uma posição numa escala, com os critérios de cada nível definidos por nós.
Cada resposta vem acompanhada do grau de confiança do próprio modelo. A lógica lembra a de uma agência de rating: ela não diz o que fazer, mas atribui uma nota e declara o quanto confia nela. Mandamos um resumo sanitizado da tarefa, sem código, dado sensível ou segredo, junto com perguntas como estas:
Uma resposta típica soa assim: a estratégia de testes é suficiente com probabilidade de 0,29, ou seja, provavelmente não; o que mais reduziria o risco seria injetar falhas aleatórias (0,51); e tudo isso com confiança baixa. Naquele caso, a sugestão entrou no plano de testes.
Números são fáceis de comparar entre rodadas e de registrar, mas não substituem a análise. O modelo nunca decide. Uma regra escrita sempre vale mais do que a resposta dele, e cada rodada fica registrada com o custo em tokens, para que a pergunta “isso compensa?” seja respondida com dados, e não com impressão.
Segurança: o que a IA ajudou a construir
A regra que orientou todo o trabalho foi escrita cedo e nunca mudou: entre o mais simples e o mais seguro, escolhe-se o mais seguro, e o trade-off fica registrado. A IA seguiu essa regra com disciplina sempre que ela estava escrita. Quando ficava implícita, não.
Os controles abaixo foram especificados, implementados e testados com apoio dos agentes. Um deles, a falha fechada, merece tradução: funciona como a catraca de um prédio corporativo, que não abre para quem não está na lista, mesmo que ninguém tenha proibido aquela pessoa de entrar.
Parte dos ganhos não veio de quem escreveu o código, mas de quem o revisou. Por exemplo, um agente revisor apontou que o caminho bruto da URL, controlado por quem faz a chamada, estava indo parar nos logs e na auditoria. A correção, gravar apenas o modelo da rota, sem os valores, foi aplicada em todos os serviços da família.
Outro caso foi uma vulnerabilidade de injeção de SQL percebida ainda no planejamento, antes da primeira linha de código. Uma carga de cerca de 2.000 cadastros seria gerada como script SQL a partir de outro sistema, e bastaria um nome com caracteres especiais para quebrar o script ou, pior, embutir comandos nele. A segunda opinião apontou esse como o principal risco da tarefa, e o tratamento de injeção entrou no plano.
O scan de segurança da esteira, por sua vez, pegou o que já tinha passado pelos agentes. Em um dos serviços, a ferramenta de análise de segurança apontou uma vulnerabilidade de injeção em log: um parâmetro da rota podia carregar quebras de linha e forjar linhas falsas no registro. A primeira correção, validar a entrada, já resolvia o problema na execução. Ainda assim, o scan seguinte manteve o alerta, porque a ferramenta só reconhece a limpeza explícita do valor no momento de gravá-lo. A correção definitiva foi sanitizar o valor em cada ponto de log.
No mesmo scan, a detecção de segredos encontrou uma chave de acesso em texto puro, dentro de um arquivo gerado pelo próprio pipeline, que sobrevivia no ambiente de build de uma execução para outra. O arquivo nunca foi versionado e estava fora do alcance da revisão dos agentes, que leem o código, e não o ambiente em que ele é construído. Também aqui a primeira correção não bastou: ignorar o arquivo no controle de versão não apagava o que já estava no ambiente. A solução foi limpar a pasta antes de cada scan e tratar a chave exposta como comprometida, com a troca dela.
Por fim, os testes de integração revelaram comportamentos silenciosos do banco que nenhum revisor havia previsto, como truncar valores longos sem acusar erro e converter caracteres parecidos em caracteres válidos. Os dois viraram regra de validação.
Onde a IA errou
O incidente mais sério não foi um bug. Foi um agente cumprindo a tarefa por um caminho que nenhum de nós teria autorizado. Os casos abaixo foram registrados na época, com causa e correção, e cada um deu origem a uma regra nova. Boa parte do fluxo que descrevi acima nasceu daqui.
Olhando os casos em conjunto, há um padrão. Quando a instrução deixa uma brecha, como “se houver credencial”, a IA tende a ler a brecha como permissão. Ela otimiza para concluir a tarefa, e em segurança o caminho mais curto costuma ser o errado. É o comportamento de um estagiário brilhante e ansioso por entregar: não age de má-fé, mas também não para para perguntar se deveria.
Houve também erros de registro. O arquivo de contexto chegou a descrever de forma errada uma decisão de arquitetura sobre o módulo de administração, até ser corrigido pelo responsável. Um erro num documento que a IA relê a cada sessão não fica parado no papel: ele se propaga para todo o trabalho que vem depois.
Custos e limites
A velocidade de escrever código aumentou muito; a de colocar em produção, bem menos. A maior parte das entregas está validada em homologação e ainda não chegou à produção, porque depende de passos que continuam humanos: aprovação, build disparado à mão, ajuste de infraestrutura, parecer jurídico.
- Manter o contexto custa trabalho. O arquivo que a IA lê em toda sessão cresceu com emendas datadas e trechos riscados, e a memória persistente passou de trinta registros. Mantê-los corretos virou tarefa recorrente, porque um registro desatualizado gera erro em cadeia.
- A carga de decisão passou para o humano. Cada entrega grande gerou dezenas de decisões numeradas para aprovar. O risco, aqui, é o carimbo: aprovar o plano inteiro porque ele parece bem fundamentado, como quem assina um relatório extenso depois de ler só o sumário.
- O escopo cresceu. O projeto começou pequeno e virou uma plataforma bem maior. Parte disso era necessária; parte foi facilitada pelo simples fato de construir ter ficado barato.
- Paralelismo gera dívida de integração. Chegamos a ter mais de vinte cópias de trabalho abertas ao mesmo tempo. Integrar, rodar a suíte completa e revisar continua sendo trabalho sequencial.
- Teste verde não é prova. Os agentes escrevem muitos testes, com cobertura acima de 90% em alguns pacotes, mas a classe de bug que de fato importa só apareceu contra a infraestrutura real.
Sobre a segunda opinião, o saldo é ambíguo, e prefiro dizê-lo assim. Cada rodada custou entre 600 e 1.200 tokens, um valor baixo. Em parte das rodadas, ela só confirmou o que já sabíamos. Em outras, apontou lacunas reais, como um job de banco que nunca tinha rodado no motor de destino ou a falta de injeção de falhas aleatórias. Como a confiança declarada foi baixa com frequência, ela serviu para priorizar, nunca para decidir.
As lições que tiramos
A lição central que tiramos foi tratar o agente de IA como uma identidade com privilégio, e não como uma ferramenta de edição. Pense num prestador de serviço que recebe a chave do escritório no primeiro dia: a pergunta que importa não é se ele é competente, mas quais portas faz sentido ele alcançar. Tudo que vale para uma conta de serviço passou a valer para o agente.
- Menor privilégio para o agente. Aprendemos a tratar as credenciais, as ferramentas de banco e o acesso à rede do agente com o mesmo cuidado que damos a qualquer serviço. O que ele alcança, ele pode usar.
- Proibições escritas, sem brecha. Vimos que “use se existir” acaba lido como permissão. Hoje escrevemos o que é proibido e o que fazer quando faltar algo: parar e relatar.
- Segredos fora do alcance. Nenhum agente gera, lê ou guarda uma chave. O que ele envia a serviços externos é sempre um resumo sanitizado.
- Revisão adversarial, separada da implementação. O agente que escreve não é o único que revisa. Revisores dedicados e a análise estática no pipeline pegaram problemas que a implementação não enxergava.
- Infraestrutura real antes do aceite. Passamos a planejar o primeiro deploy real como parte do teste, com rollback simples. Teste local verde não provou a integração com provedor de identidade, gateway e banco.
- Uma fonte normativa, sempre atualizada. Mantemos especificações e decisões registradas, com regra clara de precedência, porque a IA segue o que está escrito, inclusive quando está errado.
- O humano decide o que é irreversível. Commit, produção, cadastro de chave e acesso a dado real ficam com aprovação humana. Os bloqueios automáticos de permissão da ferramenta ajudaram, mas foram a última barreira, não a primeira.
Balanço
A IA tornou viável um nível de especificação, teste e revisão que, sem ela, exigiria muito mais esforço. Não reduziu a responsabilidade humana; mudou o lugar onde ela fica.
O ganho mais claro veio na quantidade e na profundidade dos controles: isolamento com falha fechada, auditoria sem dado pessoal, revisão de segurança em toda entrega. O custo mais claro foi a vigilância: manter o contexto correto, revisar decisões em volume e fechar cada brecha de instrução antes que o agente a encontre.
Restam duas perguntas que ainda não sei responder. Quanto do ganho veio da IA e quanto da disciplina que ela nos obrigou a ter? E como esse modelo se comporta em produção? Prefiro deixá-las em aberto a fingir uma certeza que não tenho; as respostas ficam para um próximo relato.
E as ferramentas? Por trás deste relato há um conjunto delas: O Claude Code com os agentes especializados, o JEV como segunda opinião antes de cada decisão, o Checkmarx e o SonarQube vigiando a esteira.
Danilo Farias da Silva é especialista em desenvolvimento de software na CG One, com atuação em engenharia de aplicações, automação, integração de sistemas e soluções com inteligência artificial. É MBA em Desenvolvimento de Software com Microsoft .NET e pós-graduação em Engenharia de Software em IA Aplicada. Tem experiência com .NET, Docker/Linux, pipelines de CI/CD e práticas de desenvolvimento seguro com Checkmarx (SAST, DAST e SCA), além de agentes de IA aplicados ao ciclo de desenvolvimento. Atua apoiando empresas no desenho e na construção de aplicações, APIs e automações seguras, com foco em qualidade, confiabilidade e eficiência operacional.