Entender A arquitetura
O primeiro passo não foi código. Foi arquitetura. Antes de escrever uma linha de código do Vibe Coding Hub, eu precisei responder uma pergunta simples e desconfortável:
Esse projeto vai ser só mais uma plataforma… ou um sistema que consegue evoluir sem se perder?
A resposta DEFINE! Em vez de começar pelo frontend, banco ou stack da moda, o primeiro passo foi registrar decisões. Criar uma base que permita mudar, escalar e incorporar IA sem virar caos daqui a seis meses, essa foi minha primeira pergunta ao chatgpt 5.2:
Quero criar uma plataforma chamada Vibecodinglabs.
A ideia da plataforma é ser um hub de aprendizado prático sobre vibe coding — onde pessoas compartilham experiências reais criando sistemas com IA, validam esse conteúdo pela comunidade (upvote/downvote) e recebem recomendações de acordo com o stack, framework ou ferramenta que usam.
Não é um curso, nem só um blog, nem um repositório de código.
É um lugar para organizar conhecimento prático, decisões, padrões e aprendizados que normalmente ficam espalhados.
Dito isso: não quero discutir features agora.
Antes de qualquer tela, fluxo ou funcionalidade, quero discutir a estrutura da plataforma.
Quero que você atue como arquiteto de software sênior e me ajude a pensar:
Como esse tipo de plataforma deve ser estruturada no geral
(o que precisa existir, o que deve ficar separado, responsabilidades claras)
Qual stack faz mais sentido para esse tipo de produto e por quê
Que tipos de documentos e artefatos arquiteturais eu deveria ter desde o início para não virar bagunça no futuro, como:
SPEC
README
Contracts
ADRs
Tem outra importante?
Explique tudo com linguagem simples, como se eu ainda estivesse aprendendo sobre arquitetura, mas sem tratar o projeto como algo pequeno ou amador, como as parte se conectam e porque é importante eu pensar e como será essa estrutura.
Não escreva código agora.
Quero uma base sólida, pensada para escalar, evoluir e funcionar bem em um produto guiado por IA-driven.Após um papo aqui, outro ali, pedindo explicações mais técnicas, porque daquele jeito, porque daquela stack e não outra, enfim chegamos a uma arquitetura final (Não irei postar tudo agora, criarei um post só mostrando o que foi gerado). Mas um resumo da arquitetura final, isso só num bate papo com o gpt5.2:
### 4. Estrutura do Projeto
```
vibecodinghub/
├── src/
│ ├── app/ # Next.js App Router
│ │ ├── api/ # API Routes (Claude OPUS 4.5)
│ │ ├── blog/ # Blog pages (Gemini PRO 3)
│ │ ├── cards/ # Cards pages (Gemini PRO 3)
│ │ └── (auth)/ # Auth pages (Gemini PRO 3)
│ ├── components/ # React Components (Gemini PRO 3)
│ ├── lib/ # Business Logic (Claude OPUS 4.5)
│ │ ├── services/ # Domain services
│ │ ├── repositories/ # Data access
│ │ └── supabase/ # Supabase clients
│ └── content/ # Static content
├── contracts/ # Shared types (ambas)
│ ├── domain/ # Entity types
│ └── http/ # API contracts
├── prisma/ # Database (Claude OPUS 4.5)
├── adrs/ # Architecture decisions
└── spec/ # Specifications
```Eu seeeeeeeei, parece muita coisa, complicado. Mas a IA tá gerando, vai fazendo pergunta, faça pergunta tipo "Me explique como se eu tivesse 5 anos", aos poucos você vai entendendo melhor.
Definição do MVP
Agora voltando ao MVP com Vibe Coding (sem se sabotar no processo)...
Com a arquitetura no lugar, chegou a hora de decidir o que realmente vai pro ar na primeira versão do Vibecodinglabs. E olha, definir MVP não é sobre cortar tudo até sobrar só um botão. É sobre validar a ideia sem criar uma bomba-relógio técnica pro futuro.
Eu como professor de empreendedorismo nunca sigo o que ensino 😅, mas dessa vez resovi seguir,
Pra isso foi preciso responder a três perguntas:
1. O que precisa existir pra plataforma fazer sentido?
Tipo, qual é o coração da coisa? O mínimo necessário pra alguém ver valor na plataforma, consumir e me dar feedback de verdade. Mesmo sendo simples, algumas coisas já precisam nascer estruturadas. Não dá pra improvisar tudo.
2. O que definitivamente fica pra depois?
Aquelas features que eu adoraria ter, mas que não vão matar o projeto se não estiverem na v1. Coisas que posso adiar sem precisar refatorar metade do código depois. Decisões que não preciso tomar agora (e provavelmente vou mudar de ideia mesmo).
3. O que vira arquitetura desde já?
Mesmo num MVP, com AI-DRIVEN tem coisa que precisa de documentação técnica desde o início. Contratos entre módulos que já precisam estar claros. Decisões que merecem um ADR registrado, mesmo sendo versão 0.1.
A ideia aqui não é jogar tudo no ar o mais rápido possível. É validar a proposta central, aprender com quem vai usar de verdade, mas sem criar aquele tipo de bagunça que te faz querer deletar o repositório daqui seis meses e claro, aproveitar o processo pra aprender e também repassar conhecimento.
Escrever a documentação técnica
Como a própria IA sugeriu de próximos passos:
1. Escrever `SPEC.md` detalhado
2. Formalizar `DOMAIN.md`
3. Criar ADR-001 (Hub vs Lab)
4. Definir contratos de eventos principais
5. Desenhar fluxo do mvp v1
Masssss... Isso fica para o próximo post! 🔚