O custo de mudar de ideia está caindo rápido

O texto parte de uma ideia simples: quando um agente de código entrega uma versão funcionando antes de você decidir se o produto está certo, o trabalho não some. Ele muda de lugar. Agora é preciso testar o resultado, entender o que quebrou na experiência e escolher o que vem depois. No exemplo do onboarding, os testes passaram, mas a primeira tela pedia e-mail antes de explicar o produto. O teste verificou o que o agente implementou, não se o fluxo servia a quem usa.

O autor, Hiten Shah, usa o Beam, app de Mac que construiu com Sam, como caso real. A premissa era trazer um único app de outro Mac para uma janela local. Dos 73 inscritos no acesso antecipado, só nove disseram querer normalmente um app específico, e onze queriam o Mac inteiro. Ele ressalta que são usuários autosselecionados, então a leitura é um motivo para investigar, não um veredito de mercado. Em 4 de outubro, o app ganhou a opção Whole Screen. Também entra um estudo revisado em 1º de novembro, com 445 milhões de eventos de trabalho em 655 empresas: linhas de código subiram cerca de 44%, pull requests abertos cerca de 36%, e issues resolvidas no Jira só cerca de 14%, com menor certeza estatística. A recomendação prática é decidir entre manter, revisar ou reconstruir, e registrar o motivo da decisão para o próximo agente ou sessão não repetir a discussão.

A tese não é nova no CEVIU. Em 17 de março de 2026, o CEVIU noticiou "Quando construir se torna mais barato do que especificar", sobre protótipos baratos substituindo longas especificações. Em 24 de março de 2026, em "O Design de Produtos Está Mudando no Mundo da IA e Ferramentas Autônomas", o gargalo já aparecia como decidir o que construir. Em 2 de junho de 2026, "Quando o código se torna barato: o que ainda vale no desenvolvimento?" apontava revisão e testes como o novo gargalo. Em 1º de julho, 11 de julho e 15 de julho de 2026, as matérias seguintes falavam em gestão de produto, descoberta e escolha.

O que a notícia de agora acrescenta, segundo o texto: números de adoção (o estudo com 445 milhões de eventos), um caso de produto com dados de usuários (Beam) e o problema de preservar o registro de decisões entre agentes e sessões.

Para quem toca uma startup, a leitura é que o código barato não torna a validação barata. Se cada versão nova sai sem um critério escrito de aceite, o time pode girar em revisões sem aprender nada. Registrar o que foi tentado, rejeitado e por quê parece um hábito de baixo custo que protege a atenção do time, que é o recurso escasso. O caso do Beam sugere ainda que ouvir usuários com a versão funcionando vale mais que defender a premissa original.