LLM-First ou Code-First? Onde a Inteligência Pertence na IA de Produção

Como decidir o que o modelo deve tratar, o que seu código deve tratar e como conectar os dois.

Há alguns anos, a arquitetura de uma aplicação de IA se parecia com: enviar um prompt para um grande modelo de linguagem -> obter uma resposta -> mostrá‑la ao usuário. Isso não é mais a história completa atualmente. Os modelos são solicitados a interpretar a intenção, recuperar informações, escolher ferramentas, chamar APIs, fazer planos e executar fluxos de trabalho de múltiplas etapas.

Essa mudança dividiu o campo em duas – LLM-First ou Code-First

Em uma arquitetura LLM-first, o modelo está no centro e decide o que acontece a seguir. Ele lê a solicitação, escolhe uma ferramenta, decide a ordem das operações, verifica os resultados intermediários e muda de direção quando necessário.

Em uma arquitetura code-first, o software/código continua responsável pela sequenciação, regras de negócio, validação, permissões e execução. O LLM aqui funciona como um especialista que o código chama quando é necessário entendimento ou geração de linguagem.

As pessoas adoram discutir qual é melhor. Acho que esse é o argumento errado. A questão mais importante é onde cada tipo de inteligência pertence. Os sistemas de produção mais robustos que já vi raramente são puramente um ou outro. Eles combinam raciocínio probabilístico com controle determinístico, e fazem isso de forma deliberada.

Por que LLM-First é tão Atrativo

Software tradicional funciona perfeitamente quando você pode especificar os requisitos. Por exemplo, um usuário escolhe um produto, insere um valor e envia um pagamento. Você define os estados permitidos, as regras de validação, as condições de erro e a sequência da transação em código. Pronto.

A linguagem natural não coopera assim. Imagine um usuário digitando: “Encontre as transações que pareçam incomuns, explique o que aconteceu e diga-me o que devo investigar primeiro.”

Não há um caminho fixo para essa solicitação. Aqui o sistema precisa decidir o que “incomum” significa, descobrir quais dados são relevantes, talvez chamar várias ferramentas, ponderar a resposta e escrever uma explicação que a pessoa possa usar. Nenhuma equipe de engenheiros/sem código antecipará todas as formulações e todas as combinações de pedidos com antecedência.

É onde um LLM desempenha um papel vital, atuando como uma camada flexível de raciocínio entre a linguagem humana e seus serviços determinísticos. Também é por isso que os agentes estão recebendo tanta atenção. orientação de arquitetura de IA agente da Google Cloud descreve um agente como uma aplicação onde um modelo de IA atua como o motor de raciocínio, enquanto ferramentas permitem que ele acesse sistemas e dados externos.

da Anthropic Construindo Agentes de IA Eficazes orientaçãofaz uma distinção que continuo revisitando.fluxo de trabalho, modelos e ferramentas seguem caminhos que seu código define. Em um agente, o LLM dirige seu próprio processo e decide como usar suas ferramentas. A mesma orientação recomenda começar com a arquitetura mais simples que resolve o problema, em vez de acrescentar complexidade agente por reflexo. Eu sublinharia esse conselho duas vezes.

Os Limites de “Deixe o Modelo Decidir”

Um modelo pode raciocinar sobre o que deve acontecer. Raciocínio não é o mesmo que impor uma regra.

Por exemplo, considere um fluxo de trabalho financeiro. Um LLM pode ser ótimo em entender “enviar o mesmo valor que enviei no mês passado para o mesmo fornecedor”. Mas ele também deveria decidir se a transferência está autorizada, calcular limites regulatórios, verificar a propriedade da conta, sobrescrever uma política de segurança e executar a transação?

Provavelmente não. Esses trabalhos são determinísticos, testáveis, auditáveis e aplicáveis, e isso é exatamente onde o software tradicional se destaca. O risco aumenta à medida que os modelos obtêm acesso a ferramentas. orientação de segurança de IA generativa da OWASP sinaliza excesso de autonomia como um risco significativo: conceder a um sistema baseado em LLM mais funcionalidades, permissões ou autonomia do que a tarefa requer. Uma saída de modelo estranha ou manipulada é uma coisa quando produz texto. É algo muito maior quando o modelo pode agir no mundo real.

Nada disso significa que os modelos nunca devem executar ações. Significa que a autonomia do modelo deve ser limitada por autoridade determinística.

Code-First Ainda Importa

Com a IA avançando tão rapidamente, é fácil sentir que a engenharia convencional ficou fora de moda. Eu argumentaria o contrário. A IA torna os bons sistemas determinísticos ainda mais importantes, não menos.

Código ainda é a escolha correta sempre que uma tarefa exige repetibilidade exata. Autenticação é o exemplo mais simples. Um modelo não deve “raciocinar” sobre se alguém tem privilégios de administrador. Seu aplicativo deve consultar um sistema autoritário de identidade e gerenciamento de acesso. O mesmo vale para cálculos monetários, verificações de direitos, validação de dados, restrições regulatórias, limites de transação, validação de esquema e qualquer coisa irreversível. Isso requer contratos explícitos, não suposições.

Isso está alinhado ao pensamento mais amplo de governança. O NIST AI Risk Management Framework pede que as organizações gerenciem o risco de IA ao longo do design, desenvolvimento, implantação e uso. Seu companheiro Generative AI Profile acrescenta que sistemas generativos podem precisar de supervisão extra, documentação, revisão e controles, dependendo do risco envolvido.

Então acho útil dividir cada decisão de design em duas perguntas:

O que deve acontecer?

e

O que é permitido que aconteça?

Um LLM pode frequentemente ajudar com a primeira. Sistemas determinísticos geralmente devem assumir a segunda.

The Hybrid Pattern: Reason Probabilistically, Execute Deterministically

Para a maioria das aplicações corporativas, a resposta prática é um híbrido. O LLM funciona como camada de interpretação e raciocínio. Serviços determinísticos atuam como camada de execução e aplicação de regras.

Aqui vai um exemplo. Imagine um assistente de IA que ajuda desenvolvedores a criar ambientes temporários de teste de API, e um desenvolvedor digita: “Me dê um sandbox para o fluxo de integração de cliente.”

O LLM pode interpretar isso, descobrir qual fluxo provavelmente é o pretendido, ler a documentação e sugerir quais APIs são provavelmente relevantes. Mas a criação real do ambiente não deve depender de texto gerado livremente. O código pode confirmar que as APIs solicitadas existem, validar seus contratos, verificar autorização, impor limites de recursos, gerar uma configuração aprovada e executar a implantação.

A divisão aproximada fica assim:

• The LLM: entender, raciocinar, classificar, propor, resumir.
• The code: validar, autorizar, calcular, persistir, aplicar, executar.

Cada lado faz o que faz melhor, e nenhum é solicitado a fingir as forças do outro.

Boundaries Matter More as Agents Get More Powerful

Essa separação se torna mais importante à medida que avançamos de assistentes para agentes. Um assistente que dá uma resposta ruim incomoda alguém. Um agente com acesso de escrita à produção pode causar um caos muito maior.

A solução não é necessariamente eliminar a autonomia. É adicionar autonomia gradualmente, mantendo os pontos de controle explícitos no lugar. orientação da Google sobre sistemas multiagenterecomenda combinar comportamento de IA dinâmico com controles de segurança determinísticos, observabilidade, autonomia claramente definida e supervisão humana para cenários críticos de negócios.

A aprovação humana também pode ser incorporada ao próprio fluxo de trabalho, em vez de ser uma rede de segurança informal. Microsoft’s agent framework documentation, por exemplo, suporta chamadas de ferramentas que pausam até que uma pessoa aprove explicitamente a operação solicitada.

O princípio é simples: quanto maiores as consequências de uma ação, mais fortes devem ser os controles determinísticos ao seu redor.

Cinco perguntas a fazer antes de delegar uma tarefa a um LLM

Quando decido se um componente deve ser LLM-first ou code-first, passo por estas questões:

1. O tarefa tem uma resposta objetivamente correta? Se sim, incline-se para código determinístico. Cálculos de impostos, permissões e validação de esquemas não devem mudar porque um modelo os interpreta de forma diferente hoje.
2. Envolve linguagem ambígua ou informação não estruturada? Se sim, um LLM pode agregar valor real.
3. O que acontece se o modelo errar? A arquitetura correta para um resumo de reunião é muito diferente da arquitetura correta para iniciar um pagamento.
4. É possível validar a saída de forma independente? Planos gerados por LLM ficam muito mais seguros quando regras determinísticas podem checar a ação resultante antes de sua execução.
5. Isso realmente precisa de um agente? Se você já conhece os passos, um fluxo de trabalho regular com algumas chamadas direcionadas ao LLM costuma ser mais simples, barato, fácil de testar e de operar.

Essa última pergunta merece atenção extra. Agentes são poderosos precisamente porque podem lidar com situações em que você não pode prever cada passo. Mas se você pode prever os passos, transformá‑los em um problema de raciocínio aberto costuma acrescentar variabilidade sem acrescentar inteligência.

Confiabilidade é uma propriedade arquitetural, não um prompt

Muitas equipes começam tentando melhorar a confiabilidade quase que exclusivamente por meio de engenharia de prompts. Prompts importam, mas não podem carregar todo o peso.

Um sistema de produção deve assumir que a saída do modelo às vezes será incompleta, malformada, inesperada ou simplesmente errada. O OWASP Top 10 para aplicações LLM lista riscos como injeção de prompt e manuseio inadequado de saída, o que reforça um hábito fundamental: tratar a saída do modelo como entrada não confiável para sistemas downstream, não como instruções para execução automática.

Isso muda a pergunta que você faz. Em vez de “Como escrevo um prompt que sempre faça o modelo seguir a regra?”, pergunte “Como eu projeto o sistema para que a regra não possa ser violada mesmo quando o modelo comete um erro?”

Isso é um problema de arquitetura de software, não de prompting. Um prompt pode instruir um agente a não executar uma ação não autorizada. Um serviço de autorização pode realmente impedi‑la. Esses dois controles não são equivalentes.

Além do Debate: Sistemas Intent‑First

Refletindo sobre tudo isso, passei a acreditar que o debate LLM‑first versus code‑first aponta para uma terceira ideia: intent‑first arquitetura.

Em um sistema intent‑first, a aplicação começa entendendo o que o usuário está tentando realizar. É aí que um LLM é mais valioso, porque as pessoas raramente são precisas sobre o que desejam. A partir daí, o sistema converte gradualmente essa imprecisão em operações estruturadas e determinísticas.

Um pedido como “Ajude-me a resolver o problema de pagamento do cliente” pode se transformar em um pipeline: entender a intenção, recuperar a transação, identificar o motivo da falha, recomendar uma solução, solicitar aprovação, executar a operação aprovada.

Algumas dessas etapas se beneficiam do raciocínio de modelos de linguagem. Outras devem ser serviços fixos. A arquitetura não é definida por quem “vence”, IA ou código. Ela é definida por onde a incerteza é aceitável.

Conclusão

À medida que os modelos melhoram, será tentador conceder-lhes controle sobre partes cada vez maiores da pilha. Às vezes isso será a decisão correta. Em outros sistemas, o design mais sofisticado será aquele que deliberadamente dá ao modelo menos autoridade.

Engenharia de IA de produção, no final, trata de colocar a inteligência na fronteira correta. Use modelos de linguagem onde interpretação, raciocínio, síntese e adaptação criam valor. Use software determinístico onde consistência, autorização, precisão e aplicação são importantes. Então conecte os dois por meio de interfaces estreitas, observáveis e bem testadas.

O futuro da IA empresarial provavelmente não será puramente LLM‑first nem puramente code‑first. É LLM onde a incerteza exige inteligência, e código onde a certeza exige controle.

Essa distinção pode importar muito mais do que o modelo que você escolher.