Como se tornar um engenheiro de IA 30x com bom gosto

• Na era em que a IA gera código em massa, a principal capacidade que diferencia o valor de um engenheiro não é velocidade, conhecimento ou experiência, mas sim o “bom gosto (taste)”, ou seja, a capacidade de avaliar o que deve ser construído
• Integrantes da equipe do OpenAI Codex chegaram independentemente à mesma conclusão, e qualquer pessoa com bom gosto por software pode se tornar um engenheiro 10x
• O gosto se divide em três formas: reconhecimento (recognition), bússola (compass) e visão (vision), e todas convergem para um único mecanismo: a qualidade da função interna de avaliação
• O valor se concentra em cinco áreas: escolha do problema, arquitetura de sistema, julgamento de qualidade, empatia com o usuário e comunicação
• Agora que escrever código virou commodity, julgamento e raciocínio são a verdadeira competência central e precisam ser desenvolvidos de forma intencional

---

O mundo mudou, mas a maioria dos engenheiros ainda não percebeu

• Em março de 2025, Dario Amodei, CEO da Anthropic, previu que a IA escreveria 90% do código em poucos meses; na época, isso soava absurdo
• Boris Cherny, criador do Claude Code, relatou que, em dezembro, 100% do código que ele commitou havia sido escrito por IA, e que ele não abriu a IDE nem uma vez
• Andrej Karpathy, que chamava ferramentas de programação com IA de “slop”, mudou completamente de posição em dezembro
  • “Nunca me senti tão para trás como programador, e a profissão está sendo dramaticamente reorganizada”
  • DHH, criador do Ruby on Rails, admitiu que a resistência existia porque “os modelos não eram bons o suficiente”, e que agora a situação se inverteu
  • Malte Ubl, CTO da Vercel, mencionou que “o custo de produção de software está convergindo para zero”
• Entre novembro e dezembro de 2025, Opus 4.5, GPT-5.2 e Gemini 3 ultrapassaram fronteiras invisíveis de capacidade, fazendo com que, em uma ampla variedade de tarefas, o código gerado por IA alcançasse o nível de engenheiros experientes, enquanto o tempo necessário caiu de horas para minutos
• Quando a geração de código vira commodity, o que sobra é a engenharia de software (decompor problemas, decidir o que construir, projetar testes, confiabilidade e escalabilidade, julgar trade-offs) — em suma, gosto

O que é gosto na prática

• Existem três definições de gosto segundo as melhores equipes de engenharia, e elas são apenas ângulos diferentes da mesma capacidade

• Gosto como reconhecimento (Recognition)

  • A capacidade de sentir qual das duas implementações é melhor antes mesmo de conseguir explicar por quê
  • Emma Tang: saber se um sistema é realmente limpo, escalável, sem redundâncias e simples de entender é uma questão de gosto
  • Como um chef que prova um molho e sabe que falta acidez antes mesmo de identificar isso conscientemente, o pattern matching funciona mais rápido que o raciocínio consciente
  • O caso em que a equipe do Codex escolheu Rust em vez de TypeScript para o CLI
    • Ambos funcionariam, mas reconheceram que as restrições do Rust (tipagem forte, gerenciamento explícito de memória, dependências mínimas) geravam, além de vantagens técnicas, um efeito cultural de engenharia
    • O julgamento não foi de “linguagem tecnicamente superior”, mas de “linguagem que molda os comportamentos desejados na equipe”
  • Mau gosto: escolher Rust só porque está na moda ou porque um blog disse que é mais rápido, sem entender os efeitos de segunda ordem

• Gosto como bússola (Compass)

  • A forma descrita por Tibo ao dizer que um engenheiro precisa ter “sua própria bússola”: não é avaliar o que já existe, mas saber o que construir em seguida
  • O engenheiro que diz “essa não é a funcionalidade certa” antes de escrever uma única linha de código
  • O caso em que Boris Cherny criou a funcionalidade de lista de tarefas do Claude Code em dois dias com cerca de 20 protótipos
    • Ele testou todo inline, UI em drawer, pill interativa, exibição na parte inferior da tela e outros formatos, convergindo para algo que parecia inevitável, e não arbitrário
    • Depois foi possível explicar por que a versão final era melhor, mas a insatisfação inicial com as versões intermediárias já era, por si só, o gosto funcionando como bússola
  • O gosto como bússola é mais raro que o gosto como reconhecimento, porque atua mais a montante da execução

• Gosto como visão (Vision)

  • Expresso na frase de SQ Mah de que “os humanos definem a evolução”, é a forma mais difícil: saber não o que é bom agora, mas o que será importante daqui a 2 anos
  • Peter Steinberger, criador do OpenClaw, roda de 5 a 10 agentes ao mesmo tempo e dedica a maior parte do tempo à arquitetura e ao design de sistemas
    • Ele comentou que “a maior parte do código é transformação de dados entediante” e que a energia deve se concentrar no design do sistema
  • A próxima prioridade da equipe do Codex é o planejamento baseado em contexto rico, que exige informações fora do codebase, como objetivos de negócio, dinâmica de mercado e prioridades da equipe
    • Não é apenas um gerador de código melhor, mas uma visão aplicada à estratégia de produto em direção a um futuro em que o modelo entende por que o software existe

• Definição integrada

  • As três formas convergem para um único mecanismo: gosto é a qualidade da função interna de avaliação
  • No reconhecimento, a função de avaliação opera sobre o resultado pronto; na bússola, sobre possibilidades e direção; na visão, sobre futuro e trajetória
  • Em um mundo em que a IA gera código, o trabalho humano é avaliar (decidir o que construir, julgar se o resultado é suficiente, detectar o momento de mudar a arquitetura), e avaliar passa a ser o próprio trabalho

Por que alguns engenheiros ganham muito mais

• Antes da IA, a diferença de remuneração era explicada por três fatores — empresa, senioridade e área de especialização —, mas a IA está misturando todas essas variáveis
• Em startups, a diferença entre um engenheiro excelente e um engenheiro mediano se ampliou de 3x para 10x, porque o excelente usa IA para entregar o output de uma equipe pequena
• O eixo da senioridade mudou: a experiência em escrever código importa menos do que a experiência em fazer bons julgamentos
  • O valor de “conhecer React” caiu, enquanto o valor de “conseguir projetar sistemas confiáveis sob carga” subiu
• O ponto em comum dos engenheiros com maior diferença de impacto é tomar decisões que se acumulam com juros compostos
  • Uma boa decisão de arquitetura pode economizar meses de trabalho ao longo de um ano
  • Uma boa decisão de produto pode determinar se uma funcionalidade será de fato adotada ou não
• Mesmo trabalhando mais, é possível gerar só metade do valor de alguém com gosto melhor; colocar 2 agentes no problema certo produz mais valor do que colocar 8 no problema errado
• No caso da OpenAI, os engenheiros mais produtivos não passaram a gerar mais código, mas a dedicar mais tempo a conversas com usuários, direção de produto e empatia, mudando seu foco
  • Alguns voltaram ao autocompletar por tabulação, dizendo que “perdiam a sensibilidade do codebase”, e ambas as reações são válidas

Onde o valor é realmente gerado

• Existem cinco áreas em que o bom gosto cria valor desproporcional; a maioria dos engenheiros compete apenas em uma ou duas delas

• Zona 1: escolha do problema

  • Decidir o que fazer é a escolha de bom gosto com maior alavancagem, mas a maioria quase não pensa nisso
  • Engenheiros com bom gosto perguntam: “Se eu resolver bem isto, outros cinco problemas desaparecem?”
  • Peter Steinberger passa longos ciclos de troca com o agente, refinando o plano, desafiando e contestando, e só executa o agente quando está satisfeito; o plano é o trabalho, e a execução é delegada
  • No sistema de permissões do Claude Code, em vez de RBAC complexo e políticas granulares, foi escolhida a abordagem mais simples possível (pedir permissão e depois lembrar a resposta), o que permitiu lançar algo rápido e intuitivo

• Zona 2: arquitetura de sistemas

  • É a forma como as peças se encaixam, a área em que a meia-vida do bom gosto é mais longa; boas decisões ainda rendem dividendos dois anos depois, enquanto más decisões se acumulam como dívida técnica que exige reescrita
  • A decisão de transformar o loop de agentes do Codex em uma máquina de estados, a decisão do Claude Code de escrever “o mínimo possível de lógica de negócio” e a obsessão do OpenClaw por extensibilidade modular são todas decisões de bom gosto arquitetural
  • Boris Cherny: “A cada novo modelo, apagamos um monte de código e mantemos o mínimo possível de código em volta do modelo”
    • A maioria dos times adiciona código a cada release, mas o time do Claude Code remove; o modelo é o produto e tudo ao redor deve ser o mais enxuto possível

• Zona 3: julgamento de qualidade

  • É saber se algo já está bom o bastante para lançar ou se ainda precisa de mais trabalho, uma área em que a IA não consegue ajudar (porque não sabe o que é “bom o suficiente” em um contexto específico)
  • Revisão de código em camadas no Codex: código não essencial recebe apenas revisão de IA; código central do agente exige revisão humana
    • O bom gosto está em saber qual código realmente importa; o sistema de permissões precisa de olhos humanos, já a atualização do README não
  • O time do Codex escreve quase todo o código via prompt, mas outras áreas internas ficam em cerca de 70%; os 30% escritos à mão são as partes em que o julgamento de qualidade mais importa (“regra 30/70”)

• Zona 4: empatia com o usuário

  • É entender do que o outro ser humano realmente precisa, a área em que a IA é mais fraca
  • As mensagens contextuais de carregamento do Claude Code criadas por Boris (mostrando o que o modelo está fazendo, em vez de só um spinner) não foram pedidas por ninguém, mas foram feitas por causa da diferença entre esperar sem informação e esperar com informação
  • O padrão de sandbox do Codex também é uma decisão de empatia com o usuário; Tibo: “Mesmo que isso reduza a adoção, não recomendamos por padrão algo que possa não ser seguro”
    • Isso parte do entendimento de que muitos usuários “não são tão técnicos” e podem, por engano, fazer algo irreversível; escolhe-se segurança em vez de conveniência

• Zona 5: comunicação e storytelling

  • É como você enquadra o que construiu, uma área que engenheiros consistentemente subestimam, mas que o mercado recompensa
  • O OpenClaw de Peter Steinberger registrou, em uma semana viral, mais buscas no Google do que Claude Code e Codex somados
    • Nome claro, demo convincente e a narrativa de que “uma pessoa produz como um time inteiro” impulsionaram a disseminação
  • O arquivo AGENTS.md do Codex (um README para agentes de IA, não para humanos) mostra um bom gosto de comunicação que reconhece que o público da documentação mudou e adapta o formato a isso

Exemplos de bom gosto (e da sua ausência)

• Escolha da stack tecnológica

  • Sem bom gosto: “TypeScript, porque é o mais popular e todo mundo conhece”, justificado por convenção
  • Com bom gosto: Boris escolheu TypeScript porque está “on distribution” para os modelos Claude (algo com que o modelo já lida bem), otimizando para a força do modelo, não para o conforto do time
    • O Codex escolheu Rust porque queria dependências mínimas que permitissem “refletir sobre os padrões de engenharia definidos” e inspecionar tudo diretamente; é a mesma categoria de decisão, mas em ambos os casos baseada em restrições concretas, não em preferência genérica

• Lidar com código que você não entende completamente

  • Sem bom gosto: “Foi gerado por IA e passou nos testes, então vamos lançar”, sem considerar suficiência dos testes nem manutenibilidade
  • Com bom gosto: Peter lança código que não leu por completo, mas não de forma descuidada; “ele conhece a localização e a estrutura dos componentes, e o desenho do sistema como um todo, e isso geralmente basta”
    • Testes, linting e CI local formam camadas de validação; de um lado há aposta, do outro há um sistema em que a correção é garantida estruturalmente

• Resposta a solicitações de funcionalidades

  • Sem bom gosto: implementar exatamente como está no ticket, lançar e passar para a próxima
  • Com bom gosto: Boris faz 20 protótipos em dois dias antes do lançamento; não é lentidão, é experimentação rápida para navegar até a solução certa; a inevitabilidade é a impressão digital do bom gosto

• Projetar para agentes de IA

  • Sem bom gosto: um README comum com instruções de configuração e endpoints de API
  • Com bom gosto: o Codex escreve um AGENTS.md que ensina à IA como explorar a base de código, quais comandos de teste usar e como seguir os padrões; a base é estruturada para que o modelo inevitavelmente consiga ter sucesso

• Lidar com uma enxurrada de PRs

  • Sem bom gosto: os PRs gerados por IA se acumulam, mas o processo de revisão continua o mesmo, sobrecarregando revisores e reduzindo a qualidade
  • Com bom gosto: o time de Emma Tang exige que o PR venha com o prompt anexado; se não vier, perguntam no Slack: “qual foi o prompt?”
    • No mundo da IA, revisar a intenção é mais útil do que revisar o código; Peter chama PRs de “prompt requests” e se interessa mais pelo prompt de geração do que pelo código; se a unidade de geração mudou, a unidade de revisão também muda

Um plano para cultivar bom gosto (não admiração)

• O conselho “ganhe mais experiência” é tão inútil quanto “faça mais exercício”; abaixo está um plano de 90 dias em três formas

• Mês 1: construir bom gosto de percepção com exposição estruturada

  • O mecanismo é grande exposição a variação, seguida de reflexão deliberada
  • Semanas 1–2: estudar 10 ferramentas de desenvolvedor que você admira
    • Instale Codex CLI, Claude Code, Linear, Supabase, dashboard do Stripe, Vercel, Tailwind, Railway, Resend e 1 produto não relacionado a software (uma exposição de museu bem desenhada ou o cardápio de um restaurante)
    • Para cada um, escreva por 15 minutos: o que você percebeu nos primeiros 60 segundos, o que trouxe alegria, o que gerou confusão, que decisão você copiaria
    • Ferramentas boas mostram o resultado nos primeiros 30 segundos antes de explicar o processo; ferramentas ruins explicam a arquitetura antes de mostrar por que você deveria se importar
  • Semanas 3–4: estudar 10 papers pela metodologia, não pela descoberta
    • O paper original da métrica BLEU, o paper de Constitutional AI da Anthropic, o paper do PageRank do Google, o registro do Netflix Prize e papers sobre Scaling Laws
    • Escreva: o que torna a metodologia elegante, qual é o insight que a faz funcionar, como aplicá-la ao seu domínio
    • Você perceberá que princípios estruturais como critérios de avaliação claros, divulgação honesta de limitações e formulações simples em vez de complexidade se repetem entre áreas

• Mês 2: construir bom gosto de bússola com discernimento ativo

  • Exercício semanal “Side-by-Side”: encontre dois exemplos do mesmo tipo e escreva 500 palavras explicando por que um é melhor
    • “Eu prefiro” é proibido; sempre explicite o mecanismo concreto com “isto é melhor porque...”
    • Exemplo: a documentação do Stripe é melhor porque se organiza em torno do que o desenvolvedor quer fazer (enviar pagamentos, tratar erros), e não da arquitetura interna
  • Exercício diário “Practice Noticing”: toda vez que olhar uma ferramenta, paper ou código, escolha uma decisão do criador e registre em uma frase “por que foi isso e não a alternativa óbvia”; depois de 30 dias, os padrões nas 30 observações mostram o bom gosto em formação

• Mês 3: construir bom gosto de visão com aplicação gerativa

  • Semana 9: redesenhe algo que você controla (fluxo de onboarding do time, README de projeto, experiência do desenvolvedor no pipeline de avaliação) com base no que aprendeu
  • Semana 10: escreva o texto mais preciso da sua vida até agora; não o mais longo nem o mais abrangente, mas aquele em que cada parágrafo faz seu trabalho e muda a forma de pensar do leitor
  • Semana 11: projete um sistema do zero e explique cada decisão por primeiros princípios, não por convenção (“microservices porque é best practice” não, mas “monólito porque o time tem 4 pessoas, o tráfego é previsível e a simplicidade de deploy vale mais do que benefícios de escala que não serão necessários pelos próximos 18 meses”)
  • Semana 12: compartilhe o bom gosto; ensine a diferença entre duas abordagens e escreva um AGENTS.md para sua própria base de código; a capacidade de codificar bom gosto em sistemas e documentos é o que separa habilidade individual de capacidade organizacional

Cinco projetos para desenvolver bom gosto rapidamente

• 1. Construir um framework de avaliação para código gerado por IA

  • Não um linter ou test runner, mas um framework que responda à pergunta “este código de IA é bom o suficiente para produção?”, com definição de rubricas próprias (correção, manutenibilidade, eficiência, segurança, estilo)
  • Aplicar e pontuar em 50 PRs reais gerados por IA, calibrar a rubrica com base em pontuações surpreendentes, publicar os resultados e desenvolver o gosto da Zona 3 (julgamento de qualidade)

• 2. Redesenhar o onboarding de um projeto open source

  • Fazer um fork de uma ferramenta cuja tecnologia você respeita, mas cujo onboarding é frustrante, redesenhar os primeiros 5 minutos da experiência do desenvolvedor, escrever README e guia de início, e estruturar tudo para que novos contribuidores consigam abrir um PR no primeiro dia
  • Desenvolver ao mesmo tempo a Zona 4 (empatia com o usuário) e a Zona 5 (comunicação)

• 3. Criar um “teste de gosto” para a equipe

  • Escrever um documento com 10 pares de abordagens de implementação, em cada par uma delas representa um gosto melhor, e perguntar a 5 engenheiros qual é a melhor e por quê
  • O resultado interessante não é a resposta certa, mas a divergência de opinião; os pontos em que os padrões se desalinhavam são a origem de bugs, dívida técnica e retrabalho, e isso constrói o gosto organizacional de maior alavancagem

• 4. Lançar um produto com a restrição de 48 horas

  • Não um protótipo, mas um produto funcional que outras pessoas possam usar; a restrição de tempo força constantemente decisões de gosto (o que incluir e o que cortar)
  • Se você gastar 6 horas em uma funcionalidade errada, queimará um quarto do tempo, então as consequências de más decisões são imediatas

• 5. Escrever um blog técnico que mude a forma de pensar

  • Não um tutorial ou how-to, mas um texto que reorganize conceitos familiares para que o leitor passe a enxergá-los de outra forma depois disso (perceber que gosto é, no fim, avaliação; entender que apagar código a cada novo release de modelo não é costume, mas uma filosofia de arquitetura)
  • Desenvolver a Zona 5 (comunicação e storytelling), sendo que uma perspectiva genuína é a base de todo gosto

Otimizando a carreira com foco em gosto

• Parar de competir por velocidade

  • Se a IA escreve código na velocidade da máquina, competir por velocidade de codificação é um jogo perdido; vale mais a pessoa que pensa por 30 minutos sobre quais 50 linhas realmente são necessárias do que a que gera 500 linhas por hora
  • Velocidade de implementação virou commodity, e o que não virou commodity é o julgamento sobre o que implementar e como implementar

• Investir em “habilidades adjacentes” necessárias ao gosto

  • O traço comum dos melhores engenheiros é que eles não são apenas coders; Boris é fundador de startup, Emma liderou infraestrutura de dados por 4 anos na Stripe, Peter transformou a PSPDFKit em um negócio global
  • O gosto precisa de matéria-prima; pensamento de produto, percepção de design, entendimento de negócios e capacidade de comunicação são os materiais que tornam o gosto possível

• Escolher funções em que o gosto é recompensado

  • Funções focadas em implementar especificações bem definidas recompensam velocidade; funções que decidem o que construir, como construir e o que é suficiente recompensam diretamente o gosto
  • Funções em que o gosto é especialmente recompensado: engenheiro fundador em startup inicial, tech lead em empresa de produto, engenheiro de plataforma ou infraestrutura que projeta os sistemas sobre os quais outros engenheiros trabalham, engenheiro de experiência do desenvolvedor e engenheiro staff+ que lida com decisões de arquitetura entre equipes

• Construir entregas públicas que carreguem gosto

  • Na era da IA, portfólio importa mais que currículo; a prova está nas entregas (open source bem projetado, blog técnico com ponto de vista consistente, produto que as pessoas realmente usam)
  • O OpenClaw de Peter fala mais alto do que qualquer currículo, e o protótipo Claude Code de Boris demonstra seu gosto melhor do que qualquer resposta em entrevista comportamental

A verdade desconfortável

• O gosto é distribuído de forma desigual e continuará sendo; alguns o cultivaram ao longo de 15 anos e milhares de decisões, com uma vantagem de largada impossível de alcançar com um plano de 90 dias
  • A equipe do Codex trabalha em uma empresa que cria modelos com acesso ilimitado a tokens, e Peter tem um ponto de partida atípico, com 20 anos de carreira e uma empresa vendida com sucesso
• Ainda assim, a diferença entre “sem gosto” e “algum gosto” é enorme em impacto de carreira e pode ser reduzida; o salto de alguém que só recebia tickets para implementar e passa a propor o que construir com base em pesquisa com usuários, além de usar IA para implementar até testes e arquitetura, é justamente o gosto
• O relato honesto de Gergely Orosz: “parece que algo valioso está sendo arrancado de repente; foi preciso muito esforço para eu me tornar bom em programar, e minhas melhores lembranças são de entrar em fluxo e digitar ideias”
  • A sensação de perda por a habilidade de codar manualmente se tornar menos central é real, mas a capacidade de saber que código deve existir, como ele deve ser estruturado e o que é suficiente sempre foi a competência real
• Os próximos engenheiros a prosperar serão os que entenderem isso; gosto sempre foi o trabalho, só estava escondido dentro do código, e a IA, ao assumir a digitação, está revelando isso

[clastneo]

Caramba, agora nem 10x basta mais e já temos que pensar em 30x kkk

[channprj]

Eu também queria parar de ver essas expressões um tanto exageradas como engenheiro de x vezes.. T_T
Embora pareçam quantitativas, na verdade também são expressões qualitativas.