Projetar antes de implementar

Se eu pudesse dizer uma coisa só sobre como eu trabalho, seria esta: penso o problema inteiro antes de escrever a primeira linha.

Na prática isso quer dizer especificação numerada e versionada junto ao código antes de implementar; padrão de mercado em vez de invenção própria, com tratamento de erro seguindo a RFC 9457 e a suíte pública em Clean Architecture canônica; teste e validação declarativa como critério de pronto, não como consequência; e o mapa do parque levantado antes de decidir sobre ele. Das abstrações que nasceram desse trabalho, parte foi generalizada e publicada como pacote. Ver Suíte PMQ.

Como isso funciona na prática

A especificação vem numerada e versionada com o código: o problema, a pesquisa do que já existe, o plano e a lista de tarefas. Não é documento cerimonial. É onde as decisões difíceis são tomadas enquanto ainda são baratas de mudar.

Ela tem um segundo leitor: é essa especificação que o agente executa, com o ferramental que está em Engenharia com IA.

O que eu procuro nessa fase:

• Qual é o problema real, não o pedido. O pedido costuma já vir com uma solução embutida, e quase sempre não é a melhor
• O que já existe que resolve isso, no parque, no ecossistema ou como padrão publicado
• Onde a coisa vai doer em dois anos: o ponto que vai virar dívida, e se dá para evitar agora barato
• O que fica de fora, explicitamente

Por que não é lentidão

A objeção óbvia é que isso atrasa. Na minha experiência inverte, porque o tempo gasto em especificação volta em decisão que não precisa ser refeita. O monitoramento industrial é o exemplo: tratar operação offline como requisito, e não como recurso a acrescentar depois, mudou a arquitetura inteira do cliente. Descoberta na fase de projeto, custou uma conversa. Descoberta depois, teria custado a reescrita.