Publiquei seis artigos esta semana. Um sobre PostgreSQL. Outro sobre agentes de IA. Outro sobre gestão de contexto. Um tutorial de automação. Uma análise de debugging. E um design de conselho adversarial para avaliar MVPs.
Não foi algo planejado. Cada artigo surgiu a partir de um paper, uma palestra ou um projeto que achei interessante de forma isolada. Mas, ao vê-los juntos, há um fio condutor que eu não tinha percebido enquanto escrevia.
Os seis dizem a mesma coisa.
O padrão que eu não procurei
Começou com o artigo de Bohan Zhang sobre como a OpenAI escala o PostgreSQL. A conclusão era brutal: 800 milhões de usuários, um único primary, sem sharding. PgBouncer (2007). Read replicas (conceito dos anos 90). A tecnologia mais chata do planeta, ainda funcionando numa das aplicações mais utilizadas da história.
Depois veio Michael Bolin desmontando as entranhas dos coding agents. Codex CLI, Claude Code — tanto faz. Por dentro, são apenas um loop while com um LLM. Sem grafos de conhecimento. Sem planejadores simbólicos. Um loop, ferramentas e o modelo que decide quando parar. A “mágica” era apenas um while True.
Os Cookbook articles da OpenAI sobre context engineering foram o próximo capítulo. Gerenciar o que o modelo “vê” é mais importante do que o modelo em si. E as técnicas apresentadas são antigas: injetar contexto no início (um README), cortar o histórico (um buffer circular), condensar o antigo (um resumo). Nada muito diferente do que faziam os sistemas de chat dos anos 2000.
O tutorial de automação bateu ainda mais o ponto: as Codex Automations da OpenAI são, literalmente, cron + curl + um LLM. O scheduler mais entediante de todos os tempos, Unix, acionando o modelo mais avançado do planeta. A infraestrutura tem 40 anos. O cérebro tem 2.
Então vieram dois posts que não são sobre infraestrutura. No desafio da Jane Street, uma rede neural de 2.500 camadas acabou sendo apenas MD5. Resolveram o problema com debugging clássico: observar o formato dos dados, reduzir o problema, acumular restrições até que restasse apenas uma solução. As ferramentas eram novas (solucionadores SAT, ChatGPT). O método era antigo (eliminação sistemática de hipóteses).
E o conselho adversarial para MVPs: simular cinco especialistas com um LLM para avaliar ideias antes de construí-las. Parece futurista, até você perceber que é um wargame. Os militares fazem isso desde os anos 50. As equipes de produto chamam de pre-mortem. O que há de novo é que o painel agora custa 2 dólares em tokens, em vez de 50 mil em consultores.
A tese (que não é minha)
Não estou dizendo nada original. Isso já foi dito por Dan McKinley em 2015, com sua palestra “Choose Boring Technology”. DHH repete isso sempre que alguém propõe Kubernetes para um CRUD. Fred Brooks já dizia isso em 1975, no artigo sobre a ausência de balas de prata.
Mas esta semana trouxe seis exemplos independentes que provam isso, em domínios diferentes:
| Domínio | O “entediante” que funciona | O “novo” que promete mais |
|---|---|---|
| Bancos de dados | PostgreSQL + PgBouncer | Banco distribuído com sharding |
| Agentes de IA | loop while + ferramentas | Arquitetura multiagente com orquestrador |
| Gestão de contexto | YAML + README + buffer circular | RAG com vector store + embedding pipeline |
| Automação | cron + bash + curl | Plataforma de orquestração cloud-native |
| Debugging | Observar → reduzir → hipóteses → verificar | Ferramentas de interpretabilidade end-to-end |
| Avaliação de ideias | Debate estruturado com frameworks conhecidos | Plataforma de market research com dados de painel |
A coluna da esquerda é o que as pessoas usam de verdade para resolver problemas em escala. A coluna da direita é o que é vendido nas conferências.
Por que isso acontece
Não é que a tecnologia nova seja ruim. É que ela resolve problemas que a maioria das equipes nem sequer têm.
A OpenAI não precisa de sharding porque seu padrão de acesso é 95% leitura. Um único primary aguenta todos os writes porque eles fizeram o trabalho de identificar quais eram os mais pesados e os deslocaram para outros sistemas. Nada sexy. Foi pura cirurgia de precisão.
Os coding agents não precisam de arquiteturas sofisticadas porque o modelo já é bom o suficiente para decidir, dentro de um loop simples, qual ferramenta utilizar e quando parar. A complexidade do orquestrador é inversamente proporcional à inteligência do modelo.
cron não precisa de substituto porque 99% das automações são “execute isso a cada N horas”. Se sua automação precisar de algo mais — event sourcing, compensação de falhas, retry com backoff — sim, será necessário algo diferente. Mas, na maioria das vezes, não será. E o que não é necessário, só atrapalha.
A armadilha do artesão
Há uma armadilha cognitiva que explica por que continuamos buscando a ferramenta mágica. Chama-se complexity bias: a tendência de preferir soluções complexas em vez de simples, porque as complexas parecem mais adequadas para problemas difíceis.
Quando seu banco de dados está lento, a solução “mova os writes pesados para outro lugar” soa como uma gambiarra. A solução “implemente sharding com consistent hashing e rebalanço automático” soa como engenharia. E, como engenheiros, gostamos de soluções que parecem engenharia.
Mas a gambiarra que funciona é melhor do que a engenharia que nunca chega a se concretizar.
A OpenAI poderia ter gastado seis meses implementando sharding. Em vez disso, moveram algumas cargas para Cosmos DB e investiram esse tempo desenvolvendo funcionalidades para seus 800 milhões de usuários.
Falando em termos simples: o custo de oportunidade da solução elegante é o que você deixa de construir enquanto está ocupado com ela.
O que isso implica para você
Não é que você não deva aprender tecnologias novas. Mas, antes de adotá-las, deveria perguntar a si mesmo:
Que problema eu tenho que a tecnologia entediante não resolve?
Se a resposta for “nenhum, mas a nova é mais moderna”, você está adicionando complexidade sem nenhum benefício. E a complexidade sempre cobra. Em bugs, custos de onboarding, noites em claro.
Se a resposta for “eu preciso de X e o PostgreSQL não faz isso” — perfeito. Vá para algo novo. Mas seja específico sobre o que é o “X”.
Eu consigo resolver isso com o que já tenho, usando um pouco de disciplina?
A OpenAI resolveu o gargalo de conexões com o PgBouncer. Eles não mudaram de banco de dados. Não reescreveram a camada de acesso a dados. Colocaram um connection pooler na frente. O que precisaram foi disciplina: identificar o problema real, e não o problema que queriam resolver.
Estou resolvendo um problema real ou um problema que pode acontecer?
“Isso não vai escalar” é a frase mais cara da engenharia de software. Porque quase sempre é verdade — tecnicamente, nada escala infinitamente. Mas, na prática, 99% dos projetos morrem antes de precisar escalar. E o 1% que sobrevive terá tempo e dinheiro suficientes para resolver o problema quando ele aparecer.
A disciplina não é glamourosa
Não é que não seja legal usar um banco de dados distribuído, escrito em Rust e com um protocolo de consenso próprio. Isso, com certeza, é legal. Dá boas palestras e fica incrível no LinkedIn.
Mas, se você precisa de um PostgreSQL com um connection pooler e queries bem otimizadas, o banco distribuído é um custo sem nenhum benefício. E o custo não é apenas técnico — é também de atenção. Cada hora configurando o cluster é uma hora que não é gasta entendendo seus dados, otimizando as queries ou conversando com seus usuários.
A disciplina entediante — queries simples, timeouts agressivos, isolamento de cargas, cron que roda scripts, READMEs mantidos atualizados, debugging metódico — não aparece em keynotes. Não tem logo. Não tem conferência própria.
Mas essa é a abordagem que funciona quando tudo o mais dá errado.
E essa semana, seis artigos independentes me lembraram disso ao mesmo tempo. Às vezes, o fio condutor aparece sozinho. Só é preciso estar atento.
Os seis artigos da semana:
- OpenAI escala PostgreSQL para 800M usuários com um único writer — O banco de dados experiente que cumpre o que as novas tecnologias prometem.
- Seu AI coding agent é um while loop com delírios de grandeza — Expondo a “mágica” do Codex CLI e Claude Code.
- Context engineering: a habilidade invisível — O que o modelo vê importa mais do que o próprio modelo.
- Codex Automations sem Codex — cron + bash + LLM = agentes noturnos.
- Uma rede neural de 2.500 camadas que na verdade é MD5 — Debugging clássico aplicado a ML.
- Cinco especialistas que não existem revisam sua startup — Debate adversarial como ferramenta de decisão.