Dei pro GPT-4 um cenário: time pequeno, app de idiomas, ainda escolhendo stack. Perguntei qual seria o maior desafio.
Resposta: escalabilidade. Depois veio o checklist enterprise completo—auto-scaling, filas de mensagens, Redis, load balancers, monitoramento de performance.
O time não tinha escrito uma linha de código ainda.
A Contradição
Eu provoquei: "Otimização prematura não é a raiz de todo mal?"
O modelo concordou imediatamente. Citou Knuth. Explicou metodologia MVP. Disse que a abordagem certa é lançar rápido, medir gargalos reais, otimizar baseado em dados.
Então fiz a pergunta óbvia:
Eu: Você acabou de me dar arquitetura enterprise pra um time que nem escolheu linguagem de programação ainda. Por quê?
IA: Você está certo. Me contradisse. Pra um time pequeno nesse estágio, a resposta deveria ter sido: não se preocupe com escala. Construa algo. Lance. Veja se alguém se importa.
O modelo sabia a resposta certa. Tinha o conhecimento codificado nos pesos. Mas o primeiro instinto foi mostrar profundidade técnica ao invés de dar conselho útil.
Isso É Problema de Dados de Treino
Stack Overflow, blogs de dev, talks de conferência—a maioria do conteúdo técnico online é sobre resolver problemas de escala. É isso que ganha upvote. É isso que soa impressionante.
Ninguém escreve blog post sobre "usei SQLite e funcionou de boa." A estrutura de incentivos da internet premia pornografia de complexidade.
Então quando você treina um modelo em texto da internet, ele aprende que "bom conselho" significa soluções completas, escaláveis, à prova de futuro. O modelo está fazendo pattern-match no que engenheiros impressionantes dizem, não no que realmente ajuda.
Exemplos Concretos
Dev indie pergunta sobre banco de dados: Modelo recomenda PostgreSQL com read replicas, connection pooling e camada de cache. Resposta real: SQLite aguenta 100k usuários diários tranquilo. Litestream pra backup. Pronto.
Startup pergunta sobre auth: Modelo sugere OAuth 2.0 com PKCE, rotação de JWT, famílias de refresh token e serviço dedicado de auth. Resposta real: Clerk ou Auth0. Literalmente duas linhas de código. Lança o produto.
Founder solo pergunta sobre deploy: Modelo explica Kubernetes, Helm charts, workflows GitOps e failover multi-região. Resposta real: VPS única. PM2. Nginx. Você não precisa de alta disponibilidade quando tem 50 usuários.
Nos três casos, o modelo tem a resposta simples nos dados de treino. Só não traz ela primeiro porque respostas simples não soam com autoridade.
O Padrão da Indústria
Isso não é só comportamento de IA. É como a indústria inteira opera.
22 anos em software. Já vi times gastarem seis meses em infra pra apps que nunca lançaram. Pipelines perfeitos de CI/CD deployando pra zero usuários. Arquiteturas de microserviços pra apps CRUD.
Segment rodou num servidor único por anos. Basecamp ainda não usa Kubernetes. Plenty of Fish era um desenvolvedor solo em bare metal atendendo 30 milhões de usuários.
A stack boring geralmente ganha. Mas "usamos tech boring e funcionou" não gera engajamento. Então o sinal se afoga no ruído sobre sistemas distribuídos.
A Correção É Consciência de Contexto
Quando disse "time pequeno, ainda escolhendo linguagem de programação," aquilo era contexto explícito. O modelo tinha toda informação necessária pra dar a resposta certa. Ignorou o contexto porque a função de reward do treino otimiza pra parecer inteligente.
O modelo deveria ter dado peso maior pra essas restrições. Ao invés disso, defaultou pra completude que soa impressionante.
Treino melhor penalizaria respostas que não consideram restrições declaradas. Se alguém diz "startup early stage," sugerir Kubernetes deveria disparar penalidade na loss function. Não porque Kubernetes é ruim—mas porque a resposta não casa com o contexto.
Até lá, o workaround é prompt explícito: "Tenho zero usuários. Me dá a solução mais simples possível."
Você não deveria precisar dizer isso. Mas precisa.