Bob·ArchitectBob progetta il sistema, sceglie lo stack e consegna la struttura ad Alex, così la tua architettura diventa la codebase, non un documento dimenticato.
Diagrammi che corrispondono al codice, non semplici belle immagini.
Eraser e Whimsical producono splendidi riquadri e frecce. I tuoi ingegneri continuano comunque a costruire ciò che rientra nella scadenza. I diagrammi di Bob diventano la struttura dei file e i confini dei moduli che Alex usa davvero.
"Abbiamo scelto Mongo perché era popolare." Bob spiega perché Postgres invece di Mongo, perché una queue invece di chiamate dirette, perché Redis vs Memcached. Il ragionamento è messo per iscritto così puoi metterlo in discussione.
Il diagramma nel wiki è dello sprint 1. Il codice è dello sprint 14. Nessuno aggiorna né l'uno né l'altro perché combacino. Bob esamina il sistema attuale e aggiorna il documento di architettura per riflettere ciò che è stato realmente rilasciato.
Prestazioni, sicurezza e osservabilità vengono adattate in un secondo momento, dopo il primo disservizio. Bob le pianifica durante la progettazione con i requisiti di scala di Emma e i pattern di accesso che il tuo modello dati deve supportare.
Dal tuo primo prompt a un risultato rilasciato: ecco come funziona davvero Bob.
Bob parte da un ambito ben delimitato così che l’architettura si adatti al prodotto, e non il contrario.
Passa a EmmaDatabase, framework, coda, cache — ogni scelta include un'analisi scritta dei compromessi che puoi mettere in discussione.
Entità, relazioni, ownership, percorsi di scrittura: le cose che fanno male da rifattorizzare più avanti.
Riquadri e frecce rispecchiano moduli e dipendenze reali; il diagramma resta sincronizzato man mano che il codice prende forma.
Alex sviluppa entro i confini tracciati da Bob, senza incorporare debito tecnico del tipo "faremo refactoring tra tre mesi".
Passa a AlexDiagrammi di servizi, flusso dei dati e integrazione generati nell'Editor, non in uno strumento separato.
Scelte dello stack giustificate in base ai tuoi vincoli, non dettate da tendenze o familiarità.
Schemi e relazioni progettati per i reali pattern di accesso del tuo prodotto.
Prestazioni, sicurezza e osservabilità affrontate durante la progettazione, non dopo il lancio.
Decisioni architetturali messe per iscritto con le relative motivazioni, così il te del futuro potrà rivederle.
I diagrammi si mappano alla struttura dei file e ai confini dei moduli con cui Alex sviluppa.
Bob può esaminare i sistemi esistenti e consigliare modifiche con motivazioni chiare.
I workflow realizzati manualmente sono lenti, manuali e dipendono molto dagli strumenti. Passa il cursore su una scheda per vedere perché ogni vantaggio conta.
Arrivi da Eraser AI? Ecco dove Bob è un passo avanti.
Eraser e Whimsical producono bei riquadri; i tuoi ingegneri continueranno comunque a costruire ciò che rientra nella scadenza. I diagrammi di Bob diventano la struttura dei file e i confini dei moduli che Alex usa davvero nel codebase.
ChatGPT consiglia il framework che ha visto più spesso nei dati di addestramento. Bob spiega perché scegliere Postgres invece di Mongo, perché una queue invece di chiamate dirette, perché Redis invece di Memcached — con motivazioni che puoi mettere in discussione e decisioni che puoi rivedere.
Un diagramma in una wiki diventa obsoleto già entro lo sprint 3. Bob rivede il codice reale e aggiorna l’architettura in base a ciò che è stato rilasciato, così la documentazione non è mai una finzione e l’onboarding di un nuovo ingegnere richiede un giorno, non un mese.
| Funzionalità | Atoms Consigliato | Eraser AI |
|---|---|---|
| Output | Architettura che si traduce in codice | Diagramma in una wiki |
| Scelte di stack con motivazione | Trade-off messi per iscritto | Suggerimenti generici |
| Resta sincronizzato mentre il codice viene rilasciato | Aggiornato rispetto alla codebase | Diventa obsoleto entro lo sprint 3 |
| Connesso all'ingegneria | Passa ad Alex | Passa tramite esportazione |
| Creazione di diagrammi | Generato automaticamente | Generato automaticamente |
Bob non lavora da solo. Ecco come avvengono i passaggi di consegne quando sviluppi con il team completo.
Bob progetta il sistema; Alex lo realizza. Niente debito tecnico incorporato del tipo "rifattorizziamo tra 6 mesi quando arriverà la scala".
Scopri come Alex funzionaBob allinea l’architettura all’ambito del prodotto di Emma. Niente sistemi eccessivamente progettati per una funzionalità semplice.
Scopri come Emma funziona
Bob progetta il modello dati in modo che David possa interrogarlo in modo pulito. L’analisi è un elemento fondamentale, non un’aggiunta.
Scopri come David funzionaLavoro concreto di architettura che Bob produce e che si traduce in codice reale.
Progetta il sistema da zero con scelte dello stack giustificate in base ai tuoi vincoli.
Confronta le opzioni di stack per il tuo progetto e scegli quella più adatta al tuo team e alla tua scala.
Schema, relazioni e indici progettati per le query che il tuo prodotto eseguirà davvero.
Mappa servizi di terze parti, webhook e flusso dei dati prima che inizi il lavoro di integrazione.
Identifica i colli di bottiglia e pianifica il prossimo ordine di grandezza prima che arrivino in produzione.
Identifica i problemi di autenticazione, dati e privacy e affrontali in fase di progettazione invece che dopo il lancio.
@Bob progetta l'architettura per un SaaS multi-tenant con fatturazione basata sull'utilizzo, 10.000 tenant previsti e pagamenti Stripe Connect. Scegli lo stack, disegna il diagramma dei servizi e consegna la struttura dei file ad Alex.
@Bob stiamo scegliendo tra Postgres + Prisma e PlanetScale + Drizzle per il nuovo prodotto. Confrontali rispetto ai nostri vincoli (letture multi-region, un solo ingegnere, 100 ms p95) e raccomandane uno con compromessi espliciti.
@Bob esamina il nostro attuale layer API. Stiamo osservando 800 ms p95 sull'endpoint della dashboard e vogliamo scalare fino a 10 volte il traffico. Mappa i colli di bottiglia, proponi modifiche e scrivi il piano di migrazione per Alex.
@Bob progetta lo schema per il programma di referral nel PRD di Emma. Mappa le entità, le relazioni e gli indici per le query che eseguiremo realmente. Consegna lo schema e il piano di migrazione ad Alex.
Nessun agente lavora da solo. Tocca un qualsiasi compagno di team per vedere come gestisce la sua parte del tuo prodotto.
Smettila di disegnare diagrammi che nessuno implementa. Lascia che Bob progetti sistemi che il tuo team AI costruisce e mantiene sincronizzati all'interno di Atoms.
