Como eu escrevo software com LLMs: Um fluxo de trabalho prático multi-modelo

Em 10 de março de 2026, Stavros publicou o que pode ser o guia mais honesto e prático para construir software com grandes modelos de linguagem. Não é um artigo de hype. É um fluxo de trabalho real, testado em múltiplos projetos entregues.

O ponto de partida: Fazer coisas, não programar

Stavros faz uma distincção que reenquadra toda a conversa. Ele não se importa com programação como fim em si mesma. Ele se importa em fazer coisas. Os LLMs mudaram a equação ao aproximar a programação da construção direta.

Ele usou essa abordagem para construir e manter vários projetos: um assistente pessoal chamado Stavrobot, um dispositivo de notas de voz, um projeto de relógio-artístico e uma simulação de cidade pequena chamada Pine Town.

A arquitetura de três modelos

1. O modelo de planejamento (Arquiteto)

O primeiro modelo atua como arquiteto. Stavros passa até 30 minutos em conversação antes de escrever código. A instrução-chave: não comece a implementar até que eu aprove explicitamente o plano.

2. O modelo de desenvolvimento (Implementador)

Uma vez aprovado o plano, um modelo mais barato cuida da implementação. Este modelo tem liberdade limitada — executa o plano, não o redesenha.

3. Os modelos de revisão (Múltiplos revisores)

Após a implementação, Stavros passa o código por múltiplos modelos de revisão. Usa Codex, Gemini e Opus. A diversidade importa — diferentes modelos detectam diferentes problemas.

O humano escreve as instruções do agente

Stavros escreve as instruções do agente à mão. Não permite que um LLM gere seu próprio arquivo de habilidades. O humano define as restrições; os modelos executam dentro delas.

Onde funciona bem

O fluxo de trabalho multi-modelo funciona melhor quando Stavros já entende a stack tecnológica. Nesse contexto, os LLMs funcionam como um multiplicador de produtividade.

Onde falha

Em território desconhecido, o fluxo de trabalho funciona muito pior. Más decisões se acumulam. A dívida técnica de arquiteturas mal compreendidas é a mais cara de reparar.

Conclusões práticas

Separe planejamento de implementação. Use diferentes modelos para diferentes papéis. Diversifique seus revisores. Escreva suas próprias instruções. Mantenha-se em território familiar. Fique atento a erros acumulados.