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.
De votre premier prompt à un résultat livré — voici comment Bob fonctionne réellement.
Bob part d’un périmètre délimité pour que l’architecture corresponde au produit, et non l’inverse.
Transférer à EmmaBase de données, framework, file d'attente, cache — chaque choix s'accompagne d'un arbitrage écrit que vous pouvez remettre en question.
Entités, relations, ownership, chemins d’écriture — les choses qu’il est douloureux de refactoriser plus tard.
Les boîtes et les flèches reflètent les modules et dépendances réels ; le diagramme reste synchronisé à mesure que le code arrive.
Alex construit dans les limites définies par Bob — sans dette technique intégrée du type « on refactorisera dans trois mois ».
Transférer à 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.
Les workflows conçus manuellement sont lents, manuels et très dépendants des outils. Survolez une carte pour voir pourquoi chaque gain compte.
Vous venez de Eraser AI ? Voici où Bob prend l’avantage.
Eraser et Whimsical dessinent de jolies boîtes ; vos ingénieurs construisent quand même ce qui rentre dans la deadline. Les diagrammes de Bob deviennent la structure de fichiers et les frontières de modules qu’Alex utilise réellement dans la base de code.
ChatGPT recommande le framework qu’il a vu le plus souvent dans ses données d’entraînement. Bob explique pourquoi choisir Postgres plutôt que Mongo, une file d’attente plutôt que des appels directs, Redis plutôt que Memcached — avec un raisonnement que vous pouvez remettre en question et des décisions que vous pouvez réexaminer.
Un diagramme dans un wiki est déjà obsolète au sprint 3. Bob passe en revue le code réel et met à jour l’architecture en fonction de ce qui a été livré — ainsi, la documentation n’est jamais une fiction, et l’intégration d’un nouvel ingénieur prend une journée, pas un mois.
| Fonctionnalité | Atoms Recommandé | Eraser AI |
|---|---|---|
| Résultat | Une architecture qui se traduit en code | Diagramme dans un wiki |
| Choix de stack avec justification | Compromis documentés | Suggestions génériques |
| Reste synchronisé à mesure que le code est livré | Actualisé par rapport à la base de code | Devient obsolète dès le sprint 3 |
| Connecté à l’ingénierie | Transférer à Alex | Transférer via export |
| Création de diagrammes | Généré automatiquement | Généré automatiquement |
Bob ne travaille pas seul. Voici comment se font les relais quand vous construisez avec l’équipe complète.
Bob conçoit le système ; Alex le construit. Pas de dette technique intégrée du type « on refactorisera dans 6 mois quand l’échelle augmentera ».
Voir comment Alex fonctionneBob aligne l’architecture sur le périmètre produit d’Emma. Pas de système surconçu pour une fonctionnalité simple.
Voir comment Emma fonctionne
Bob conçoit le modèle de données pour que David puisse l’interroger proprement. L’analytics est un élément de premier plan, pas un ajout après coup.
Voir comment David fonctionneConcrete 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.
Aucun agent ne travaille seul. Touchez n’importe quel coéquipier pour voir comment il gère sa partie de votre produit.
Stop drawing diagrams nobody implements. Let Bob design systems your AI Team builds and keeps in sync inside Atoms.
