Garantir que o código gerado pela IA funcione é um dos desafios que mais me interessam hoje. Eu e o Guilherme Silveira falamos muito sobre isso no nosso dia-a-dia, e recentemente vi um post do Prof Philipp Leitner formalizando a discussão, que gostei muito.

Dá pra separar esses mecanismos, que nós e a comunidade tem chamado de ‘guardrails’, de duas formas:

  • Primeiro é o “guardrail leve” (ou soft em inglês). Esse é aquele guardrail onde você define para a LLM as suas estratégias para garantir qualidade. Por exemplo, você diz pra ela, no seu prompt, arquivo de contexto, skill, etc, que ela deve sempre fazer boundary testing (prática de teste de software), que ela deve sempre garantir que todo código trate possíveis null pointers, e que ela deve sempre rodar os testes antes de marcar a tarefa como pronta. Guardrails leves são fáceis de serem criados. A LLM vai dar o seu melhor, mas sabemos que ela é não-determinística e pode “sem querer” não seguir a sua instrução.

  • O segundo é o “guardrail pesado” (ou hard em ingles). Esse é aquele onde não é possível “pular”. É a sua integração contínua garantindo que os testes rodem antes do merge. É a sua análise estática para garantir que realmente NPEs não acontecem. Esses geralmente são mais difíceis de serem implementados, especialmente se você precisa de customização.

No mundo ideal, e acredito que chegaremos lá eventualmente, guardrails via AI seriam suficientes. Mas hoje eles sozinhos não são suficientes, e portanto precisamos encontrar o balanço entre esses dois tipos de guardrails, para que possamos entregar cada vez mais código.

Referências