Am Dienstag habe ich eingeordnet, was aus Boston zu erwarten ist, gestützt auf die Amsterdam-Leitlinie "The clean stack for Artisans and agents". Jetzt liegt der offizielle Recap vor, veröffentlicht am 29. Juli direkt nach der Keynote. Zeit für einen kurzen Abgleich, was von der Erwartung bestätigt wurde und was neu dazukam.
Die Amsterdam-Linie wurde fortgeschrieben, nicht ersetzt
Die Einschätzung aus dem Dienstag-Artikel hat sich bestätigt: Boston war eine Vertiefung, keine Kehrtwende. Die drei KI-Bausteine AI SDK, Boost und MCP wurden nicht neu erfunden, sondern gezielt erweitert. Für DACH-Agenturen, die Laravel-Projekte neben Symfony einordnen müssen, ist das die wichtigste Nachricht: Wer die Amsterdam-Strategie bereits verstanden hat, muss sein mentales Modell nicht neu aufbauen.
Human-in-the-Loop für AI-Agenten
Der praktisch relevanteste Punkt für Agentur-Projekte: Das Laravel AI SDK bekommt eine HITL-API (Human-in-the-Loop). Bisher liefen Agenten, die mit dem AI SDK gebaut wurden, ohne Eingriffsmöglichkeit durch. Sobald ein Agent einen Tool-Call ausgeführt hat, war der Schritt getan. Die neue API erlaubt es, einzelne Agent-Aktionen abzufangen und eine Freigabe zu verlangen, bevor der Agent weiterläuft, mit den Optionen genehmigen, ablehnen oder modifizieren.
Kurz: Für Projekte, bei denen ein KI-Agent schreibend auf Kundendaten oder Produktivsysteme zugreift, ist das der fehlende Baustein zwischen Demo und produktivem Einsatz.
Boost lernt die eigenen Konventionen
Laravel Boost leitet jetzt die tatsächlichen Coding-Konventionen eines Projekts über eine eigene Skill ab und protokolliert seine Entscheidungen während der Arbeit. KI-Agenten, die über Boost im Code arbeiten, folgen damit den Mustern des jeweiligen Teams statt den Mustern eines durchschnittlichen Laravel-Projekts.
Das passt zur Beobachtung aus dem Laravel-Blogpost vom 24. Juli, der bereits vor der Konferenz andeutete, dass der nächste Fokus nicht mehr korrekter, sondern idiomatischer Code ist. Boston hat diese Richtung mit einer konkreten Funktion untermauert.
Symfony läuft jetzt auf Laravel Cloud
Ein Detail, das für mich als Symfony-Entwickler besonders auffällt: Laravel Cloud unterstützt inzwischen auch Symfony-Anwendungen, nicht nur Laravel-Apps. Deploy, Infrastrukturkosten und Betrieb laufen über dieselbe Plattform, unabhängig vom Framework darunter. Für Agenturen mit gemischtem Stack, die sowohl Laravel- als auch Symfony-Projekte betreuen, ist das ein Grund, Laravel Cloud noch einmal unabhängig von der eigenen Framework-Präferenz zu prüfen.
Laravel LSP: Editor-Unabhängigkeit
Die Laravel-VS-Code-Extension wurde als eigenständiges Language Server Protocol verallgemeinert. NeoVim, Zed und Sublime Text bekommen damit dieselbe Autocomplete- und Navigationsunterstützung für Routes, Views und Config, die VS-Code-Nutzer bereits hatten. Wer im Team unterschiedliche Editoren einsetzt, muss sich nicht mehr auf VS Code festlegen, um von der Laravel-Tooling-Qualität zu profitieren.
Was aus der NativePHP-Vorschau wurde
Der NativePHP-Track lief als Side-Event parallel zur Hauptbühne, wie in der Vorschau erwartet. Der offizielle Framework-Recap selbst nennt dazu keine neuen Details, was zur bereits am Dienstag formulierten Erwartungshaltung passt: Konferenz-Präsenz ist kein Signal für Produktionsreife. Wer NativePHP für ein Projekt in Betracht zieht, sollte weiterhin eigenständig prüfen, wie belastbar der aktuelle Stand ist.
Ein entspannter Ausklang
Für die kommende Woche gibt es aus diesem Recap keinen akuten Handlungsbedarf, eher Beobachtungspunkte für die eigene Roadmap. Ich wünsche ein gutes Wochenende.
Dennis Schwenker-Sanders ist PHP- und Symfony-Entwickler und ordnet technische Entwicklungen im PHP-Ökosystem regelmäßig für Agenturen und Entscheider im DACH-Raum ein.