Erste Schritte mit 4Geeks AI Studio: Von der Konsole zum ersten Deploy¶
Übersicht¶
4Geeks AI Studio liefert Software über Pods: ein menschlicher 4Geeks-Pod-Lead plus ein kleines Team von KI-Agenten, das an Ihrem Repository arbeitet. Sie beschreiben das Ergebnis, genehmigen einen Plan und prüfen eine Merge Request. Der Pod übernimmt Planung, Code, Tests und Nachweise.
In diesem Tutorial lernen Sie:
- Den Plan zu wählen, der zu Ihrem Arbeitsvolumen passt (Lite, Starter oder Pro)
- Ihren ersten Pod im Assistenten zu erstellen
- Das Intake zu beantworten und Ihr Repository zu verbinden
- Den Plan zu genehmigen und den Build zu verfolgen
- Das Ergebnis des Pods zu prüfen und zu mergen
Voraussetzungen¶
- Ein 4Geeks-Konto (Registrierung unter console.4geeks.io)
- Ein GitLab- oder GitHub-Repository mit einem Zugriffstoken, das Schreibrechte auf das Projekt hat
- Ein aktiver AI-Studio-Plan oder eine hinterlegte Karte, um einen zu starten
Schritt 1: Wählen Sie Ihren Plan¶
Öffnen Sie AI Studio in der Konsole. Die Karte Plan und Guthaben zeigt Ihren aktuellen Plan, die verbrauchten Tasks und Pod-Lead-Stunden, das Vorauszahlungsguthaben und das Limit gleichzeitiger Pods.
| Plan | Monatliche Basis | Tasks / Monat | Pod Lead / Monat | Pods gleichzeitig |
|---|---|---|---|---|
| Lite | $390 | 10 | Auf Abruf ($75/h) | 1 |
| Starter | $790 | 15 | 2 h | 1 |
| Pro | $1,590 | 40 | 6 h | 3 |
- Nur gelieferte Arbeit wird berechnet: ein fehlgeschlagener Versuch und ein Retry gehen zu Lasten von 4Geeks.
- Arbeit über die monatliche Bag hinaus wird aus der Vorauszahlungs-Wallet bezahlt, nie durch eine Überraschungsrechnung.
- Der Organisationsbesitzer oder ein Admin kann den Plan in AI Studio kaufen oder ändern; Änderungen werden taggenau berechnet.
Tokens werden für Kosten und Support gemessen, sind aber keine Kundenkontingent und blockieren nie einen Task.
Schritt 2: Öffnen Sie den Assistenten¶
Klicken Sie in AI Studio auf Neuer Pod. Der Assistent hat vier Schritte: was Sie brauchen, einige Fragen, das Repository und die Bestätigung.
Wählen Sie das passende Ergebnis: erster Teil meines Produkts, Funktion hinzufügen, Bug finden und beheben, meinen Code prüfen, meine Datenbank migrieren, mein System dokumentieren, Qualität und Tests verbessern, Abhängigkeiten aktualieren oder ein Produkt bzw. eine Plattform.
Wenn nichts passt, wählen Sie Etwas anderes und beschreiben das Ziel selbst. Wenn Sie eine Person bevorzugen, wählen Sie Ich bin mir nicht sicher, ich brauche Hilfe – ein Pod Lead liest Ihre Antworten.
Schritt 3: Beantworten Sie das Intake¶
Das Intake besteht aus fünf Fragen in Business-Sprache. Nur die markierten sind Pflicht.
| Frage | Warum sie zählt |
|---|---|
| Was soll es tun? | Das Ergebnis, auf das der Plan zielt. Beschreiben Sie das Ergebnis, nicht die Bildschirme. |
| Wer wird es nutzen? | Zielgruppe und Rollen, die der Plan abdecken muss. |
| Was muss es können? | Die drei oder vier Dinge, die nicht fehlen dürfen. |
| Welchen Systemen muss es antworten? | Optional. Integrationen wie Zahlungen, E-Mail oder ein ERP. |
| Woran erkennen Sie, dass es fertig ist? | Der Abnahmetest in Ihren Worten. Daraus wird die Definition von fertig. |
Ihre Antworten werden zum Briefing, das der Pod Lead prüft und der Planner für den Plan nutzt.
Schritt 4: Verbinden Sie das Repository¶
- Wählen Sie GitLab oder GitHub und geben Sie die Instanz-URL ein (zum Beispiel
https://gitlab.com). - Geben Sie den Projektpfad und den Branch an, mit dem der Pod starten soll.
- Fügen Sie ein Zugriffstoken mit Schreibrechten für dieses Projekt ein. Es wird verschlüsselt in der Vault gespeichert und nur von der Sandbox des Pods verwendet.
- Wählen Sie das Runtime-Image: Base, Web, JVM oder Android. Der Assistent schlägt eines vor, wenn er das Repository prüfen kann.
Der Pod arbeitet auf einem Branch und öffnet eine Merge Request. Er pusht nie auf Ihren geschützten Branch.
Schritt 5: Bestätigen und Pod erstellen¶
Der Bestätigungsbildschirm zeigt die Größe (S, M, L oder XL), das Briefing, das Playbook, das Repository, das Runtime-Image, die Capabilities, die Tools, das verfügbare Guthaben und die erste Schätzung.
- Capabilities aktivieren, was der Pod ausführen kann: docs, SCRUM, data, quality, E2E, security, design und preview. Sie können sie ändern, bis der Plan genehmigt ist.
- Tools sind Jira, Confluence, Notion oder eine Datenbank im Read-only-Zugriff; Zugangsdaten können später verbunden werden.
- Schätzung und Guthaben: Laden Sie zuerst die Wallet auf, wenn das Guthaben niedrig ist.
Klicken Sie auf Pod erstellen. Der Pod erscheint in der Liste, danach wird der Plan erzeugt.
Schritt 6: Genehmigen Sie den Plan¶
Wenn der Plan fertig ist, erscheint der Pod unter Sie werden gebraucht. Prüfen Sie Zusammenfassung, die Tasks mit ihren Abnahmekriterien, die Annahmen, die Risiken und was nicht enthalten ist.
Klicken Sie auf Genehmigen und starten, um den Pod in den Build zu bringen, oder Änderungen anfordern, um ihn mit Feedback zurückzusenden. Erst die Planfreigabe startet den Build.
Schritt 7: Verfolgen Sie den Build¶
Der Pod-Room ist von oben nach unten gegliedert:
| Zone | Was sie beantwortet |
|---|---|
| Kopfzeile | Entität, Status und eine Fortschrittszeile: Phase plus abgeschlossene Tasks. |
| Sie werden gebraucht | Die wichtigste offene Entscheidung: Plan, Budget, Tool-Freigabe oder eine Frage. |
| Was passiert | Die Live-Timeline und der Composer mit dem Filter Alles/Unterhaltung. |
| Tasks | Zuerst Fehler, dann der laufende Task und die folgenden. |
| Pod-Details | Der beschlossene Plan, das Team, die Wallet, die Deliverables und technische Details. |
Während der Pod arbeitet, führt das Quality Gate die Build- und Testskripte Ihres Repositorys in der Sandbox aus. Ein Pod mit Quality oder E2E kann ohne grünen Lauf nicht als geliefert markiert werden – die Merge Request ist also bereits durch QA.
Schritt 8: Prüfen und mergen¶
Wenn die Arbeit fertig ist, öffnet der Pod eine Merge Request mit Tests und Nachweisen:
- Öffnen Sie die Merge Request in Ihrem Repository.
- Prüfen Sie den Diff, die Tests und die am Pod angehängten Nachweise.
- Sehen Sie sich bei Bedarf die Pod-Timeline an; sie ist als JSON mit geschwärzten Zugangsdaten exportierbar.
- Mergen Sie, wenn Sie zufrieden sind. Ihr Pipeline deployed.
Der Pod mergt nie von selbst und deployed nie direkt in Produktion.
Best Practices¶
- Beschreiben Sie das Ergebnis, nicht die Schritte. „Kunden können mit gespeicherter Karte zahlen” ist besser als „Tabelle und Endpoint hinzufügen”.
- Schreiben Sie die Definition von fertig ins Intake. Je klarer „fertig” ist, desto weniger Runden braucht der Plan.
- Antworten Sie schnell auf „Sie werden gebraucht”. Der Pod pausiert bei einer Entscheidung, nicht im Hintergrund.
- Halten Sie das Quality Gate an. Build und Tests sind die günstigste Versicherung gegen einen schlechten Merge.
- Laden Sie auf, bevor die Wallet leer ist. Eine Budget-Pause kostet mehr Zeit als ein Nachschlag.
- Nutzen Sie den Pod Lead. Er ist eingebunden für Umfang, Risiken und blockierte Arbeit.
Was kommt als Nächstes?¶
- Lesen Sie über AI Factory verstehen: Multi-Modell-Orchestrierung, um zu erfahren, wie verschiedene LLMs eingesetzt werden
- Lernen Sie, Smart Context Injection einzurichten für bessere Code-Generierung
- Erkunden Sie Automatisiertes QA & Sicherheitsbarrieren, um die Qualitätstore zu verstehen
- Siehe die API-Referenz für programmatischen Zugriff
Brauchen Sie Hilfe?¶
- Dokumentation: docs.4geeks.io
- Discord: Discord
- Support: Verfügbar über das Konsolen-Dashboard
- Vertrieb: Kontaktieren Sie uns
Noch Fragen? Frag uns auf Discord oder entdecke die Tutorials.