Prompt não dura. Ele apaga junto com a sessão. Um bom prompt funciona uma vez, num modelo e num contexto que já eram outros na semana seguinte, e depois não vale quase nada. Mesmo assim, boa parte da conversa por aí trata o prompt como se fosse o produto do trabalho. E isso sempre me incomodou, porque contraria a lógica que eu defendo aqui. No paradigma 70/30, o peso está nos 70% de intenção e desenho, não nos 30% de execução. O prompt vive na execução, justo a camada que envelhece mais rápido.
Foi por isso que travei num artigo que o Unmesh Joshi publicou ontem no site do Martin Fowler. O título é seco, "DSLs Enable Reliable Use of LLMs", mas tem uma frase no meio que eu fiquei relendo. Ele diz que o ativo duradouro não é o prompt, é a DSL e o modelo semântico. Simples assim. E isso bate exatamente onde eu venho insistindo aqui: quando a execução fica barata, o valor migra pra intenção e pra abstração. Só que o Joshi foi um passo além do que eu costumo dizer.
O prompt é andaime, o modelo semântico é a fundação
A conversa pública ainda gira em torno de "prompt engineering" como se o prompt fosse a peça de valor. Você capricha na instrução, o modelo cospe o código, e a gente celebra a instrução como se fosse o entregável. Mas repare no que sobra depois. O código gerado, talvez. A instrução em si, quase nunca. Ela serviu de andaime pra levantar uma coisa, e andaime a gente desmonta.
O que o Joshi propõe é inverter a atenção. Em vez de perseguir o prompt perfeito, você investe em construir uma linguagem de domínio, uma DSL, com um vocabulário fixo pro seu problema. O exemplo dele é o Tickloom, um framework pra testar sistemas distribuídos. Quando você pede pro modelo "implementa um key-value store baseado em quórum", o código que volta fica dentro do vocabulário do framework. Fala em Replica, quorumRequest, countResponseIf. Não reinventa threading, não reinventa rede. Um teste de cenário chega a ler quase como uma frase em inglês: o cliente escreve um valor, espera sucesso, outro cliente lê, espera aquele valor de volta.
O prompt que gerou isso pode sumir. A DSL fica. E é ela que continua legível seis meses depois, quando ninguém lembra mais qual foi a instrução exata.
Por que a coleira deixa o modelo mais confiável
Meu primeiro reflexo foi desconfiar. Restringir o modelo não seria podar justo a parte boa, a flexibilidade? Fui atrás de número e achei um que me fez mudar de ideia.
Tem um paper recente, o Anka, do Saif Al Mazrouei, que descreve uma DSL desenhada de propósito pra geração de código por LLM. O detalhe que me pegou: o Claude 3.5 Haiku, numa linguagem que ele nunca tinha visto no treino, acertou 95,8% das tarefas e teve 99,9% de parse success em cem problemas de benchmark. E numa tarefa de pipeline com várias etapas, essa DSL desconhecida bateu Python por 40 pontos percentuais. Cem por cento contra sessenta. Python, onde o modelo tem uma montanha de dados de treino, perdeu feio pra uma linguagem que ele viu pela primeira vez ali.
Isso soa contra-intuitivo até você entender o mecanismo. Python aceita mil jeitos de escrever a mesma coisa, e o modelo escorrega justamente na sequência das operações e no controle das variáveis. A DSL tira a variação da mesa. Sobra menos espaço pra alucinar. A restrição não é a coleira que atrapalha, é o trilho que segura. O Joshi diz que a DSL responde bem a poucos exemplos no contexto, e é por isso: com o espaço de solução estreito, dois ou três exemplos já ensinam o modelo a acertar.
Design não desce pronto de uma especificação
Aqui tem a parte que mexe com o que eu mesmo já escrevi. Eu venho defendendo spec-driven development, a ideia de que a especificação virou o código-fonte. Continuo achando isso certo. Mas o Joshi coloca uma ressalva honesta que eu preciso incorporar.
Ele diz que a especificação de cima não captura tudo. As restrições reais, os trade-offs que importam, eles aparecem enquanto você implementa, não antes. Design emerge na implementação. Por isso o desenvolvimento com IA pede refinamento iterativo, e não geração de uma tacada só. E é aí que a DSL vira parceira, porque cada rodada de implementação ensina você sobre o vocabulário que o domínio realmente precisa.
O Joshi separa dois papéis do modelo que valem guardar. No começo, quando você ainda está descobrindo a abstração, o LLM é parceiro de brainstorm pra desenhar a linguagem. Depois que a linguagem existe, ele vira interface em linguagem natural pra ela. São momentos diferentes e pedem coisas diferentes de você. No primeiro, você é o arquiteto do modelo e o modelo é instrumento. No segundo, você delega a digitação e cobra que o resultado caiba no vocabulário.
O que isso muda pra quem lidera engenharia
Se o ativo durável é a linguagem de domínio, a pergunta que eu levaria pro time muda. Não é "qual prompt funcionou". É "que vocabulário a gente está construindo pra esse domínio, e ele está ficando mais claro ou mais bagunçado a cada rodada".
Investir antes num modelo semântico dá trabalho e não rende manchete. Ninguém posta no LinkedIn que passou a semana afinando a abstração de um domínio chato. Mas é esse investimento que faz a geração seguinte ser confiável, a revisão ser rápida, e o artefato continuar entendível muito depois de gerado. É o oposto de gerar volume de código na base do prompt e rezar pra revisão dar conta.
Fica também uma pista de governança. Uma DSL bem desenhada é um jeito de constranger o que a IA pode fazer sem precisar revisar linha por linha. O espaço de saída já nasce estreito. Isso conversa direto com a lógica de habilitar antes em vez de aprovar depois, que eu insisto tanto: você não fiscaliza cada geração, você desenha o trilho onde ela corre.
No fim, o recado do Joshi é quase modesto perto do barulho de fora. Enquanto o mercado discute qual prompt mágico vai destravar a produtividade, ele aponta pro lugar sem glamour: construa a linguagem primeiro. O prompt some com a sessão. A linguagem é o que fica.