Código Ficou Barato — Gosto, Julgamento e Arquitetura São o Novo Premium

Lembro o momento exato em que caiu a ficha.

Era final de 2024. Eu liderava engenharia de plataforma para uma empresa de serviços financeiros — o tipo de trabalho onde cada pipeline de deploy, cada decisão de infraestrutura, cada linha de Terraform carrega consequências reais. Meu time tinha passado três semanas construindo uma ferramenta interna: um dashboard que agregava dados de quatro serviços diferentes, tratava edge cases de autenticação, e exibia tudo numa interface limpa que nosso time de operações conseguia de fato usar.

Três semanas. Quatro engenheiros. Incontáveis code reviews, discussões de arquitetura e sessões de debugging.

Aí um dos nossos engenheiros júnior abriu o Cursor, descreveu mais ou menos o que tínhamos construído, e viu a IA gerar algo visualmente parecido em uns quarenta minutos.

Minha primeira reação foi medo. Do tipo visceral, que te gela o estômago. Se um engenheiro júnior com uma ferramenta de IA conseguia produzir em quarenta minutos o que meu time tinha levado três semanas, qual exatamente era o valor do meu time? Qual era o meu valor?

Esse medo durou mais ou menos um dia. Aí eu olhei mais de perto o que a IA tinha de fato produzido.

A interface parecia certa. Os dados estavam conectados. Até tratava alguns estados de erro básicos. Mas a autenticação era um pesadelo de segurança — tokens armazenados em localStorage, sem lógica de refresh, gestão de sessão que falharia silenciosamente em produção. As queries no banco teriam derrubado nossa instância Postgres sob qualquer carga real. Não havia observabilidade, nem degradação graciosa, nenhuma consideração sobre o que acontece quando o Serviço B cai mas o Serviço A continua rodando.

Parecia a coisa. Não era a coisa.

E foi aí que o medo virou clareza.

A Grande Inversão

Estamos vivendo o que comecei a chamar de Grande Inversão. Por décadas, o gargalo na construção de software era o código em si. Escrevê-lo era difícil, lento, caro. Empresas pagavam fortunas por engenheiros que conseguiam traduzir requisitos em sistemas funcionais. A capacidade de escrever código era o recurso escasso.

Essa escassez está evaporando. A Lovable atingiu US$100M de ARR em oito meses. O Cursor alcançou um valuation de US$9,9B. A Replit reporta que 75% dos seus usuários nunca escrevem uma única linha de código. A OpenAI adquiriu o Windsurf por US$3B. Vinte e cinco por cento do batch W25 da YC tinha codebases 95% geradas por IA.

O código em si ficou barato. Em alguns casos, praticamente de graça.

Mas o que não ficou barato: saber qual código deveria existir. Saber por que essa feature importa e aquela outra não. Saber como estruturar um sistema para que ele sobreviva ao contato com usuários reais, escala real e tempo real.

O gargalo não desapareceu. Ele se moveu para cima.

Garry Tan, presidente da Y Combinator, colocou de forma precisa: “As duas coisas mais importantes quando inteligência sob demanda está disponível são na verdade agência e gosto… todo mundo virou PM agora. Você realmente precisa entender o produto.”

Agência e gosto. Não habilidade técnica. Não a capacidade de escrever um componente React limpo ou otimizar uma query de banco. A capacidade de decidir o que importa e agir com base nessa convicção.

A Ressaca do Vibe Coding

Vamos falar de vibe coding, porque é o estudo de caso perfeito do que acontece quando confundimos a capacidade de produzir código com a capacidade de construir produtos.

Andrej Karpathy cunhou o termo no início de 2025. O Collins English Dictionary elegeu como Palavra do Ano. A ideia era intoxicante: descreva o que você quer em linguagem natural, deixe a IA resolver a implementação, nem olhe o código. Só vibe.

E funcionou — para demos. Para protótipos. Para o tipo de coisa que você mostra numa reunião de pitch.

Aí as pessoas tentaram manter o que tinham construído.

A CodeRabbit analisou 470 pull requests no GitHub e encontrou que código co-autorado por IA continha 1,7x mais problemas graves e 2,74x mais vulnerabilidades de segurança que código escrito por humanos. A Whitespectre, uma consultoria de desenvolvimento, encontrou que apenas cerca de 30% do código gerado por IA é aproveitável em produção. E 170 de 1.645 apps gerados pela Lovable tinham problemas de segurança identificáveis — API keys expostas, autenticação inexistente, vulnerabilidades de SQL injection à vista de todos.

Desenvolvedores começaram a chamar de “inferno de desenvolvimento” — a experiência de tentar manter, debugar e estender uma aplicação que foi vibe-coded à existência. O código funcionava, no sentido estrito de que executava. Mas não tinha arquitetura coerente, nem padrões consistentes, nenhuma consideração pelas coisas que só importam depois que a demo acaba: monitoramento, tratamento de erros, migração de dados, performance sob carga.

Até fevereiro de 2026, o próprio Karpathy já tinha seguido em frente. Declarou vibe coding “passé” e propôs “agentic engineering” como o sucessor maduro — um workflow onde humanos orquestram agentes de IA com supervisão e escrutínio em vez de aceitar cegamente o que o modelo produz.

A mudança é reveladora. A pessoa que cunhou o termo reconheceu que o gargalo nunca foi a geração de código. Sempre foi o julgamento humano ao redor dele.

Todo Mundo Virou PM Agora

O Request for Startups da Spring 2026 da YC inclui duas entradas que cristalizam essa mudança.

A primeira é “Cursor for Product Managers.” A tese: “Escrever código é apenas parte de construir um produto que as pessoas querem — a parte mais importante é descobrir o que construir em primeiro lugar.” Estão buscando ferramentas que ajudem product managers a tomar decisões melhores sobre o que construir, não ferramentas que ajudem engenheiros a escrever código mais rápido. O problema de geração de código está efetivamente resolvido. O problema do que construir está escancarado.

A segunda é “AI-Native Agencies.” O pitch: “Agências do futuro vão se parecer mais com empresas de software, com margens de software, e vão escalar muito mais do que qualquer agência que existe hoje.” Não se trata de agências que usam IA. São agências que são estruturadas em torno do fato de que código é barato. Quando o custo de execução se aproxima de zero, o valor se concentra inteiramente em estratégia, gosto e julgamento.

O Nielsen Norman Group, referência máxima em pesquisa de UX, chegou à mesma conclusão por outro ângulo: “Designers não serão mais diferenciados por habilidades técnicas. Seleção, gosto e discernimento é que fazem você se destacar.”

O padrão é consistente em todo domínio. Quando IA comoditiza a execução, o julgamento humano se torna o ativo premium.

O Que Gosto Realmente Significa

Quero ser específico sobre o que quero dizer com “gosto,” porque é uma dessas palavras que soa vaga até você ver sua presença ou ausência em decisões reais de produto.

Gosto é o fundador que olha para vinte features que sua ferramenta de IA poderia gerar nesta semana e escolhe as três que importam. Gosto é saber que seu fluxo de onboarding precisa de menos passos, não mais, mesmo que adicionar passos seja trivialmente fácil agora. Gosto é a decisão de não construir a feature que seu maior cliente pediu porque você entende que ela comprometeria o produto para todos os outros.

Gosto é Steve Jobs decidindo que o iPhone não teria teclado físico. É o Stripe escolhendo otimizar para experiência do desenvolvedor quando todo outro processador de pagamento estava otimizando para vendas enterprise. É o tipo de decisão que parece óbvia em retrospecto mas exige convicção genuína no momento.

Na era da IA, gosto se manifesta de uma forma muito específica: saber o que aceitar do output da IA e o que rejeitar. Quando uma ferramenta de IA gera uma feature em quinze minutos, o engenheiro com gosto consegue olhar e dizer: “A UI está certa mas o modelo de dados está errado — isso não vai escalar acima de dez mil usuários e aqui está o porquê.” O engenheiro sem gosto coloca em produção e descobre o problema três meses depois.

Julgamento: Saber Quando Parar

Se gosto é saber o que construir, julgamento é saber quando parar.

Ferramentas de IA têm uma tendência patológica à completude. Peça uma página de configurações de usuário e você vai receber preferências de frequência de notificação, seleção de idioma, gestão de fuso horário, opções de acessibilidade, exportação de dados, exclusão de conta — tudo que uma página de configurações poderia ter.

O fundador com julgamento sabe que para um produto pré-PMF, a página de configurações precisa exatamente de duas coisas: trocar sua senha e excluir sua conta. Todo o resto é distração disfarçada de completude.

Vejo isso constantemente nos fundadores que avaliamos na Basalt. Os que têm dificuldade não são os que não conseguem construir. Construir é fácil agora. Os que têm dificuldade são os que não conseguem parar de construir. Lançam feature atrás de feature, cada uma gerada numa fração do tempo que teria levado um ano atrás, e seu produto se torna um labirinto de funcionalidades que nenhum usuário consegue navegar.

Os melhores fundadores com quem trabalho têm um senso implacável de escopo. Usam IA para explorar possibilidades rapidamente — prototipando três abordagens diferentes num dia em vez de se comprometer com uma e gastar um mês nela. Mas então escolhem uma, cortam até a essência, e constroem aquela direito. A IA acelera a exploração. O julgamento humano conduz a convergência.

Arquitetura: Fazer Durar

Uma verdade que a IA não mudou: os problemas mais difíceis em software não são escrever o código. São decidir como as peças se encaixam.

Arquitetura é o conjunto de decisões que são caras de mudar depois. Qual banco de dados. Como serviços se comunicam. Onde ficam os limites entre componentes. Quais dados fluem para onde e por quê. Essas decisões se compõem ao longo do tempo — boas escolhas arquiteturais tornam toda feature futura mais fácil; más escolhas criam um imposto sobre cada mudança.

Ferramentas de IA são, até hoje, genuinamente ruins em arquitetura. Otimizam para a requisição imediata sem considerar a trajetória do sistema ao longo do tempo. Geram alegremente uma função monolítica que lida com autenticação, autorização, busca de dados e renderização num único arquivo porque é o caminho mais rápido para “funciona.” Não pensam sobre o que acontece quando você precisa adicionar um segundo provedor de autenticação, ou quando seu modelo de dados muda, ou quando você precisa fazer deploy em múltiplas regiões.

É por isso que a estatística “25% do batch W25 da YC tinha codebases 95% geradas por IA” é tão interessante. Essas empresas lançaram rápido. Algumas vão ter sucesso porque encontraram product-market fit rapidamente e podem reconstruir depois. Mas muitas estão acumulando dívida arquitetural numa velocidade que gerações anteriores de startups nunca experimentaram, porque o código está sendo gerado mais rápido do que qualquer humano consegue revisá-lo para coerência estrutural.

Os fundadores que entendem arquitetura usam IA de forma diferente. Estabelecem padrões primeiro — manualmente, deliberadamente — e depois deixam a IA gerar código dentro desses padrões. Tratam a IA como um engenheiro júnior incrivelmente produtivo mas que precisa de guardrails. A arquitetura é o guardrail.

O Que a Basalt Procura

Quando avaliamos fundadores na Basalt, adaptamos nossa lente para essa nova realidade. Passamos menos tempo perguntando “você consegue construir isso?” e mais tempo fazendo três perguntas diferentes.

Você sabe decidir o que construir? Me mostra uma decisão de produto que você tomou onde os dados apontavam numa direção mas seu instinto dizia outra. O que aconteceu? Como você pensou sobre o trade-off? Isso revela gosto.

Você sabe decidir o que não construir? Que pedido de feature você recusou? O que seus usuários queriam que você deliberadamente escolheu não dar a eles? Isso revela julgamento.

Você consegue fazer durar? Me explica a arquitetura do seu sistema. Por que é estruturada assim? Que trade-offs você fez? O que faria diferente se começasse do zero? Isso revela pensamento arquitetural — a capacidade de raciocinar sobre sistemas ao longo do tempo, não apenas no momento.

Essas perguntas importam mais agora do que há dois anos porque o gap entre “tenho uma demo” e “tenho um produto” aumentou dramaticamente. IA tornou demos praticamente gratuitas. Isso significa que a demo não nos diz quase nada. O que nos diz algo é o pensamento por trás da demo — as decisões, os trade-offs, as coisas que o fundador escolheu não incluir e por quê.

O Gap de Protótipo para Produção

Tem um modo de falha específico que vejo o tempo todo, e vale a pena nomear explicitamente: o gap de protótipo para produção.

Um fundador constrói um protótipo com ferramentas de IA em uma semana. Fica ótimo. Usuários adoram a demo. Investidores se interessam. Aí tentam transformar aquilo num produto real — adicionar autenticação, tratar edge cases, implementar tratamento de erros adequado, configurar CI/CD, escrever testes, lidar com migrações de dados, adicionar monitoramento — e descobrem que a arquitetura do protótipo luta ativamente contra tudo isso.

O protótipo não foi projetado. Foi gerado. E código gerado otimiza para o caminho feliz. Sistemas de produção precisam lidar com os caminhos infelizes — os edge cases, as falhas, os estados estranhos que só aparecem quando usuários reais fazem coisas reais em escala real.

Esse gap é o novo premium. A capacidade de pegar um protótipo vibe-coded e enxergar com clareza o que precisa mudar para torná-lo pronto para produção — é aí que o valor mora. Não em escrever o código de produção (IA pode ajudar com isso também), mas em saber o que “pronto para produção” significa. Saber quais atalhos são aceitáveis e quais vão te prejudicar. Saber quando “bom o suficiente” é genuinamente bom o suficiente e quando é uma armadilha.

A Habilidade Mais Valiosa de 2026

Aqui é onde cheguei, dois anos depois de assistir a IA transformar como software é construído.

A habilidade mais valiosa em 2026 não é escrever código. Não é dar prompts para a IA escrever código. Não é nem revisar código gerado por IA, embora isso esteja mais perto.

A habilidade mais valiosa é saber qual código deveria existir.

Essa é uma habilidade de produto, não técnica. Exige entender usuários profundamente o suficiente para saber o que precisam, entender tecnologia amplamente o suficiente para saber o que é possível, e ter o gosto e julgamento para navegar o espaço entre esses dois.

Eu costumava achar que meu valor como engenheiro de plataforma estava na minha capacidade de construir sistemas confiáveis. Hoje acho que meu valor sempre esteve na minha capacidade de decidir quais sistemas precisavam ser confiáveis, quais modos de falha realmente importavam, e quais abstrações serviriam o time por anos em vez de meses. A construção era o output visível. A decisão era o trabalho de verdade.

Para fundadores construindo em 2026, a implicação é clara. O código é de graça. O gosto não é. A IA vai gerar o que você pedir — a questão é se você está pedindo a coisa certa.

Os fundadores que prosperam nessa era não serão os que conseguem lançar mais código mais rápido. Serão os que conseguem olhar para um problema, enxergar a forma da solução antes de uma única linha ser escrita, e então usar toda ferramenta disponível — IA inclusa — para trazer aquela visão específica à realidade.

Código ficou barato. Gosto, julgamento e arquitetura são o novo premium.

A pergunta que fazemos a todo fundador que chega à Basalt é simples: O que você enxerga que a IA não consegue?

Essa resposta é onde o valor mora.