Das Wichtigste in Kürze
- Der eigentliche Engpass in KI-gestützter Entwicklung liegt nicht im Schreiben von Code, sondern im präzisen Beschreiben von Anforderungen – schlechte Issues bleiben auch mit KI schlechte Ergebnisse.
- Die Issue-Pipeline übersetzt ein gesprochenes Anforderungsgespräch in ein strukturiertes Issue mit Ziel, Kontext, Akzeptanzkriterien und Grenzen, bevor ein Agent die Aufgabe bearbeitet.
- Jede Etappe des Prozesses – vom Gespräch bis zum Pull Request – hinterlässt eine belegbare Spur, sodass Agentenarbeit kontrollierbar bleibt und am Ende ein prüfbarer PR steht, der dieselben Reviews wie jeder andere Beitrag durchläuft.
- Im Developer-Modus lässt sich die Plattform als formbares Entwicklungssystem einsetzen, bei dem Oberfläche, Workflows und Kundenlogik angepasst werden können, ohne jedes Mal ein komplett neues System aufzubauen.
Warum Anforderungen der Engpass sind
KI beschleunigt die Umsetzung, aber schlechte Anforderungen bleiben schlecht – sie werden nur schneller in falschen Code gegossen. Wenn unklar ist, was genau gebaut werden soll, produziert auch der beste Agent etwas, das technisch funktioniert, aber am Bedarf vorbeigeht. Der eigentliche Engpass moderner Entwicklung liegt deshalb selten im Tippen, sondern im präzisen Beschreiben.
Der erste Schritt muss also sein, ein Gespräch in ein klares Issue zu übersetzen. Ein gutes Issue enthält typischerweise:
- Ziel: Welches Problem wird gelöst und welcher Nutzen entsteht?
- Kontext: Welche Systeme, Daten und Randbedingungen sind betroffen?
- Akzeptanzkriterien: Woran erkennen alle Beteiligten, dass die Aufgabe erledigt ist?
- Grenzen: Was gehört ausdrücklich nicht dazu, was darf nicht verändert werden?
Launchpad soll genau diese Übersetzung unterstützen: aus einem gesprochenen Anforderungsgespräch ein strukturiertes Issue machen, das ein Agent sinnvoll bearbeiten kann.
Wie Agentenarbeit kontrollierbar wird
Die Issue-Pipeline kann Agentenläufe strukturieren, Zwischenergebnisse dokumentieren und Reviews vorbereiten. Damit wird KI-Entwicklung schneller, ohne die Kontrolle aus dem Prozess zu nehmen. Statt eines undurchsichtigen Sprungs von der Idee zum fertigen Code entsteht eine Kette nachvollziehbarer Schritte – jeder mit einem Zwischenstand, den ein Mensch prüfen kann.
Codex-Kompatibilität ist dabei zentral: Launchpad lässt sich mit Codex anzeigen, verwalten und im regulären Arbeitsalltag nutzen. Wichtig bleibt das Prinzip, dass am Ende ein prüfbarer Pull Request steht, der dieselben Reviews und Checks durchläuft wie jeder andere Beitrag. Der Agent liefert die Arbeit, aber der Prozess – nicht der Agent – entscheidet, was tatsächlich gemergt wird.
Vom Gespräch zum Pull Request: die Schritte
Konkret lässt sich der Weg in fünf nachvollziehbare Etappen zerlegen:
- Anforderung sprechen: Der Bedarf wird im Gespräch erfasst, statt in einem leeren Ticketfeld zu versanden.
- Issue erzeugen: Daraus entsteht ein strukturiertes Issue mit Ziel, Kontext und Akzeptanzkriterien.
- Agent startet: Der Agentenlauf arbeitet die Aufgabe ab und dokumentiert seine Zwischenschritte.
- Codex prüft: Das Ergebnis wird gegen die Kriterien geprüft und für das Review aufbereitet.
- PR mergen: Nach menschlicher Freigabe und grünen Checks wandert die Änderung in die Codebasis.
Jede Etappe hinterlässt eine Spur. Dadurch ist am Ende belegbar, wie aus einem Wunsch eine geprüfte Änderung wurde.
Häufige Fehler ohne strukturierte Pipeline
Wer Agenten ohne tragende Struktur einsetzt, erlebt oft dieselben Probleme. Sie entstehen nicht durch das Modell, sondern durch fehlende Übersetzung und fehlende Prüfpunkte:
- Schwammige Aufträge: „Bau mal eben X“ ohne Akzeptanzkriterien führt zu Ergebnissen, die niemand eindeutig abnehmen kann.
- Kein Review: Agentencode landet direkt im Hauptzweig, und Fehler fallen erst beim Kunden auf.
- Verlorener Kontext: Warum eine Änderung so gebaut wurde, ist später nicht mehr nachvollziehbar.
- Unkontrollierte Sonderwünsche: Jede Kundenanpassung wird zum Einzelfall ohne gemeinsame Basis.
Eine Issue-Pipeline adressiert genau diese Punkte, indem sie Anforderung, Umsetzung und Prüfung in einen durchgängigen, belegbaren Ablauf bringt – statt sie dem Zufall einzelner Prompts zu überlassen.
Warum Developer-Modus für Anpassungen sinnvoll ist
Für individuelle Kundenanpassungen sollte Launchpad eher als Runtime und Entwicklungssystem installiert werden, nicht nur als starres, fertiges Tool. Der Unterschied ist erheblich: Ein starres Werkzeug kann man bedienen, ein Entwicklungssystem kann man formen. Gerade bei Kundenprojekten, die fast immer Sonderwünsche mitbringen, ist diese Formbarkeit entscheidend.
Im Developer-Modus lassen sich Oberfläche, Design, Workflows und Kundenlogik mit wenigen Befehlen anpassen. Wer das Standard-Design nicht mag, kann eigene Skins und Oberflächen gestalten. So bleibt dieselbe geprüfte Basis erhalten, während das sichtbare Ergebnis zur jeweiligen Marke und zum jeweiligen Prozess passt – ohne dass für jede Anpassung ein komplett neues System gebaut werden muss.
Häufige Fragen
Was ist eine Issue-Pipeline und warum brauche ich sie für KI-Agenten?
Eine Issue-Pipeline übersetzt Anforderungsgespräche in strukturierte Issues mit Ziel, Kontext und Akzeptanzkriterien, bevor ein Agent loslegt. Ohne diese Struktur entstehen häufig technisch funktionierende, aber am eigentlichen Bedarf vorbeigegangene Ergebnisse. Die Pipeline bringt Anforderung, Umsetzung und Prüfung in einen durchgängigen, belegbaren Ablauf.
Wie landet das Ergebnis eines Agentenlaufs sicher in der Codebasis?
Am Ende jedes Laufs steht ein prüfbarer Pull Request, der dieselben Reviews und automatisierten Checks durchläuft wie jeder andere Code-Beitrag. Der Agent liefert die Arbeit, aber der Prozess entscheidet, was tatsächlich gemergt wird – ein Mensch gibt die Freigabe. Jede Etappe hinterlässt eine Spur, sodass später nachvollziehbar ist, wie aus einem Wunsch eine geprüfte Änderung wurde.
Muss ich die Plattform komplett neu bauen, wenn ein Kunde ein eigenes Design oder Sonderwünsche hat?
Nein – im Developer-Modus lassen sich Oberfläche, Design, Workflows und Kundenlogik mit wenigen Befehlen anpassen, ohne ein komplett neues System aufzubauen. Eigene Skins und Oberflächen sind möglich, während die geprüfte gemeinsame Basis erhalten bleibt. Der Unterschied zwischen einem starren Werkzeug und einem formbaren Entwicklungssystem ist dabei entscheidend.
Quellen und Weiterlesen
Was wir daraus machen
NADOOIT verbindet diese Themen mit praktischen Angeboten: KI-Kompetenz-Schulung, Launchpad-Workflows, IT-Sicherheit, E-Mail-Automatisierung und technische Unterstützung beim Projektstart. Der Einstieg ist bewusst pragmatisch: vorhandenes Postfach ordnen, wiederkehrende Anfragen automatisieren und bestehende Systeme kontrolliert anbinden.
KI-Entwicklerkurse ansehen Newsletter abonnieren Weitere Artikel lesen