Die Automatisierung der Laravel-Entwicklung mit KI-Agenten: Entwickeln, Testen, Beheben, Wiederholen

Der Kopieren-und-Einfügen-Laufband

Zählen Sie, wie oft ein typischer Tag mit einem KI-Programmierassistenten so abläuft: Man schreibt eine Anfrage, kopiert die Ausgabe in den Editor, führt php artisan test aus – es tritt ein Fehler auf. Dann wird der Fehlertext kopiert, wieder in die KI eingegeben, mit „Bitte beheben Sie das“ versehen, und der Vorgang beginnt von vorne mit dem Kopieren.

Einige Entwickler wiederholen diesen Zyklus täglich dutzende Male. Das wird als KI-gestützte Entwicklung bezeichnet, doch die am meisten beschäftigte Person in diesem Kreislauf ist nicht die KI. Es ist die Person, die Nachrichten zwischen dem Modell und der Konsole hin- und herüberträgt: Sie entscheidet, wann Tests ausgeführt werden sollen, liest die Fehler, beurteilt, ob weitere Korrekturen nötig sind, und kopiert alles hin und her. Die KI bleibt untätig, bis die nächste Anweisung eintrifft.

Eine bessere Lösung verzichtet auf den menschlichen Kurier. Ein kleines System kann den Zyklus aus Erstellen, Testen, Beheben und Wiederholen eigenständig durchführen, bis die Arbeit tatsächlich abgeschlossen ist, wobei ein Mensch nur noch für die endgültige Überprüfung eingreift. Hier werden Laravel Boost und OpenCode CLI verwendet – zwei Tools, die zum heutigen Laravel-Ökosystem passen. Die Erklärungen werden absichtlich langsam dargelegt, damit auch jemand, der noch nie mit diesen Tools gearbeitet hat, folgen kann.

Wortschatz

Mehrere Begriffe tauchen wiederholt auf:

• Agent: eine KI, der eine definierte Aufgabe sowie ein definiertes Set an Werkzeugen zur Verfügung gestellt werden, vergleichbar mit einem Mitarbeiter mit einer schriftlich festgelegten Rolle.
• MCP (Model Context Protocol): ein Anschlusspunkt, über den die KI direkt Fragen an Ihr System richten kann – sei es an die Datenbank oder die Protokolle –, sodass sie nicht mehr aus dem heraus raten muss, was zufällig eingegeben wurde.

CLI (Befehlszeilenschnittstelle): Betrieb von Software durch Eingabe von Befehlen in einer Terminalanzeige anstelle des Klickens auf einer grafischen Oberfläche.

Aufgaben und Warteschlange: Wie Laravel Aufgaben im Hintergrund nacheinander abwickelt, sodass keine Benutzer vor einem Ladebalken sitzen bleiben.

Orchestrator: Der Verkehrsleiter, der die Reihenfolge der Aufgaben festlegt, überwacht, wer an der Reihe ist, und weiß, wo nach einem Fehler weitergemacht werden soll.

Die Frage hat sich von „Kann KI Code schreiben?“ weiterentwickelt

Jeder, der bereits Claude Code, Cursor oder ein ähnliches Tool mit Laravel verwendet hat, weiß, dass KI Migrationsdateien, Modelle, Policies und Tests erstellen kann. Das verbleibende Problem ist der manuelle Arbeitsablauf dazu:

Developer → AI → Developer → Test → Developer → AI → Developer → Test → ...

Jeder Pfeil steht für eine Person, die den Kontext manuell von einem Schritt zum nächsten überträgt und entscheidet, dass es Zeit ist zu testen oder dass ein Fehler an die KI zurückgesendet werden muss.

Vergleichen Sie eine automatisierte Version:

Developer → Orchestrator → Build → Test → (failed? → Fix → Test again) → Review → Done

Der Unterschied scheint gering zu sein, doch er hat große Auswirkungen. Es gibt nun einen Orchestrierer – eine Schicht, die den Ablauf der Aufgaben kennt, weiß, wann nachgeversucht werden muss und wann gestoppt werden sollte – ohne dass jemand alle dreißig Sekunden nachschaut.

Auch Laravel entwickelt sich in diese Richtung. Laravel Boost wurde entwickelt, damit KI-Code-Agenten echten Kontext zu einer Laravel-Anwendung erhalten, anstatt aus allgemeinen Mustern zu raten.

Die beiden Hauptwerkzeuge

Laravel Boost: Übersetzer zwischen KI und Anwendung

Eine KI kann im Allgemeinen gut mit Laravel umgehen, in Ihrem spezifischen Projekt jedoch völlig blind sein. Sie weiß nicht, welche Laravel-Version Sie verwenden, wie Ihre Datenbank tatsächlich strukturiert ist, ob Sie Livewire oder Inertia nutzen, oder welche Namenskonventionen Ihr Team vereinbart hat.

Boost ist ein Composer-Paket, das der KI den tatsächlichen Zustand des Projekts zeigt. Es arbeitet über MCP, sodass die KI die Anwendung direkt abfragen kann: das Datenbankschema überprüfen, vorhandene Routen ansehen, den neuesten Fehler erkennen, Artisan-Befehle ausführen und in den Laravel-Dokumentationen nach Informationen suchen, die den tatsächlich installierten Paketversionen entsprechen.

Die Installation erfordert zwei Befehle:

composer require laravel/boost --dev

php artisan boost:install

Das zweite ist interaktiv. Es fragt nach der verwendeten IDE oder KI-Tool und installiert die entsprechenden Ressourcen.

Es sei klar gesagt, dass Boost den Kontext übersetzt, aber keine Entscheidungen trifft. Es wird weder „Führen Sie jetzt die Tests aus“ noch „Starten Sie den Fix-Agent bei Fehlern“ sagen. Seine einzige Aufgabe besteht darin zu verhindern, dass die Agenten die tatsächliche Zustandslage der Anwendung übersehen.

OpenCode: Wo der Agent die Arbeit erledigt

Während Boost den Kontext übersetzt, ist OpenCode die Arbeitsumgebung – eine CLI, die speziell für KI-Programmierung entwickelt wurde. Im Gegensatz zu einem gewöhnlichen Chatbot ermöglicht es Ihnen, mehrere Agenten mit unterschiedlichen Aufgaben zu definieren, beispielsweise einen, der Code schreibt, und einen anderen, der Testergebnisse liest, wobei jeder seine eigenen Anweisungen und Grenzen hat.

OpenCode kann sich außerdem mit MCP-Servern verbinden, darunter auch Boost. Sobald eine Verbindung hergestellt ist, stehen alle Funktionen von Boost dem Agenten zur Verfügung, der innerhalb von OpenCode läuft.

Praktische Anwendung: Boost mit OpenCode verbinden

Beginnen Sie damit, zunächst manuell im Terminal auszuprobieren, bevor Sie etwas automatisieren.

1. OpenCode auf Boost ausrichten

Da Boost installiert ist, muss OpenCode erfahren, wo sich sein MCP-Server befindet. Diese Information wird in eine opencode.json-Datei im Projektverzeichnis geschrieben:

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "laravel-boost": {
      "type": "local",
      "command": ["php", "artisan", "boost:mcp"],
      "enabled": true
    }
  }
}

Der genaue Befehl kann je nach Boost-Version variieren, daher sollten Sie dem folgen, was php artisan boost:install erzeugt, anstatt dies blind zu kopieren. Dies gehört zu den Teilen, die am ehesten zwischen den Versionen ändern.

Stellen Sie sicher, dass OpenCode den Server sehen kann:

opencode mcp list

Falls laravel-boost als verbunden aufgeführt ist, haben die Agenten Zugriff auf alles, was Boost bereitstellt.

2. Erstellen Sie Agenten mit unterschiedlichen Aufgaben

Anstatt einen einzigen Agenten für alle Aufgaben zu verwenden, teilen Sie die Aufgaben auf. Erstellen Sie eine .opencode/agent/builder.md-Datei im Projekt:

---
description: Build Agent for new features
mode: primary
tools:
  write: true
  edit: true
---
You are the Build Agent.
Use Laravel Boost tools to understand the application structure
before writing any code. Never assume the database structure -
always check the schema first. Write tests for every new behavior.
At the end of your work, return ONLY JSON in this format:
{"status": "success", "files_changed": [...], "summary": "..."}

Die Zeile tools.write: true erlaubt diesem Agenten, Dateien zu ändern. Ein späterer Agent erhält write: false, wodurch er nur zum Lesen geeignet ist und nichts verändern kann; der entscheidende Grund dafür wird gleich erläutert.

Listen Sie die registrierten Agenten auf:

opencode agent list

3. Führen Sie es zunächst manuell aus.

opencode run --agent builder "Add a task assignment feature to TaskFlow according to the requirements in TASK.md"

Eine kurze Erläuterung zu diesem Befehl:

• --agent wählt aus, welcher Agent ausgeführt wird – sei es der Builder, der Tester oder ein anderer definierter Agent.
• Durch Hinzufügen von --format json wird die Ausgabe als Rohdaten statt als für Menschen lesbare Darstellung bereitgestellt. Das wird später von einer PHP-Aufrufung verwendet.
• --session und --continue ermöglichen es dem Agenten, sich an frühere Gespräche zu erinnern, anstatt jedes Mal von vorne anzufangen.

Führen Sie ihn mehrmals manuell aus, um ein Gefühl dafür zu bekommen, bevor Sie die Automatisierung einsetzen.

Ein konkreter Fall: Aufgabenzuweisung in TaskFlow

Ein einziges funktionierendes Beispiel hilft, die Dinge greifbar zu machen. Stellen Sie sich eine einfache Aufgabenverwaltungs-App namens TaskFlow vor, die folgende Funktionalität benötigt: Benutzer können eine Aufgabe an einen anderen Benutzer weitergeben, allerdings ausschließlich innerhalb eines Projekts, auf das beide Zugriff haben. Aufgeschlüsselt in Anforderungen:

1. A task has an assignee column (belongs to a User).
2. A user can only assign tasks within a project they're a member of.
3. A user must not assign or access tasks from other projects.
4. All of the above must be covered by automated tests.

Es handelt sich um eine gängige Anforderung, was sie zu einer guten Demonstration macht. Solche Fälle erfordern oft zwei oder drei Versuche, bevor die Frage, wer auf was zugreifen darf – technisch als Autorisierung bezeichnet – eindeutig geklärt ist. Genau hier kommt ein automatisierter Zyklus ins Spiel.

Warum der Prozess ein Protokoll benötigt

Sobald die Arbeit im Hintergrund abläuft, kann sich niemand auf sein Gedächtnis verlassen, um sich daran zu erinnern: „Wie hieß nochmal dieser Fehler?“ Alles muss aufgezeichnet werden, und das bedeutet in diesem Fall eine Datenbanktabelle, die als Fortschrittsprotokoll dient:

Schema::create('ai_tasks', function (Blueprint $table) {
    $table->id();
    $table->string('type');
    $table->string('status')->default('pending');
    $table->text('prompt');
    $table->json('result')->nullable();
    $table->unsignedTinyInteger('iteration')->default(0);
    $table->timestamps();
});

Das Modell:

class AiTask extends Model
{
    protected $fillable = [
        'type', 'status', 'prompt', 'result', 'iteration',
    ];

    protected function casts(): array
    {
        return ['result' => 'array'];
    }
}

Die status-Spalte trägt die Bedeutung. Sie durchläuft diese Phasen:

pending → building → testing → (fixing → testing)* → reviewing → completed / failed

Warum nicht einfach ein done-Flag? Weil der Orchestrierer wissen muss, in welcher Phase die Arbeit sich befindet – und nicht nur, ob sie abgeschlossen ist. Die Phasenverfolgung ermöglicht außerdem, einen Lauf nach einem Absturz eines Workers mitten im Ablauf fortzusetzen, und macht den aktuellen Fortschritt sichtbar.

OpenCode in PHP integrieren

Menschen überspringen oft diesen Schritt: Verstreuen Sie OpenCode-Befehle nicht über viele Dateien. Wenn das Tool später ausgetauscht wird, sollten Dutzende von Stellen nicht bearbeitet werden müssen. Erstellen Sie einen einzigen Eingangspunkt, eine Schnittstelle:

interface AgentRunner
{
    public function run(string $agent, string $prompt): array;
}

Dann die eigentliche Implementierung, die OpenCode aus PHP aufruft:

class OpenCodeAgentRunner implements AgentRunner
{
    public function run(string $agent, string $prompt): array
    {
        $result = Process::timeout(600)->run([
            'opencode', 'run',
            '--agent', $agent,
            '--format', 'json',
            $prompt,
        ]);

        if (! $result->successful()) {
            return [
                'status' => 'error',
                'error' => $result->errorOutput(),
            ];
        }

        return json_decode($result->output(), true) ?? [
            'status' => 'error',
            'error' => 'Agent output was not valid JSON',
        ];
    }
}

Binden Sie es bei einem Dienstleister ein:

$this->app->bind(AgentRunner::class, OpenCodeAgentRunner::class);

Mit diesem Muster kommuniziert jede Aufgabe nur mit AgentRunner und kümmert sich nicht darum, ob dahinter OpenCode oder etwas anderes steht.

Eine Aufgabe pro Phase

Für alle, die mit Laravel Jobs neu sind: Eine Aufgabe ist eine Task, die im Hintergrund über einen Queue ausgeführt wird, sodass niemand darauf warten muss, bis sie abgeschlossen ist.

Die Build-Aufgabe

class BuildFeature implements ShouldQueue
{
    public function __construct(protected AiTask $task) {}

    public function handle(AgentRunner $agent): void
    {
        $result = $agent->run(
            agent: 'builder',
            prompt: $this->task->prompt,
        );

        $this->task->update([
            'status' => 'testing',
            'result' => $result,
        ]);

        RunTests::dispatch($this->task);
    }
}

Hier läuft der Build Agent, sein Ergebnis wird gespeichert, und der Ablauf geht ohne manuelles Klicken direkt zum nächsten Job (RunTests).

Der Testjob

Dieser Job wird absichtlich einfach gehalten. Er benötigt kein Verständnis für Code. Er führt die Testsuite aus und liest das Ergebnis ein.

class RunTests implements ShouldQueue
{
    public function __construct(protected AiTask $task) {}

    public function handle(): void
    {
        $result = Process::timeout(300)->run('php artisan test --compact');

        if ($result->successful()) {
            $this->task->update(['status' => 'reviewing']);
            ReviewFeature::dispatch($this->task);
            return;
        }

        $this->task->update(['status' => 'failed']);
        AnalyzeFailure::dispatch($this->task, $result->output());
    }
}

Der Ablauf ist einfach:

Test
 ├── passed → move to Review
 └── failed → move to Analyze

Geben Sie keine rohen Fehler an den Agenten weiter

Diese Lektion ist am einfachsten zu überspringen, hat aber den größten Einfluss auf die Qualität. Dem Agenten nur mitzuteilen, dass ein Test fehlgeschlagen ist, und um eine Korrektur zu bitten, reicht nicht aus. Er muss von vorne anfangen, jede Datei erneut lesen und raten, was schiefgelaufen ist.

Strukturieren Sie zunächst den Fehler:

{
  "status": "failed",
  "failed_tests": [
    {
      "name": "user_cannot_assign_task_from_other_project",
      "error": "Expected response status code [403] but received 200."
    }
  ]
}

Dann übergeben Sie es einem Agenten, dessen einzige Aufgabe die Diagnose ist – nennen wir ihn Debug Agent – zusammen mit Anweisungen, die streng begrenzen, was er tun darf:

You are the Debug Agent.

Analyze the failed tests below. DO NOT modify any files.
Inspect: relevant models, policies, migrations, and tests.
Return JSON with:
- root_cause
- affected_files
- recommended_fix
- risk_of_regression

Warum sollte die Diagnose von der Behebung getrennt werden? Um eine Lücke zwischen dem Verständnis des Problems und der Durchführung der Reparatur zu schaffen. Wenn dem Agenten einfach gesagt wird, die Probleme zu beheben, verschwindet der Überblick darüber, warum eine bestimmte Datei geändert wurde, und die abschließende Überprüfung wird viel schwieriger zu verifizieren.

Für TaskFlow würde die Ausgabe des Debug-Agenten plausibel wie folgt aussehen:

{
  "status": "analyzed",
  "root_cause": "TaskPolicy does not verify project membership before allowing assignment",
  "affected_files": ["app/Policies/TaskPolicy.php"],
  "recommended_fix": "Add a project membership check inside the assign() method",
  "next_action": "fix"
}

Das wäre eine glaubwürdige Erkenntnis, da es sich um einen der häufigsten Autorisierungsfehler handelt: eine Richtlinie, die nur prüft, ob der Benutzer eingeloggt ist, nicht jedoch, ob er tatsächlich zum Projekt gehört.

Bessern Sie es erst, testen Sie anschließend erneut – niemals nur bessern und dann fertig.

class FixFeature implements ShouldQueue
{
    public function __construct(protected AiTask $task, protected array $analysis) {}

    public function handle(AgentRunner $agent): void
    {
        $result = $agent->run(
            agent: 'fixer',
            prompt: json_encode($this->analysis),
        );

        $this->task->increment('iteration');
        $this->task->update([
            'status' => 'testing',
            'result' => $result,
        ]);

        RunTests::dispatch($this->task);
    }
}

Achten Sie darauf, dass nach der Korrektur der Status wieder auf testing zurückgeht, anstatt direkt auf completed zu wechseln. Das Prinzip ist klar: Ein Agent hat keine Befugnis, einfach weil sich eine Datei geändert hat, zu behaupten, er sei fertig. Der einzige gültige Beweis für Richtigkeit ist ein Testsuite, der tatsächlich erneut ausgeführt wurde – nicht die eigene Aussage des Agents.

Der Orchestrator als Verkehrslenker

Zuerst scheint es verlockend, die Jobs in einer geraden Linie anzuordnen:

Bus::chain([
    new BuildFeature($task),
    new RunTests($task),
    new ReviewFeature($task),
])->dispatch();

Aber das ist nur eine Linie. Sobald ein Zweig entsteht, zum Beispiel beim Zurückkehren zur Behebung eines Fehlers bei einem Test, reicht eine lineare Kette nicht aus. Was benötigt wird, ähnelt einem Verkehrsleiter, der bei jeder Aufrufung den aktuellen Status überprüft und von dort aus die nächste Aktion wählt:

class AgentOrchestrator
{
    public function next(AiTask $task): void
    {
        match ($task->status) {
            'pending'   => BuildFeature::dispatch($task),
            'testing'   => RunTests::dispatch($task),
            'failed'    => AnalyzeFailure::dispatch($task),
            'fixing'    => RunTests::dispatch($task),
            'reviewing' => ReviewFeature::dispatch($task),
            'completed', 'stopped' => null,
            default => throw new LogicException("Unknown status: {$task->status}"),
        };
    }
}

Der Wandel in der Denkweise ist bedeutend. Der Orchesterer fragt nicht mehr, welche Aufgabe als Nächstes ausgeführt werden soll. Stattdessen wird gefragt, welche Übertragung angesichts des aktuellen Status gültig ist. Dadurch lässt sich leichter debuggen, und ein neuer Schritt wie eine Sicherheitsüberprüfung kann hinzugefügt werden, ohne den Ablauf zu stören.

Maximalanzahl der Wiederholungen begrenzen

Ohne Limit kann sich ein solches Szenario entwickeln:

Fix → Test fails → Fix → Test fails → Fix → Test fails → ...

Das verschwendet Zeit, und jeder AI-Aufruf hat auch Kosten. Die Lösung ist eine Obergrenze:

class RunTests implements ShouldQueue
{
    protected const MAX_ITERATIONS = 5;

    public function handle(): void
    {
        if ($this->task->iteration >= self::MAX_ITERATIONS) {
            $this->task->update(['status' => 'needs_human_review']);
            return;
        }
        // ... run tests as usual
    }
}

Falls fünf Korrekturvorschläge nicht ausreichen, stoppt das System und markiert die Aufgabe für einen Menschen, anstatt endlos weiterzuprobieren. Das bedeutet nicht unbedingt, dass die KI bei dieser Aufgabe schlecht ist. Manchmal sind die Anforderungen unklar, oder die Entscheidung erfordert tatsächlich einen Menschen.

Grüne Tests bedeuten noch keine fertige Funktion

Man vergisst das leicht, sobald das selbstständig arbeitende System faszinierend erscheint. Angenommen, der Agent schreibt etwas wie:

public function assign(User $user, Task $task): bool
{
    return $user->isAdmin();
}

Die Tests könnten alle bestehen, weil sie nur die Szenarien abdecken, die zu dem Zeitpunkt jemand sich vorgestellt hat. Die tatsächliche Anforderung besagte, dass der Benutzer ein Projektmitglied sein muss – nicht unbedingt ein Administrator. Die Logik ist falsch, obwohl alle Tests als erfolgreich angezeigt werden.

Deshalb ist dieser Ablauf unsicher:

Build → Tests pass → Deploy immediately

Die sicherere Variante sieht so aus:

Build → Test → (if failed: Debug → Fix → Test again) → Human review → Deploy

Die Überprüfungsphase sollte mindestens von einer Person durchgeführt werden, insbesondere bei allen Aspekten, die mit den Zugriffsrechten zusammenhängen. Bei sicherheitskritischen Änderungen wie dieser ist es sinnvoll, eine menschliche Überprüfung vor dem Zusammenführen der Änderungen zu verlangen, egal wie sauber der automatisierte Prozess auch erscheinen mag.

Parallel laufende Agenten und Dateikonflikte

Der Gedanke, einen Sicherheitsagenten und einen Forschungsagenten gleichzeitig auszuführen, birgt ein Problem. Wenn zwei Agenten etwa zur gleichen Zeit auf dieselbe Datei schreiben können, entsteht ein Wettlaufzustand, wodurch zwei Prozesse die Arbeit des anderen überschreiben.

Agent A → writes Task.php
Agent B → reads Task.php (nearly at the same time)
Agent A → writes Task.php again

Die geltende Regel ist es, die Verantwortlichkeiten danach zu verteilen, wer schreiben darf und wer nur lesen darf:

Research Agent   → read-only
Review Agent     → read-only
Security Agent   → read-only
Build Agent      → write access
Fix Agent        → write access

Das erklärt auch die Zeile tools.write: true im früheren builder.md. Sie bestimmt, welche Agenten Dateien ändern dürfen und welche nur darauf schauen können.

Gegen den Super-Agent vorgehen

Die größte Verlockung, sobald das funktioniert, ist ein einziger Agent, der planen, erstellen, testen, debuggen, beheben, überprüfen und bereitstellen kann. Das neigt dazu, ins Gegenteil umzuschlagen. Je mehr Verantwortung ein Agent trägt, desto mehr Informationen muss er verarbeiten, desto mehr Tools besitzt er – und desto wahrscheinlicher ist es, dass er irgendwo einen Fehler macht. Eine Aufteilung nach Verantwortungsbereichen funktioniert besser:

Planner   → designs the approach
Builder   → writes the new feature's code
Tester    → runs the test suite
Debugger  → diagnoses failures (read-only)
Fixer     → executes the fix
Reviewer  → final quality check (read-only)

Das ist dasselbe Prinzip wie das Vermeiden einer einzigen riesigen Klasse, die in einer Anwendung alles handhabt. Erstellen Sie auch keinen einzigen Agenten, der alles erledigt.

Eine minimale Checkliste vor dem eigentlichen Einsatz

Für Experimente in einem echten Projekt sollten diese bereits ab dem ersten Tag vorhanden sein und nicht später hinzugefügt werden:

• eine Obergrenze für Wiederholungsversuche, damit der Korrekturlauf nicht ewig andauert
• eine Zeitbeschränkung für jeden Befehl, den ein Agent ausführt
• Lese- oder Schreibbeschränkungen für Dateizugriffe, die zur Rolle des Agents passen
• Tests, die vorhanden und bestanden sein müssen, bevor der Status auf „Überprüfung“ geändert werden kann
• menschliche Freigabe, bevor etwas in die Produktion gelangt
• Protokollierung jeder Entscheidung, die der Agent trifft – nicht nur des endgültigen Ergebnisses
• Schutz für geheime Dateien wie .env, damit ein Agent sie nicht versehentlich liest

Der letzte Punkt wird oft unterschätzt. Sobald ein Agent über die oben genannten Process::run()-Aufrufe Befehle im System ausführen kann, kann er praktisch alles auf diesem Server ausführen. Zugriffsbeschränkungen sind von Anfang an erforderlich, keine Option.

Die tatsächliche Rolle von Boost

Hier ist das vollständige Bild:

Developer (us)
    │
    ▼
Orchestrator (traffic controller, running on Laravel Queue)
    │
    ├── Build Agent
    ├── Test Agent
    ├── Debug Agent
    └── Fix Agent
          │
          ▼
      OpenCode (where the agent does its work)
          │
          ▼
    Laravel Boost (context translator, via MCP)
          │
          ▼
    Our Laravel application

Boost entscheidet niemals selbst, ob Tests ausgeführt oder der Fix-Agent bei Fehlern aktiviert werden soll. Es erledigt eine wichtige Aufgabe: Es stellt sicher, dass jeder Agent im Projekt den tatsächlichen Zustand der Anwendung versteht und nicht aufgrund allgemeiner Muster ratet. Die Fragen, wer wann handelt und wann alles zum Stillstand kommt, bleiben beim auf Laravel Queue basierenden Orchestrator.

Die Frage, die jetzt gestellt werden muss

Vor einigen Jahren lautete die interessante Frage, ob KI korrekten Laravel-Code schreiben kann. Das kann sie eindeutig – und wird ständig besser. Die wichtigere Frage heute ist, ob KI ihren eigenen Feedback-Zyklus aus Erstellen, Testen, Scheitern, Verstehen des Grundes, Beheben und erneutem Testen durchlaufen kann, bis die Aufgabe tatsächlich abgeschlossen ist – ohne dass ein Mensch bei jedem Schritt als manueller Vermittler eingreift.

Das TaskFlow-Szenario legt nahe, dass die Antwort ja lautet, sofern drei Dinge nicht vergessen werden. Der Fortschritt benötigt eine klare Dokumentation, Wiederholungsversuche müssen einer festen Obergrenze unterliegen, und grüne Tests sollten als ein Signal gelten, nicht als Ziellinie.

Boost hilft den Agenten, den Kontext der Anwendung zu verstehen. OpenCode bietet ihnen einen Arbeitsraum. Laravel Queue wird zur Grundlage, die alles sequenziert. Zudem können Entwickler auf eine höhere Ebene aufsteigen – von manuellen Operatoren bei jedem Schritt zu Überprüfern des Endresultats.

Vibe-Coding beschleunigt das Schreiben. Eine solche Orchestrierung ermöglicht es dem Programmierprozess, sich selbst abzuspielen – und genau da werden KI-basierte Programmierexperimente interessant.