Quando todo mundo é builder, como evitar a bagunça no produto

O builder é o papel que junta UX e produto numa só posição, com a missão de levar uma ideia da concepção até a produção. Não é um projeto de software: é uma função organizacional, descrita por Jeff Gothelf a partir de conversas com dois primos que trabalham em tech. Um é designer numa empresa de cerca de 100 pessoas, o outro é group product manager numa de cerca de 4000, com um time de produto e UX de 350 pessoas. Em uma empresa o papel se chama "creator", na outra "builder". Nenhuma das duas, segundo ele, definiu como isso funciona na prática.

O argumento central é que o processo de build e deploy (code review, QA, segurança, testes de performance, rollouts graduais) sempre foi também um filtro de qualidade. A IA removeu esse filtro e a pressão por lançar mais cresceu. Gothelf cita ainda uma empresa que criou skills do Claude que "fazem discovery" e geram wireframes clicáveis em minutos, e nelas a ideia sempre se mostra viável. Como limitação, o texto traz relatos de poucas empresas, não dados sistemáticos. O número citado é do relatório da Pendo de 2019: 80% das funcionalidades de um produto médio são raramente ou nunca usadas.

As cinco recomendações: separar o direito de construir do direito de lançar, com evidência a cada etapa de exposição; exigir hipótese, critério de sucesso e data de revisão antes de ir ao ar; fazer reuniões trimestrais de aposentadoria; criar com engenharia caminhos rápidos de deploy; e medir comportamento do cliente e impacto no negócio, não funcionalidades entregues.

O tema já vinha sendo coberto pelo CEVIU. Em 19 de agosto de 2026, a matéria "A ascensão do 'Full Stack Builder' e os desafios à qualidade do software na era da IA" apontava que a ausência de handoff entre equipes pode comprometer a qualidade. Em 8 de setembro de 2026, "O Risco da Construção Desenfreada na Era da IA" descrevia o "slop-creep", o acúmulo de funcionalidades sem propósito. Em 12 de outubro de 2026, "A 'Big Ball of Mud' da IA" tratava da fragilidade de sistemas criados por não especialistas. A matéria de hoje sai do diagnóstico e entrega práticas de governança: gates por evidência, revisão de hipótese e aposentadoria de funcionalidades.

Para quem gerencia produto, a leitura é que o gargalo deixou de ser construir e passou a ser decidir o que merece existir. Se a sua empresa adota o builder, vale definir quem responde pelo resultado de cada funcionalidade e quando ela será revisada, antes de o suporte e a UX pagarem a conta. Medir por entrega tende a produzir mais ruído.