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.
Desde tu primer prompt hasta un resultado entregado: así es como realmente funciona Bob.
Bob parte de un alcance acotado para que la arquitectura se ajuste al producto, y no al revés.
Transferir a EmmaBase de datos, framework, cola, caché: cada elección viene con una explicación escrita de sus trade-offs que puedes cuestionar.
Entidades, relaciones, ownership, rutas de escritura: las cosas que luego más duelen al refactorizar.
Los cuadros y las flechas reflejan módulos y dependencias reales; el diagrama se mantiene sincronizado a medida que se implementa el código.
Alex construye dentro de los límites que trazó Bob; no incorpora deuda técnica del tipo "lo refactorizaremos en tres meses".
Transferir a 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.
Los flujos de trabajo hechos manualmente son lentos, manuales y dependen mucho de herramientas. Pasa el cursor sobre cualquier tarjeta para ver por qué importa cada mejora.
¿Vienes de Eraser AI? Aquí es donde Bob toma la delantera.
Eraser y Whimsical dibujan cajas bonitas; tus ingenieros igual construyen lo que encaje con la fecha límite. Los diagramas de Bob se convierten en la estructura de archivos y los límites de módulos que Alex realmente usa en la base de código.
ChatGPT recomienda el framework que vio con más frecuencia en los datos de entrenamiento. Bob explica por qué Postgres en lugar de Mongo, por qué una cola en lugar de llamadas directas, por qué Redis frente a Memcached, con un razonamiento que puedes cuestionar y decisiones que puedes revisar de nuevo.
Un diagrama en una wiki se queda obsoleto para el sprint 3. Bob revisa el código real y actualiza la arquitectura según lo que se lanzó, para que la documentación nunca sea una ficción y la incorporación de un nuevo ingeniero tome un día, no un mes.
| Funcionalidad | Atoms Recomendado | Eraser AI |
|---|---|---|
| Resultado | Arquitectura que se traduce en código | Diagrama en una wiki |
| Selecciones de stack con fundamentos | Trade-offs por escrito | Sugerencias genéricas |
| Se mantiene sincronizado a medida que el código se entrega | Actualizado según la base de código | Queda obsoleto para el sprint 3 |
| Conectado a ingeniería | Transferir a Alex | Transferir mediante exportación |
| Creación de diagramas | Generado automáticamente | Generado automáticamente |
Bob no trabaja solo. Así es como se concretan los traspasos cuando construyes con el equipo completo.
Bob diseña el sistema; Alex lo construye. Sin deuda técnica incorporada del tipo «refactorizar en 6 meses cuando llegue la escala».
Ver cómo Alex funcionaBob ajusta la arquitectura al alcance del producto de Emma. Nada de sistemas sobrediseñados para una función simple.
Ver cómo Emma funciona
Bob diseña el modelo de datos para que David pueda consultarlo con claridad. La analítica es una parte fundamental, no un añadido.
Ver cómo 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.
Ningún agente trabaja solo. Toca a cualquier compañero para ver cómo se encarga de su parte de tu producto.
Stop drawing diagrams nobody implements. Let Bob design systems your AI Team builds and keeps in sync inside Atoms.
