Abbiamo già discusso dell’impatto dell’Intelligenza Artificiale (AI) sul lavoro dei software architect, evidenziando come possa aumentare la produttività nella documentazione dei design, nella ricerca di nuove tecnologie e nell’estrazione di informazioni chiave dai documenti architetturali. Tuttavia, l’AI non può sostituire i software architect: è solo uno strumento potente, i cui limiti non sono ancora del tutto definiti. Gli architetti software prendono decisioni critiche e forniscono output di alta qualità basati sulla loro competenza di dominio, sul contesto aziendale e sulla profondità tecnica.

Ma, per curiosità, abbiamo voluto fare un esperimento: può l’AI comportarsi come un “software architect”? E, se sì, con quali risultati?
Abbiamo messo alla prova quattro modelli LLM (Large Language Models), fornendo a ciascuno lo stesso set di prompt, valutando i loro output e diagrammi, e tirando le somme alla fine. I modelli testati sono:

• GPT-4o (ChatGPT)
• Claude 4.0 Sonnet (Anthropic)
• Sonar (Perplexity)
• Grok 3 (xAI)

Scenario: Servizio di Raccomandazione Bancaria

Immaginiamo questa situazione:
Il management vuole aumentare l’engagement dei clienti offrendo esperienze bancarie personalizzate, aiutando gli utenti a scoprire prodotti finanziari rilevanti. Chiede quindi al team di ingegneria di progettare un servizio di raccomandazione basato su Machine Learning, capace di analizzare il comportamento degli utenti, la cronologia delle transazioni e altri segnali per suggerire prodotti su misura (es. carte di credito, conti di risparmio, opzioni di investimento).

Il team ha un software architect incaricato di definire il perimetro del progetto e disegnare il diagramma architetturale che mostri come integrare questa nuova funzionalità nella piattaforma bancaria esistente. Per accelerare la pianificazione, l’architetto vuole verificare se un LLM può aiutarlo a generare una proposta architetturale di qualità.

Il Prompt

Ecco il prompt che abbiamo fornito ai modelli:

“Sei un software architect incaricato di creare diagrammi C4 per un servizio di raccomandazione di prodotti bancari basato su ML. Vogliamo un nuovo componente software che sfrutti il comportamento dell’account utente, la cronologia delle transazioni e segnali finanziari di terze parti per generare raccomandazioni personalizzate (es. conti di risparmio, carte di credito, opzioni di investimento). Questo componente deve essere accessibile sia dalle app interne della banca sia dai canali rivolti ai clienti (web e mobile). Lo chiameremo Panda Service.

Il tuo compito è creare un diagramma architetturale completo per Panda basato sul modello C4:

• Context Diagram: mostra come Panda si inserisce nel sistema bancario e chi interagisce con esso (servizi interni, utenti finali, fornitori di dati).
• Container Diagram: suddividi il sistema Panda in container/servizi deployabili (es. API layer, training del modello, inferenza, data ingestion).
• Component Diagram: dettaglia i componenti all’interno di ciascun container (pipeline dati, endpoint di inferenza, estrattori di feature, retraining del modello, scheduler, ecc.).
• Code Diagram: per un componente selezionato (es. servizio di inferenza), mostra astrazioni a livello di classi o moduli.

Assicurati che il design sia completo e pronto per la produzione, così da poterlo presentare sia al team tecnico sia al product management per approvazione e successiva implementazione. Considera tutti gli aspetti tecnici: flusso dei dati, interfacce, astrazioni, scalabilità e monitoraggio.

I tuoi diagrammi devono riflettere le best practice di progettazione e conformarsi alle normative bancarie.”

Osservazioni

Ecco cosa abbiamo notato:

• Le risposte dei quattro LLM tendevano a concentrarsi sul Code Diagram, mentre faticavano a produrre i diagrammi di Context, Container e Component.
• I modelli fornivano concetti chiave con qualche spiegazione (gateway bancari, pipeline di ingestion, inferenza del modello), ma mancavano di motivare le scelte architetturali.
• Le tecnologie suggerite erano sempre le stesse: AWS API Gateway, SageMaker, PostgreSQL, Redis, S3. Sembrava che i modelli scegliessero soluzioni popolari basandosi su pattern ricorrenti, piuttosto che applicare logica contestuale.
• Spesso i design erano pensati per un “mondo perfetto”, ignorando vincoli reali come restrizioni tecnologiche, limiti di budget o cambi di requisiti. Bastava una domanda di follow-up per metterli in difficoltà.
• Anche se i modelli identificavano gli attori del sistema bancario, trascuravano aspetti pratici: come distribuire il codice in produzione, gestire nuove versioni del servizio di raccomandazione o esportare i dati per analisi avanzate.

Il nostro verdetto sugli LLM

• Disegnano diagrammi come sviluppatori junior o mid-level.
• Mancano di pensiero pragmatico nelle decisioni architetturali.
• Assumono scenari ideali e non coprono casi limite o requisiti in evoluzione.

TL;DR: possiamo fidarci solo dei software architect, non degli LLM.

Analisi dei modelli

1. GPT-4o (ChatGPT)

Ha iniziato bene con il Context Diagram, descrivendo attori e sistemi esterni (clienti, dipendenti bancari, integrazioni dati). Tuttavia, non è riuscito ad approfondire i diagrammi Component e Container.
Ha elencato i componenti principali (gateway bancario, servizio di inferenza, feature store, pipeline dati), ma senza dettagli sulle interazioni.
Nel Container Diagram, ha confuso il concetto con il Code Diagram, generando container come classi Python (es.RecommendationEngine, Preprocessor, RequestValidator).
Il Code Diagram era quasi una copia del Container, con snippet di codice.
In sintesi: discreto sul Context e Container, insufficiente su Component e Code.

2. Claude 4.0 Sonnet (Anthropic)

Claude ha mostrato una buona capacità di strutturare il Context Diagram, con attori e flussi chiari. Sul Container Diagram, ha proposto una suddivisione più realistica (API Gateway, servizio di inferenza, data pipeline, feature store). Tuttavia, il Component Diagram era superficiale e il Code Diagram si è limitato a pseudocodice generico.
Claude ha dimostrato un approccio più ordinato rispetto a GPT-4o, ma senza entrare nel dettaglio tecnico necessario per un’architettura pronta alla produzione.

3. Sonar (Perplexity)

Sonar ha prodotto diagrammi molto semplificati, con poche entità e relazioni. Ha suggerito tecnologie standard senza giustificarne la scelta. Il Code Diagram era quasi assente, mentre il Context Diagram sembrava più una lista di attori che un vero schema.
In sintesi: output troppo superficiale per essere utile in un contesto reale.

4. Grok 3 (xAI)

Grok ha puntato molto sul Code Diagram, fornendo classi e metodi dettagliati, ma ha trascurato completamente il Context e il Component Diagram. Ha proposto un’architettura “perfetta” senza considerare vincoli reali.
Risultato: interessante per chi vuole vedere codice, ma inutile per chi deve progettare un sistema scalabile e conforme alle normative.

Best Practice per usare LLM nell’architettura software

• Prompt chiari e dettagliati: più il contesto è ricco, più l’output sarà utile.
• Validazione umana: ogni proposta deve essere revisionata da un architetto esperto.
• Usali per brainstorming, non per decisioni critiche.
• Integra i diagrammi generati con strumenti professionali (PlantUML, Structurizr DSL).
• Considera i vincoli reali: budget, compliance, scalabilità.