🤖 Spiega con IA

Casi d’uso di AI Studio¶

Otto modi reali in cui i team usano 4Geeks AI Studio, ciascuno con le capacità che attiva, il processo che segue il pod, il risultato che ottieni e i deliverable che arrivano nel tuo repository. Usa questa pagina per scegliere l’obiettivo giusto per il tuo primo pod.

I casi d’uso a colpo d’occhio¶

flowchart LR
    A[Scegli il tuo obiettivo] --> B[Intake breve in linguaggio di business]
    B --> C[Il pod lead rivede il perimetro]
    C --> D[Tu approvi il piano]
    D --> E[Il pod costruisce su un branch]
    E --> F[Il quality gate esegue i controlli QA]
    F --> G[Tu rivedi la merge request]

Gli otto casi d’uso di AI Studio¶

1. Costruire un nuovo MVP¶

Playbook: greenfield · Dimensione tipica: S–L

• Capacità: Docs, Design e Quality. Aggiungi E2E quando la prima slice deve essere provata in un browser reale.
• Processo: rispondi all’intake con il problema, gli utenti e i tre requisiti essenziali; il pod lead li trasforma in un piano con una slice dichiarata; tu approvi; il pod costruisce il flusso in una sandbox sul tuo branch; il quality gate esegue build e test; tu rivedi la merge request.
• Risultato: una prima slice del prodotto che gira nel tuo repository, coperta da test e pronta per il tuo team da deployare.
• Deliverable: una merge request con il flusso funzionante, i test che lo provano, il pannello operativo se era nello scope e documentazione scritta dal codice.

2. Aggiungere una funzionalità alla tua app¶

Playbook: feature · Dimensione tipica: S o M

• Capacità: Docs e Quality sempre; Design quando la funzionalità cambia l’interfaccia; E2E quando il flusso è critico, come checkout o registrazione.
• Processo: descrivi il risultato in linguaggio di business e scrivi nell’intake come saprai che è finito; arriva il piano con task e criteri di accettazione; lo approvi; il pod costruisce su un branch; i test girano nel gate; tu rivedi e fai il merge.
• Risultato: la funzionalità funzionante da capo a coda nel tuo codice, con test di regressione che la mantengono attiva.
• Deliverable: una merge request, i test e la documentazione aggiornata quando la modifica cambia come si usa il prodotto.

3. Correggere bug sulla tua piattaforma¶

Playbook: bugfix · Dimensione tipica: S

• Capacità: Docs e Quality.
• Processo: riporti il sintomo e come riprodurlo; il pod riproduce il guasto nella sua sandbox e scrive un test che fallisce; il pod lead conferma la causa; entra la correzione; il test diventa verde; tu rivedi la merge request.
• Risultato: la causa spiegata, provata da un test che fallisce, e corretta senza rompere ciò che già funzionava.
• Deliverable: il test che fallisce e prova il bug, la correzione, un test di regressione e la merge request con la spiegazione.

4. Rilevare nuovi errori e migliorare la qualità¶

Playbook: qa · Dimensione tipica: M

• Capacità: Quality, più E2E quando i flussi browser contano.
• Processo: il pod esegue la tua suite attuale, riproduce i fallimenti che trova, amplia la copertura attorno ad essi, aggiunge test browser con Playwright quando E2E è attivo e riesegue tutto sotto il gate.
• Risultato: fallimenti riprodotti con i passi per attivarli, più copertura di test e un run browser verde per i flussi critici.
• Deliverable: test nuovi e aggiornati, un report dei fallimenti con i passi di riproduzione, il report E2E e la merge request.

5. Audire il codice prima di investire¶

Playbook: audit · Dimensione tipica: S o M

• Capacità: Security per la revisione stessa, Data quando lo schema conta, Docs per il report. Il pod gira in read-only.
• Processo: punti il pod al repository; ispeziona codice, dipendenze e schema; i risultati sono ordinati per rischio e sforzo; il pod lead rivede il report prima che tu lo veda.
• Risultato: un elenco prioritizzato di rischi e debito tecnico su cui puoi agire prima di impegnare budget.
• Deliverable: il report con rischi, evidenze e ordine di lavoro consigliato. Nel tuo codice non viene cambiato nulla.

6. Migrare il mio database¶

Playbook: db-migration · Dimensione tipica: M o L

• Capacità: Data e Quality. Il pod riceve accesso read-only al database di origine.
• Processo: il pod mappa lo schema di origine e destinazione, scrive il DDL per la revisione, esegue una validazione in shadow su dati reali e prepara il piano di taglio.
• Risultato: una migrazione di cui puoi fidarti, validata con uno run shadow, con un runbook che il tuo DBA può eseguire.
• Deliverable: la mappa dello schema, il DDL revisionato, l’evidenza della validazione shadow e il runbook. Spostare i dati resta dalla tua parte.

7. Documentare il mio sistema¶

Playbook: docs · Dimensione tipica: S o M

• Capacità: Docs, più SCRUM quando l’output deve diventare issue in Jira, Confluence o Notion.
• Processo: il pod legge il codice reale, redige i documenti, il pod lead li verifica sul codice e tu scegli dove pubblicarli.
• Risultato: documentazione coerente con il sistema com’è scritto, non come viene ricordato.
• Deliverable: un set di documentazione come README, architecture decision record e un riferimento API, pubblicati dove ti servono.

8. Aggiornare dipendenze o refactorare un segmento¶

Playbook: upgrade · Dimensione tipica: S o M

• Capacità: Docs e Quality; E2E quando il refactor tocca un flusso critico.
• Processo: il pod prende una baseline di build e test, applica l’aggiornamento o il refactor, corregge ciò che si rompe e riesegue il gate prima di aprire la merge request.
• Risultato: l’aggiornamento applicato, la rottura corretta e il comportamento esistente preservato dalla suite di test.
• Deliverable: una merge request con changelog, i test aggiornati e una nota su ogni breaking change che il tuo team deve gestire.

Review e QA¶

Ogni caso d’uso qui sopra passa dagli stessi due livelli di qualità. Nel prodotto entrambi fanno parte della capacità Quality e rispondono a domande diverse: QA chiede “funziona?”, Review chiede “dobbiamo mergearlo?”

Cosa copre QA

• Build ed esecuzione dei test nella sandbox con gli script del tuo repository, così il controllo corrisponde al tuo progetto.
• E2E nel browser con Playwright ed Chromium quando la capacità E2E è attiva.
• Un pod con Quality o E2E non può essere marcato come consegnato senza un run verde; un fallimento blocca la consegna con QUALITY_GATE_FAILED.
• Solo una waiver può accettare una consegna, con motivo scritto, e viene registrata nell’audit trail.
• Un tentativo fallito e un retry sono assorbiti da 4Geeks.

Cosa copre Review

• Il pod lead rivede il perimetro prima che tu approvi il piano e decide quando una consegna è pronta.
• Il pod apre una merge request su un branch; non spinge mai su un branch protetto e non mergea mai da solo.
• Il tuo team rivede il diff, i test e le evidenze e fa il merge quando è soddisfatto. Il deploy resta nel tuo pipeline.
• La timeline del pod registra task, controlli, approvazioni e messaggi ed è esportabile in JSON con le credenziali oscurate.

Come funzionano quality gate e deliverable

Storie reali di clienti¶

Gli stessi casi d’uso, consegnati a clienti reali:

• Modernizzazione di dati e infrastruttura — Ketsin: migrazione cloud e operazioni regionali (casi 1 e 6).
• Pagamenti per e-commerce — Nandallo: pagamenti senza attrito per la crescita (caso 2).
• Una piattaforma di ricavi — One Ticket: operazioni semplificate (caso 1).
• Salute e benessere — Total Natural in Costa Rica (caso 2).

Impara il prodotto in questo ordine¶

La documentazione è scritta perché tu possa usare il prodotto da solo, in questa sequenza:

1. Creare un pod passo dopo passo — la wizard, l’intake, il repository, il piano e la pod room. Parti da qui.
2. Capire uso, piani e wallet — task, ore di pod lead, budget e cosa succede quando la borsa finisce.
3. Quality gate e deliverable — esattamente cosa controlla il QA e cosa ricevi.
4. Sfoglia le FAQ di AI Studio — perimetro, sicurezza, fatturazione e limiti.
5. Leggi il Private AI Gateway — come funzionano il routing dei modelli, i budget e l’audit.
6. Tutorial introduttivo — lo stesso flusso dalla console.

Verifica di essere pronto¶

Prima di creare il tuo primo pod:

• Riesci a descrivere il risultato in una frase di business.
• Hai scritto come saprai che è finito.
• Sai quale dei casi d’uso qui sopra corrisponde al tuo bisogno.
• Il tuo repository è raggiungibile e hai un token con permessi di scrittura.
• Sai chi nel tuo team reviewerà e mergerà la richiesta.

Risoluzione dei problemi¶

Domande frequenti¶

Prossimi passi¶

• Creare un pod passo dopo passo
• Capire uso, piani e wallet
• Sfoglia le FAQ di AI Studio

Crea il tuo primo pod

Hai ancora domande? Chiedi su Discord o esplora i tutoriali.