Há mais de três décadas que o GeneXus faz uma aposta que hoje soa estranhamente atual: não se escreve o sistema, modela-se; e a partir desse modelo o código é gerado de forma determinística. Quando o negócio muda, muda o modelo, e o sistema é regenerado.

A irrupção dos LLMs coloca essa aposta sob uma nova luz. O desenvolvimento assistido por Inteligência Artificial avança rapidíssimo, mas o faz tropeçando em um problema antigo que o GeneXus leva anos resolvendo: como confiar no que foi construído, entendê-lo e responder por ele?

Este artigo descreve como estamos repensando o GeneXus para esta era – o que preservamos de seu núcleo, o que abrimos e o que incorporamos dos LLMs – para desenvolver e manter sistemas críticos com IA de forma segura e auditável.

A ideia em uma frase: no novo GeneXus, a conversa não produz diretamente o código. Produz um modelo formal e versionado; o código é uma de suas projeções.

Duas abordagens frequentes no desenvolvimento com LLMs

A primeira é deixar-se levar: pedir ao modelo o que queremos e confiar que ele resolva bem, apostando que cada nova versão seja um pouco melhor que a anterior. É rápido e chega longe, até que é preciso entender, manter ou responder pelo que foi construído.

A segunda é colocar andaimes: uma especificação que declara a intenção, acompanhada de hooks e controles que vigiam o modelo enquanto trabalha. É uma abordagem disciplinada e séria. Mas mantém um limite fundamental: a especificação é prosa.

Pode ser revisada, mas é difícil verificar de forma determinística que esteja completa, que não se contradiga e que cada parte da implementação responda a uma intenção explícita. A correspondência entre o que foi pedido e o que foi construído acaba descansando na revisão do código, dos testes e do comportamento final – justamente o que cada vez custa mais examinar em profundidade.

As duas abordagens são legítimas e resolvem coisas reais. A diferença que propomos não é de velocidade, mas de que tipo de garantia fica ao final do processo.

A terceira forma: modelar a intenção

Em vez de deixar a intenção escrita apenas em prosa, o GeneXus converte a conversa com o usuário em um modelo formal, guiado por uma ontologia que sabe quais preocupações um sistema deve resolver e quais perguntas precisam ser respondidas para considerá-lo completo.

Convém ser preciso sobre o que é essa ontologia, porque aí está a chave – e também o limite da abordagem.

Não é um oráculo neutro: é conhecimento opinado, a codificação do que o GeneXus aprendeu em trinta anos construindo sistemas de negócio. Essa opinião é seu valor: não se reinventa em cada projeto o que é necessário para que um sistema esteja completo. E, como tudo o mais no GeneXus, é inspecionável e versionável.

Sobre esse modelo, a verificação deixa de ser apenas uma leitura. E aqui vale dizer exatamente o que garante e o que não garante.

O que se verifica de forma determinística é que o modelo cumpra as regras da ontologia: que todas as preocupações obrigatórias tenham sido atendidas, que cada referência aponte para algo que existe, que as restrições sejam cumpridas e que o modelo não se contradiga.

O que não se demonstra por máquina é que o modelo diga o que o negócio realmente precisa. Esse salto – da intenção real aos fatos tipados – ainda é feito por uma conversa.

A diferença em relação à prosa não é que tenhamos eliminado essa conversa, mas que a elevamos a um terreno verificável. Antes, a interpretação ficava dispersa em um documento que alguém lia e considerava suficientemente bom. Agora fica tipada, registrada e contrastável com uma ontologia explícita.

O risco não desaparece: se concentra, torna-se visível e passa a ser auditável. O processo não pode declarar completo, em relação à ontologia, aquilo que ainda não o está.

Um exemplo, de ponta a ponta

Tomemos algo tão comum quanto as permissões.

O agente não pergunta sobre modelos de autorização, políticas nem perfis. Pergunta se qualquer pessoa pode entrar no sistema, se todas as pessoas veem as mesmas opções e quem pode fazer cada coisa.

Cada resposta é salva como um fato tipado no modelo.

E aqui se vê a diferença: se o sistema declara, por exemplo, uma operação para excluir uma fatura mas nunca se definiu quem pode executá-la, a verificação detecta isso. Essa preocupação ficou em aberto e o sistema não pode avançar como se estivesse resolvida.

Não é preciso confiar em que um revisor a descubra lendo código: existe uma operação declarada e falta o conhecimento necessário para governá-la. Esse vazio é visível para uma máquina.

Quando o modelo de permissões está completo e verificado, as estruturas, as validações e os controles de acesso repetíveis podem ser gerados de forma determinística.

E se houvesse uma regra de permissão única que nenhum gerador ainda cobre – por exemplo, “somente o gerente regional que aprovou a operação pode reabrí-la” -, essa parte é tratada de outra forma, como veremos mais adiante, mas também fica registrada e deve apresentar evidência.

O mesmo princípio torna-se ainda mais importante quando o negócio muda.

Suponhamos que uma fatura que antes podia ser fechada diretamente agora requer uma aprovação prévia. A mudança não começa buscando quais arquivos precisam ser alterados. Começa modificando o modelo: surge uma nova regra, uma nova operação ou estado e as relações necessárias para representá-la.

A partir daí, o sistema pode calcular quais partes dependem desse conhecimento e quais projeções foram alcançadas pela mudança. As que corresponderem são regeneradas; as que não dependem dela permanecem intactas.

Assim, a pergunta deixa de ser “lembramos de modificar todos os lugares afetados?” e passa a ser “o que o grafo diz que depende desta mudança?”.

Esse fio – conversa em linguagem de negócio, fatos tipados, verificação que expõe o que falta, análise explícita do impacto, geração do que é repetível e um tratamento distinto para o que é único – é o que percorrem os nove princípios.

Como se captura a intenção

1. Conversa em linguagem de negócio, não em jargão técnico

Tudo ocorre dentro de um ambiente de desenvolvimento agêntico, um ADE, com um chat a partir do qual o usuário conversa com o agente sobre o sistema que quer construir.

O usuário não precisa conhecer os termos da ontologia: fala do negócio e o agente traduz.

Assim incorporamos uma das grandes vantagens dos LLMs – uma conversa fluida em linguagem natural – sem transferir ao usuário o vocabulário técnico do modelo.

2. Nível de exigência declarado no início; a ontologia adapta o obrigatório

Ao começar, declara-se o nível de exigência do projeto: uma prova de conceito, uma ferramenta interna ou um sistema de missão crítica.

De acordo com esse perfil, a ontologia determina quais preocupações devem ser cobertas obrigatoriamente e quais podem ser resolvidas com decisões já estabelecidas pelo GeneXus.

A partir daí, o agente explora o que falta. Não improvisa perguntas em cada conversa, mas trabalha sobre o conhecimento que o GeneXus codificou a respeito do que é necessário para construir sistemas de qualidade.

Isso é especialmente importante nos Sistemas de Missão Crítica. O usuário não precisa conhecer todas as dimensões técnicas necessárias para construir um: segurança, acesso, integração, acessibilidade, operabilidade, internacionalização, governança e outras preocupações do sistema.

O GeneXus toma uma posição sobre isso. Sua ontologia codifica o que deve ser considerado para cada tipo de sistema e obriga a que essas preocupações sejam atendidas ou explicitamente declaradas como não aplicáveis. O agente leva essas decisões a uma conversa em linguagem de negócio.

O usuário explica o que precisa. O GeneXus contribui com o conhecimento sobre o que precisa ser considerado para construí-lo com o nível de exigência declarado.

Como se verifica

3. Modelo formal com fatos tipados, não prosa interpretável

No desenvolvimento guiado por especificações, o agente segue instruções escritas em prosa.

Aqui, as respostas ficam representadas como fatos tipados dentro de um modelo formal.

Por isso o que o sistema deve cumprir pode ser verificado de maneira determinística. Não é uma especificação que alguém lê e considera suficientemente boa: é um modelo que uma máquina pode aceitar ou rejeitar.

4. O modelo vive no Git, não em uma base proprietária

O modelo são arquivos de texto em um repositório Git.

É possível fazer diff. É possível revisar em um pull request. É possível trabalhar com branches. O Git blame pode dizer quem declarou cada fato, quando e em qual mudança ele apareceu.

Um hook de pre-commit valida o modelo contra a ontologia e rejeita o commit se ele não estiver em conformidade.

A fonte de verdade não está presa dentro do ADE nem de uma base proprietária. Está em arquivos abertos, versionáveis e processáveis com as mesmas ferramentas com que qualquer equipe de desenvolvimento já trabalha.

Se amanhã o usuário quiser construir outra ferramenta sobre esse conhecimento, o modelo continuará lá. Se quiser auditá-lo, também.

5. Nada ocorre em uma caixa preta

O ADE oferece visualizações para compreender o modelo, saber o que falta para que o sistema esteja pronto, explorar suas relações e antecipar quais artefatos serão produzidos.

E o modelo não retorna simplesmente “válido” ou “inválido”.

Pode mostrar qual preocupação continua em aberto, o que foi resolvido por uma decisão do perfil, o que foi declarado como não aplicável e o que ainda precisa de uma resposta humana.

A cada momento é possível ver o estado real do sistema e as razões pelas quais ele ainda não pode avançar.

O gate bloqueia; o ADE explica o porquê.

Como se torna código

Antes de falar de geração, convém definir uma expressão que usaremos daqui em diante.

Chamamos de regime compilado os casos em que o conhecimento necessário está representado no modelo e existe um gerador capaz de transformá-lo em um artefato sem precisar pedir novamente a um LLM que interprete a intenção.

Nesse regime, gerar deixa de ser uma nova decisão. É uma compilação de conhecimento já capturado.

6. Geração determinística para o que é repetível

Quando o modelo está completo e verificado, começa a geração.

O que se repete – estruturas de dados, operações, políticas, contratos e padrões recorrentes dos sistemas de negócio – pode ser produzido por geradores determinísticos.

Quando existe um gerador para esse conhecimento dentro do regime compilado, dado o mesmo modelo e o mesmo gerador produz-se sempre a mesma saída. Não há nada a reinterpretar nem a adivinhar: o gerador transforma em código o conhecimento que já foi capturado.

7. O código é uma projeção do modelo, não um artefato solto

Como vimos no exemplo da fatura, quando o negócio muda o modelo muda, e as dependências do grafo permitem determinar quais projeções foram alcançadas e devem ser regeneradas.

No regime compilado, o código não é o lugar onde a intenção é preservada: é uma consequência do modelo.

A disciplina para o que é único

Nem tudo é repetível.

Para o que é verdadeiramente novo – que muitas vezes é a lógica mais crítica e diferenciadora de um negócio – não basta um gerador.

A resposta não é fingir que sim, mas oferecer uma garantia diferente e explícita.

8. Objetos genéricos com procedência e evidência

Quando algo ocorrerá uma única vez e ainda não existe um gerador que o cubra, é representado como um objeto genérico.

Aí o LLM pode construí-lo, mas não a partir de uma conversa que depois se perde.

A entrada que utilizou, a especificação e o material de contexto ficam salvos e versionados. O resultado deve declarar como foi produzido e apresentar evidência de que funciona.

Não se exige dele a mesma garantia que a um artefato compilado. Exige-se outra, de forma explícita: procedência e evidência.

É deliberadamente o ponto onde a abordagem convive com a incerteza em vez de negá-la, e a administra deixando-a rastreável.

9. Regra da segunda instância: o que é repetível se torna um gerador

Existe uma regra fundamental: se aparece uma segunda instância do mesmo tipo de entrada, o sistema não permite mais tratá-la como um caso único.

E isso não é uma recomendação metodológica que um desenvolvedor precisa lembrar. A cardinalidade faz parte do modelo e a validação rejeita que uma segunda instância continue declarada como um caso único.

Nesse momento, esse conhecimento deve se tornar um gerador.

O LLM pode ajudar a escrevê-lo, mas a partir daí deixa de reinventar cada resultado.

A primeira aparição pode precisar de autoria e evidência. A segunda revela que existe um padrão. O padrão se formaliza e passa para o território compilado.

Assim, o território do incerto não cresce indefinidamente com o sistema: estreita-se à medida que o conhecimento se consolida.

O produto que estamos projetando

Estamos projetando um novo GeneXus: um agente com o qual você fala sobre o seu negócio e que transforma essa conversa em um modelo formal e verificável.

Você não precisa saber o que é necessário tecnicamente para construir um Sistema de Missão Crítica. O GeneXus tem uma posição sobre isso: sua ontologia incorpora esse conhecimento e garante que as preocupações importantes não fiquem silenciosamente esquecidas.

A aposta não é apenas construir mais rápido. É poder confiar no que se constrói: saber que o necessário foi considerado, que o que falta é visível e que o que já sabemos resolver é produzido de forma repetível.

Essa confiança se sustenta sobre uma única linha de conhecimento, verificável de ponta a ponta, onde cada elo diz o que garante e qual é o seu limite.

Não estamos projetando um agente que escreva mais código.

Estamos projetando um GeneXus que converte conversas em conhecimento verificável, e conhecimento verificável em software no qual possamos confiar.

Você também pode estar interessado em ler:

GeneXus e a Arquitetura Neuro-Simbólica

O problema do desenvolvimento baseado em prompts

GeneXus for Agents: 15 perguntas essenciais respondidas