🤖 Spiega con IA

Pod di AI Studio¶

Un pod è l’unità di lavoro, di team e di fatturazione in 4Geeks AI Studio. Ha un obiettivo, un playbook, un repository, strumenti collegati, un piano, task, un wallet e un pod lead umano. Questa pagina mostra come crearne uno, cosa fa ogni parte e come ottenere il massimo.

Cos’è un pod?¶

Un pod è un ambiente di consegna autonomo:

Un pod non è una sessione di chat. Mantiene lo stato, esegue job, registra le prove e si mette in pausa per le decisioni che richiedono una persona.

Dimensioni e ambito dei pod¶

Il wizard stima la dimensione del brief da ciò che contiene. Non dichiari mai tu la dimensione.

Un pod L conserva la lista out_of_scope e le phases rimanenti nel piano, così tutti possono vedere cosa questa consegna non include. Un programma XL è una conversazione commerciale con un pod lead, non un pod automatico.

Creare un pod passo passo¶

1. Apri il wizard¶

In AI Studio, clicca su New pod. Il wizard ha quattro passaggi: cosa ti serve, alcune domande, il repository e la conferma.

Scegli il risultato più vicino:

• Prima fetta del mio prodotto
• Aggiungere una funzionalità alla mia app
• Trovare e correggere un bug
• Fare un audit del codice prima di investire
• Migrare il mio database
• Documentare il mio sistema
• Migliorare qualità e test
• Aggiornare le mie dipendenze
• Un prodotto o una piattaforma

Se nessuno è adatto, scegli Something else e descrivi tu l’obiettivo. Se preferisci una persona, scegli I am not sure, I want help.

2. Rispondi al questionario¶

Il questionario è composto da cinque domande in linguaggio di business. Solo quelle contrassegnate sono obbligatorie; le altre possono restare vuote.

Le tue risposte diventano il brief che il pod lead rivede e che il planner usa. Le risposte grezze restano nei metadati del pod; non vengono incollate nel prompt di ogni task.

3. Collega il repository¶

Un pod lavora su un branch e apre una merge request. Non fa mai push sul tuo branch protetto.

1. Scegli GitLab o GitHub.
2. Inserisci l’URL dell’istanza (ad esempio https://gitlab.com).
3. Inserisci il percorso del progetto e il branch da cui il pod deve partire.
4. Incolla un token di accesso con permessi di scrittura su quel progetto. Il token è salvato cifrato nel vault ed è usato solo dalla sandbox del pod.
5. Scegli la runtime image: Base, Web, JVM o Android. Il wizard ne suggerisce una dal repository quando riesce a ispezionarlo.

4. Conferma il pod¶

La schermata di conferma mostra la dimensione, il brief, il playbook, il repository, l’immagine runtime, le capacità, gli strumenti, il saldo disponibile e la prima stima.

• Dimensione e ambito: S, M, L o XL. Un pod L mostra la prima fetta e le fasi successive.
• Capacità: cosa il pod può eseguire. Puoi cambiarle fino all’approvazione del piano.
• Strumenti: Jira, Confluence, Notion o un database. Puoi collegare le credenziali più tardi; il piano dirà cosa manca.
• Stima: la prima stima di consegna e il saldo del wallet. Se il saldo è basso, ricarica prima di creare il pod.
• Create pod: avvia il provisioning. Il pod compare nella lista e subito dopo viene generato il piano.

5. Approva il piano¶

Quando il piano è pronto, il pod compare in Needs you. Aprilo e rivedi:

• Il riepilogo e l’approccio.
• I task e i loro criteri di accettazione.
• Le ipotesi e i rischi.
• Cosa non è incluso in questa consegna.
• Le fasi successive per un pod L.

Clicca su Approve and start per portare il pod in build, oppure su Request changes per rimandarlo indietro con un feedback. Il piano si approva in un solo posto: la riga di approvazione. Approvare il piano è ciò che avvia la build.

6. Segui la build e revisiona la merge request¶

La pod room è organizzata dall’alto verso il basso:

Quando il lavoro è finito, il pod apre una merge request con test e prove. Il tuo team revisiona e fa il merge. Il pod non fa deploy in produzione.

Il pod lead¶

Ogni pod ha un pod lead umano di 4Geeks. È la persona responsabile dietro il pod:

• Rivede l’ambito e il piano prima che tu li approvi.
• Risponde alle domande nella pod room e via email.
• Sblocca un pod fermo e decide quando fare escalation.
• Gestisce la conversazione commerciale per un brief L o XL.

Tempo e fatturazione: Starter include 2 h di pod lead al mese e Pro 6 h. Lite ha il pod lead su richiesta a $75/h. I minuti inclusi nel piano sono gratuiti; l’eccesso è addebitato al wallet a $75/h.

Chiedi aiuto: usa Talk to my pod lead nel composer, oppure scegli I am not sure, I want help nel wizard. Una richiesta di aiuto richiede:

1. Un piano attivo per il workspace.
2. Minuti di pod lead residui nel periodo corrente (Lite non ne include, quindi è su richiesta).
3. Una carta registrata a garanzia del tempo.

Una richiesta di aiuto non è un ticket di supporto. È un breve questionario che un pod lead legge prima di contattarti.

Capacità¶

Le capacità definiscono cosa un pod può realmente eseguire. Ognuna attiva competenze, toolchain, tipi di task e artefatti attesi. Il piano viene validato in base a esse, quindi una capacità è un impegno, non un badge.

Le capacità possono cambiare prima dell’approvazione del piano. Una volta approvato il piano vengono bloccate, perché il piano, l’immagine runtime e i task sono stati costruiti intorno a esse. preview viene rilasciata inattiva finché il gateway di anteprima non è configurato per il workspace.

Quality è la capacità dietro Review e QA: i controlli automatici che devono passare prima che un pod possa consegnare, e la merge request con le prove che il tuo team rivede prima del merge. Vedi come funzionano Review e QA.

Playbook e immagini runtime¶

Il playbook decide il team predefinito, i tipi di task e le destinazioni dell’output. Normalmente scegli un risultato e il wizard sceglie il playbook; puoi cambiarlo in Advanced options.

Un pod esegue una sola immagine, scelta prima della creazione della sua sandbox:

L’immagine è immutabile una volta che la sandbox esiste, così un progetto non cambia toolchain a metà lavoro. Se le capacità richiedono due immagini contemporaneamente, il wizard ti avvisa e installa un toolchain a runtime.

Ciclo di vita del pod e pod room¶

stateDiagram-v2
    [*] --> draft
    draft --> provisioning
    provisioning --> planning
    planning --> awaiting_plan
    awaiting_plan --> building: piano approvato
    building --> reviewing
    reviewing --> awaiting_review
    awaiting_review --> delivering
    delivering --> done
    building --> paused
    building --> blocked
    building --> failed

• Draft: creato ma non avviato.
• Provisioning / planning: la sandbox e il piano sono in preparazione.
• Awaiting plan: il piano è pronto per la tua approvazione.
• Building / reviewing: il pod sta eseguendo i task e i controlli.
• Awaiting review: la merge request è pronta per il tuo team.
• Delivering / done: le consegne sono pubblicate e il pod è chiuso.
• Paused / blocked / failed: una decisione o un fallimento ha fermato l’avanzamento; la pod room spiega perché.

Puoi mettere in pausa un pod mentre è in esecuzione e riprenderlo più tardi; puoi eliminarlo solo quando è in pausa, done o failed. Eliminare un pod rimuove piano, task, timeline, messaggi, consegne e sandbox; il repository, gli strumenti e lo storico di fatturazione restano.

Quality gate e consegne¶

Un pod con Quality o E2E non può essere segnato come consegnato senza una build e un’esecuzione dei test verdi. I controlli eseguono gli script del cliente nella sandbox e i risultati vengono salvati con il pod. L’E2E browser aggiunge un’esecuzione Playwright e un report.

• Un controllo fallito blocca la consegna con QUALITY_GATE_FAILED.
• Una deroga approvata può accettare una consegna senza un’esecuzione verde, con una motivazione scritta e una voce di audit.
• Le consegne includono la merge request, documenti, report, artefatti di migrazione, link di anteprima e pagine pubblicate.
• Modificare un artefatto contrassegna la sua copia pubblicata come stale; il pod può aggiornarla sul posto invece di duplicare la pagina.

Buone pratiche¶

1. Un risultato per pod. Dividi il lavoro delle dimensioni di un prodotto in un pod L o un programma.
2. Scrivi la definizione di completato nel questionario. “Un cliente paga con una carta salvata” è meglio di “migliora il checkout”.
3. Collega il branch giusto. Il pod parte dal branch che gli dai e apre la sua MR contro di esso.
4. Tieni attivo il quality gate. Build e test sono l’assicurazione più economica contro un merge sbagliato.
5. Revisiona il piano, non solo i task. Ipotesi ed elementi fuori ambito sono dove si nascondono le sorprese.
6. Rispondi rapidamente a “We need you”. Un pod in pausa su una decisione non sta avanzando.
7. Usa il pod lead per ambito e rischio. Sono inclusi per mantenere onesta la consegna.
8. Allega riferimenti quando il design conta. Un mockup più un brief scritto è meglio di uno dei due da solo.
9. Ricarica prima che il wallet si esaurisca. Una pausa per budget costa più tempo di una ricarica.
10. Archivia i pod finiti. Mantiene la lista focalizzata e libera un posto per un pod simultaneo.

Risoluzione dei problemi¶

Domande frequenti¶

Prossimi passi¶

• Vedi i casi d’uso di AI Studio
• Comprendi utilizzo, piani e wallet
• Leggi il Private AI Gateway
• Consulta le domande frequenti su AI Studio

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