Passei os dias 28 e 29 de abril em San Francisco no AI Dev 26, organizado por Andrew Ng e pela DeepLearning.AI. Milhares de desenvolvedores, dois dias, três palcos e uma mensagem que se repetiu em quase todas as sessões: a engenharia de software está sendo reconstruída em torno de agents. As empresas que ainda discutem se a IA ajuda ou atrapalha a produtividade estão fazendo a pergunta errada.
Abaixo estão minhas conclusões: o que a indústria está acertando, onde eu enxergo a lacuna e como estamos trabalhando em cima disso na Cheesecake Labs.
O código virou commodity. A maioria dos times ainda não percebeu.
O primeiro dia voltou várias vezes ao mesmo tema. Anush Elangovan, da AMD, Marc Brooker, da AWS, o painel com Replit, LandingAI, Oracle e Practical Data Media. Cada sessão abordava o assunto de um jeito, mas o conteúdo era o mesmo: escrever código deixou de ser onde está o valor.
Andrew Ng foi o mais direto na keynote dele: o gargalo não é mais o código, é decidir o que construir. Quando você aceita isso, o resto do organograma começa a balançar. Se um generalista com bom instinto de produto consegue entregar um protótipo funcional em um dia, qual é o papel de um time de seis pessoas dedicado a uma feature?
E se um engenheiro consegue supervisionar três ou quatro agents ao mesmo tempo, qual é o papel de um gestor cujo trabalho era coordenar três ou quatro engenheiros?
A resposta honesta que a maioria dos líderes evita: esses papéis não desaparecem, eles se fundem. Quem trabalha com produto vai precisar entregar código. Engenheiros vão precisar falar com clientes. E os gestores, como resumiu o painel, vão todos virar gestores de agents.
75% do código entregue no Google já é escrito com IA. Esse número é citado o tempo todo. O dado mais interessante, que apareceu depois na sessão da JetBrains, é que 95% das empresas não veem retorno nenhum no investimento em IA. Os dois são verdadeiros ao mesmo tempo. A diferença não está no modelo, está no processo em volta do modelo.
De assistente a piloto
A Vibe Coding Master Class de Brandon Middleton, pela Replit, foi a articulação mais clara dessa mudança de mentalidade. Ele dividiu o novo trabalho em três partes.
- Especificação: saber o que pedir.
- Review: ler código que você não escreveu.
- Orquestração: costurar agents, ferramentas, integrações e dados.
A frase de Karpathy que ele citou vai pegar: a linguagem de programação mais quente do momento é o inglês.
Isso bate com o que vimos defendendo na Cheesecake Labs há meses. A mudança não é sair de “escrevo código sem IA” para “escrevo código com IA”. Isso é um ajuste de produtividade. A mudança de verdade é a IA deixar de auxiliar e passar a conduzir. A IA não te ajuda com a tarefa, ela entrega a tarefa. Você supervisiona.
Ler código que você não escreveu e decidir se aquilo vai para produção virou a habilidade central da função. Essa única frase muda a forma de contratar, treinar, revisar código e montar times.
Engenharia agêntica, não vibe coding
Se teve uma palestra que cristalizou o quadro estratégico para mim, foi a sessão de Paul Everitt pela JetBrains: Code vs. Staff vs. Quality: The Shift to Agentic Engineering. Ele deu nome ao que a maioria de nós vinha rodeando.
O vibe coding nos deixou empolgados, mas não vai nos levar até produção. O que leva é um conjunto de práticas que já tem nome nos cantos mais sérios da indústria.
Spec driven development. Evals em todas as camadas. Harness engineering. Context engineering. Bases de código modulares e bem documentadas. TDD com ciclos red e green, ainda válidos, mas agora aplicados às specs e às implementações geradas por IA. QA agents com browser e dev tools plugados. Observabilidade que vai bem além dos logs.
O lema do framework de harness engineering da OpenAI que apareceu na sessão dele é o resumo mais limpo que já ouvi do novo trabalho: engenheiros não constroem mais a coisa, eles constroem a coisa que constrói a coisa. Se você esbarrar em um problema, corrija a causa, não o sintoma. Faça com que o humano não seja o gargalo.
Esse último ponto é a parte difícil. A maioria das organizações de engenharia ainda está estruturada para colocar o humano no gargalo. Code review, aprovação, liberação de ambiente, testes, deploy. Cada uma dessas etapas é um portão humano.
Em um modelo de entrega agent native, cada um desses portões vira um agent ou uma política que um agent faz cumprir, e o humano sobe na cadeia para arquitetura, julgamento e decisões de tradeoff.
A lacuna de qualidade e confiança
Os números menos discutidos da conferência estavam do lado da qualidade.
Cinquenta por cento mais problemas indo para produção em muitas bases de código. Prompt injection já aparece como uma categoria real de produção. Vinte e nove por cento dos engenheiros confiam na precisão do que a IA produz. Menos de trinta por cento dos agents corporativos chegam a produção, número que Diamond Bishop, da Datadog, citou em The Next 100 Agents: Building the Agent-Native Office.
A sessão da CodeRabbit, Deploying AI Code Review at Scale: Turning AI Velocity into a Reliable Quality Gate, foi direta nesse ponto. O volume de pull requests subiu trinta por cento. A taxa de bugs também. Code review depende de contexto, e o volume de código gerado já ultrapassou o contexto que a maioria dos revisores carrega.
Tom Howlett, da Sonar, foi mais afiado em Can LLMs Generate Enterprise Quality Code? A resposta é condicional. Conseguem, desde que você os envolva em um loop de guiar, verificar e resolver. 90% dos problemas são pegos logo no início se você instruir o agent a analisar o próprio output antes de uma verificação completa no CI. Essa ordem importa: analisar, depois corrigir, depois verificar no CI é mais rápido e mais limpo do que o padrão de lint e review que a maioria dos times ainda usa por default.
O padrão em todas essas sessões é o mesmo. A IA levanta o teto e o piso ao mesmo tempo. Sem rigor, o piso cai mais rápido do que o teto sobe. E rigor é um problema de processo, não de modelo.
A terceira era de ouro
Paul Everitt citou um texto do Pragmatic Engineer que chamou este momento de terceira era de ouro da engenharia de software. Acho a leitura correta e acho que a maioria dos líderes de engenharia está subestimando isso.
A primeira era de ouro foi a ascensão do computador pessoal e a saída dos mainframes para o software distribuído. A segunda foi a nuvem e a saída do produto em caixinha para a entrega contínua. Esta terceira é a passagem de humanos que escrevem código para humanos que desenham e supervisionam sistemas que escrevem código.
O que a leitura da terceira era de ouro enfatiza, e que a leitura mais barulhenta do vibe coding descarta, é design de sistemas. Fluência em arquitetura. Entender por que as coisas estão organizadas do jeito que estão, onde ficam as costuras e como as peças devem se encaixar. Simon Willison, ao que tudo indica, está escrevendo um livro sobre isso. Ótimo. Precisamos dele.
Spec driven development, context engineering, validação agêntica, compounding engineering. São essas as palavras que vão importar. São também as palavras que vão separar os times que entregam sistemas funcionando dos times que entregam demos.
Principais aprendizados do AI Dev SF 26
Primeiro, a IA não é mais tratada como assistente. Ela é a camada principal de execução. O papel humano é especificar, revisar e orquestrar. Internamente, essa postura não é negociável. Se alguém ainda usa IA como autocomplete, tratamos como uma lacuna de treinamento e resolvemos.
Segundo, o harness importa mais do que o modelo. Skills, arquivos de contexto, wikis de projeto dentro dos repositórios, prompts reutilizáveis, templates de spec bem estruturados, evals, QA agents. Nada disso é glamouroso. Tudo isso se acumula. Os times que investem no harness abrem vantagem e mantêm essa vantagem. Os times que correm atrás do próximo lançamento de modelo ficam parados.
Terceiro, a contratação está mudando. O perfil que buscamos está mais próximo de um product engineer do que de um desenvolvedor full stack tradicional. Alguém que sai de um problema vago para um protótipo funcional em menos de um dia. Alguém que consegue ler código que não escreveu e decidir se aquilo vai para produção. Alguém que traduz um problema não técnico em uma especificação de sistema. Alguém que entrega ponta a ponta e depura nas costuras entre as partes.
Quarto, aprender virou prática diária, não iniciativa trimestral. Trinta minutos por dia, todo dia, foi o número mencionado mais de uma vez no palco. Acho que está certo. O ritmo de mudança não permite mais aprendizado em lote.
Reflexão final sobre o AI Dev SF deste ano
O resumo honesto de dois dias em San Francisco no AI Dev SF 26 é este. A tecnologia está pronta. O redesenho organizacional não. A maioria dos líderes de engenharia ainda fala de IA como ferramenta. Os líderes que vão parecer visionários daqui a três anos são os que já tratam a IA como um redesenho da função.
Aumentar e inovar, não automatizar e substituir, foi uma das frases finais da palestra de Paul Everitt. Eu iria além. Aumentar e inovar, sim, mas aceitando que a ampliação, feita a sério, já é um redesenho. A descrição de cargo de um engenheiro em 2026 não é a descrição de 2024 com ferramentas de IA acopladas. É outra coisa, e as empresas que nomearem essa diferença e se reconstruírem em torno dela serão as que entregam.
É esse o trabalho que fazemos na Cheesecake Labs todos os dias. Somos parceiros de empresas que já passaram da fase de protótipo e precisam colocar IA em produção com o rigor que isso realmente exige. Specs, evals, harnesses, entrega agent native, a infraestrutura chata que separa demos de produtos duráveis. Se o seu time está encarando essa lacuna, fale com a gente.
