🤖 Erklären mit KI

Anwendungsfälle von AI Studio¶

Acht reale Wege, wie Teams 4Geeks AI Studio einsetzen – jeweils mit den Fähigkeiten, die sie aktivieren, dem Prozess, dem Pod folgt, dem Ergebnis, das Sie erhalten, und den Deliverables, die in Ihrem Repository landen. Nutzen Sie diese Seite, um den richtigen Ausgangspunkt für Ihren ersten Pod zu wählen.

Anwendungsfälle auf einen Blick¶

flowchart LR
    A[Wählen Sie Ihr Ergebnis] --> B[Kurzes Business-Intake]
    B --> C[Pod Lead prüft den Umfang]
    C --> D[Sie genehmigen den Plan]
    D --> E[Pod baut auf einem Branch]
    E --> F[Quality Gate führt QA-Checks aus]
    F --> G[Sie prüfen die Merge Request]

Die acht Anwendungsfälle von AI Studio¶

1. Ein neues MVP bauen¶

Playbook: greenfield · Typische Größe: S bis L

• Fähigkeiten: Docs, Design und Quality. E2E, wenn die erste Slice in einem echten Browser bewiesen werden muss.
• Prozess: Sie beantworten das Intake mit Problem, Nutzern und den drei Muss-Anforderungen; der Pod Lead macht daraus einen Plan mit einer deklarierten Slice; Sie genehmigen; der Pod baut den Flow in einer Sandbox auf Ihrem Branch; das Quality Gate führt Build und Tests aus; Sie prüfen die Merge Request.
• Ergebnis: Eine erste Slice des Produkts in Ihrem Repository, mit Tests abgedeckt und bereit für Ihr Team zum Deployen.
• Deliverables: Eine Merge Request mit dem funktionierenden Flow, den Tests, die ihn belegen, dem Operations-Panel, falls im Umfang, und Doku, die aus dem Code geschrieben wurde.

2. Eine Funktion zur App hinzufügen¶

Playbook: feature · Typische Größe: S oder M

• Fähigkeiten: Docs und Quality immer; Design, wenn die Funktion die Oberfläche ändert; E2E, wenn der Flow kritisch ist, etwa Checkout oder Registrierung.
• Prozess: Sie beschreiben das Ergebnis in Business-Sprache und schreiben ins Intake, woran Sie „fertig” erkennen; der Plan kommt mit Tasks und Abnahmekriterien; Sie genehmigen; der Pod baut auf einem Branch; die Tests laufen im Gate; Sie prüfen und mergen.
• Ergebnis: Die Funktion Ende-zu-Ende in Ihrem Code, mit Regressionstests, die sie am Laufen halten.
• Deliverables: Eine Merge Request, die Tests und aktualisierte Doku, wenn die Änderung die Nutzung des Produkts betrifft.

3. Bugs auf Ihrer Plattforme beheben¶

Playbook: bugfix · Typische Größe: S

• Fähigkeiten: Docs und Quality.
• Prozess: Sie melden das Symptom und wie man es reproduziert; der Pod reproduziert den Fehler in seiner Sandbox und schreibt einen Test, der fehlschlägt; der Pod Lead bestätigt die Ursache; der Fix kommt hinein; der Test wird grün; Sie prüfen die Merge Request.
• Ergebnis: Die Ursache erklärt, durch einen fehlschlagenden Test belegt und behoben, ohne Bestehendes zu zerstören.
• Deliverables: Der Test, der den Fehler beweist, der Fix, ein Regressionstest und die Merge Request mit der Erklärung.

4. Neue Fehler erkennen und Qualität verbessern¶

Playbook: qa · Typische Größe: M

• Fähigkeiten: Quality, plus E2E, wenn Browser-Flows wichtig sind.
• Prozess: Der Pod führt Ihre aktuelle Suite aus, reproduziert die gefundenen Fehler, erweitert die Abdeckung darum, fügt mit Playwright Browser-Tests hinzu, wenn E2E aktiv ist, und führt alles erneut unter dem Gate aus.
• Ergebnis: Reproduzierte Fehler mit Schritten zum Auslösen, mehr Testabdeckung und ein grüner Browser-Lauf für die kritischen Flows.
• Deliverables: Neue und aktualisierte Tests, ein Fehlerbericht mit Reproduktionsschritten, der E2E-Bericht und die Merge Request.

5. Code vor einer Investition prüfen¶

Playbook: audit · Typische Größe: S oder M

• Fähigkeiten: Security für die Prüfung selbst, Data wenn das Schema zählt, Docs für den Bericht. Der Pod läuft read-only.
• Prozess: Sie richten den Pod auf das Repository; er prüft Code, Abhängigkeiten und Schema; Befunde werden nach Risiko und Aufwand sortiert; der Pod Lead prüft den Bericht, bevor Sie ihn sehen.
• Ergebnis: Eine priorisierte Liste von Risiken und technischer Schulden, der Sie vor der Budgetfreigabe folgen können.
• Deliverables: Der Bericht mit Risiken, Nachweisen und empfohlener Reihenfolge. An Ihrem Code wird nichts geändert.

6. Meine Datenbank migrieren¶

Playbook: db-migration · Typische Größe: M oder L

• Fähigkeiten: Data und Quality. Der Pod erhält read-only-Zugriff auf die Quelldatenbank.
• Prozess: Der Pod mappt Quell- und Zielschema, schreibt das DDL zur Prüfung, führt eine Shadow-Validierung an echten Daten aus und bereitet den Cutover-Plan vor.
• Ergebnis: Eine Migration, der Sie vertrauen können, validiert in einem Shadow-Lauf, mit einem Runbook, das Ihr DBA ausführen kann.
• Deliverables: Das Schema-Mapping, das geprüfte DDL, der Shadow-Validierungsnachweis und das Runbook. Das Datenverschieben bleibt auf Ihrer Seite.

7. Mein System dokumentieren¶

Playbook: docs · Typische Größe: S oder M

• Fähigkeiten: Docs, plus SCRUM, wenn das Ergebnis Issues in Jira, Confluence oder Notion werden soll.
• Prozess: Der Pod liest den echten Code, entwirft die Dokumente, der Pod Lead gleicht sie mit dem Code ab, und Sie entscheiden, wo sie veröffentlicht werden.
• Ergebnis: Dokumentation, die zum System so wie es geschrieben ist passt – nicht so wie es jemand in Erinnerung hat.
• Deliverables: Ein Dokumentations-Set wie README, Architecture Decision Records und eine API-Referenz, veröffentlicht, wo Sie sie brauchen.

8. Abhängigkeiten aktualisieren oder ein Segment refactoren¶

Playbook: upgrade · Typische Größe: S oder M

• Fähigkeiten: Docs und Quality; E2E, wenn der Refactor einen kritischen Flow berührt.
• Prozess: Der Pod nimmt eine Baseline von Build und Tests, wendet das Update oder den Refactor an, behebt Brüche und führt das Gate erneut aus, bevor die Merge Request geöffnet wird.
• Ergebnis: Das Update angewandt, der Bruch behoben und das bestehende Verhalten durch die Testsuite bewahrt.
• Deliverables: Eine Merge Request mit Changelog, die aktualisierten Tests und ein Hinweis auf Breaking Changes, die Ihr Team bearbeiten muss.

Review und QA¶

Jeder der Anwendungsfälle durchläuft dieselben zwei Qualitätsebenen. Im Produkt sind beide Teil der Fähigkeit Quality und beantworten verschiedene Fragen: QA fragt „Funktioniert es?”, Review fragt „Sollten wir es mergen?”

Was QA abdeckt

• Build und Tests laufen in der Sandbox mit den Skripten Ihres Repositorys, der Check passt also zu Ihrem Projekt.
• Browser-E2E mit Playwright und Chromium läuft, wenn die E2E-Fähigkeit aktiv ist.
• Ein Pod mit Quality oder E2E kann nicht als geliefert markiert werden, ohne einen grünen Lauf; ein Fehler blockiert die Lieferung mit QUALITY_GATE_FAILED.
• Nur ein Waiver kann eine Lieferung akzeptieren – mit schriftlicher Begründung, protokolliert im Audit-Trail.
• Ein fehlgeschlagener Versuch und ein Retry gehen zu Lasten von 4Geeks.

Was Review abdeckt

• Der Pod Lead prüft den Umfang, bevor Sie den Plan genehmigen, und entscheidet, wann eine Lieferung bereit ist.
• Der Pod öffnet eine Merge Request auf einem Branch; er pusht nie auf Ihren geschützten Branch und mergt nie von selbst.
• Ihr Team prüft den Diff, die Tests und die Nachweise und mergt, wenn es zufrieden ist. Das Deployen bleibt in Ihrer Pipeline.
• Die Pod-Timeline protokolliert Tasks, Checks, Freigaben und Nachrichten und ist als JSON mit geschwärzten Zugangsdaten exportierbar.

So funktionieren Quality Gate und Deliverables

Echte Kundenstories¶

Dieselben Anwendungsfälle, umgesetzt für echte Kunden:

• Modernisierung von Daten und Infrastruktur — Ketsin: Cloud-Migration und regionale Betriebsabläufe (Fälle 1 und 6).
• Zahlungen für E-Commerce — Nandallo: reibungslose Zahlungen fürs Wachstum (Fall 2).
• Eine Umsatzplattform — One Ticket: vereinfachte Abläufe (Fall 1).
• Gesundheit und Wohlbefinden — Total Natural in Costa Rica (Fall 2).

Lernen Sie die Produktreihenfolge¶

Die Dokumentation ist so geschrieben, dass Sie das Produkt selbst bedienen können – in dieser Reihenfolge:

1. Einen Pod Schritt für Schritt erstellen — Assistent, Intake, Repository, Plan und Pod-Room. Beginnen Sie hier.
2. Nutzung, Pläne und Wallet verstehen — Tasks, Pod-Lead-Stunden, Budgets und was passiert, wenn die Basis aufgebraucht ist.
3. Quality Gate und Deliverables — genau was QA prüft und was Sie erhalten.
4. AI Studio FAQ lesen — Umfang, Sicherheit, Abrechnung und Grenzen.
5. Private AI Gateway lesen — wie Modell-Routing, Budgets und Audit funktionieren.
6. Erste-Schritte-Tutorial — derselbe Ablauf aus der Konsole.

Prüfen Sie, ob Sie bereit sind¶

Bevor Sie Ihren ersten Pod erstellen:

• Sie können das Ergebnis in einem Business-Satz beschreiben.
• Sie haben aufgeschrieben, woran Sie „fertig” erkennen.
• Sie wissen, welcher der Anwendungsfälle oben zu Ihrem Bedarf passt.
• Ihr Repository ist erreichbar und Sie haben ein Token mit Schreibrechten.
• Sie wissen, wer in Ihrem Team die Anfrage prüft und mergt.

Fehlerbehebung¶

Häufig gestellte Fragen¶

Nächste Schritte¶

• Einen Pod Schritt für Schritt erstellen
• Nutzung, Pläne und Wallet verstehen
• AI Studio FAQ lesen

Ihren ersten Pod erstellen

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