✏️ Do desenho ao protótipo
No módulo anterior você desenhou a arquitetura: canais, agentes, serviços, ferramentas. Mas um desenho é uma promessa, não uma prova. O protótipo é o momento em que a promessa vira algo que roda — onde alguém digita uma mensagem e o sistema responde de verdade. A passagem do desenho para o protótipo é a hora em que você descobre o que o papel não contava.
🛠️ Desenho prova ideia, protótipo prova realidade
O desenho responde "será que faz sentido?". O protótipo responde "será que funciona?". São perguntas diferentes — e só a segunda paga as contas. Por isso o arquiteto não se apaixona pelo blueprint perfeito: ele corre para colocar a menor versão de pé e ver o sistema reagir a um caso real.
O ciclo de quem prototipa
Desenho
O blueprint da arquitetura: o que existe e como conversa.
Protótipo
A menor versão que já entrega o resultado principal.
Testar
Um caso real passa pelo sistema; a realidade aparece.
Iterar
Ajusta com base no que viu e volta ao protótipo — em loop.
🌱 Começar pequeno (MVP)
MVP quer dizer Produto Mínimo Viável: a menor versão da solução que já resolve o problema principal de ponta a ponta. Mínimo não é mal feito — é enxuto. Você corta tudo que é "seria legal ter" e mantém só o caminho que entrega o resultado central. O MVP do seu Jarvis faz uma coisa bem, não dez coisas pela metade.
✓ MVP bem cortado
- ✓Resolve UM problema de ponta a ponta.
- ✓Um canal só (ex.: WhatsApp) para começar.
- ✓Fica pronto em horas ou poucos dias.
- ✓Já dá para mostrar para alguém usar.
✗ MVP inflado (não é MVP)
- ✗Tenta resolver tudo de uma vez.
- ✗Três canais e cinco integrações antes do primeiro teste.
- ✗Demora semanas e nunca "fica pronto".
- ✗Cheio de recursos que ninguém pediu.
💡 Dica prática
Pergunta de corte: "se eu tirar isso, o sistema ainda resolve o problema principal?". Se a resposta é sim, tira do MVP. Guarde a lista de cortes — ela vira a fila de melhorias depois que o protótipo provar valor.
🎯 Testar com caso real
Testar com exemplo inventado é fácil — e enganoso. O protótipo só prova alguma coisa quando enfrenta um caso real: uma mensagem que um cliente de verdade mandou, um documento que existe na empresa, um pedido como ele chega no dia a dia. O caso real traz a bagunça que o exemplo limpo esconde: gírias, erros de digitação, pergunta fora do roteiro.
Um caso real entrando no protótipo
Recriação ilustrativa de um teste — o caso real expõe o que o exemplo limpo nunca mostraria.
🔎 O que observar no teste
- Acertou o essencial? A resposta resolve o que o cliente queria.
- Onde travou? Em que ponto o sistema se perdeu ou chutou.
- O tom serve? Soa como a empresa falaria de verdade.
🔄 Iterar rápido
Iterar é repetir o ciclo testar → ajustar → testar de novo, em voltas curtas. O segredo não é acertar de primeira — é encurtar o tempo entre ver um problema e corrigi-lo. Voltas pequenas e frequentes vencem o grande "vou consertar tudo de uma vez": cada ajuste é fácil de medir e, se piorar, fácil de desfazer.
Uma volta de iteração (curta)
Rodar um caso
Passa um caso real e observa a resposta.
Achar UM problema
Escolhe o defeito mais gritante, não todos de uma vez.
Ajustar uma coisa
Muda só aquilo — uma instrução, uma regra, um exemplo.
Testar de novo
Confirma que melhorou — e começa outra volta.
💡 Dica prática
Mude uma coisa por vez. Se você ajusta cinco coisas e o resultado melhora, não sabe qual ajuste funcionou — e se piora, não sabe qual estragou. Uma mudança por volta mantém o aprendizado limpo.
⚠️ Erros comuns no protótipo
A maioria dos protótipos não morre por falta de capacidade técnica — morre por armadilhas previsíveis. Conhecer os erros mais comuns antes de cair neles economiza dias. Veja os cinco que mais derrubam protótipo de IA — e o antídoto de cada um.
Antídoto: corte até sobrar só o caminho que resolve o problema principal.
Antídoto: teste feio primeiro; só invista em acabamento no que provou valor.
Antídoto: jogue casos reais e bagunçados desde a primeira volta.
Antídoto: uma mudança por volta, para saber o que funcionou.
Antídoto: defina antes o que conta como "funciona" (próximo tópico).
💡 Dica prática
O erro mais caro é o perfeccionismo precoce: gastar dias deixando bonito algo que ninguém usou ainda. Protótipo feio que roda vale mais que protótipo lindo que nunca saiu do papel.
✅ Critério de "funciona"
"Funciona" não pode ser uma sensação. Sem um critério claro, você itera para sempre ou para cedo demais. O critério de "funciona" é uma frase objetiva, definida antes de testar, que diz qual resultado prova que o protótipo está pronto para a próxima etapa — medir e evoluir. Ele é o que fecha o ciclo do MVP.
✓ Critério claro (mensurável)
- ✓"Responde 8 de 10 perguntas reais sem erro."
- ✓"Resolve o pedido sem precisar de humano."
- ✓"Entrega em menos de 30 segundos."
- ✓Dá para responder sim ou não, sem discussão.
✗ Critério vago (sensação)
- ✗"Ficou bom."
- ✗"Tá quase lá."
- ✗"Acho que dá pra mostrar."
- ✗Depende de quem você pergunta.
🏁 O critério fecha o ciclo
Com um critério objetivo, você sabe quando parar de iterar e seguir para o Módulo 3.5 (medir resultado). Sem ele, o protótipo ou nunca fica "pronto" ou é declarado pronto cedo demais. O critério é a linha de chegada que você desenha antes de correr.
Auto-checagem (opcional): o que é começar pelo MVP?
🛠️ Resumo do módulo
Próximo módulo:
3.5 — Medir Resultado: sair do "parece que funciona" para o número que prova o valor.