Lovable reduziu impasses em 5% com arquivos de conhecimento e RAG

Um agente de IA autônomo parece mais poderoso do que um controlado: ele pode planejar sozinho, acionar ferramentas, criar subtarefas e trabalhar até alcançar o objetivo. A Lovable testou essa ideia em um produto no qual as pessoas criam aplicativos por meio de chat e obteve o efeito contrário. Os agentes se perdiam em labirintos técnicos, acumulavam erros e não conseguiam concluir o trabalho de forma previsível.

A equipe removeu temporariamente quase todo o código complexo do agente. No lugar de um ciclo aberto, manteve uma sequência clara: solicitação do usuário, alterações nos arquivos, verificação do resultado em uma prévia ao vivo e solicitação seguinte. Mais tarde, a autonomia começou a ser reintroduzida, junto com uma infraestrutura que permitia identificar rapidamente um erro e testar outro caminho com segurança.

Primeiro, restrinja a tarefa

Inicialmente, a Lovable se concentrou em novos aplicativos e escolheu uma única stack tecnológica. O usuário apresenta uma ideia, e o serviço cria o código e o executa em um ambiente previamente definido. Isso é muito mais simples do que trabalhar com qualquer repositório existente, no qual podem surgir dependências, versões e métodos de build arbitrários.

Imagine um agente que precisa adicionar um formulário de pagamento. Em um projeto qualquer, primeiro ele precisa entender a arquitetura, o gerenciador de pacotes, as regras de gestão de segredos e a estrutura de implantação. Em uma stack controlada, a maior parte dessas decisões já foi tomada. O agente precisa apenas resolver a tarefa específica, enquanto a plataforma sabe como verificar o resultado.

A lição prática não é que todos precisam do mesmo framework. Outra regra é mais útil: a liberdade do agente deve corresponder à capacidade do modelo de identificar e corrigir os próprios erros. Se o modelo ainda usa ferramentas de forma instável, um processo curto e controlado pode resultar em um produto melhor do que uma autonomia com várias etapas.

As instruções se mostraram mais úteis do que um modelo inicial com ajuste fino

A equipe esperava fazer o ajuste fino dos modelos com o histórico das sessões dos usuários. Na prática, arquivos de texto comuns produziram resultados mais rapidamente. Os engenheiros estudaram aplicativos com problemas, identificaram causas recorrentes e registraram regras curtas. Por exemplo: usar apenas ícones que realmente existam na biblioteca escolhida e, em caso de dúvida, selecionar um ícone universal.

Antes de cada geração, a busca selecionava as regras pertinentes e as adicionava ao contexto do modelo. Em essência, era a combinação hoje conhecida de uma base de instruções com RAG. Depois que uma falha era analisada, ela começava a ajudar os usuários seguintes sem exigir um novo ciclo de treinamento. Segundo a própria Lovable, uma versão inicial de seu sistema de busca de problemas e soluções reduziu em 5% a parcela de usuários que ficavam travados durante o trabalho. Essa é uma métrica interna da empresa e, portanto, não deve ser tratada como um resultado universal.

Para uma equipe de produto, essa abordagem também é conveniente do ponto de vista organizacional. Uma regra pode ser lida, discutida, alterada e vinculada a um erro específico. Mas uma base de conhecimento exige manutenção: instruções contraditórias ou desatualizadas podem prejudicar o resultado com a mesma facilidade com que boas instruções podem melhorá-lo.

A velocidade depende da verificação, não apenas do modelo

A Lovable mantém o ambiente do projeto em execução, atualiza a prévia sem um build completo de produção e realiza verificações incrementais de TypeScript separadamente. O erro retorna mais rápido ao agente, que consegue preparar uma correção enquanto o aplicativo continua funcionando. Mais tarde, a plataforma aprendeu a preservar o estado do ambiente e a criar ramificações dele junto com os arquivos, processos e banco de dados.

É aqui que está a conclusão mais prática. Ao desenvolver um agente, meça não apenas o tempo até a primeira resposta, mas todo o ciclo: alteração, verificação, detecção da falha e correção. Comece com um conjunto limitado de ações, transforme erros recorrentes em instruções verificáveis e adicione autonomia apenas onde houver um sinal rápido sobre o resultado e uma reversão segura. A Lovable não provou que encontrou a arquitetura definitiva. Sua trajetória, porém, mostra claramente por que um agente confiável não é apenas um modelo poderoso, mas um modelo dentro de um sistema corretamente limitado e observável.