Die meisten Gespräche über autonome Softwareentwicklung beginnen mit Agenten, die Code schreiben. Ein Agent nimmt sich eines Issues an, implementiert ein Feature, erstellt einen Pull-Request. Die Demo funktioniert. Die Leute sind begeistert.
Bevor autonome Auslieferung zuverlässig funktionieren kann, muss jemand das Engineering-System entwerfen, in dem die Autonomie operieren wird. Die Projektstruktur, die Technologieentscheidungen, die architektonischen Grenzen, die Designrichtung, die Engineering-Konventionen, die Validierungsmechanismen, die Spezialistenrollen, die Genehmigungsgrenzen. Nichts davon sollte aus einer Sammlung unabhängiger Agenten entstehen, die parallel raten.
Mein Ansatz beginnt mit einer anderen Aufteilung der Verantwortlichkeiten. Menschen entwerfen das Engineering-System. Spezialisierte Agenten führen die Arbeit aus. Asynchrone Loops orchestrieren, wann diese Arbeit stattfindet und was als Nächstes kommt.
Das Ziel ist nicht, den Menschen aus der Softwareentwicklung zu entfernen. Es geht darum, die menschliche Beteiligung auf die Entscheidungen zu konzentrieren, die Urteilsvermögen, Kontext und Produktverständnis erfordern, während eine Umgebung geschaffen wird, in der ein Großteil der Ausführung eigenständig weiterlaufen kann.
Dies sind die sechs Schritte, die ich jedes Mal befolge, wenn ich ein Projekt starte, das irgendwann ohne meine Aufsicht laufen soll.
Schritt 1: Der Mensch entwirft das Engineering-System
Wenn ich ein Projekt beginne, bitte ich keinen autonomen Agenten, seine Grundlagen zu erfinden.
Ich entscheide zuerst über die wichtigen Teile: wie das Repository organisiert sein soll, welche Technologien verwendet werden, wie die wichtigsten architektonischen Grenzen funktionieren, wie die Designrichtung aussieht, welche Engineering-Konventionen befolgt werden müssen und wo die Autonomie aufhören soll. Diese Entscheidungen werden zur Grundlage von allem, was danach kommt.
Dann verwende ich opencode-onboard, um sie im Repository zu kodieren.
/make-engineer erstellt die spezialisierten KI-Ingenieure, die das Projekt benötigt. Frontend, Backend, Infrastruktur, Testing, Sicherheit, Daten, Mobil – was auch immer das Produkt verlangt. Dies sind keine generischen Agenten mit unterschiedlichen Etiketten. Jeder hat eine definierte Spezialisierung, eine Reihe von Fähigkeiten und einen klaren Platz im Engineering-Workflow.
/make-architecture erfasst die technische Struktur und die Grenzen in ARCHITECTURE.md. /make-design erfasst die visuelle Sprache, Design-Tokens und Komponentenmuster in DESIGN.md. /make-guardrails wandelt all diese Entscheidungen in konkrete Regeln um, die jeder Agent respektieren muss. Architektonische Grenzen, Namenskonventionen, Testerwartungen, Codestil, Sicherheitseinschränkungen, Git-Praktiken. Sie sind nicht mehr nur Wissen des ursprünglichen Entwicklers, sondern werden Teil der Betriebsumgebung.
Das Repository enthält mehr als nur Dokumentation. Es enthält eine kodierte Engineering-Organisation und eine gemeinsame Quelle der Wahrheit für jeden Agenten, der darin arbeiten wird.
Der Mensch definiert zuerst das System. Erst dann wird autonome Ausführung sinnvoll.
Schritt 2: Die interaktive Grundlage kommt vor der Autonomie
Sobald das Engineering-System definiert ist, baue ich die anfängliche Projektgrundlage interaktiv auf.
Normalerweise verwende ich an diesem Punkt /plan-quick und /plan-apply. /plan-quick analysiert ein fokussiertes Ziel und wandelt es in eine konkrete, geordnete Abfolge von Aufgaben um. Es ist bewusst leichter als ein vollständiger Spezifikations-Workflow. Ich verwende es, wenn die Arbeit klar ist und ich schnell vorankommen möchte, ohne die Übersicht oder Kontrolle zu verlieren. /plan-apply setzt diese Aufgaben um und überprüft das Ergebnis.
So etabliere ich die grundlegende Infrastruktur des Projekts. Repository-Struktur, Anwendungsgerüst, Datenbank-Setup, Authentifizierungsgrundlagen, Design-System, Testinfrastruktur, CI/CD-Konfiguration, Deployment-Grundlagen.
Die frühen Phasen eines Projekts enthalten Entscheidungen, die alles später Gebaute beeinflussen. Eine schwache Abstraktion, eine inkonsistente Ordnerstruktur, eine unklare Teststrategie. Jede davon kann hunderte Male reproduziert werden, sobald autonome Agenten zu arbeiten beginnen. Ich habe es gesehen. Es ist nicht schön.
Aus diesem Grund bleibt diese Phase schnell und KI-gestützt, aber beaufsichtigt.
Der Zweck ist nicht, die Autonomie so früh wie möglich zu maximieren. Der Zweck ist, das Projekt stabil, verständlich und vorhersagbar genug zu machen, dass Autonomie später sicher darin operieren kann.
Schritt 3: Menschliche Beteiligung wird zur Projektrichtlinie
Nachdem die Grundlagen fertig sind, entscheide ich, wie viel Autonomie das Auslieferungssystem haben soll.
Dies ist keine binäre Wahl zwischen manueller Entwicklung und vollständiger Automatisierung. Menschliche Beteiligung kann an verschiedenen Punkten im Lebenszyklus existieren, und die richtige Konfiguration hängt vom Projekt ab.
Ein vollständig überwachtes Projekt könnte erfordern, dass ein Mensch das Issue verfeinert, den Implementierungsplan genehmigt, den Pull-Request überprüft, den Merge genehmigt und das Deployment autorisiert.
Ein teilweise autonomes Projekt könnte der KI die Verfeinerung und Implementierung überlassen, während Menschen unbeantwortete Fragen klären, wichtige Pull-Requests überprüfen oder die Kontrolle über den endgültigen Merge behalten.
Ein hochautonomes Projekt könnte dem System erlauben, Änderungen automatisch zu verfeinern, zu implementieren, zu überprüfen und zu mergen, wenn die erforderlichen Leitplanken, Tests und Qualitätsprüfungen bestanden sind.
Ein neues Produkt mit instabilen Anforderungen braucht mehr menschliche Beteiligung als ein ausgereiftes internes Tool. Ein reguliertes System erfordert explizite Genehmigungstore, die für ein kleines Experiment unnötig wären. Und dasselbe Projekt kann im Laufe der Zeit autonomer werden, wenn seine Architektur, Tests und Auslieferungsmechanismen reifen.
Der wichtige Punkt ist, dass Autonomie bewusst definiert wird. Issue-Verfeinerung, Frageklärung, Plangenehmigung, Pull-Request-Überprüfung, Merge-Genehmigung, Deployment-Genehmigung. Dies sind keine zufälligen Unterbrechungen. Sie sind konfigurierbare Tore im Engineering-System.
Jedes Projekt wählt ein anderes Maß an Autonomie, und diese Grenzen entwickeln sich mit ihm weiter.
Schritt 4: Ideen werden zu beständigen Backlog-Elementen
Die interaktive Konsole ist immer noch der Ort, an dem ich Ideen untersuche.
Wenn eine Idee unvollständig ist, verwende ich /plan-explore. Dies ist kein Implementierungsbefehl. Es ist ein kollaborativer Erkundungsprozess. Der Agent untersucht das Repository, kartiert relevante Komponenten, identifiziert bestehende Muster, hinterfragt Annahmen, verfolgt Abhängigkeiten, bewertet Risiken und hilft zu bestimmen, was tatsächlich gebaut werden sollte.
Viele Entwicklungsprobleme sehen zunächst wie Programmieraufgaben aus, sind aber eigentlich Verständnisprobleme. Eine unklare Idee direkt in einen autonomen Implementierungs-Workflow zu schicken, führt in der Regel zu einer unklaren Implementierung. Exploration gibt der Idee genug Struktur, um handlungsfähig zu werden, ohne sich voreilig auf eine Lösung festzulegen.
Sobald die Richtung klar ist, verwende ich /ops-backlog, um ein strukturiertes Arbeitselement in GitHub, Azure DevOps oder Jira zu erstellen. Das Arbeitselement wird zur dauerhaften Übergabe zwischen interaktivem Denken und asynchroner Ausführung. Es kann den Kontext, den Umfang, die Abnahmekriterien, Risiken, offene Fragen und Abhängigkeiten enthalten, die für die nächsten Phasen des Workflows benötigt werden.
An diesem Punkt ist der Backlog nicht mehr nur ein Ort, an dem Aufgaben gespeichert werden. Er wird zur gemeinsamen Koordinationsschicht zwischen Menschen, Agenten und Loops.
Menschen erstellen Ideen, beantworten Fragen und treffen Entscheidungen. Loops beobachten Issue-Zustände und wählen geeignete Arbeiten aus. Agenten erhalten fokussierte Aufgaben mit dem Kontext, der für ihre Ausführung erforderlich ist.
Der Backlog verwandelt ein interaktives Gespräch in dauerhafte Arbeit, die fortgesetzt wird, nachdem dieses Gespräch beendet ist.
Schritt 5: Loop-task orchestriert asynchrone Arbeit
Sobald das Projekt, die Ingenieure, die Leitplanken, der Backlog und die Genehmigungsrichtlinie bereit sind, konfiguriere ich loop-task auf einem lokalen Rechner oder einer VM.
loop-task führt die äußeren Orchestrierungsschleifen aus. Diese Schleifen durchsuchen kontinuierlich den Backlog, identifizieren geeignete Arbeiten, rufen den entsprechenden Engineering-Workflow auf und aktualisieren den Status jedes Issues.
Eine Verfeinerungsschleife kann ein neues Issue auswählen, es untersuchen, seine Spezifikation verbessern und Fragen hinzufügen, wenn Informationen fehlen. Wenn eine menschliche Entscheidung erforderlich ist, wechselt das Issue in einen Wartezustand. Eine Person antwortet, wenn verfügbar, und die Schleife wird fortgesetzt, sobald die Informationen erscheinen.
Sobald das Issue klar genug ist, wechselt es in einen bereit-zur-Implementierung-Zustand. Die Implementierungsschleife nimmt es auf und ruft den autonomen Engineering-Workflow auf.
Eine Überprüfungsschleife kann Pull-Request-Feedback inspizieren, Korrekturen koordinieren, den notwendigen Workflow erneut ausführen und die Änderung zurück zur Akzeptanz bewegen. Eine Abschlussschleife kann akzeptierte Arbeit mergen, das zugehörige Issue schließen und dem nächsten berechtigten Element erlauben, in das System einzutreten.
Die Loops müssen nicht direkt miteinander kommunizieren. Sie koordinieren sich über dauerhafte Backlog-Zustände. Ein typisches Issue durchläuft einen Lebenszyklus wie diesen:
Neu, In Verfeinerung, Warte auf Antworten, Bereit zur Implementierung, In Implementierung, Pull-Request, In Überprüfung, Erledigt.
Menschen können in den Prozess einsteigen, wann immer die Projektrichtlinie es erfordert, aber das System ist nicht darauf angewiesen, dass jemand ständig ein Terminal im Auge behält. Selbst wenn der Entwickler offline ist, überprüft die VM weiterhin den Backlog und bringt geeignete Arbeiten voran.
Dies ist die Unterscheidung im Zentrum des Loop-Engineerings:
Agenten führen die Arbeit aus. Loops entscheiden, wann Arbeit existiert, wann sie beginnen soll, welcher Workflow sie ausführen soll und was als Nächstes passiert.
Schritt 6: /plan-goal führt ein Issue von Anfang bis Ende aus
Wenn die Implementierungsschleife ein Issue findet, das bereit ist, ruft sie /plan-goal auf.
Dieser Befehl ist nicht dafür verantwortlich, die Produktrichtung zu bestimmen oder die Projektarchitektur zu erfinden. Diese Entscheidungen wurden bereits getroffen und im Repository kodiert. Seine Verantwortung ist es, ein ausreichend verfeinertes Arbeitselement innerhalb des bestehenden Engineering-Systems auszuführen.
/plan-goal liest das Issue, erkundet die relevanten Teile der Codebasis, erstellt einen OpenSpec-Vorschlag, generiert strukturierte Aufgaben, identifiziert Spezifikations- oder Testlücken, wählt die entsprechenden Fach-Ingenieure aus, weist Modell-Stufen zu, berechnet Abhängigkeiten und organisiert die Implementierungsarbeit in parallele Ausführungswellen.
Aufgaben, die unabhängig sind und separate Bereiche des Repositorys modifizieren, können gleichzeitig verschiedenen Ingenieuren zugewiesen werden. Aufgaben, die von vorheriger Arbeit abhängen oder dieselben Dateien betreffen, werden in der erforderlichen Reihenfolge ausgeführt.
Der Leitagent koordiniert die Arbeit, sammelt jedes Ergebnis, erstellt fokussierte Commits, führt Tests, Linting, Typprüfungen und Builds durch. Er stoppt, anstatt die Änderung auszuliefern, wenn die Überprüfung nicht erfolgreich abgeschlossen werden kann.
Wenn die Implementierung gültig ist, wird der Branch gepusht und ein Pull-Request mit dem notwendigen Kontext und den Nachweisen erstellt.
Die konfigurierte Projektrichtlinie bestimmt dann, was als Nächstes passiert. Ein Mensch kann den Pull-Request überprüfen. Ein anderes KI-System kann die Überprüfung durchführen. Ein hochautonomes Projekt kann automatisch mergen, wenn alle erforderlichen Prüfungen bestanden sind. In anderen Projekten bleibt die endgültige Entscheidung explizit beim Menschen.
Dies offenbart die beiden Orchestrierungsebenen im System. loop-task ist die äußere Orchestrierungsebene. Sie verwaltet den Backlog-Lebenszyklus und entscheidet, wann Verfeinerung, Implementierung, Überprüfung oder Abschluss stattfinden sollen. /plan-goal und die anderen opencode-onboard-Befehle bilden den inneren Engineering-Workflow. Sie verstehen, wie man eine bestimmte Änderung erkundet, plant, zuweist, implementiert, überprüft und ausliefert.
Ein System, das das Gespräch überdauert
Eine der Einschränkungen der promptbasierten Entwicklung ist, dass zu viel Zustand in einem temporären Gespräch lebt.
Die Architektur muss jedes Mal neu erklärt werden. Frühere Entscheidungen werden vergessen. Eine unterbrochene Implementierung ist schwer wieder aufzunehmen. Ein Entwickler muss anwesend sein, um nach jedem Schritt zu entscheiden, was der Agent tun soll.
Dieser Workflow verschiebt diesen Zustand in dauerhafte Systeme. Das Repository enthält die Architektur, die Designregeln, die Ingenieure und die Leitplanken. OpenSpec enthält die geplante Änderung und ihre Aufgaben. Git enthält die Implementierungshistorie und Wiederherstellungspunkte. Der Backlog enthält den Auslieferungszustand und menschliche Entscheidungen. Der lokale Rechner oder die VM bietet die persistente Umgebung, in der die Loops weiterlaufen.
Das Ergebnis ist nicht ein einzelner autonomer Agent, der versucht, sich wie eine gesamte Softwareorganisation zu verhalten. Es ist ein koordiniertes System, in dem verschiedene Komponenten unterschiedliche Verantwortlichkeiten haben.
Menschen definieren die Richtung, die Einschränkungen und die Verantwortungsgrenzen. Spezialisierte Agenten führen fokussierte Engineering-Arbeit aus. Loops koordinieren den Lebenszyklus asynchron. Der Backlog verbindet sie.
Die wichtigste Veränderung ist nicht, dass Agenten mehr Code generieren können. Der größere Wandel geht von isolierten KI-Interaktionen hin zu persistenten Engineering-Systemen.
Anstatt das Repository vor jeder Aufgabe zu erklären, trägt das Projekt seine eigene Architektur und Leitplanken. Anstatt einen generischen Agenten zu bitten, alles zu implementieren, wird Arbeit an Spezialisten vergeben. Anstatt manuell zu entscheiden, was nach jedem Schritt passieren soll, reagieren Loops auf dauerhafte Workflow-Zustände. Anstatt den gesamten Prozess in einem Gespräch zu halten, überlebt der Fortschritt in Issues, Spezifikationen, Commits, Pull-Requests und lokalem Zustand.
Die menschliche Rolle verschwindet nicht. Sie verschiebt sich hin zum Entwurf der Umgebung, in der autonome Ausführung operieren darf.
Das ist das Modell, das ich derzeit aufbaue: ein menschlich entworfenes KI-SDLC, bei dem der Entwickler zuerst die Engineering-Umgebung und die Autonomiegrenzen festlegt, dann asynchrone Loops spezialisierte Agenten durch einen backloggesteuerten Auslieferungslebenszyklus koordinieren.
Von null zu Loops, die von selbst laufen. Sechs Schritte, jeder baut auf dem vorherigen auf, jeder verschiebt ein wenig mehr Zustand aus dem Gespräch in Systeme, die nicht vergessen.
PS: Sie finden loop-task, opencode-onboard und die restlichen dieser Tools auf ckgrafico.com
