Bob·ArchitectBob dessine le système, choisit la stack et transmet la structure à Alex afin que votre architecture devienne la base de code, et non un document oublié.
Des schémas qui correspondent au code, pas de jolies images.
Eraser et Whimsical produisent de magnifiques boîtes et flèches. Vos ingénieurs continuent malgré tout à construire ce qui rentre dans les délais. Les schémas de Bob deviennent la structure des fichiers et les limites des modules qu’Alex utilise réellement.
"Nous avons choisi Mongo parce que c’était populaire." Bob explique pourquoi Postgres plutôt que Mongo, pourquoi une queue plutôt que des appels directs, pourquoi Redis vs Memcached. Le raisonnement est consigné par écrit afin que vous puissiez le remettre en question.
Le schéma du wiki date du sprint 1. Le code date du sprint 14. Personne ne met l’un ou l’autre à jour pour qu’ils correspondent. Bob passe en revue le système actuel et met à jour le document d’architecture pour refléter ce qui est réellement livré.
Les performances, la sécurité et l’observabilité sont ajoutées après coup, après la première panne. Bob les prévoit dès la phase de conception, avec les exigences de montée en charge d’Emma et les schémas d’accès que votre modèle de données doit prendre en charge.
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 à AlexDiagrammes de service, de flux de données et d’intégration générés dans l’Éditeur, et non dans un outil séparé.
Choix de stack justifiés en fonction de vos contraintes, et non dictés par les tendances ou l’habitude.
Schémas et relations conçus pour les véritables modèles d’accès de votre produit.
Performance, sécurité et observabilité prises en compte dès la conception, et non après le lancement.
Décisions architecturales consignées avec leur justification afin que votre futur vous puisse les réexaminer.
Les diagrammes correspondent à la structure des fichiers et aux limites des modules avec lesquels Alex construit.
Bob peut examiner des systèmes existants et recommander des changements avec un raisonnement clair.
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 fonctionneTravail d’architecture concrète que Bob produit et qui correspond à du vrai code.
Concevez le système à partir de zéro avec des choix de stack justifiés selon vos contraintes.
Comparez les options de stack pour votre projet et choisissez celle qui correspond à votre équipe et à votre échelle.
Schéma, relations et index conçus pour les requêtes que votre produit exécutera réellement.
Cartographiez les services tiers, les webhooks et les flux de données avant le début du travail d’intégration.
Identifiez les goulots d’étranglement et planifiez le prochain ordre de grandeur avant qu’ils n’atteignent la production.
Identifiez les enjeux d’authentification, de données et de confidentialité et traitez-les dès la conception plutôt qu’après le lancement.
@Bob conçois l’architecture d’un SaaS multi-locataire avec facturation basée sur l’usage, 10k locataires attendus et paiements Stripe Connect. Choisis la stack, dessine le diagramme des services et remets la structure des fichiers à Alex.
@Bob nous choisissons entre Postgres + Prisma et PlanetScale + Drizzle pour le nouveau produit. Compare-les selon nos contraintes (lectures multi-région, un seul ingénieur, 100ms p95) et recommande-en une avec des compromis explicités.
@Bob passe en revue notre couche API actuelle. Nous constatons un p95 de 800ms sur l’endpoint du tableau de bord et voulons passer à 10x le trafic. Identifie les goulots d’étranglement, propose des changements et rédige le plan de migration pour Alex.
@Bob conçois le schéma du programme de parrainage dans le PRD d’Emma. Cartographie les entités, les relations et les index pour les requêtes que nous exécuterons réellement. Remets le schéma et le plan de migration à Alex.
Aucun agent ne travaille seul. Touchez n’importe quel coéquipier pour voir comment il gère sa partie de votre produit.
Arrêtez de dessiner des schémas que personne ne met en œuvre. Laissez Bob concevoir des systèmes que votre équipe IA construit et maintient synchronisés dans Atoms.
