🤖 Erklären mit KI

AI Studio Pods¶

Ein Pod ist die Einheit für Arbeit, Team und Abrechnung in 4Geeks AI Studio. Er hat ein Ziel, ein Playbook, ein Repository, verbundene Tools, einen Plan, Aufgaben, eine Wallet und einen menschlichen Pod Lead. Diese Seite zeigt, wie Sie einen erstellen, was die einzelnen Teile tun und wie Sie das Beste daraus holen.

Was ist ein Pod?¶

Ein Pod ist eine in sich geschlossene Delivery-Umgebung:

Ein Pod ist keine Chat-Sitzung. Er hält Zustand, führt Jobs aus, zeichnet Nachweise auf und pausiert für Entscheidungen, die einen Menschen brauchen.

Pod-Größen und Umfang¶

Der Assistent schätzt die Größe des Briefings anhand seines Inhalts. Die Größe geben Sie nie selbst an.

Ein L-Pod speichert seine out_of_scope-Liste und seine verbleibenden phases im Plan, sodass alle sehen, was diese Lieferung nicht enthält. Ein XL-Programm ist ein kommerzielles Gespräch mit einem Pod Lead, kein automatischer Pod.

Einen Pod Schritt für Schritt erstellen¶

1. Den Assistenten öffnen¶

Klicken Sie in AI Studio auf New pod. Der Assistent hat vier Schritte: was Sie brauchen, einige Fragen, das Repository und die Bestätigung.

Wählen Sie das nächstliegende Ergebnis:

• Erster Teil meines Produkts
• Ein Feature zu meiner App hinzufügen
• Einen Bug finden und beheben
• Meinen Code vor einer Investition auditieren
• Meine Datenbank migrieren
• Mein System dokumentieren
• Qualität und Tests verbessern
• Meine Dependencies aktualisieren
• Ein Produkt oder eine Plattform

Wenn nichts passt, wählen Sie Something else und beschreiben das Ziel selbst. Wenn Ihnen ein Mensch lieber ist, wählen Sie I am not sure, I want help.

2. Das Intake beantworten¶

Das Intake sind fünf Fragen in Geschäftssprache. Nur die markierten sind Pflicht; der Rest kann leer bleiben.

Ihre Antworten werden zum Briefing, das der Pod Lead prüft und der Planner verwendet. Die Rohantworten bleiben in den Pod-Metadaten; sie werden nicht in jeden Aufgaben-Prompt kopiert.

3. Das Repository verbinden¶

Ein Pod arbeitet auf einem Branch und öffnet einen Merge Request. Er pusht nie in Ihren geschützten Branch.

1. Wählen Sie GitLab oder GitHub.
2. Geben Sie die Instanz-URL ein (zum Beispiel https://gitlab.com).
3. Geben Sie den Projektpfad und den Branch ein, von dem der Pod starten soll.
4. Fügen Sie einen Access Token mit Schreibzugriff auf dieses Projekt ein. Der Token wird verschlüsselt im Vault gespeichert und nur von der Sandbox des Pods verwendet.
5. Wählen Sie das Runtime-Image: Base, Web, JVM oder Android. Der Assistent schlägt eines aus dem Repository vor, wenn er es inspizieren kann.

4. Den Pod bestätigen¶

Der Bestätigungsbildschirm zeigt die Größe, das Briefing, das Playbook, das Repository, das Runtime-Image, die Capabilities, die Tools, das verfügbare Guthaben und die erste Schätzung.

• Größe und Umfang: S, M, L oder XL. Ein L-Pod zeigt den ersten Ausschnitt und die späteren Phasen.
• Capabilities: was der Pod ausführen kann. Sie können sie ändern, bis der Plan genehmigt ist.
• Tools: Jira, Confluence, Notion oder eine Datenbank. Zugangsdaten können Sie später verbinden; der Plan sagt, was fehlt.
• Schätzung: die erste Schätzung für die Lieferung und das Guthaben der Wallet. Ist das Guthaben niedrig, laden Sie vor dem Erstellen des Pods auf.
• Create pod: startet das Provisioning. Der Pod erscheint in der Liste, und als Nächstes wird der Plan erzeugt.

5. Den Plan genehmigen¶

Wenn der Plan bereit ist, erscheint der Pod unter Needs you. Öffnen Sie ihn und prüfen Sie:

• Die Zusammenfassung und das Vorgehen.
• Die Aufgaben und ihre Abnahmekriterien.
• Die Annahmen und Risiken.
• Was in dieser Lieferung nicht enthalten ist.
• Die späteren Phasen bei einem L-Pod.

Klicken Sie auf Approve and start, um den Pod in den Build zu schicken, oder auf Request changes, um ihn mit Feedback zurückzusenden. Der Plan wird an genau einer Stelle genehmigt: der Genehmigungszeile. Die Genehmigung des Plans ist es, was den Build startet.

6. Den Build verfolgen und den Merge Request prüfen¶

Der Pod-Raum ist von oben nach unten aufgebaut:

Wenn die Arbeit fertig ist, öffnet der Pod einen Merge Request mit Tests und Nachweisen. Ihr Team prüft und merged. Der Pod deployt nicht in die Produktion.

Der Pod Lead¶

Jeder Pod hat einen menschlichen Pod Lead von 4Geeks. Er ist die verantwortliche Person hinter dem Pod:

• Er prüft den Umfang und den Plan, bevor Sie ihn genehmigen.
• Er beantwortet Fragen im Pod-Raum und per E-Mail.
• Er entblockt einen stockenden Pod und entscheidet, wann eskaliert wird.
• Er verantwortet das kommerzielle Gespräch für ein L- oder XL-Briefing.

Zeit und Abrechnung: Starter enthält 2 h Pod Lead pro Monat und Pro enthält 6 h. Bei Lite gibt es den Pod Lead auf Abruf für $75/h. Minuten innerhalb des Plans sind kostenlos; der Überschuss wird mit $75/h aus der Wallet berechnet.

Um Hilfe bitten: Nutzen Sie Talk to my pod lead im Composer oder wählen Sie I am not sure, I want help im Assistenten. Eine Anfrage für Hilfe braucht:

1. Einen aktiven Plan für den Workspace.
2. Verbleibende Pod-Lead-Minuten in der aktuellen Periode (Lite enthält keine, daher auf Abruf).
3. Eine hinterlegte Karte zur Absicherung der Zeit.

Eine Anfrage für Hilfe ist kein Support-Ticket. Es ist ein kurzes Intake, das ein Pod Lead liest, bevor er Sie kontaktiert.

Capabilities¶

Capabilities legen fest, was ein Pod tatsächlich ausführen kann. Jede aktiviert Skills, Toolchains, Aufgabenarten und erwartete Artefakte. Der Plan wird gegen sie validiert, eine Capability ist also eine Zusage, kein Abzeichen.

Capabilities lassen sich vor der Genehmigung des Plans ändern. Sobald der Plan genehmigt ist, sind sie gesperrt, weil Plan, Runtime-Image und Aufgaben um sie herum gebaut wurden. preview ist inaktiv, bis das Preview-Gateway für den Workspace konfiguriert ist.

Quality ist die Capability hinter Review und QA: die automatischen Checks, die bestehen müssen, bevor ein Pod liefern darf, und die Merge Request mit Nachweisen, die Ihr Team vor dem Merge prüft. So funktionieren Review und QA.

Playbooks und Runtime-Images¶

Das Playbook bestimmt das Standardteam, die Aufgabenarten und die Output-Ziele. Normalerweise wählen Sie ein Ergebnis und der Assistent wählt das Playbook; unter Advanced options können Sie es ändern.

Ein Pod läuft mit einem Image, das vor der Erstellung seiner Sandbox gewählt wird:

Das Image ist unveränderlich, sobald die Sandbox existiert, sodass ein Projekt seine Toolchain nie mitten im Lauf wechselt. Wenn die Capabilities zwei Images gleichzeitig brauchen, warnt Sie der Assistent und installiert eine Toolchain zur Laufzeit.

Pod-Lebenszyklus und Pod-Raum¶

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

• Draft: erstellt, aber nicht gestartet.
• Provisioning / planning: die Sandbox und der Plan werden vorbereitet.
• Awaiting plan: der Plan ist bereit für Ihre Genehmigung.
• Building / reviewing: der Pod führt Aufgaben aus und startet Checks.
• Awaiting review: der Merge Request ist bereit für Ihr Team.
• Delivering / done: die Ergebnisse sind veröffentlicht und der Pod ist geschlossen.
• Paused / blocked / failed: eine Entscheidung oder ein Fehler hat den Fortschritt gestoppt; der Pod-Raum erklärt warum.

Sie können einen laufenden Pod pausieren, ihn fortsetzen und ihn nur löschen, wenn er pausiert, fertig oder fehlgeschlagen ist. Das Löschen eines Pods entfernt seinen Plan, seine Aufgaben, Timeline, Nachrichten, Ergebnisse und die Sandbox; Repository, Tools und Abrechnungsverlauf bleiben.

Quality Gate und Ergebnisse¶

Ein Pod mit Quality oder E2E kann nicht als geliefert markiert werden, ohne dass Build und Tests grün sind. Die Checks führen die eigenen Skripte des Kunden in der Sandbox aus und werden mit dem Pod gespeichert. Browser-E2E ergänzt einen Playwright-Lauf und einen Bericht.

• Ein fehlgeschlagener Check blockiert die Lieferung mit QUALITY_GATE_FAILED.
• Ein genehmigter Waiver kann eine Lieferung ohne grünen Lauf akzeptieren, mit schriftlicher Begründung und einem Eintrag im Audit.
• Zu den Ergebnissen gehören der Merge Request, Dokumente, Berichte, Migrationsartefakte, Preview-Links und veröffentlichte Seiten.
• Das Bearbeiten eines Artefakts markiert seine veröffentlichte Kopie als stale; der Pod kann sie an Ort und Stelle aktualisieren, statt die Seite zu duplizieren.

Best Practices¶

1. Ein Ergebnis pro Pod. Teilen Sie Arbeit in Produktgröße in einen L-Pod oder ein Programm auf.
2. Schreiben Sie die Definition of Done ins Intake. „Ein Kunde zahlt mit einer gespeicherten Karte“ ist besser als „Checkout verbessern“.
3. Verbinden Sie den richtigen Branch. Der Pod startet von dem Branch, den Sie ihm geben, und öffnet seinen MR dagegen.
4. Lassen Sie das Quality Gate aktiv. Build und Tests sind die günstigste Versicherung gegen einen schlechten Merge.
5. Prüfen Sie den Plan, nicht nur die Aufgaben. Annahmen und nicht zum Umfang gehörende Punkte sind dort, wo Überraschungen lauern.
6. Antworten Sie schnell auf „We need you“. Ein Pod, der bei einer Entscheidung pausiert, macht keinen Fortschritt.
7. Nutzen Sie den Pod Lead für Umfang und Risiko. Er ist enthalten, damit die Lieferung ehrlich bleibt.
8. Hängen Sie Referenzen an, wenn Design zählt. Ein Mockup plus ein schriftliches Briefing ist besser als nur eines von beiden.
9. Laden Sie auf, bevor die Wallet leer ist. Eine Budget-Pause kostet mehr Zeit als ein Top-up.
10. Archivieren Sie fertige Pods. Das hält die Liste fokussiert und gibt einen Slot für gleichzeitige Pods frei.

Fehlerbehebung¶

Häufig gestellte Fragen¶

Nächste Schritte¶

• Die AI Studio Anwendungsfälle ansehen
• Nutzung, Pläne und Wallet verstehen
• Das Private AI Gateway lesen
• Die AI Studio FAQ durchsuchen

Noch Fragen? Frag uns auf Discord oder entdecke die Tutorials.