O problema que nenhuma assinatura de IA resolve
Sua empresa comprou IA para todo mundo. Três meses depois, tem mais código, mais bugs, e os mesmos problemas de sempre.
Novidade: lançamos o banco de perguntas de entrevistas reais do NaGringa. Já tem 1130+ perguntas de empresas internacionais, filtrável por empresa, senioridade e tipo. Você também pode contribuir com perguntas que recebeu em processos seletivos. Dá uma olhada nos filtros completos aqui.
Você ouviu que IA ia tornar todo engenheiro 10x mais produtivo.
Seu chefe leu que o Stripe está shippando 1300 PRs por semana1.
A empresa agora investiu: assinaturas de IA para todo mundo, Copilot em cada IDE, agentes no CI, Claude Code rodando automaticamente.
Três meses depois, o time está produzindo mais código do que nunca. Mais PRs, mais deploys, mais features.
E os mesmos problemas de antes. Ou piores: mais bugs, mais incidentes, mais retrabalho.
O código ficou mais rápido. O resultado, não.
Eu não precisei de IA para cometer esse erro. Fiz isso sozinho, antes de IA sequer existir do jeito que existe hoje.
Na Brex, passei semanas refatorando um componente de UI. Organizei o código, escrevi os testes, abri o PR. Tudo passou.
O resultado pro produto? Zero. Ninguém pediu aquela refatoração, e ela não resolveu nenhum problema real.
Refatoração não é desperdício por definição, mas aquela não tinha critério de sucesso. Não era “reduzir tempo de build de 8 para 2 minutos” ou “desbloquear o time Y para lançar feature Z”. Era código mais bonito sem um porquê.
Alguns meses depois, olhei para um dado diferente: 40% dos usuários abandonavam o fluxo de Bill Pay antes de completar.
Ninguém tinha me pedido para investigar isso. Instrumentei os eventos por conta própria porque queria entender se havia problemas no fluxo.
E havia. Vários campos tinham taxas de erro altíssimas. Usuários esqueciam de preenchê-los ou colocavam valores errados. A validação do backend falhava silenciosamente, travando o processo.
A solução não foi complexa: criei o conceito de campos “inteligentes”.
Pré-preencher com o último método de pagamento usado
Mostrar as últimas 3 contas pagas para o usuário poder copiar valores
Se um campo não mudou nas últimas 3 transações (como a conta de destino), já vem preenchido
Se havia apenas uma opção para o campo, selecionar automaticamente
Tudo sobre empurrar a complexidade para o código e simplificar a vida do usuário. Conversão subiu 26%, cerca de 160 usuários a mais por dia completando o fluxo.
Mesma habilidade técnica nas duas situações. A diferença foi que no Bill Pay eu tinha um sinal claro de que algo estava errado e uma definição de sucesso antes de abrir o editor.
Essa diferença ficou ainda mais clara quando a IA entrou de vez no meu trabalho. IA acelera execução: você escreve, refatora, testa em uma fração do tempo.
Mas IA não muda a pergunta que você faz antes de abrir o editor. E é essa pergunta que decide se o trabalho importa.
Um problema mais antigo do que você pensa
O problema de construir a coisa errada não é novo.
Marty Cagan já dizia em Inspired: “O maior risco é sempre construir algo que ninguém quer.” Donald Reinertsen mostrou em The Principles of Product Development Flow que reduzir tempo de execução sem melhorar a qualidade das decisões pode aumentar o desperdício.
Essa tensão entre velocidade e clareza existe há décadas.
O que mudou é que o custo natural do desenvolvimento costumava funcionar como um freio. Quando escrever código era caro, times eram forçados a pensar antes de construir. Havia uma pressão de seleção que filtrava ideias ruins antes delas virarem código.
IA removeu esse freio. Execução ficou barata, mas o custo de estar errado continua o mesmo.
Luca Rossi, da Refactoring.fm, tem uma analogia que captura bem essa dinâmica: desenvolvimento de software é um jogo de telefone sem fio2.
Tudo começa com a intenção de alguém. Essa intenção vira um documento de produto. Que vira um design. Que vira uma spec técnica. Que vira código. Que vai para produção. Cada etapa é uma chance da mensagem original se distorcer.
IA acelerou as etapas mais próximas do código. As primeiras etapas da cadeia, onde a intenção original se define, seguem sendo lentas, humanas e propensas ao erro.
Mike Krieger, co-fundador do Instagram, colocou isso de forma direta3: “Os modelos são bons em adicionar features. Eles não são necessariamente bons em descobrir o que cortar do produto.”
Ele foi além. Na Anthropic, construiu um produto inteiro com Claude antes do lançamento e percebeu que tinha adicionado funcionalidade demais. “Criamos uma matriz de funcionalidades que era difícil de testar e difícil de explicar para as pessoas.”
É o que ele chama de construir a árvore dentro de casa, sem exposição ao vento: ela cresce, mas não tem a estrutura que vem do contato com o mundo real.
Com IA, a tentação de adicionar “só mais uma feature” ficou ainda maior, porque o custo percebido de cada adição caiu perto de zero.
O problema não está onde você pensa
Luca Rossi publicou uma pesquisa com 340 times de engenharia4 que traz dados sobre onde exatamente a cadeia quebra. E o resultado foi contraintuitivo.
A maioria das pessoas assume que o problema começa na definição do problema, na falta de clareza sobre o “por quê”. Mas os dados sugerem o oposto: os engenheiros geralmente acreditam que entendem o porquê. O que eles não sabem é o que significa “feito”.
Vale uma ressalva: são dados auto-reportados. Há uma diferença entre acreditar que você entende o problema e realmente entendê-lo.
Mas mesmo com essa limitação, o gap entre “entendo o porquê” e “sei o que feito significa” é grande demais para ignorar.
Um tech lead que respondeu à pesquisa resumiu bem: “Os desenvolvedores não fazem perguntas suficientes durante o refinamento, o que leva a tickets incompletos. Ao mesmo tempo, os POs fornecem critérios de aceite muito genéricos.”
E aqui está a ironia: o investimento de IA está desalinhado com o problema.
A maioria usa IA para escrever código. Faz sentido, já que é onde IA é mais capaz hoje.
Mas os problemas que causam retrabalho, requisitos vagos e definição de “feito” incompleta, continuam intocados. Conforme IA ficar melhor em ajudar com discovery e requisitos, essa distribuição deveria mudar. Por enquanto, o gap existe.
A pergunta certa antes de uma linha de código
Voltando ao PostHog: quando comecei a trabalhar no Surveys, o onboarding era confuso. Formulários grandes, campos desconexos, customização demais exposta de uma vez.
Ninguém me pediu para mexer nisso. Era minha área de responsabilidade, então fui investigar. Instrumentei para entender quantas pessoas desistiam do fluxo de criação.
Tentei uma abordagem: menos campos visíveis, um wizard guiado, menos opções por etapa. A definição de sucesso era clara: mais surveys sendo criadas.
A taxa de conversão do onboarding melhorou 93%. Hoje, mais de 40% de todas as surveys são criadas por aquela tela.
O padrão é o mesmo nos dois casos, Brex e PostHog. O trabalho que gerou impacto foi o trabalho com uma definição clara de sucesso. O trabalho que sumiu foi o trabalho bem executado sem saber o que “feito” significava.
Isso é o que engenheiros de produto fazem diferente: eles não esperam o ticket chegar perfeito. Eles constroem a clareza que precisam antes de abrir o editor.
Luca Rossi chama isso de “ficar na altitude certa” no processo de desenvolvimento[1-1]. Cada etapa da cadeia exige um tipo diferente de artefato, e você precisa inspecionar a coisa certa em cada ponto.
Se você está inspecionando código mas o problema está na definição do que deveria ser construído, nenhum code review vai resolver.
O engenheiro que Gergely Orosz descreveu como top 3% na Uber5 tinha um método específico. Assim que entendia o que precisava ser feito, quebrava tudo em partes no papel ou no quadro branco. Identificava os trade-offs e comunicava os stakeholders.
Não para pedir permissão, mas para alinhar o que “feito” significava antes de começar. Quando havia atrasos, comunicava como trade-offs, não como problemas.
O resultado dessa postura: uma reputação tão forte que empresas criam posições só para ele.
Como operar assim no dia a dia
Saber que o gargalo mudou é uma coisa. Mudar a forma de trabalhar é outra.
Isso não se aplica a todo tipo de trabalho. Um hotfix ou um bug de uma hora não precisa de uma sessão de discovery. Mas para qualquer trabalho que vai consumir mais do que um ou dois dias, esses hábitos fazem diferença.
John Ousterhout, em A Philosophy of Software Design, faz a distinção entre programadores “táticos” e “estratégicos”. O tático quer fazer a coisa funcionar o mais rápido possível. Cada tarefa é um sprint para o próximo commit.
O estratégico investe tempo entendendo a forma do problema antes de escrever código. Os três hábitos abaixo são o que programação estratégica parece na prática:
Defina o critério de sucesso antes de abrir o editor. A pergunta certa é “como vou saber se funcionou?”. Um número, um comportamento do usuário, uma métrica.
Se você não consegue responder isso antes de começar, o ticket está incompleto. E você vai descobrir isso no pior momento: no meio do sprint.
No Bill Pay, o critério era “reduzir a taxa de abandono do fluxo”. No Surveys, “aumentar a taxa de criação de surveys no onboarding”. Sem esses critérios, eu teria feito melhorias genéricas que talvez não mudassem nada.
Use o produto que você constrói. A tela do PostHog só existiu porque eu usava o Surveys e via o problema com meus próprios olhos. Nenhum ticket ia me dizer aquilo.
No Bill Pay, instrumentei os eventos por conta própria porque queria ver onde o fluxo travava. Engenheiros que usam o produto que constroem encontram problemas que PMs não conseguem articular, porque não dá para articular o que você não viu.
Questione o ticket, não apenas execute. Se o ticket diz “melhorar performance da página”, pergunte: qual métrica? LCP? Tempo de interação? Para qual threshold?
Se o requisito está vago, complete. Se a solução pedida resolve um sintoma em vez do problema, proponha outra.
O engenheiro da Uber fazia exatamente isso: comunicava trade-offs, não objeções. Objeção trava. Trade-off informa e dá opções para quem decide.
Se o seu trabalho é infraestrutura, plataforma ou SRE, o critério de sucesso não vai ser uma taxa de conversão. Mas a pergunta é a mesma: “como vou saber se funcionou?”
Pode ser latência p99 abaixo de 200ms. Tempo de deploy caindo de 15 para 3 minutos. Número de incidentes por semana. O formato muda, a postura não.
Esses três hábitos não exigem mais habilidade técnica. Exigem uma mudança de postura: de executor de tarefas para co-responsável pelo resultado.
🌟 Resumo
O problema de construir a coisa errada sempre existiu. O que IA fez foi remover o freio natural: quando execução era cara, times eram forçados a pensar. Agora, construir errado ficou tão barato quanto construir certo
Dado da pesquisa (auto-reportado, mas revelador): engenheiros acreditam entender o porquê de uma feature, mas não sabem o que significa “feito”. Esse gap é o maior gargalo de times hoje
Mike Krieger (co-fundador do Instagram): IA é boa em adicionar, não em cortar. Construir demais antes de lançar é agora o erro mais fácil de cometer
95% dos times usam IA para código, 9% para requisitos. Faz sentido dado as capacidades atuais, mas é exatamente onde os problemas reais estão
Três hábitos para trabalho que importa: definir critério de sucesso antes de começar, usar o produto que você constrói, e comunicar trade-offs em vez de só executar
Se quiser se aprofundar nas skills que complementam esse julgamento de produto, veja também:
Se você quer entender como as melhores empresas internacionais pensam sobre engenharia de produto, a NaGringa tem vagas curadas e um banco com 1.000 perguntas reais de entrevistas para você explorar.
📖 Leitura adicional
John Ousterhout, A Philosophy of Software Design. Programadores táticos vs. estratégicos e o custo de não investir em entender o problema.
Marty Cagan, Inspired / Empowered. Discovery antes de delivery e o risco de construir o que ninguém quer.
Donald Reinertsen, The Principles of Product Development Flow. Como acelerar execução sem melhorar decisões pode aumentar o desperdício.
Lenny Rachitsky, How I AI: How Stripe built “minions”—AI coding agents that ship 1,300 PRs per week + How to turn Claude Code into your personal life operating system, Lenny's Newsletter, 2026.
Luca Rossi e Amelia Wattenberger, The Telephone Game of Software, Refactoring.fm, 2026.
Mike Krieger, entrevistado por Dan Shipper no podcast AI & I, Every.to, 2026. Assistir no YouTube
Luca Rossi, The State of Product Development 2026, Refactoring.fm, 2026. Pesquisa com 340 profissionais de engenharia, de startups a organizações com 1.000+ engenheiros.
Gergely Orosz, How to be a 10x engineer, interview with a standout dev, The Pragmatic Engineer, 2025.
Excelente texto, venho sentindo isso na prática, nesses últimos meses onde a empresa investiu pesado em ferramentas de IA;
Não entendia bem a problemática mas você expos muito bem e realmente:
“Critérios de aceite vagos e indefinidos”
“Queda absurda na percepção de esforço relativo ao desenvolvimento”
A soma desses dois pontos leva a features mal estruturadas ou completamente sem propósito, e no pior dos casos, features que não são harmônicas as necessidades da equipe que utiliza o sistema;
Uma feature sem propósito, tem como função somente trazer bugs e complexidade desnecessária ao sistema.