Você sabe construir. Mas isso não diz o que merece existir

O código mais caro da sua vida é o que não deveria existir. Não é o código com bug — bug se conserta. Nem o código lento — o profiler encontra. O código que sai mais caro é o limpo, testado, no ar, resolvendo um problema que ninguém tem. Nenhuma ferramenta acusa esse erro, porque todas as ferramentas que você usa começam depois que a decisão de construir já foi tomada.

Saber construir também cria um risco

Quando você sabe programar, o reflexo diante de uma ideia nova é abrir o editor. Parece progresso — o repositório cresce, a demo funciona, o gráfico de commits vai ficando verde. E com agentes de código esse reflexo ficou baratíssimo: o que levava um mês agora cabe num fim de semana.

Só que construir ficar barato não aumentou em nada a chance de você construir a coisa certa. Apenas encurtou o caminho entre a ideia que surgiu no banho e o produto feito pela metade do qual você já não consegue desapegar. A proteção que existia antes — construir era caro, então você pensava duas vezes — sumiu. A velocidade eliminou a pausa onde morava a dúvida.

Suas ferramentas entram depois da decisão

Repare nas ferramentas da sua máquina. Agentes de código escrevem código brilhantemente e não entendem nada do negócio — implementam qualquer coisa que você pedir, sem nunca perguntar se alguém quer aquilo. As ferramentas de prompt-para-app vão além: transformam a ideia errada em uma ideia errada em produção, em uma tarde. E o raciocínio que deveria vir antes — para quem é isso, o que essas pessoas fazem hoje, por que trocariam — fica numa página de Notion ou na foto de um quadro branco, desconectado de tudo o que acontece depois.

Nenhuma dessas ferramentas é ruim no que se propõe. O problema é o vão entre elas: o raciocínio de negócio vive num mundo, o código vive em outro, e a pergunta "isso deveria existir?" não pertence a nenhum dos dois. Então ninguém faz.

A decisão que fica no meio

O passo que mais se perde fica entre ter uma ideia e apostar semanas nela. Um fundador que leva ideias a sério preenche esse espaço com perguntas, mais ou menos nesta ordem: qual é a ideia, dita em uma frase? Quem sente esse problema — gente de verdade, não um recorte demográfico? O que essas pessoas fazem hoje a respeito? Qual é a hipótese mais arriscada por trás de tudo? E qual é o teste mais barato capaz de provar que essa hipótese está errada?

Nada disso pede MBA. Pede a disciplina de segurar a parte divertida até as perguntas chatas terem respostas honestas. E é exatamente essa disciplina que evapora quando a parte divertida está a um prompt de distância.

O que custa pular esse passo

Quem constrói por tempo suficiente quase sempre já lançou a coisa errada. A conta não é só as semanas de trabalho. É a motivação que vai embora quando o lançamento cai no silêncio. É o desgaste de pedir para os amigos testarem algo que não precisava existir. E é o custo de oportunidade: a ideia certa que ficou na gaveta porque a errada já estava em andamento.

O pior é que esse fracasso ensina a lição errada. "Lancei e ninguém apareceu" soa como problema de divulgação ou azar. Na maioria das vezes, o resultado já estava decidido antes do primeiro commit — a ideia nunca foi testada contra o comportamento real de uma pessoa real.

Como recolocar a decisão no fluxo

A resposta não é construir mais devagar. É tornar a validação tão rápida e natural no seu fluxo quanto construir ficou — para que pensar antes deixe de parecer desvio. Questione a ideia como um fundador questionaria, escreva o que provaria que ela está errada, rode o teste honesto mais barato e só então solte os agentes no repositório.

É daí que nasce o Motriz: um lugar onde a ideia passa pelo crivo de produto antes de virar compromisso — as cinco perguntas de fundador, evidência registrada e uma decisão honesta de construir. Quando chega a hora de executar, o escopo sustentado pela evidência vira uma fila de tarefas para agentes de código no seu repositório real. O raciocínio continua ligado ao trabalho, em vez de precisar ser remontado a cada ferramenta.

Próximo texto da série: como validar uma ideia antes de escrever a primeira linha de código — a versão prática de tudo isso.