Beakman, Ford e dividir para entregar

Quando eu era criança, não perdia O Mundo de Beakman na TV Cultura. Era barulhento e estranho, e me ensinou como as coisas funcionam. Um episódio ficou comigo para a vida toda: o do Henry Ford e a linha de montagem. A ideia de que você podia pegar uma tarefa enorme e intimidadora, construir um carro inteiro, e transformá-la numa sequência de passos pequenos e repetíveis que qualquer pessoa conseguia fazer bem.

Décadas depois, é assim que eu ainda penso em entregar software. O instinto da maioria dos times, diante de algo grande, é mapear todos os requisitos antes de escrever código. Parece responsável, mas é assim que o projeto trava.

Quarenta endpoints e uma squad presa na especificação

Um exemplo ao qual sempre volto: uma squad estava atrasada numa integração com cerca de quarenta endpoints. O time estava paralisado, tentando especificar todos os quarenta antes de construir qualquer coisa. A especificação só crescia, o prazo só andava, e nada de fato funcionava.

Então fiz uma pergunta diferente: e se, em vez de mapear todos os quarenta endpoints, a gente fizesse o sistema de ponta a ponta com um só? Um endpoint, mas ligado pelo sistema inteiro, da requisição à resposta, autenticação, tratamento de erro, log, tudo. De repente o time tinha algo real rodando. Dava para validar a abordagem rodando. E, igualmente importante, veio a sensação de completude, a prova de que o caminho funcionava. Depois disso, os endpoints restantes deixaram de ser um muro e viraram uma checklist. Cada um era só mais um trecho de uma estrada que eles já tinham pavimentado.

O mesmo truque, em migrações de CRM

Faço a mesma coisa em migrações de dados. A tentação é sempre mapear todos os campos antes de mover um único registro. Em vez disso, começo com um exemplo simples e representativo e levo ele até o fim. Esse único registro te ensina o formato real da conexão, as manhas de autenticação, os limites de taxa, os campos que não batem, muito mais rápido do que qualquer documento de mapeamento. E dá ao cliente algo para ver e reagir em poucos dias.

Não mudou com a IA. Ficou mais importante.

Vejo gente cometendo o mesmo velho erro com uma ferramenta nova: tentar construir uma solução de IA complexa de uma vez só, com prompt, agente, ferramentas e avaliação entrando juntos. Como o Matt Pocock já disse, os processos de engenharia de software continuam valendo, mesmo com IA no meio. O modelo muda como você escreve o código; a disciplina de entregar uma fatia fina, validar e iterar continua.

O Ford simplificou o processo, uma estação por vez, e eu vi isso num programa infantil de ciências antes de escrever a primeira linha de código.