Bob·ArchitectBob entwirft das System, wählt den Stack und übergibt die Struktur an Alex, sodass Ihre Architektur zur Codebasis wird und nicht zu einem vergessenen Dokument.
Diagramme, die Code abbilden, keine hübschen Bilder.
Eraser und Whimsical erstellen schöne Kästchen und Pfeile. Ihre Ingenieure bauen trotzdem das, was zur Deadline passt. Bobs Diagramme werden zur Dateistruktur und zu den Modulgrenzen, die Alex tatsächlich verwendet.
„Wir haben Mongo gewählt, weil es populär war.“ Bob erklärt, warum Postgres statt Mongo, warum eine Queue statt direkter Aufrufe, warum Redis vs Memcached. Die Begründung ist schriftlich festgehalten, sodass Sie sie hinterfragen können.
Das Diagramm im Wiki stammt aus Sprint 1. Der Code ist aus Sprint 14. Niemand aktualisiert beides, damit es übereinstimmt. Bob prüft das aktuelle System und aktualisiert das Architekturdokument, damit es das widerspiegelt, was tatsächlich ausgeliefert wurde.
Performance, Sicherheit und Observability werden erst nach dem ersten Ausfall nachgerüstet. Bob plant sie bereits während des Designs mit Emmas Skalierungsanforderungen und den Zugriffsmustern, die Ihr Datenmodell unterstützen muss.
Von Ihrem ersten Prompt bis zu einem ausgelieferten Ergebnis — so funktioniert Bob tatsächlich.
Bob startet mit einem klar abgegrenzten Umfang, damit die Architektur zum Produkt passt — und nicht umgekehrt.
An Emma übergebenDatenbank, Framework, Queue, Cache — zu jeder Auswahl gibt es eine schriftliche Abwägung, die Sie hinterfragen können.
Entitäten, Beziehungen, Ownership, Schreibpfade — die Dinge, deren Refactoring später richtig schmerzt.
Kästen und Pfeile bilden echte Module und Abhängigkeiten ab; das Diagramm bleibt synchron, während Code hinzukommt.
Alex entwickelt innerhalb der von Bob gesetzten Grenzen — ohne eingebaute technische Schulden nach dem Motto „Das refaktorieren wir in drei Monaten“.
An Alex übergebenService-, Datenfluss- und Integrationsdiagramme, die im Editor und nicht in einem separaten Tool erstellt werden.
Stack-Entscheidungen, die anhand Ihrer Anforderungen begründet werden, statt nach Trends oder Vertrautheit getroffen zu werden.
Schemata und Beziehungen, die für die tatsächlichen Zugriffsmuster Ihres Produkts entworfen werden.
Performance, Sicherheit und Observability werden bereits während des Designs berücksichtigt, nicht erst nach dem Launch.
Architekturentscheidungen werden zusammen mit ihrer Begründung dokumentiert, damit Ihr zukünftiges Ich sie erneut nachvollziehen kann.
Diagramme werden auf die Dateistruktur und die Modulgrenzen abgebildet, mit denen Alex arbeitet.
Bob kann bestehende Systeme prüfen und Änderungen mit klarer Begründung empfehlen.
Manuell erstellte Workflows sind langsam, händisch und toollastig. Bewege den Mauszeiger über eine beliebige Karte, um zu sehen, warum jeder Gewinn wichtig ist.
Du kommst von Eraser AI? Hier zeigt sich, wo Bob die Nase vorn hat.
Eraser und Whimsical zeichnen hübsche Kästchen; deine Engineers bauen trotzdem das, was in den Zeitplan passt. Bobs Diagramme werden zur Dateistruktur und zu den Modulgrenzen, die Alex tatsächlich in der Codebase verwendet.
ChatGPT empfiehlt das Framework, das es in den Trainingsdaten am häufigsten gesehen hat. Bob erklärt, warum Postgres statt Mongo, warum eine Queue statt direkter Aufrufe, warum Redis statt Memcached — mit Begründungen, die du hinterfragen kannst, und Entscheidungen, die du später erneut prüfen kannst.
Ein Diagramm in einem Wiki ist spätestens bis Sprint 3 veraltet. Bob prüft den tatsächlichen Code und aktualisiert die Architektur anhand dessen, was ausgeliefert wurde — so ist die Dokumentation nie bloße Fiktion, und das Onboarding eines neuen Engineers dauert einen Tag statt eines Monats.
| Funktion | Atoms Empfohlen | Eraser AI |
|---|---|---|
| Ausgabe | Architektur, die sich in Code abbilden lässt | Diagramm in einem Wiki |
| Stack-Auswahl mit Begründung | Dokumentierte Abwägungen | Allgemeine Vorschläge |
| Bleibt synchron, während Code ausgeliefert wird | Gegen die Codebasis aktualisiert | Spätestens ab Sprint 3 veraltet |
| Mit Engineering verbunden | An Alex übergeben | Per Export übergeben |
| Diagrammerstellung | Automatisch generiert | Automatisch generiert |
Bob arbeitet nicht allein. So laufen die Übergaben ab, wenn du mit dem gesamten Team entwickelst.
Bob entwirft das System; Alex baut es. Keine eingebaute technische Schuld nach dem Motto „In 6 Monaten refaktorieren wir, wenn die Skalierung kommt“.
Sehen, wie Alex funktioniertBob richtet die Architektur an Emmas Produktumfang aus. Kein überkonstruiertes System für ein einfaches Feature.
Sehen, wie Emma funktioniert
Bob entwirft das Datenmodell so, dass David sauber darauf zugreifen kann. Analytics ist ein zentraler Bestandteil und kein nachträglicher Anbau.
Sehen, wie David funktioniertKonkrete Architekturarbeit, die Bob erstellt und die sich echtem Code zuordnen lässt.
Entwerfen Sie das System von Grund auf, wobei die Stack-Auswahl im Hinblick auf Ihre Anforderungen begründet wird.
Vergleichen Sie Stack-Optionen für Ihr Projekt und wählen Sie diejenige aus, die zu Ihrem Team und Ihrer Skalierung passt.
Schema, Beziehungen und Indizes, ausgelegt auf die Abfragen, die Ihr Produkt tatsächlich ausführen wird.
Ordnen Sie Drittanbieterdienste, Webhooks und den Datenfluss zu, bevor die Integrationsarbeit beginnt.
Identifizieren Sie Engpässe und planen Sie für die nächste Größenordnung, bevor sie die Produktion erreichen.
Identifizieren Sie Authentifizierungs-, Daten- und Datenschutzbedenken und berücksichtigen Sie sie bereits im Design statt erst nach dem Launch.
@Bob entwirf die Architektur für ein mandantenfähiges SaaS mit nutzungsbasierter Abrechnung, 10.000 erwarteten Mandanten und Stripe Connect-Auszahlungen. Wähle den Stack, zeichne das Servicediagramm und übergib die Dateistruktur an Alex.
@Bob wir wählen für das neue Produkt zwischen Postgres + Prisma und PlanetScale + Drizzle. Vergleiche sie anhand unserer Anforderungen (Multi-Region-Reads, ein einzelner Engineer, 100 ms p95) und empfehle eine Option mit expliziten Trade-offs.
@Bob überprüfe unsere aktuelle API-Schicht. Beim Dashboard-Endpunkt sehen wir 800 ms p95 und möchten auf das 10-fache an Traffic skalieren. Ermittle die Bottlenecks, schlage Änderungen vor und schreibe den Migrationsplan für Alex.
@Bob entwirf das Schema für das Empfehlungsprogramm in Emmas PRD. Stelle die Entitäten, Beziehungen und Indizes für die Abfragen dar, die wir tatsächlich ausführen werden. Übergib das Schema und den Migrationsplan an Alex.
Kein Agent arbeitet allein. Tippen Sie auf ein beliebiges Teammitglied, um zu sehen, wie es seinen Teil Ihres Produkts bearbeitet.
Vertraut von Kunden aus
Hören Sie auf, Diagramme zu zeichnen, die niemand umsetzt. Lassen Sie Bob Systeme entwerfen, die Ihr KI-Team in Atoms erstellt und synchron hält.
