Em 17 de setembro de 2026 participei do episódio “Produtividade Pro: IA na Prática com Delphi, Lazarus e ACBr”, do Papo Pro ACBr. A conversa, com pouco mais de uma hora, passou por ferramentas, código legado, agentes, segurança e formação profissional, mas uma ideia conecta todos esses assuntos: inteligência artificial só produz ganho sustentável quando está inserida em um processo de engenharia que define o trabalho, limita o escopo e verifica o resultado.

Esse ponto merece atenção porque o debate sobre IA costuma começar pela ferramenta ou pelo chamado “prompt perfeito”. Para quem mantém um ERP em Delphi, desenvolve com Lazarus ou integra documentos fiscais por meio do ACBr, porém, o problema real raramente cabe em uma pergunta isolada. Há regras de negócio acumuladas durante anos, dependências visuais, bancos de dados, serviços externos e obrigações fiscais que não admitem uma resposta apenas plausível. Neste artigo, organizo os principais aprendizados do episódio e mostro como convertê-los em um fluxo de adoção prático, com critérios para especificação, validação, segurança e evolução da equipe.

O ponto de partida não é o prompt mágico

Modelos generativos parecem simples porque aceitam linguagem natural, mas essa facilidade de entrada pode esconder a complexidade da tarefa. Pedir “refatore esta unit” ou “adicione emissão de NFS-e” não informa quais comportamentos devem permanecer, quais versões e componentes fazem parte do ambiente, como o código se relaciona com outras camadas nem qual evidência permitirá considerar o trabalho correto. A IA preenche essas lacunas com padrões aprendidos. Às vezes acerta; em outras, entrega uma solução convincente que não respeita o sistema real.

No episódio, proponho uma estrutura de solicitação com quatro perguntas: quem executará o trabalho, o que deverá ser feito, como deverá ser feito e como o resultado será validado. O “quem” define o papel e o repertório esperado, como um desenvolvedor sênior familiarizado com ACBr e Object Pascal. O “o quê” delimita o resultado. O “como” registra arquitetura, convenções, restrições e sequência. A validação estabelece condições objetivas, como compilação sem erros, testes automatizados aprovados, análise estática dentro do limite e verificação funcional do fluxo principal.

Essa estrutura não é um truque para obter uma resposta melhor; ela recupera práticas conhecidas da engenharia de software. Antes de delegar uma mudança a outra pessoa, também precisamos explicar contexto, critérios de aceite e limitações. A diferença é que um colega pode perceber ambiguidades, fazer perguntas e reconstruir parte do conhecimento tácito. Um agente automatizado tende a avançar com o contexto disponível. Quanto maior a autonomia concedida, mais importante se torna explicitar fronteiras e mecanismos de parada.

Esse é também o tema central de SDD em Delphi: Como especificar, projetar e desenvolver software Delphi com apoio de IA. A obra aprofunda a passagem de uma demanda vaga para uma especificação verificável, conectando requisitos, regras, restrições e critérios de aceite à arquitetura, ao código e aos testes. É um complemento direto para quem deseja transformar as quatro perguntas apresentadas no podcast em uma disciplina de desenvolvimento aplicável a projetos Delphi reais.

Especificar bem permite automatizar com segurança

Um dos casos discutidos foi a migração gradual de um sistema Delphi com cerca de 22 anos. A base possuía características comuns em aplicações que cresceram por muito tempo: DataModules extensos, datasets usados diretamente pela interface e regras distribuídas entre eventos e componentes. O ganho não veio de entregar todo o repositório a um agente e pedir uma arquitetura nova. Aproximadamente cinco semanas e meia foram dedicadas à preparação dos casos, das regras e das verificações; depois, a execução automatizada permaneceu trabalhando por cerca de 78 horas.

Os números são menos importantes do que a proporção entre preparação e execução. O trabalho humano concentrou-se em compreender o comportamento existente, escolher a direção arquitetural, decompor a mudança e construir os mecanismos de validação. O agente cuidou de uma parcela extensa e repetitiva da transformação. Cada módulo só podia avançar quando compilação, testes unitários, testes de fumaça e análise pelo Sonar confirmavam o resultado esperado. Quando uma barreira falhava, a próxima etapa não começava.

Esse modo de avançar por etapas também orienta Delphi Vivo: Como modernizar sistemas existentes sem reescrever tudo. O livro trata a modernização como recuperação gradual da capacidade de mudança: primeiro tornar o comportamento observável, depois criar pontos de proteção e somente então alterar estrutura, dependências e arquitetura. É uma leitura complementar especialmente útil para equipes que reconheceram no relato do podcast os mesmos acoplamentos, formulários extensos e regras espalhadas que encontram em seus próprios sistemas.

Isso muda a leitura comum de produtividade. Digitar muitas linhas em poucos minutos não é necessariamente acelerar o projeto; pode apenas antecipar defeitos. A automação se torna valiosa quando transforma uma especificação confiável em alterações verificáveis, especialmente em tarefas repetitivas. Foi também a lógica apresentada no meu artigo sobre como adaptar um ERP em Delphi com apoio de inteligência artificial: o modelo ajuda a ampliar a capacidade da equipe, mas regras fiscais, arquitetura e critérios de aceite continuam sob responsabilidade profissional.

Código legado pode ser um bom candidato, desde que seja compreendido

Delphi e Lazarus aparecem com frequência em sistemas empresariais maduros, nos quais o valor não está apenas na linguagem, mas nas regras acumuladas. Isso não torna o código incompatível com IA. Ao contrário, tarefas como localizar padrões, criar testes de caracterização, separar responsabilidades e repetir uma transformação controlada podem se beneficiar bastante de um agente. O risco surge quando a equipe confunde código antigo com código descartável e tenta modernizar sem primeiro descobrir o que precisa ser preservado.

Uma abordagem segura começa com uma fatia vertical pequena. Escolha um fluxo representativo, registre entradas e saídas observáveis, identifique efeitos colaterais e crie testes que descrevam o comportamento atual. Em seguida, peça uma mudança limitada, revise o diff e execute as mesmas verificações. O agente não deve migrar o próximo conjunto automaticamente se o anterior não tiver passado por todas as barreiras. Esse ciclo curto torna o erro localizável e permite ajustar as instruções antes de multiplicá-lo pelo restante da aplicação.

O mesmo raciocínio vale para componentes ACBr. Uma integração fiscal envolve configurações, certificados, leiautes, regras por município ou unidade federativa e respostas de serviços externos. A IA pode ajudar a navegar pelo código, produzir estruturas iniciais ou explicar um retorno, mas a documentação oficial, os exemplos compatíveis com a versão utilizada e os testes em ambiente apropriado precisam permanecer como referência. Em Delphi na era da IA: o programador Delphi aumentado, desenvolvo essa mudança de papel: o profissional passa menos tempo em tarefas mecânicas, sem deixar de responder pelas decisões e pelo produto entregue.

Skills e agentes transformam conhecimento em processo reutilizável

Quando uma equipe descobre uma boa maneira de executar determinada tarefa, não deveria depender de alguém reescrever as mesmas instruções a cada conversa. No episódio, tratamos as skills como procedimentos reutilizáveis que ensinam ao agente como agir em um contexto: convenções do projeto, etapas obrigatórias, documentos que devem ser consultados, comandos de validação e condições em que o trabalho precisa parar. Em um projeto ACBr, por exemplo, uma skill pode orientar a identificação do componente correto, a conferência da versão, o tratamento seguro de certificados e a execução de testes sem dados reais de clientes.

Um agente, por sua vez, combina modelo, instruções, contexto e ferramentas para realizar uma sequência de ações, em vez de apenas sugerir um trecho de código. Essa capacidade exige governança proporcional: permissões mínimas, escopo de arquivos bem definido, revisão das alterações e comandos destrutivos protegidos. Também é útil separar responsabilidades. Um agente pode pesquisar a documentação, outro implementar uma alteração e um terceiro revisar testes, desde que todos trabalhem sobre critérios comuns e o responsável humano faça a síntese.

O benefício mais consistente não está em criar personagens elaborados, mas em registrar conhecimento operacional. Uma boa skill funciona como uma rotina de equipe executável e versionada. Se a arquitetura mudar, a instrução deve mudar junto; se um erro recorrente for descoberto, a proteção deve ser incorporada ao procedimento. Desse modo, o aprendizado deixa de ficar preso a um prompt perdido e passa a melhorar as próximas tarefas.

MCP aproxima a IA dos sistemas, mas amplia a responsabilidade

Outro tema da conversa foi o Model Context Protocol, ou MCP. A documentação oficial define o MCP como um padrão aberto para conectar aplicações de IA a sistemas externos, incluindo dados, ferramentas e fluxos de trabalho. Em termos práticos, ele pode oferecer ao agente uma interface controlada para consultar informações ou executar funções, sem depender de copiar manualmente grandes quantidades de conteúdo para uma conversa.

Em um ERP, isso abre possibilidades úteis: localizar um cadastro autorizado, consultar o estado de uma nota, obter metadados de um documento ou iniciar uma rotina previamente aprovada. A demonstração conceitual comentada no podcast — receber uma solicitação em linguagem natural e acionar funções do sistema — ajuda a visualizar o potencial, mas não deve ser confundida com permissão irrestrita. Cada ferramenta exposta pelo servidor MCP precisa de autenticação, autorização, validação dos parâmetros, registro de auditoria e limites claros sobre leitura e escrita.

Também é importante lembrar que o contexto mais sensível de um ERP pode estar nos dados, não no código CRUD que os manipula. Informações fiscais, comerciais, pessoais e financeiras não devem ser enviadas a um provedor por conveniência. Antes da adoção, a empresa precisa conferir contrato, plano utilizado, política de retenção, local de processamento e possibilidade de desativar o uso para treinamento. A política empresarial da OpenAI declara que dados de produtos empresariais e da API não são usados para treinamento por padrão e descreve controles de retenção e criptografia; isso é uma característica de serviços e condições específicos, não uma autorização geral para compartilhar qualquer conteúdo.

Modelos locais podem reduzir parte da exposição externa, mas introduzem outros custos: hardware, atualização, operação, controle de acesso e, muitas vezes, desempenho inferior em determinadas tarefas. A escolha correta depende da classificação da informação e do risco do caso de uso. Segredos, chaves, certificados, dados pessoais e bases de clientes devem permanecer fora do contexto por padrão. Quando dados reais forem indispensáveis, aplique minimização, mascaramento, consentimento e controles organizacionais adequados.

Um roteiro prático para começar sem perder o controle

A adoção pode começar com uma tarefa pequena, repetitiva e reversível, em uma cópia controlada do projeto. Não é necessário iniciar com uma migração completa nem conectar o agente ao banco de produção. O roteiro abaixo resume o método discutido no episódio e acrescenta barreiras que ajudam a torná-lo repetível:

1. Escolha uma tarefa observável: prefira documentação, criação de testes, análise de dependências ou uma refatoração pequena, cujo resultado possa ser comparado objetivamente.
2. Registre o contexto: informe versões de Delphi ou Lazarus, bibliotecas, sistema operacional, banco, convenções e arquivos permitidos. Não inclua segredos nem dados reais.
3. Descreva o resultado e os limites: explique o comportamento esperado, o que não deve mudar e quais decisões exigem confirmação humana.
4. Defina as verificações antes da implementação: compilação, testes, análise estática, revisão do diff e teste funcional devem existir antes que o agente comece.
5. Execute em ciclos curtos: uma mudança por vez, com parada automática diante de falha. Evite acumular centenas de alterações sem inspeção.
6. Leia o código produzido: testes verdes reduzem risco, mas não substituem a avaliação de clareza, segurança, manutenção e aderência à arquitetura.
7. Transforme acertos em procedimento: depois de repetir uma tarefa com sucesso, registre o método em uma skill ou guia versionado e revise-o periodicamente.

Esse roteiro também melhora a formação de profissionais iniciantes. Ensinar somente a pedir respostas à IA cria dependência sem compreensão. Fundamentos de lógica, estruturas de dados, orientação a objetos, banco de dados, depuração e testes continuam necessários para reconhecer uma solução inadequada. Ao mesmo tempo, proibir a ferramenta não prepara ninguém para o ambiente atual. A alternativa é aprender programação e uso responsável de IA em conjunto, sempre exigindo que o aluno explique o código, teste hipóteses e identifique limites.

Aprofunde a prática com Delphi, MCP e ACBr

Para quem deseja transformar a discussão sobre MCP em uma implementação executável, escrevi Delphi na Era dos Agentes: Construa servidores MCP e conecte sistemas e ERPs à Inteligência Artificial. No livro, construo um servidor MCP local em Delphi 13 e o conecto a um MiniERP fictício, passando por JSON-RPC, transporte stdio, tools, resources, prompts, autorização, testes e aprovação humana. A obra já está disponível em edição impressa e para Kindle.

Também estou preparando ACBr com IA na Prática: Inteligência artificial aplicada ao dia a dia do desenvolvimento com Delphi e ACBr. O próximo lançamento acompanha uma aplicação Delphi VCL até a emissão de NFC-e em homologação e mostra como fornecer contexto à IA, conferir fontes, configurar componentes, interpretar retornos e validar cada mudança com compilação, testes, schemas e evidências. Na página oficial, você pode conhecer a proposta completa e solicitar um aviso quando o livro estiver disponível.

Conclusão

A principal conclusão do Papo Pro não é que a IA escreverá todo sistema Delphi, Lazarus ou ACBr, nem que existe uma frase capaz de resolver projetos complexos. A oportunidade está em deslocar esforço mecânico para agentes enquanto a equipe fortalece aquilo que torna a automação confiável: especificação, arquitetura, testes, revisão e segurança. Quanto mais autonomia a ferramenta recebe, mais objetivos precisam ser os critérios que a cercam.

Para começar, escolha um problema pequeno, escreva claramente quem fará o trabalho, o que deve entregar, como deve agir e como será validado. Só amplie o escopo depois de comprovar o ciclo completo. No código legado, preserve o comportamento antes de transformar a estrutura; em integrações e MCP, conceda apenas as permissões necessárias; diante de qualquer resultado, leia e verifique. A IA pode aumentar muito a capacidade de uma equipe, mas o ganho duradouro nasce da engenharia que vem antes e depois da geração.

Referências

MODEL CONTEXT PROTOCOL. What is the Model Context Protocol (MCP)? Model Context Protocol, [s. d.]. Disponível em: https://modelcontextprotocol.io/docs/getting-started/intro. Acesso em: 17 set. 2026.

OPENAI. Enterprise privacy at OpenAI. OpenAI, 8 jan. 2026. Disponível em: https://openai.com/enterprise-privacy/. Acesso em: 17 set. 2026.

PROJETO ACBr. Papo Pro ACBr: Produtividade Pro: IA na Prática com Delphi, Lazarus e ACBr. Spotify, 17 set. 2026. Disponível em: https://open.spotify.com/episode/6nEyRTmqW9KQb7Dgq2Cxyf. Acesso em: 17 set. 2026.

PROJETO ACBr. Produtividade Pro: IA na prática com Delphi, Lazarus e ACBr. Portal Projeto ACBr, 17 set. 2026. Disponível em: https://www.projetoacbr.com.br/forum/events/?view=overview. Acesso em: 17 set. 2026.