Faça existir primeiro, melhore depois: por que começar simples acelera produtos reais

Existe uma armadilha recorrente em projetos técnicos: tentar desenhar a terceira versão de um sistema antes de colocar a primeira para funcionar.

No papel, tudo parece limpo. A equipe antecipa cenários futuros, cria abstrações para problemas que ainda não surgiram e adia a primeira entrega em nome de uma arquitetura supostamente definitiva. Quando o produto finalmente encontra o uso real, descobre-se que o gargalo estava em outro lugar.

As duas imagens acima resumem com precisão uma metodologia que costumo defender em engenharia, produto e liderança: faça existir primeiro, melhore depois (make it exist first, make it good later).

A lição dos motores Raptor: complexidade visível antes da simplicidade elegante

A comparação mostra duas gerações do motor Raptor, desenvolvido pela SpaceX para impulsionar o sistema Starship.

Na primeira imagem, o Raptor 1 parece um emaranhado de tubos, cabos, válvulas e sensores externos. Para quem olha de fora, pode parecer um projeto inacabado. Na prática, aquela configuração cumpria um propósito claro: colocar um motor de ciclo fechado de combustão em estágios na bancada de testes, medir pressão e temperatura em cada ponto e descobrir como o conjunto se comportava sob fogo real.

Na segunda imagem, o Raptor 3 apresenta uma silhueta limpa. Canais de resfriamento e fluxos secundários foram integrados à própria parede da carcaça, juntas expostas desapareceram, o peso caiu e o empuxo aumentou.

O ponto central dessa evolução é simples: não era possível projetar o Raptor 3 direto na prancheta.

Sem os sensores externos e os dutos acessíveis do Raptor 1, os engenheiros não saberiam quais conexões poderiam ser fundidas com segurança nem onde o calor exigia margem extra. A simplicidade da terceira geração não veio de adivinhação teórica; veio do aprendizado acumulado ao fazer a primeira geração existir e operar.

Fazer funcionar, fazer certo, fazer rápido

Na engenharia de software, Kent Beck sintetizou essa sequência na máxima atribuída ao desenvolvimento iterativo: “Make it work, make it right, make it fast” (faça funcionar, faça certo, faça rápido).

Quando invertemos essa ordem, pagamos caro em duas frentes:

1. Paralisia na largada: meses são consumidos discutindo a estrutura ideal sem que nenhum usuário ou operação receba valor.
2. Otimização às cegas: o time engessa partes do sistema que precisariam mudar logo na primeira semana de uso real e deixa desprotegidos os pontos que realmente sofrem carga.

Martin Fowler trata desse fenômeno ao defender a chamada arquitetura sacrificial: aceitar que a primeira versão de um componente existe para provar a utilidade do produto e revelar o que a versão seguinte realmente precisará suportar.

Isso conversa diretamente com a conhecida Lei de Gall, formulada por John Gall em Systemantics: sistemas complexos que funcionam invariavelmente evoluíram a partir de sistemas simples que funcionavam. Um sistema complexo desenhado do zero raramente funciona de primeira, e quase nunca pode ser consertado sem que se volte ao básico.

Como isso aparece em produtos e sistemas de IA em produção

Ao construir produtos de software e sistemas de IA aplicada, vejo essa diferença todos os dias.

Diante de um problema operacional, a tentação inicial de muitas equipes é desenhar uma malha complexa de múltiplos agentes autônomos, dezenas de ferramentas conectadas e fluxos elaborados antes mesmo de validar a primeira decisão assistida.

Aplicar a lógica de iniciar primeiro para melhorar depois muda o caminho:

• Começar por um fluxo estreito e observável: escolher uma etapa concreta do trabalho (como enriquecer a triagem de um alerta ou organizar evidências de uma vulnerabilidade) e colocá-la para rodar com escopo fechado.
• Manter a “instrumentação exposta” na versão 1: assim como os tubos e sensores visíveis do Raptor 1, a primeira versão de um fluxo de IA precisa registrar entradas, fontes consultadas, recomendações geradas e revisões humanas. Sem enxergar onde o modelo erra ou hesita, qualquer tentativa de refinar o sistema vira chute.
• Simplificar com base no uso real: depois de semanas de operação, fica claro quais etapas agregam valor, quais prompts ou ferramentas geram ruído e onde a automação pode avançar com segurança. Só então faz sentido consolidar a arquitetura e remover camadas desnecessárias.

Fazer existir primeiro não é entregar sem critério

Vale separar pragmatismo de improviso. Colocar a primeira versão no mundo não significa ignorar segurança, privacidade ou confiabilidade.

Na bancada de testes de um motor de foguete, o protótipo pode ter tubulações aparentes, mas opera cercado de telemetria e limites rígidos de contenção. Em software e IA, a regra é a mesma.

Para que a primeira versão possa existir com segurança e ensinar o que precisa melhorar, três bases não são negociáveis desde o primeiro dia:

• Limites claros de acesso e dados: menor privilégio para integrações, proteção de informações sensíveis e separação de ambientes.
• Pessoa no circuito para decisões de impacto: enquanto o sistema amadurece, a ação final em cenários críticos passa por validação humana explícita.
• Capacidade de medir e reverter: se algo sair do esperado, a equipe precisa perceber rápido e voltar ao estado anterior sem interromper a operação.

Com essas proteções no lugar, o restante do produto ganha liberdade para começar simples, aprender rápido e evoluir com base em fatos.

Melhorar depois é parte do compromisso

A frase só funciona quando as duas metades caminham juntas. “Faça existir primeiro” destrava a inércia; “melhore depois” exige disciplina para voltar ao que foi construído, limpar excessos e transformar aprendizado em robustez.

Antes de adiar o próximo lançamento ou refinar mais uma vez um diagrama que ainda não rodou em produção, vale fazer quatro perguntas:

1. Qual é a menor versão deste sistema que resolve um problema real com segurança?
2. Que sinais precisamos medir na primeira versão para saber o que mudar na segunda?
3. O que estamos tentando decidir no quadro branco que só o uso real vai responder?
4. Quando vamos reservar tempo para transformar o protótipo que funciona na arquitetura enxuta que permanece?

A excelência técnica raramente nasce pronta no primeiro rascunho. Na maioria das vezes, ela é o resultado visível de quem teve a coragem de fazer existir primeiro e a constância de melhorar depois.

Qual ideia ou produto você está tentando desenhar já como “versão 3” no papel, quando o próximo passo real seria colocar a “versão 1” em funcionamento?