💻 Der Laptop als letzter Flaschenhals: Von Coding Agents zu gemeinsamen Arbeitsabläufen

vom 26. Juli 2026

Ein einzelner Codierungsagent im Terminal ist überschaubar. Man lässt ihn eine Datei ändern, wirft einen Blick auf die Änderungen, führt die erinnerten Tests aus und macht weiter. Die unsichtbare Checkliste passt immer noch in einen Kopf.

Dann öffnen Sie einen zweiten Agenten. Dann einen dritten. Einer arbeitet an der API. Ein anderer überarbeitet die Dokumentation. Ein dritter versucht einen Sicherheitspass. Plötzlich programmieren Sie nicht mehr nur. Sie planen, überprüfen und erinnern sich. Wurde bei diesem Lauf eine statische Analyse durchgeführt? Wurde dieser Branch auf Sicherheit geprüft? Was hat uns der gestrige Fehler gelehrt, was dieser Chat bereits wieder vergessen hat?

Die Agenten sind nicht zwangsläufig unfähig. Der Prozess um sie herum ist nach wie vor individuell. Das ist die These dieses Artikels, basierend auf einem kleinen PHP-Experiment: Bereitstellung einer Checkliste für die Änderungsprüfung im Engineering als HTTP-API mit Framework X als asynchroner Laufzeitumgebung und Darkwood Flow als Orchestrierungsschicht.

Die zentrale technische Idee ist einfach:

Framework X empfängt und führt Anfragen aus. Flow beschreibt und koordiniert die durch diese Anfragen ausgelösten Aktionen.

Sie sind keine Konkurrenten. Sie beschäftigen sich mit unterschiedlichen Aspekten desselben Problems.

Der verborgene Arbeitsablauf

Softwareentwicklung ist bereits ein Arbeitsablauf, selbst wenn niemand die einzelnen Elemente vorgibt:

Change code
    ↓
Run tests
    ↓
Run static analysis
    ↓
Review security
    ↓
Update documentation
    ↓
Review result

Wenn diese Vorgehensweise nur noch aus Gewohnheit besteht – „Ich führe immer PHPUnit aus, bevor ich pushe“ –, ist sie fehleranfällig. An einem müden Freitag wird ein Schritt ausgelassen. Ein neuer Teamkollege hat ihn nie gelernt. Ein Agenten-Chat, der aus dem Kontext gerissen wurde, kann ihn nicht wiederherstellen.

Der fehlende Schritt ist nicht eine intelligentere Eingabeaufforderung. Es geht darum, den Prozess explizit zu gestalten: mit benannten Schritten, Ein- und Ausgaben, Fehlermodi und einer Ablaufverfolgung der tatsächlich ausgeführten Aktionen.

Warum der Laptop zum Flaschenhals wird

Die Aussage „Der Laptop ist der Flaschenhals“ wird leicht als Hardwareproblem missverstanden. Interessant ist jedoch die Aussage, dass es sich um ein Organisationsproblem handelt.

Der Laptop beherbergt mehr als nur die CPU. Er speichert Identitäten und Anmeldeinformationen, Zugriffsrechte auf das Repository, private Eingabeaufforderungen und Fähigkeiten, lokale Skripte, Modellkonfigurationen, Agentenverlauf, Projektkonventionen und die Erkenntnisse aus den Fehlern der letzten Woche. Er ist sowohl eine Laufzeitumgebung als auch ein Wissensspeicher.

Wenn mehrere Agenten parallel laufen, bleibt alles, was ihre Grenzen ausgleicht, individuell:

• Denken Sie an Tests, statische Analyse, Sicherheit, Dokumentation, Überprüfung und Bereitstellungsbeschränkungen;
• sich daran erinnern, was die vorherigen Durchgänge gelehrt haben;
• Die Geheimnisse und die Zulassungslisten sollten auf einem einzigen Rechner gespeichert werden.

Das lässt sich nicht auf ein Team übertragen. Wenn die Person – oder der Laptop – geht, gehen auch die Automatisierung und ihre gespeicherten Daten verloren.

Von Agentenbefehlen zu Workflows

Der konzeptionelle Wandel besteht in Folgendem:

Give one agent a large task

Zu:

Define a sequence of bounded steps

Jeder Schritt kann später PHP-Code, ein Shell-Befehl, ein API-Aufruf, ein Codierungsagent, ein anderes Modell, eine menschliche Freigabe oder ein Bereitstellungsdienst sein. Im unten beschriebenen Experiment sind die Schritte – bewusst – deterministische lokale PHP-Dienste. Es geht um die Struktur des Prozesses, nicht um eine weitere LLM-Demo.

Der Workflow bildet die beständige Schicht. Das aktuelle Modell bzw. der aktuelle Agent ist austauschbar.

Das Framework X-Experiment

Der Prototyp befindet sich in einem kleinen Projekt namens framework-x-flow. Es handelt sich nicht um ein Produkt, sondern um ein Labor für eine Frage: Können wir eine interne Checkliste für Entwickler in etwas HTTP-Sichtbares, Überprüfbares und Reproduzierbares umwandeln – ohne dabei so zu tun, als hätten wir eine Cloud-Agentenplattform entwickelt?

Architektur in einem Diagramm:

HTTP request
    ↓
Framework X route + middleware
    ↓
Flow workflow (jobs over Ip payloads)
    ↓
Steps (validate → analyse → quality → docs → review → retrospective)
    ↓
Trace + retrospective
    ↓
JSON response (+ atomic file under var/runs/)

Umgesetzte Verantwortungsaufteilung:

So funktioniert Framework X (gerade genug)

Framework X (clue/framework-x, aktuell 0.17.x) ist ein Mikroframework für ReactPHP. Dieselbe App kann als langlebiger CLI-HTTP-Server oder hinter einer herkömmlichen PHP-SAPI ausgeführt werden.

Die Runner-Auswahl ist SAPI-fähig: Auf der Kommandozeile bindet HttpServerRunner einen Socket (Standard: 127.0.0.1:8080, überschreibbar mit X_LISTEN) und führt die Ereignisschleife von ReactPHP aus. Hinter FPM oder Apache verarbeitet SapiRunner eine Anfrage aus den globalen Variablen. Für Tests und Einbettungen verarbeitet App::__invoke() eine einzelne PSR-7-Anfrage und wartet auf Promises.

Handler können eine synchrone PSR-7-Antwort, ein PromiseInterface oder einen Generator, der Promises erzeugt, zurückgeben. Unter PHP 8.1+ im CLI-Modus kapselt HttpServerRunner jede Anfrage in einen FiberHandler, sodass React\Async\await() synchron erscheinen kann, ohne das mentale Modell des Codes zu blockieren. Fehler sollen HTTP-Antworten auslösen, anstatt den Prozess zum Absturz zu bringen: ErrorHandler normalisiert Ausnahmen, abgelehnte Promises und ungültige Rückgabetypen.

Dependency Injection ist ein kleiner Container: Array-Konfiguration, Factories, ENV-förmige Parameter, optionales PSR-11. Klassenstring-Controller werden verzögert aufgelöst.

Deshalb ist Framework X für diesen Artikel relevant: Es kann Workflows über HTTP bereitstellen und einen asynchronen Prozess am Laufen halten. Es handelt sich dabei nicht um einen Scheduler, eine Warteschlange, eine Multi-Tenant-Sandbox oder eine Agentenlaufzeitumgebung.

Es hat auch einige Schwächen, die erwähnt werden sollten. Der standardmäßige ErrorHandler bettet immer Ausnahmeklasse, Fehlermeldung und Dateipfad in HTML-500-Fehlerberichte ein – es gibt keinen Debug-/Produktionsmodus. RouteHandler behält seinen eigenen HTML-404/405-Pfad bei. Das Paket ist noch in Version 0.x. Ein langlebiger CLI-Prozess teilt sich den Speicher über mehrere Anfragen hinweg: Veränderliche Singletons, blockierende Aufrufe und verschachtelte Loop::stop()-Aufrufe sind potenzielle Fehlerquellen. Eine asynchrone Laufzeitumgebung macht blockierendes PHP nicht nicht-blockierend; sleep(), synchrone HTTP-Clients und umfangreiche Dateisystemoperationen blockieren die Schleife weiterhin.

Wie Flow passt

Darkwood Flow (darkwood/flow v8.1.1, PHP ≥ 8.5) ist eine treiberbasierte Job-Pipeline. Sie erstellen eine Kette mit FlowFactory::create(), übergeben Aufgaben als Ip-Werte und rufen await() auf, bis der Datenstrom abgearbeitet ist. Ein Job empfängt $ip->data und gibt den nächsten Datenwert zurück. Fehler werden zu Flow\Exception\RuntimeException; optional wird pro Stufe ein errorJob ausgeführt, und die Ip wird nicht an die nächste Stufe weitergeleitet.

In der Demo ist der Workflow für die Änderungsprüfung in etwa wie folgt aufgebaut (Closures umschließen aufrufbare Schrittobjekte – Flow akzeptiert Closure|JobInterface, keine einfachen aufrufbaren Objekte):

return (new FlowFactory($driver))->create(static function () use (…) {
    yield [static fn (ChangeReviewContext $ctx) => $validate($ctx), $errorJob];
    yield [static fn (ChangeReviewContext $ctx) => $analyse($ctx), $errorJob];
    // concurrent quality adapter, or sequential tests / static / security stages
    yield [static fn (ChangeReviewContext $ctx) => $docs($ctx), $errorJob];
    yield [static fn (ChangeReviewContext $ctx) => $final($ctx), $errorJob];
    yield [static fn (ChangeReviewContext $ctx) => $retro($ctx), $errorJob];
}, ['driver' => $driver]);

Konzeptionelle Schritte:

validate
    ↓
analyse
    ↓
tests | static-analysis | security-review
    ↓
documentation
    ↓
final-review
    ↓
retrospective

HTTP-Oberfläche (Framework X-Routen):

$app->get('/health', HealthHandler::class);
$app->get('/workflows/change-review', DescribeWorkflowHandler::class);
$app->post('/workflows/change-review/runs', RunWorkflowHandler::class);
$app->get('/workflows/change-review/runs/{runId}', GetWorkflowRunHandler::class);
$app->get('/analysis/framework-x-flow', AnalysisHandler::class);
$app->get('/experiments/sequential-vs-concurrent', ExperimentHandler::class);

Was Flow bietet: Jobketten, IPs, Treiber, Strategien wie MaxIpStrategy und errorJob-Hooks.

Was die Demo hinzufügt: HTTP-Darstellung, Lauf-IDs, Schrittzeitverfolgung, atomare JSON-Persistenz unter var/runs/, nachträgliche Formatierung, kontrollierte Fehlerflags und – ganz entscheidend – einen EmbeddedReactDriver. Die native Methode Flow\Driver\ReactDriver::await() ruft Loop::run() und Loop::stop() auf. Der HttpServerRunner von Framework X verwaltet die Schleife bereits; ein Aufruf der nativen Methode await() innerhalb einer Anfrage würde den HTTP-Server stoppen. Der eingebettete Treiber behält die asynchrone/verzögerte Semantik von React bei, schließt aber ein Promise ab, ohne die gemeinsame Schleife zu stoppen. Dieser Adapter ist Projektcode und nicht Teil des Upstream-Flows.

Der Standard-Qualitätsmodus fasst drei Prüfungen in einem Flow-Job mithilfe von ReactPHP Promise::all (ConcurrentQualityChecksStep) zusammen. Dies ist ebenfalls ein Adapter. Das native Parallelitätsmodell von Flow sieht viele IPs durch eine Phase mit MaxIpStrategy vor, nicht einen parallelen DAG von untergeordneten Schritten innerhalb einer IP.

Sequenzielle versus parallele Ausführung

Das CLI-Experiment (php bin/experiment) vergleicht drei IPs, die jeweils eine Verzögerung von 0,05 s aufweisen:

Diese Zeitangaben dienen lediglich der Veranschaulichung und sind nicht wissenschaftlich. Sie entsprechen dem erwarteten Verlauf: drei aufeinanderfolgende Verzögerungen im Vergleich zu drei sich überlappenden Verzögerungen.

Eine subtile Erkenntnis: LinearIpStrategy allein führt unter ReactDriver immer noch zu Überlappungen asynchroner Aufgaben, da die Pull-Schleife die nächste IP-Adresse starten kann, während die vorherige Arbeit noch ausgeführt wird. Für eine wirklich sequentielle Steuerung ist MaxIpStrategy(1) erforderlich. Solche Details werden erst bei Messungen sichtbar.

Parallelverarbeitung ist nur dann hilfreich, wenn Aufgaben unabhängig und nicht blockierend sind. Das Einbetten blockierender Aufgaben in ein Promise gibt die Ereignisschleife nicht frei.

Fehler sind Teil des Arbeitsablaufs

Orchestrierung beschränkt sich nicht nur auf die Abfolge erfolgreicher Abläufe. Die Demo akzeptiert kontrollierte Fehlerflags im POST-Body (exception, promise, async, security), weist ungültiges JSON mit einem sicheren 400-Fehler zurück und ordnet Schrittfehler einem strukturierten Ausführungsbericht zu.

Da Framework X standardmäßig ausführliche HTML-Fehlermeldungen ausgibt, bindet die Anwendung einen JsonErrorHandler, der von ErrorHandler abgeleitet ist. Diese Ableitung ist wichtig: Eine einfache Middleware, die davor platziert wird, erhält weiterhin einen Standard-HTML-ErrorHandler, der nicht durch den Anwendungsstart verschoben wird. Zugriffsprotokolle müssen, sofern vorhanden, unmittelbar von einer ErrorHandler-Instanz gefolgt werden. Clients sehen Fehlercodes wie internal_error oder invalid_json; Details werden in einer lokalen Protokolldatei gespeichert.

Eine fehlgeschlagene Sicherheitsprüfung erzeugte beispielsweise einen Bericht mit folgendem Inhalt:

{
  "code": "quality_check_failed",
  "message": "Security check failed: no dependency audit result was supplied."
}

und ging so weit, dass eine retrospektive Analyse eine konkrete Workflow-Änderung vorschlagen konnte – nicht nur einen Stacktrace im Browser.

Der retrospektive Schritt

Der letzte Job erstellt eine deterministische Retrospektive: langsame Schritte, fehlgeschlagene Prüfungen, Warnungen, Erkenntnisse und suggestedWorkflowChanges. Bezüglich des oben genannten Sicherheitsfehlers lautete der Vorschlag:

{
  "target": "security-review",
  "reason": "The security check failed because no dependency audit result was supplied.",
  "proposal": "Add a dependency audit step before final review."
}

Der jeder Retrospektive beigefügte Hinweis ist beabsichtigt:

Nur Vorschläge – dieser Schritt ändert weder Anwendungscode noch Workflow-Definitionen.

Eine Workflow-Änderung vorschlagen ist nicht dasselbe wie den Workflow stillschweigend umzuschreiben. Gezielte Selbstverbesserung ist unkontrollierter Selbstmodifikation vorzuziehen. Automatisches Lernen, automatische Vorschlagserstellung und autonome Mutation der Produktionsautomatisierung sind drei unterschiedliche Ansätze; dieser Prototyp erprobt lediglich den mittleren.

Was der Umzug in die Cloud wirklich bedeutet

Die Bereitstellung desselben PHP-Skripts auf einem Server ist keine Kollaboration. Eine Workflow-Plattform für Teams benötigt weiterhin gemeinsame Ausführung, dauerhafte Historie, Identitäts- und Berechtigungsverwaltung, Geheimnisisolierung, Sandboxing, Netzwerkrichtlinien, Kontingente, Auditierbarkeit, Bereinigung und oft auch Warteschlangen oder verteilte Planung.

Produkte in der Branche – Upsun Dispatch ist ein Beispiel für die breitere Diskussion um die Ausführung von Remote-Agenten – existieren, weil diese Probleme komplex sind. Die Erwähnung dieses Kontextes stellt keine Empfehlung für einen bestimmten Anbieter dar. Darkwoods Fokus ist enger gefasst: Orchestrierung (was Flow untersucht) und sicheres Multi-Tenant-Agentenhosting (was dieser Prototyp nicht versucht) sind separate Ebenen. Framework X und Flow bieten derzeit keine sichere Sandbox; das Gegenteil zu behaupten, wäre falsch.

Was dieser Prototyp nicht beweist

• Keine sichere Cloud-Sandbox, kein Credential Broker und keine Befehls-Whitelist.
• Kein verteilter Scheduler oder dauerhafte Nachrichtenwarteschlange.
• Keine Mandantenisolierung oder automatische Teamführung.
• Keine sichere, autonome Selbstmodifikation von Arbeitsabläufen. Es gibt keine Anhaltspunkte dafür, dass jede Programmieraufgabe zu einem formalen Arbeitsablauf werden sollte.
• Es gibt keine Anhaltspunkte dafür, dass Framework X die einzige oder beste Laufzeitumgebung für dieses Modell ist.
• Es gibt keinen Beweis dafür, dass das Codieren einer Checkliste auf einem Laptop automatisch zu einem Team-Workflow führt – die gemeinsame Nutzung erfordert weiterhin Bereitstellung, gemeinsamen Speicher und soziale Prozesse.

Es zeigt sich, dass ein expliziter Ausführungsbericht leichter zu überprüfen ist als ein privates Chatprotokoll, dass asynchrone Laufzeitumgebungen und Workflow-Engines unterschiedliche Probleme lösen und dass ehrliche Adapter (EmbeddedReactDriver, nebenläufige Qualität über Promise::all) besser sind als die Erfindung von Funktionen, die die Bibliotheken nicht haben.

Abschluss

Modelle werden sich ändern. Codierungsagenten werden sich ändern. Anbieter werden dieselben Infrastrukturprobleme immer wieder anders benennen.

Was weiterhin nützlich ist, ist der Prozess, den ein Team benennen, ausführen, überprüfen, sicher im Fehlerfall durchlaufen und gezielt verbessern kann: validieren, analysieren, Qualität prüfen, dokumentieren, überprüfen, retrospektiv betrachten – kodiert als Daten, nicht als Folklore auf einem Laptop.

Framework X kann die Schnittstelle sein, die die Anfrage empfängt. Flow kann der Graph sein, der die Arbeit koordiniert. Beides ersetzt jedoch nicht die komplexen Aspekte der Cloud-Agent-Ausführung. In diesem kleinen Experiment machen sie gemeinsam die Checkliste sichtbar.

Das nützliche Artefakt ist nicht mehr die private Eingabeaufforderung. Es ist der Workflow, den man morgen wieder ausführen und in einem Pull Request diskutieren kann.