Bob·ArchitectBob draws the system, picks the stack, and hands the structure to Alex so your architecture becomes the codebase, not a forgotten doc.
Diagrams that map to code, not pretty pictures.
Eraser and Whimsical render beautiful boxes and arrows. Your engineers still build whatever fits the deadline. Bob's diagrams become the file structure and module boundaries Alex actually uses.
"We picked Mongo because it was popular." Bob explains why Postgres over Mongo, why a queue over direct calls, why Redis vs Memcached. The reasoning is in writing so you can challenge it.
The wiki diagram is from sprint 1. The code is from sprint 14. Nobody updates either to match. Bob reviews the current system and updates the architecture doc to reflect what is actually shipped.
Performance, security, and observability get retrofitted after the first outage. Bob plans them during design with Emma's scale requirements and the access patterns your data model needs to support.
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 AlexService, data flow, and integration diagrams generated in the Editor, not in a separate tool.
Stack choices justified against your constraints, not picked by trend or familiarity.
Schemas and relationships designed for the actual access patterns of your product.
Performance, security, and observability addressed during design, not after launch.
Architectural decisions written down with reasoning so future-you can revisit them.
Diagrams map to the file structure and module boundaries Alex builds with.
Bob can review existing systems and recommend changes with clear reasoning.
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 funcionaConcrete architecture work Bob produces that maps to real code.
Design the system from scratch with stack choices justified against your constraints.
Compare stack options for your project and pick the one that fits your team and scale.
Schema, relationships, and indexes designed for the queries your product will actually run.
Map third-party services, webhooks, and data flow before integration work starts.
Identify bottlenecks and plan for the next order of magnitude before they hit production.
Identify auth, data, and privacy concerns and address them in design instead of post-launch.
@Bob design the architecture for a multi-tenant SaaS with usage-based billing, 10k expected tenants, and Stripe Connect payouts. Pick the stack, draw the service diagram, and hand the file structure to Alex.
@Bob we are choosing between Postgres + Prisma and PlanetScale + Drizzle for the new product. Compare them against our constraints (multi-region reads, single engineer, 100ms p95) and recommend one with explicit trade-offs.
@Bob review our current API layer. We are seeing 800ms p95 on the dashboard endpoint and want to scale to 10x traffic. Map the bottlenecks, propose changes, and write the migration plan for Alex.
@Bob design the schema for the referral program in Emma's PRD. Map the entities, relationships, and indexes for the queries we will actually run. Hand the schema and migration plan to Alex.
Nenhum agente trabalha sozinho. Toque em qualquer colega de equipe para ver como ele cuida da parte dele no seu produto.
Stop drawing diagrams nobody implements. Let Bob design systems your AI Team builds and keeps in sync inside Atoms.
