Bob·ArchitectBob desenha o sistema, escolhe a stack e entrega a estrutura para Alex, para que sua arquitetura se torne a base de código, e não um documento esquecido.
Diagramas que correspondem ao código, não apenas imagens bonitas.
Eraser e Whimsical renderizam lindas caixas e setas. Seus engenheiros ainda constroem o que couber no prazo. Os diagramas do Bob se tornam a estrutura de arquivos e os limites dos módulos que o Alex realmente usa.
"Escolhemos Mongo porque estava na moda." Bob explica por que Postgres em vez de Mongo, por que uma fila em vez de chamadas diretas, por que Redis vs Memcached. O raciocínio fica por escrito para que você possa questioná-lo.
O diagrama na wiki é da sprint 1. O código é da sprint 14. Ninguém atualiza nenhum dos dois para que correspondam. Bob revisa o sistema atual e atualiza o documento de arquitetura para refletir o que realmente foi entregue.
Desempenho, segurança e observabilidade são adaptados depois da primeira indisponibilidade. Bob os planeja durante o design com os requisitos de escala da Emma e os padrões de acesso que o seu modelo de dados precisa suportar.
Do seu primeiro prompt a um resultado entregue — veja como Bob realmente funciona.
Bob começa com um escopo bem delimitado para que a arquitetura se ajuste ao produto, e não o contrário.
Passar para EmmaBanco de dados, framework, fila, cache — cada escolha vem com um trade-off documentado que você pode questionar.
Entidades, relacionamentos, ownership, caminhos de escrita — as coisas que doem para refatorar depois.
Caixas e setas refletem módulos e dependências reais; o diagrama permanece sincronizado à medida que o código entra em produção.
Alex desenvolve dentro dos limites definidos por Bob — sem dívida técnica embutida do tipo "vamos refatorar em três meses".
Passar para AlexDiagramas de serviço, fluxo de dados e integração gerados no Editor, não em uma ferramenta separada.
Escolhas de stack justificadas com base nas suas restrições, não por tendência ou familiaridade.
Esquemas e relacionamentos projetados para os padrões reais de acesso do seu produto.
Desempenho, segurança e observabilidade tratados durante o design, não após o lançamento.
Decisões arquiteturais documentadas com justificativas para que você no futuro possa revisitá-las.
Os diagramas são mapeados para a estrutura de arquivos e os limites dos módulos com os quais Alex constrói.
Bob pode revisar sistemas existentes e recomendar mudanças com justificativas claras.
Workflows feitos manualmente são lentos, manuais e dependem de muitas ferramentas. Passe o cursor sobre qualquer card para ver por que cada ganho importa.
Vindo de Eraser AI? Aqui é onde Bob sai na frente.
Eraser e Whimsical desenham caixinhas bonitas; seus engenheiros ainda vão construir o que couber no prazo. Os diagramas do Bob viram a estrutura de arquivos e os limites de módulos que o Alex realmente usa na base de código.
O ChatGPT recomenda o framework que ele viu com mais frequência nos dados de treinamento. Bob explica por que Postgres em vez de Mongo, por que uma fila em vez de chamadas diretas, por que Redis vs. Memcached — com um raciocínio que você pode questionar e decisões que você pode revisitar.
Um diagrama em uma wiki fica desatualizado até o sprint 3. Bob revisa o código real e atualiza a arquitetura com base no que foi entregue — assim, a documentação nunca vira ficção, e o onboarding de um novo engenheiro leva um dia, não um mês.
| Recurso | Atoms Recomendado | Eraser AI |
|---|---|---|
| Saída | Arquitetura que se traduz em código | Diagrama em uma wiki |
| Escolhas de stack com justificativa | Trade-offs documentados | Sugestões genéricas |
| Permanece em sincronia conforme o código é entregue | Atualizado com base no codebase | Fica desatualizado até o sprint 3 |
| Conectado à engenharia | Passar para Alex | Passar via exportação |
| Criação de diagramas | Gerado automaticamente | Gerado automaticamente |
Bob não trabalha sozinho. Veja como as passagens de trabalho acontecem quando você desenvolve com a equipe completa.
Bob projeta o sistema; Alex o constrói. Sem dívida técnica embutida do tipo "refatorar em 6 meses quando a escala chegar".
Veja como Alex funcionaBob alinha a arquitetura ao escopo do produto da Emma. Nada de sistema superdimensionado para uma funcionalidade simples.
Veja como Emma funciona
Bob projeta o modelo de dados para que David possa consultá-lo com clareza. Analytics é parte fundamental, não um complemento.
Veja como David funcionaTrabalho concreto de arquitetura que Bob produz e que se conecta ao código real.
Projete o sistema do zero com escolhas de stack justificadas de acordo com suas restrições.
Compare opções de stack para o seu projeto e escolha a que melhor se adapta à sua equipe e escala.
Esquema, relacionamentos e índices projetados para as consultas que seu produto realmente executará.
Mapeie serviços de terceiros, webhooks e fluxo de dados antes do início do trabalho de integração.
Identifique gargalos e planeje a próxima ordem de magnitude antes que eles cheguem à produção.
Identifique questões de autenticação, dados e privacidade e trate delas no design em vez de após o lançamento.
@Bob projete a arquitetura para um SaaS multi-tenant com cobrança baseada em uso, 10 mil tenants esperados e repasses via Stripe Connect. Escolha a stack, desenhe o diagrama de serviços e entregue a estrutura de arquivos para Alex.
@Bob estamos escolhendo entre Postgres + Prisma e PlanetScale + Drizzle para o novo produto. Compare-os com base em nossas restrições (leituras multi-região, um único engenheiro, 100ms p95) e recomende uma opção com trade-offs explícitos.
@Bob revise nossa camada de API atual. Estamos vendo 800ms p95 no endpoint do dashboard e queremos escalar para 10x mais tráfego. Mapeie os gargalos, proponha mudanças e escreva o plano de migração para Alex.
@Bob projete o schema para o programa de indicação no PRD da Emma. Mapeie as entidades, os relacionamentos e os índices para as consultas que realmente vamos executar. Entregue o schema e o plano de migração para Alex.
Nenhum agente trabalha sozinho. Toque em qualquer colega de equipe para ver como ele cuida da parte dele no seu produto.
Pare de desenhar diagramas que ninguém implementa. Deixe Bob projetar sistemas que sua Equipe de IA constrói e mantém em sincronia dentro do Atoms.
