Engenharia na era dos LLMs

• Texto que reúne um ano e meio de reflexões na Reindeer sobre como construir produto e organização de desenvolvimento na era dos LLMs, partindo da percepção de que o contexto humano (human context) é o recurso mais escasso
• O volume de produção de conteúdo explodiu, mas a velocidade de consumo humano continua a mesma, e essa diferença virou um novo gargalo — é preciso bloquear o ciclo vicioso em que slop alimenta slop (slop feeds slop)
• Decisões estruturais como modelagem e desenho de API ainda continuam sendo território humano, e é preciso haver alguém para dizer "não" aos artefatos produzidos por LLMs
• Não dá para vencer LLMs só com revisão de código, então é necessário criar camadas de defesa automáticas e baseadas em disciplina, como linters, juízes de LLM (LLM judges) e PRs pequenos
• A principal competência do desenvolvedor não é conhecimento técnico profundo, mas sim troca de contexto e o tamanho da própria janela de contexto, e quem se adapta vira alguém superprodutivo, enquanto quem não se adapta se torna um saldo negativo (net negative) para a equipe

---

Contexto humano é um recurso escasso

• Um fato que não mudou em 25 anos de indústria — o recurso mais caro é o contexto humano, e as pessoas, assim como LLMs, também têm janela de contexto limitada e máscara de atenção
• A mudança que aconteceu agora é que slop de LLM está sendo despejado de todos os lados — a proporção entre velocidade de produção e velocidade de consumo humano virou o novo gargalo
• O problema é que slop alimenta slop
  • LLMs geram comentários de código inflados, descrições de PR prolixas e documentação que enumera o histórico em vez do resultado
  • O próximo LLM lê isso e continua do mesmo jeito, com o contexto já preenchido por ruído
• O conteúdo textual dentro da organização deve ser compressivo e conter apenas o que não fica claro no código e no seu comportamento

Áreas que não podem ser substituídas por humanos

• Modelagem é trabalho humano
  • O trabalho de traduzir CUJ (Critical User Journey) em fluxo de API e decidir o que são os componentes, quais são seus interesses e onde estão seus limites
  • Como o LLM cospe código rapidamente, modelagem ruim também se espalha rápido, criando dependências distorcidas que depois não dá para corrigir
  • Quanto mais barato fica o custo de execução, maior fica o peso das decisões humanas sobre estrutura no valor final
  • Modelagem é a verdade real da organização e precisa continuar viva em um lugar acessível
• Definir API exige disciplina humana rigorosa
  • LLMs tendem a adicionar campos convenientes para uma tarefa específica, e cada um desses campos polui a API de forma permanente
  • API é um contrato público (public contract), não um bloco de rascunho — é preciso um humano para dizer "não"

Defesa em larga escala contra slop

• Não dá para vencer LLMs com revisão humana de código — isso não escala e acaba levando a um estado em que todo mundo aprova de olhos fechados
• A Reindeer convergiu para camadas automáticas de enforcement
  • Linters: regras lógicas absolutas como dependências proibidas entre serviços e limites de arquitetura
  • Juízes de LLM (LLM judges): coisas difíceis de codificar, mas que um modelo consegue inspecionar, como contratos implícitos
• Ainda assim, quando a API é alterada ou a modelagem muda, revisão humana real é obrigatória
• No nível do dia a dia, a regra é "não jogar slop uns nos outros"
  • PRs pequenos, ou stacked PRs quando necessário
  • É preciso resistir à tentação de jogar um PR de slop com 2.000 linhas e à chance de o revisor aprovar de olhos fechados
  • PR é a unidade básica de atenção (attention) — se ultrapassa a janela de contexto da pessoa, ele pode ser aprovado, mas não será lido

Padded rooms — áreas para soltar os LLMs

• Com essa estrutura, dá para identificar áreas em que LLMs podem correr soltos, os "padded rooms" (salas amortecidas)
  • Áreas que não afetam a modelagem e não têm dependências de longo prazo
  • Mesmo que gerem slop, podem ser substituídas com facilidade e não contaminam o restante do codebase
  • Podem representar a maior parte do código da empresa, mas não sustentam carga (load bearing)
• A resposta para customização de clientes também está aqui
  • A customização precisa viver 100% dentro de padded rooms
  • No momento em que vaza para o core, o core se fragmenta e cada novo cliente passa a trazer risco
  • Padded rooms são a infraestrutura que permite dizer "sim" rapidamente ao cliente sem pagar o preço na arquitetura

A inversão econômica da dívida técnica

• A separação entre áreas que sustentam carga e áreas padded também muda a relação com a dívida técnica
• Antes: ao encontrar um problema de modelagem durante o desenvolvimento, a pessoa deixava para o seu eu do futuro; como o custo de reescrita era alto, engolia-se a dívida no meio de um trabalho grande
• Agora: o custo de reescrita converge para quase zero
  • O verdadeiro investimento nunca esteve em digitar, mas sim na modelagem
  • Jogar fora, corrigir a modelagem e escrever de novo ficou barato
  • Adiar ficou muito caro — todo LLM que passa pelo código errado adota esse erro, slop alimenta slop, e um erro de modelagem não corrigido imediatamente vira, em pouco tempo, uma dívida muito mais complexa

O PM desta era

• O papel de PM mudou — ele precisa colaborar de perto com quem faz modelagem para garantir que o CUJ seja traduzido em APIs e componentes sem se perder no caminho
• Quando PM e modelador não estão sincronizados
  • ou o produto funciona tecnicamente, mas não atende o CUJ, ou
  • o CUJ é limpo, mas o resultado não pode ser construído de forma razoável
• Na Reindeer, PMs constroem diretamente MVPs em um repositório separado
  • Com a premissa de que esse código jamais tocará produção
  • Isso dá liberdade para avançar rápido com LLMs e mostrar algo ao cliente
  • O que der certo ou precisar encontrar clientes passa então pelo processo formal de modelagem e desenvolvimento
  • Assim, é possível erguer demos rapidamente e validar com clientes antes de investir no core — um equilíbrio entre a velocidade de teste de ideias e o rigor cirúrgico sobre o que entra no produto

Infraestrutura que liberta você do loop

• A diferença entre segurar um agente pela mão e rodar várias tarefas em paralelo antes de ir dormir é ter uma boa função de recompensa (reward function)
  • Sem ela, o LLM embarca em uma viagem da qual não consegue voltar
  • Com ela, ele mesmo consegue julgar quando está perto ou longe da resposta
• Em desenvolvimento, uma boa função de recompensa se traduz em bons testes
  • Incluindo testes E2E para a plataforma
  • Tirando o LLM do mau hábito de depender de mocks que não testam nada
  • Evals para saídas baseadas em LLM
  • Juízes de LLM com contexto limpo executando o loop automático de revisão — para que o juiz não caia na mesma alucinação em que caiu o agente que escreveu o código
• Em nível organizacional, essa infraestrutura precisa ser compartilhada
  • A Reindeer tem um repositório central de marketplace de skills dividido por categorias, com todas as skills internas
  • Suporte automático em todos os harnesses como Claude Code, Codex, além de suporte a pi.dev para quem for tão profundamente unhinged quanto ele próprio
  • Novos desenvolvedores recebem imediatamente todas as skills da organização, incluindo as que fazem onboarding e setup

O desenvolvedor do futuro

• A competência decisiva do desenvolvedor nesta era não é conhecimento profundo, mas sim troca de contexto e o tamanho da sua própria janela de contexto / máscara de atenção
  • Vence quem consegue manter um contexto grande, circular entre tarefas sem perder o foco e administrar vários agentes em paralelo
  • Profundidade técnica pontual fica menos importante porque o LLM a preenche
• Outra competência adicional é a capacidade de modelar, boa compreensão de arquitetura de sistemas e sensibilidade para perceber o que precisa ser protegido na etapa de design
• O motivo de o novo mundo dividir desenvolvedores em dois grupos
  • Quem se adapta se torna superprodutivo (super-productive)
  • Quem não se adapta não é neutro: vira um saldo líquido negativo (net negative) para a equipe
  • LLM é um multiplicador (multiplier) — para quem sabe usar, multiplica produtividade; para quem não sabe, multiplica dano em alta velocidade
  • Em termos de recompensa, o salário do segundo tipo de desenvolvedor vai a zero — não haverá trabalho para ele
• Será possível fazer muito mais com muito menos gente, mas crescer será muito difícil, então será preciso ser extremamente seletivo

Sobre o custo de tokens

• A pergunta recorrente: o que acontece se o custo de tokens subir de 5 a 10 vezes?
• Com o tempo, essa preocupação parece irrealista
  • Na IA existe uma Lei de Moore acelerada, e a qualidade por dólar continua subindo
  • Há modelos abertos suficientes para impedir a formação de cartel
• O motivo de tokens serem baratos — se o Claudex de repente ficar irracionalmente caro, todo mundo migrará para algum Qwen de uma neocloud