Um sistema Delphi que funciona há anos não é uma folha em branco. Ele reúne decisões, componentes, integrações e comportamentos que nem sempre estão registrados em um documento. Quando pedimos à IA para melhorar uma rotina, a sugestão pode parecer elegante e ainda assim remover uma exceção importante, mudar uma assinatura usada por outro módulo ou depender de um recurso que o ambiente não oferece.
Este é o quarto capítulo da série IA na prática: do protótipo à operação responsável. Vamos transformar o contexto e as instruções anteriores em um fluxo de trabalho: compreender o ambiente, delimitar uma mudança, proteger o comportamento e revisar a evidência produzida. O objetivo não é impedir a evolução, mas torná-la examinável antes de chegar ao usuário.
Se sua rotina envolve melhorar um sistema que não pode parar, Delphi Vivo aprofunda a modernização incremental: diagnóstico de dependências, compilação reproduzível, proteção de comportamentos com testes, separação de responsabilidades e retorno seguro de uma mudança. Conheça a proposta e leia a degustação gratuita para avaliar como organizar esse percurso sem começar por uma reescrita. Para descrever exatamente o que a IA pode alterar e como verificar a entrega, SDD em Delphi complementa a leitura com requisitos, contratos e critérios de aceite.
O paradigma: apoiar a mudança, não delegar o entendimento
Um modelo de linguagem produz respostas a partir das informações disponíveis e de padrões aprendidos. Um agente de programação acrescenta ferramentas para consultar arquivos, propor alterações e, quando autorizado e configurado para isso, executar verificações. A presença dessas ferramentas não significa que o agente conheça automaticamente as regras do seu produto.
Minha proposta é manter separadas três coisas: a intenção do responsável pelo sistema, a hipótese apresentada pela ferramenta e a evidência obtida no ambiente. Uma resposta convincente é uma hipótese de solução. Ela se torna uma alteração aceitável somente quando atende aos critérios definidos e passa pelas verificações pertinentes.
Isso muda a primeira pergunta. Em vez de solicitar “modernize este módulo”, comece por “explique este caminho de execução e indique o que ainda precisa ser confirmado”. A ferramenta pode localizar dependências, mas uma explicação sobre um arquivo não comprova que todos os caminhos do produto foram examinados.
No capítulo sobre engenharia de contexto, discutimos a seleção das informações necessárias. Aqui, essa seleção ganha um destino concreto: permitir uma mudança pequena sem transformar o desconhecido em autorização para reorganizar o sistema inteiro.
Primeiro, estabeleça um ponto de comparação
Antes de alterar código, registre qual versão do projeto será usada, como ele é compilado e quais verificações já existem. Compilação é a transformação do código-fonte em um programa ou biblioteca. Um resultado anterior bem-sucedido não demonstra que o ambiente atual consegue reproduzir a entrega nem que a próxima mudança permanecerá compatível.
Inclua a versão efetiva do compilador, a plataforma de destino e as dependências relevantes. Uma aplicação Win32 e uma aplicação Win64 podem exigir verificações diferentes. Não basta escrever “Delphi instalado”: componentes adicionais, caminhos de bibliotecas e configurações do projeto também fazem parte das condições de execução.
Faça a compilação antes da mudança quando isso estiver disponível. Se o projeto já falha, registre a falha e não a atribua automaticamente à IA depois. O ponto de comparação permite separar um problema prévio de uma regressão, isto é, um comportamento que deixa de funcionar após uma alteração.
No exemplo preparado para este artigo, o ambiente respondeu com o compilador Delphi para Win32, versão 30.0. O programa mínimo foi compilado e executado em 2 de outubro de 2026. Isso demonstra apenas a execução daquele exemplo naquele ambiente; não demonstra compatibilidade com todos os projetos Delphi nem substitui testes no ambiente de cada equipe.
Escolha uma mudança que caiba em uma revisão
Considere um caso fictício: uma importação permite registrar um nome formado apenas por espaços. A equipe quer impedir esse caso sem modificar o nome que será armazenado, sem alterar o formato do arquivo e sem mudar a persistência. Persistência é o mecanismo que mantém os dados, normalmente em um banco.
O escopo parece pequeno, mas já contém decisões importantes. Validar o campo e reescrever seu conteúdo são operações diferentes. Se a IA incluir uma normalização que remove espaços do valor armazenado, terá ultrapassado a demanda, mesmo que a tela pareça funcionar melhor depois.
Escreva os critérios de aceite, as condições usadas para decidir se a tarefa foi atendida. Neste exemplo: texto vazio é inválido; somente espaços comuns é inválido; um nome com letras é válido; espaços ao redor não invalidam o nome; a função não modifica a entrada. Não estamos definindo uma política completa para nomes ou para todos os caracteres Unicode.
Explique também o que não pode mudar. Não haverá migração de banco, biblioteca nova, alteração da assinatura pública da importação ou gravação durante a prévia. Essas restrições fazem parte do contrato que a revisão precisa conferir. Se surgirem casos ambíguos, a decisão deve voltar ao responsável pelo requisito.
Consulte o caminho completo, não apenas a linha suspeita
Peça à IA para localizar onde o campo entra, onde é validado e onde é usado depois. Em aplicações com interface VCL, biblioteca visual do Delphi para Windows, uma regra pode aparecer tanto no evento de uma tela quanto em uma rotina de processamento. Não suponha que corrigir a tela proteja uma importação que passa por outro caminho.
O resultado esperado dessa inspeção é um mapa pequeno, com arquivos e chamadas relevantes, acompanhado das dúvidas restantes. Se a ferramenta não encontrou a implementação de um componente, essa ausência deve ser registrada. Não aceite uma descrição inventada para preencher a lacuna ou uma conclusão sem indicação de onde foi observada.
Evite entregar credenciais, documentos de clientes ou uma cópia indiscriminada do banco para facilitar a investigação. Use entradas sintéticas que reproduzam o problema. Quando um exemplo depende de um dado real, descreva a característica necessária e prepare uma amostra autorizada, preservando apenas o que importa para o teste.
As regras permanentes podem ficar nas instruções do projeto e procedimentos reutilizáveis. A solicitação atual precisa explicar seu próprio resultado e seus limites. Um arquivo de orientações não substitui a especificação da mudança nem o controle técnico de acesso aos recursos.
Um exemplo mínimo, separado da interface
Para demonstrar a parte isolada do problema, usamos uma função que responde se o nome atende ao critério descrito. Ela não grava dados, não acessa componentes visuais e não altera o parâmetro. O trecho abaixo integra o programa mínimo compilado e executado; a conexão com um ERP real permanece uma proposta, não uma integração testada.
function NomeValido(const Valor: string): Boolean;
begin
Result := Trim(Valor) <> '';
end;A função usa Trim, disponível em System.SysUtils no ambiente ensaiado. A verificação executada abrangeu quatro entradas: cadeia vazia, três espaços comuns, Ana e Ana. Os resultados esperados foram, respectivamente, falso, falso, verdadeiro e verdadeiro. O programa encerrou normalmente e informou quatro verificações aprovadas. Essa descrição é resultado do ensaio próprio, não de um desempenho anunciado pelo fornecedor.
Essa evidência é deliberadamente estreita. Não avaliamos caracteres invisíveis, limites de tamanho, nomes internacionais, arquivos malformados ou a interação com o banco. Se o requisito exigir esses casos, eles precisam ser definidos e acrescentados à verificação. Um teste pequeno bem descrito é mais útil do que uma alegação ampla de que a rotina está pronta.
Em uma base real, examine os pontos de chamada antes de extrair ou substituir a regra. Separar uma função pode facilitar o teste, mas mover código também pode alterar dependências e ordem de execução. Faça a extração como uma etapa própria quando a equipe não consegue revisar com clareza a extração e a mudança de comportamento juntas.
Peça uma proposta antes de pedir a alteração
Um pedido adequado pode solicitar: “Localize a validação atual, indique os arquivos que precisariam mudar e proponha uma alteração mínima para rejeitar nomes vazios ou compostos apenas de espaços comuns. Preserve o valor original, a persistência e as interfaces públicas. Não implemente ainda; apresente dúvidas e casos de verificação.”
Esse texto é um exemplo de solicitação, não um comando executado sobre um sistema real. Ele coloca a análise antes da edição. A equipe pode descobrir que o problema está no processamento posterior ou que uma regra compartilhada deve ser corrigida em vez de duplicada. A proposta também permite examinar alternativas sem aceitar a primeira solução produzida.
Depois de aprovar o plano, autorize somente o escopo necessário. A ferramenta deve apresentar o que mudou e o que foi verificado. Se aparecer uma necessidade nova, como alterar uma estrutura de dados pública, interrompa aquela parte e decida explicitamente. Uma dificuldade técnica não amplia sozinha a autorização concedida.
Fluxo proposto neste artigo, sem dados quantitativos. Cada passagem exige uma decisão verificável; o desenho não representa uma integração executada em um ERP.
Revise as diferenças e a evidência
O controle de versões permite comparar o estado anterior e o atual. Essa comparação, frequentemente chamada de diff, mostra linhas adicionadas, removidas ou modificadas. Leia as diferenças completas, incluindo arquivos auxiliares. Uma mudança aparentemente localizada pode vir acompanhada de ajustes de configuração que alteram a compilação ou uma dependência.
Confira se os critérios foram implementados e as restrições respeitadas. Pergunte também o que não foi testado. Compilar verifica determinadas propriedades do código e das dependências, mas não demonstra, sozinho, que o usuário obterá o resultado esperado. Executar quatro entradas não demonstra que a importação inteira está correta.
Para organizar uma suíte, um conjunto de testes, o DUnitX oferece testes identificados por atributos, asserções e preparação e encerramento de casos. Asserção é uma verificação que compara uma condição com o resultado esperado. Este artigo não instalou nem executou DUnitX; o ensaio mínimo usou um programa de console próprio.
Ao revisar testes propostos pela IA, os resultados esperados devem vir do requisito. No caso fictício, esperar que Ana seja rejeitado só porque a implementação produz falso esconderia uma falha em vez de detectá-la. O próximo capítulo aprofunda essa diferença entre executar um teste e produzir evidência útil.
Controle também a entrega e o retorno
Uma alteração aprovada ainda precisa chegar ao ambiente correto. Registre o que será entregue, quem autoriza a implantação e como verificar o comportamento depois. Não transforme a conclusão da edição em permissão automática para distribuir executáveis ou executar operações em produção. A liberação continua sendo uma decisão sobre risco e responsabilidade.
Planeje a reversão, frequentemente chamada de rollback: o caminho para voltar a uma versão anterior ou desfazer efeitos da mudança. Reverter código não desfaz necessariamente dados gravados. Uma tarefa que inclui migração, escrita no banco ou comunicação externa exige planejamento distinto do exemplo isolado deste artigo, incluindo consequências que não desaparecem ao restaurar arquivos.
Trate conteúdos consultados como informação, não como novas ordens. A OWASP descreve a injeção indireta de instruções em fontes externas. Um comentário encontrado durante a análise não deve autorizar envio de dados ou ampliar acesso. Instruções ajudam a orientar; permissões e aprovações precisam existir no sistema de execução.
Conclusão
Usar IA em um projeto Delphi existente não exige começar por uma grande reorganização. O caminho proposto é estabelecer um ponto de comparação, escolher uma mudança pequena, explicitar o contrato e revisar tanto o código quanto a evidência. A ferramenta pode ajudar em cada etapa, mas não substitui a decisão sobre o que o sistema deve preservar.
O exemplo compilado demonstra uma função e quatro casos, não um ERP validado. Essa distinção é a principal lição prática: declare exatamente o que foi inspecionado, executado e aprovado. Assim, a velocidade de produzir uma sugestão deixa de esconder o trabalho necessário para transformar essa sugestão em uma entrega confiável.
Quando a mudança pequena revelar dependências ou comportamentos sem proteção, o desafio passa a ser recuperar a capacidade de evoluir o sistema. Delphi Vivo desenvolve diagnóstico, testes, separação de responsabilidades e entrega reversível. Consulte o sumário e a degustação gratuita para avaliar esse percurso de modernização antes de ampliar o escopo da alteração.
Referências
OWASP FOUNDATION. LLM01:2025 Prompt Injection. OWASP Gen AI Security Project, [s. d.]. Disponível em: https://genai.owasp.org/llmrisk/llm01-prompt-injection/. Acesso em: 2 out. 2026.
SILVEIRA, Régys Borges da. AGENTS.md, instruções e skills: como orientar uma IA dentro do projeto. regys.com.br, [s. d.]. Disponível em: https://regys.com.br/agents-md-instrucoes-e-skills-como-orientar-uma-ia-dentro-do-projeto/. Acesso em: 2 out. 2026.
SILVEIRA, Régys Borges da. Delphi Vivo. Livros de Régys Borges da Silveira, [s. d.]. Disponível em: https://livros.regys.com.br/delphi-vivo. Acesso em: 2 out. 2026.
SILVEIRA, Régys Borges da. Engenharia de contexto: por que um bom prompt não basta para programar com IA. regys.com.br, [s. d.]. Disponível em: https://regys.com.br/engenharia-de-contexto-por-que-um-bom-prompt-nao-basta-para-programar-com-ia/. Acesso em: 2 out. 2026.
SILVEIRA, Régys Borges da. SDD em Delphi. Livros de Régys Borges da Silveira, [s. d.]. Disponível em: https://livros.regys.com.br/sdd-em-delphi. Acesso em: 2 out. 2026.
VSOFT TECHNOLOGIES. DUnitX. GitHub, [s. d.]. Disponível em: https://github.com/VSoftTechnologies/DUnitX. Acesso em: 2 out. 2026.
0 comentário(s)