LLMs têm dificuldade para projetar sistemas que usam LLMs, aponta artigo

O artigo parte de um caso concreto: alguém tentou fazer vibe coding de uma ferramenta de memória que sinalizasse quando um item contradizia outro. Hoje isso é trivial com um LLM, que pode varrer as contradições em lote ou par a par. Mas, ao receber o pedido de uma abordagem "estado da arte", o agente de IA não recomendou LLMs. Montou um sistema simbólico complexo, que convertia os itens em átomos lógicos e os comparava com um solver. Não funcionou e não tinha como funcionar, já que não existe método analítico para saber se duas frases em linguagem natural expressam a mesma proposição.

O autor, Sean Goedecke, levanta três explicações. A primeira é que o código de treino é majoritariamente anterior aos LLMs, mas ele a descarta como causa única: os modelos não escolhem jQuery ou Backbone no lugar de JS moderno ou React. A segunda é que o RLVR (aprendizado por reforço com verificação automática) provavelmente não oferece credenciais e acesso a APIs para um modelo chamar outros modelos, o que seria caro, lento e arriscado. Ele admite que não sabe isso com certeza. A terceira, a preferida dele, é que os agentes atuais simplesmente não são bons em design de software. Ele cita outros erros do tipo: algoritmos de consenso complexos no lugar de tolerar dados defasados e checagens síncronas em sistemas orientados a eventos.

Para quem constrói produtos com IA, a leitura prática é desconfiar do agente justamente nas decisões de arquitetura que envolvem LLMs. Se a tarefa é classificar, comparar ou julgar texto, vale perguntar de forma explícita se uma chamada a modelo resolve antes de aceitar regex, palavras-chave ou solvers. O próprio autor sugere ainda perguntar ao agente sobre o estado da arte da área, embora admita que o caso mostra que a formulação do pedido pesa.