O código compilou, rodou 100% — e ainda assim eu pedi pra IA refazer

Pedi pra IA fazer uma melhoria numa funcionalidade — num projeto Delphi, usando GitHub Copilot no VS Code. Antes de deixar ela sair implementando, pedi o planejamento técnico da alteração — ela apresentou o plano, fez sentido, autorizei a implementação. Até aqui, tudo dentro do que eu já recomendo em outros posts aqui: planejar antes de codar.

A IA implementou. Eu buildei o projeto. Rodou 100%, sem erro nenhum.

E mesmo assim, pedi pra ela refazer parte do que tinha feito.

O que eu vi na revisão

Build verde não foi o fim da história — foi só o início da revisão. Ao conferir o código gerado, percebi que a implementação tinha criado um método novo direto na unit, sem vincular ele a nenhuma classe:

procedure ValidarCampos;
begin
  // ...
end;

Em vez de:

procedure TMinhaClasse.ValidarCampos;
begin
  // ...
end;

A diferença parece pequena, mas não é. Do jeito que a IA implementou, ValidarCampos virou uma rotina solta, acessível de qualquer lugar da aplicação que use aquela unit — sem pertencer a classe nenhuma. Mesmo sendo usado só ali, naquele contexto específico, ele nasceu exposto no nível da aplicação inteira. Funcionalmente, não tinha erro nenhum: compilava, rodava, entregava o resultado esperado. Isso é o tipo de problema que nenhum teste automatizado ou build vai pegar — só aparece pra quem lê o código com atenção.

O que eu fiz

Falei pra IA que não gostei daquela parte da implementação, expliquei o porquê, e passei a forma certa de fazer — e não deixei isso só na conversa: virou uma regra registrada, pra não precisar repetir a mesma correção depois. Mais ou menos assim:

Não crie métodos globais soltos na unit, sem vínculo com nenhuma classe. Se o método só é usado dentro daquele contexto (a própria classe, a unit, o data module etc.), implemente ele como método da classe, no escopo private. Só use o escopo public se ele realmente precisar ser chamado de fora dessa classe.

Isso é encapsulamento básico do Object Pascal (e vale, com outro nome, pra praticamente qualquer linguagem orientada a objetos): todo método deveria pertencer a uma classe, e a visibilidade dele — private ou public — deveria refletir exatamente quem precisa chamá-lo, nunca "global" por padrão. A regra em si não é novidade nenhuma pra quem já trabalha com boas práticas de POO. O que importa aqui é ela foi parar: não ficou só numa correção pontual naquele momento — virou uma instrução permanente que o Copilot passa a seguir em toda tarefa futura naquele projeto, o mesmo princípio de "documentar padrões antes de pedir código" que eu já comentei em outro post.