Com IA, construir ficou fácil; difícil é decidir o que tirar do produto

O texto parte de uma experiência na Livesport, empresa por trás do Flashscore, plataforma esportiva de placares ao vivo e estatísticas. Um pedido para melhorar o acompanhamento de pontos individuais no tênis foi construído com desenvolvimento assistido por IA. O autor conta que, pela primeira vez, o time gastou mais tempo discutindo o que construir do que construindo. Agentes de IA responderam a comentários no YouTrack, geraram um link de teste e chegaram a questionar uma revisão proposta. Quem conversava com eles era o assistente Claude do autor, não ele diretamente.

A tese: o gargalo não some, ele muda de lugar. Construir ficou rápido, mas testar, medir e decidir o que fica continua limitado. O autor aponta três frentes. Primeiro, medição: lançar muita coisa ao mesmo tempo impede saber o que funcionou, e poucos times têm tráfego como o do Booking.com, que segundo o texto roda mais de mil experimentos simultâneos. Segundo, coerência: funcionalidades antigas, configurações esquecidas e comportamentos desiguais se acumulam. Terceiro, critérios combinados antes: definir o que é sucesso, como medir e que resultado justifica mudar ou remover, e agir de fato quando a meta não é batida.

O tema não é novo na cobertura do CEVIU. Em 14 de abril de 2026, a matéria "Vômito de Funcionalidades: A IA e o Desafio de Manter o Foco no Produto" já apontava que a IA facilita construir muito e dificulta manter o foco. Em 1 de maio de 2026, "Um novo desafio para Product Managers de software" falava em decidir o que não construir. Em 13 de maio de 2026, "Customer development tem um problema com IA" tratava da disciplina de parar trabalhos sem resultado. Em 12 de junho de 2026, "A IA não facilita o seu trabalho" dizia que a IA leva as equipes mais cedo às partes difíceis. Em 29 de junho de 2026, "Menos é mais, mais ou menos" lembrava que mais entregas não significam produtos melhores. O que a matéria de hoje acrescenta é um caso prático da Livesport e o foco explícito em remover funcionalidades, medição com tráfego limitado e coerência do produto.

Leitura editorial: para quem gerencia produto, a restrição de engenharia deixava de filtrar ideias por você. Agora esse filtro precisa ser deliberado. Na prática, isso sugere escolher quais experimentos merecem a audiência disponível, fixar critérios de remoção antes do lançamento e tratar a coerência da experiência como responsabilidade de alguém. Em times com pouco tráfego, o ganho pode estar mais em prototipar e validar cedo do que em lançar mais.