Laravel-Projekt übernehmen: LLMs, Tests & Xdebug

Ein fremdes Laravel-Projekt lässt sich nicht seriös anhand einiger Controller und einer grünen Startseite bewerten. Für einen Teamlead ist zuerst wichtig, ob das System zuverlässig geändert und betrieben werden kann. Die technische Übernahme beginnt deshalb mit dem Weg einer Änderung durch das gesamte System: vom Ticket über Code und Daten bis zu Deployment, Monitoring und Support.

Das erste Ergebnis einer Übernahme ist kein großer Umbau. Es ist ein belastbares Bild davon, wo Änderungen sicher möglich sind und wo noch Unsicherheit besteht.

Vor dem Code kommt der geschäftliche Kontext

Eine Codebasis erklärt nicht, welche Abläufe Umsatz erzeugen, welche Fristen kritisch sind oder welche Daten besonders geschützt werden müssen. Ein kurzer Termin mit Produktverantwortlichen, Entwicklung und Betrieb liefert meist mehr als ein Tag ungerichtetes Lesen.

Diese Fragen gehören an den Anfang:

Welche drei Abläufe dürfen unter keinen Umständen ausfallen?
Wo entstehen aktuell Fehler, Wartezeiten oder manueller Aufwand?
Welche Releases, Verträge oder Compliance-Termine stehen bevor?
Wer entscheidet fachlich, wer deployt und wer reagiert auf Störungen?
Welche Bereiche sollen ausdrücklich nicht verändert werden?

Damit bekommt die technische Analyse eine Reihenfolge. Ein langsamer interner Export ist anders zu bewerten als eine fehlerhafte Berechtigungsprüfung im Kundenportal.

Einen vertikalen Pfad verfolgen

Statt wahllos Verzeichnisse zu lesen, verfolge ich einen wichtigen Anwendungsfall durch alle Schichten. Bei einer Bestellung oder Freigabe betrifft das Route, Middleware, Request-Validierung, Policy, Domain-Logik, Datenbanktransaktion, Events, Queue-Jobs und Benachrichtigungen. Danach wird geprüft, wie der Ablauf getestet, protokolliert und deployt wird.

Dieser vertikale Schnitt zeigt schnell:

wo fachliche Regeln tatsächlich liegen,
ob Berechtigungen nur in der Oberfläche oder auch serverseitig gelten,
ob Seiteneffekte wiederholbar und fehlertolerant sind,
welche Datenbankannahmen bestehen,
ob Fehler im Betrieb sichtbar werden.

Laravel-Konventionen helfen bei der Orientierung, ersetzen diese Prüfung aber nicht. Zwei Anwendungen mit derselben Framework-Version können bei Zuständigkeiten und Betriebsrisiko völlig unterschiedlich sein.

LLMs als kontrollierten Beschleuniger einsetzen

Bei einer modernen Projektübernahme würde ich auf LLMs nicht verzichten, sofern Auftrag, Datenschutz und Vertraulichkeit ihren Einsatz erlauben. Modelle mit großem Kontext können je nach Umfang weite Teile oder sogar die gesamte Codebasis gemeinsam auswerten. Sie finden Querverbindungen schneller, als ein Entwickler sie Datei für Datei zusammensuchen könnte. Das ist besonders hilfreich bei gewachsenen Projekten mit wenig Dokumentation.

Ein Modell kann in der ersten Analyse unter anderem:

Routen, Middleware, Policies, Models, Events, Listener, Jobs und Commands zu einer vorläufigen Systemkarte verbinden,
Datenwege von einem Request bis zur Datenbank, Queue oder externen API verfolgen,
implizite Annahmen und widersprüchliche Implementierungen markieren,
die vorhandene Docker-, Sail- oder lokale Entwicklungsumgebung analysieren und fehlende Schritte dokumentieren,
Kandidaten für Characterization Tests sowie positive und negative Feature-Tests vorschlagen,
relevante Stellen für eine Änderung finden und die mögliche Auswirkung auf angrenzende Abläufe erklären.

Das Wort vorläufig ist entscheidend. Ein plausibel formulierter Zusammenhang ist noch kein bewiesener Zusammenhang. LLM-Ausgaben sind Hypothesen, bis Route, Konfiguration, Test oder Laufzeitbeobachtung sie bestätigen.

Vor der Analyse steht die Datenfreigabe

Ein Repository kann Zugangsdaten, Kundennamen, Produktionsbeispiele, interne Geschäftslogik oder noch nicht veröffentlichte Schwachstellen enthalten. Deshalb wird vor dem ersten Prompt festgelegt, welche Verarbeitung zulässig ist.

Datenlage	Sinnvoller Modellbetrieb	Zusätzliche Kontrolle
Repository ausdrücklich für externen Dienst freigegeben	leistungsfähiges Frontier-Modell mit Repository-Kontext	Anbieter, Speicherung, Training und Aufbewahrung vertraglich prüfen
vertraulicher Quellcode oder sensible Projektdaten	lokales Modell in kontrollierter Infrastruktur	Netzwerkzugriffe, Logs und Modellartefakte begrenzen
gemischte Datenklassen	lokaler Gesamtüberblick, extern nur bereinigte Ausschnitte	Geheimnisse und Kundendaten technisch entfernen, nicht nur im Prompt verbieten
Freigabe ungeklärt	keine Übergabe des Codes an ein Modell	zuerst Verantwortliche und Regeln klären

Für sensible Projekte kann die Analyse vollständig lokal erfolgen. Für freigegebene Repositories kann ein Frontier-Modell mehr Geschwindigkeit oder Analysequalität liefern. Die Entscheidung richtet sich nach der Datenklasse, nicht nach persönlicher Vorliebe. Der ausführliche Vergleich steht im Beitrag Lokale LLMs oder Frontier-Modelle.

Gute Prompts beginnen mit einer fachlichen Invariante

„Schreibe Tests für diesen Controller“ erzeugt häufig Tests, die lediglich die aktuelle Implementierung nacherzählen. Besser ist ein Auftrag, der das erlaubte und verbotene Verhalten nennt und Unsicherheit sichtbar lässt:

Ziel: Den Freigabeprozess für Rechnungen als Characterization Test absichern.

Fachliche Invarianten:
- Nur Benutzer des richtigen Mandanten dürfen eine Rechnung sehen.
- Nur die Rolle finance_lead darf freigeben.
- Eine bereits freigegebene Rechnung darf keinen zweiten Buchungsjob erzeugen.

Erstelle Pest Feature-Tests für Erfolgsfall, fremden Mandanten,
fehlende Rolle und wiederholte Anfrage. Ändere keinen Produktionscode.
Liste jede Annahme und verweise auf die Datei, aus der sie stammt.

Der Entwickler prüft anschließend, ob Fixtures, Assertions und erwartete Statuscodes die Fachregel tatsächlich abbilden. Ein neuer Test wird mindestens einmal gezielt zum Scheitern gebracht. Erst dann ist sichtbar, dass er auf die gewünschte Abweichung reagiert und nicht nur zufällig grün ist.

Auch die Entwicklungsumgebung lässt sich schneller erschließen

Das Modell kann composer.json, Lockfile, .env.example, Dockerfiles, Sail-Konfiguration, Queue-Treiber, Scheduler und Build-Skripte gemeinsam lesen. Daraus entsteht eine Setup-Checkliste mit benötigten Diensten, Ports, Daten und Startbefehlen. Verlässlich ist sie erst nach einem sauberen Start ohne lokale Altlasten:

Repository in ein frisches Verzeichnis auschecken.
Abhängigkeiten aus dem Lockfile installieren.
Services mit dokumentierten Befehlen starten.
Migrationen, Seed-Daten, Tests, Worker und Scheduler ausführen.
jeden manuellen Zwischenschritt in das Setup zurückführen.

So beschleunigt das LLM die Suche. Die reproduzierbare Umgebung liefert den Beweis.

Betrieb und Lieferweg nachvollziehen

Ein lokaler Testlauf beweist nicht, dass die Anwendung sicher ausgeliefert werden kann. Zur Übernahme gehören deshalb auch Infrastruktur und Lieferprozess.

Bereich	Zu klärende Frage	Erster Nachweis
Deployment	Ist der Ablauf reproduzierbar?	dokumentierter oder automatisierter Lauf
Datenbank	Sind Migrationen rückwärtsverträglich?	Prüfung der letzten produktiven Änderungen
Queues	Was passiert bei Wiederholung?	Idempotenz und Fehlerbehandlung
Scheduler	Welche Jobs sind zeitkritisch?	Liste, Laufzeit und Alarmierung
Dateien	Wo liegen Uploads und Backups?	Speicher- und Wiederherstellungstest
Monitoring	Werden Nutzerfehler sichtbar?	Logs, Metriken und Alarmwege

Auch Abhängigkeiten verdienen Aufmerksamkeit. Veraltete Pakete sind nicht automatisch eine akute Schwachstelle. Ungepflegte Kernbibliotheken, blockierte PHP-Versionen oder Pakete mit weitreichenden Rechten können jedoch den nächsten Release bestimmen.

Tests nach Risiko auswählen

Eine niedrige Testabdeckung sagt wenig, wenn die kritischen Abläufe gut geschützt sind. Eine hohe Prozentzahl hilft ebenfalls wenig, wenn nur Getter und einfache Erfolgsfälle geprüft werden. Zuerst entstehen Tests für die teuersten Fehlerbilder:

unberechtigter Zugriff auf fremde Objekte oder Mandanten,
doppelte Verarbeitung eines Jobs oder Webhooks,
falscher Statuswechsel in einem Geschäftsprozess,
Teilfehler während einer Zahlung oder externen Integration,
Datenverlust bei Migration oder Import.

Negative Tests sind besonders wertvoll. Sie belegen nicht nur, dass ein erlaubter Ablauf funktioniert, sondern auch, dass eine verbotene Aktion tatsächlich abgewiesen wird.

Wenn statisches Lesen nicht reicht: Xdebug und Laufzeitdaten

Bei komplexen Projekten ist der tatsächliche Laufzeitpfad oft wichtiger als die vermutete Architektur. Container-Bindings, dynamische Events, Observer, globale Scopes, Magic Methods und verzweigte Jobs können einen Datenfluss verändern, ohne dass dies an einer einzelnen Datei erkennbar wäre.

Dann ergänze ich die LLM-gestützte Codeanalyse gezielt:

Xdebug Step Debugging verfolgt den Kontrollfluss mit Breakpoints und zeigt konkrete Variablen und Datenstrukturen.
Xdebug Function Traces protokollieren die real ausgeführten Funktionsaufrufe. Das hilft besonders beim Einstieg in eine unbekannte Anwendung.
Xdebug Profiling beantwortet Performancefragen mit gemessenen Laufzeitkosten statt mit Vermutungen.
Laravel Telescope kann lokal Requests, Exceptions, Queries, Jobs, Events, Gate-Entscheidungen und weitere Framework-Aktivitäten zusammenführen.

Xdebug und umfangreiche Beobachtung werden gezielt in einer lokalen oder isolierten Entwicklungsumgebung aktiviert. Traces, Dumps und Telescope-Einträge können Tokens, personenbezogene Daten und Geschäftsobjekte enthalten. Sie gehören weder unkontrolliert in die Produktion noch ungeprüft in einen externen Modellkontext.

Jede Erkenntnis bekommt einen Nachweis

Aussage aus der Analyse	Geeigneter Nachweis
„Diese Policy schützt den Export“	Request als erlaubter und fremder Benutzer, plus negativer Feature-Test
„Der Job ist bei Wiederholung sicher“	denselben Payload zweimal ausführen und Seiteneffekte vergleichen
„Dieser Listener schreibt den Status“	Breakpoint oder Function Trace entlang eines realistischen Ablaufs
„Diese Query ist der Engpass“	Query-Messung und Profil vor und nach genau einer Änderung
„Das Projekt ist lokal reproduzierbar“	vollständiger Start aus einem frischen Checkout nach Dokumentation

Diese Kombination ist schneller als ausschließlich manuelles Lesen und belastbarer als ausschließlich generierter Code. Das LLM verdichtet die Codebasis, der Entwickler formuliert die fachliche Frage, und Tests sowie Laufzeitdaten entscheiden, ob die Erklärung stimmt.

Der erste Lieferumfang

Nach der Analyse sollte kein monatelanger Sanierungsplan ohne sichtbaren Nutzen entstehen. Ein guter erster Lieferumfang verbindet eine relevante Verbesserung mit gezielter Risikoreduktion. Das kann eine blockierte Funktion, ein Laravel-Upgrade für einen klaren Bereich oder die Stabilisierung eines fehleranfälligen Imports sein.

Der Umfang braucht:

ein fachlich prüfbares Ergebnis,
benannte Risiken und Annahmen,
passende automatisierte Tests,
einen Rollout- und Rückfallplan,
eine kurze Dokumentation der berührten Architektur.

So zeigt die erste Lieferung gleichzeitig, ob Zusammenarbeit, Review und Betrieb funktionieren.

Was ein Teamlead am Ende wissen sollte

Eine sinnvolle Übernahme beantwortet vier Fragen: Was ist geschäftskritisch? Wo liegen die größten technischen Risiken? Welcher Bereich kann als Erstes verantwortet werden? Welche Informationen fehlen noch? Erst danach ist eine belastbare Aussage zu Budget und Geschwindigkeit möglich.

Konkretes Ergebnis der ersten fünf Arbeitstage

Eine Übernahme sollte früh sichtbare Artefakte liefern. Dieser kompakte Satz reicht für die erste belastbare Entscheidung:

Artefakt	Inhalt	Entscheidung für den Teamlead
Systemkarte	Web, Worker, Scheduler, Datenbank, Speicher und externe Dienste	Welche Komponenten gehören wirklich zum Betrieb?
Risikoregister	Auswirkung, Wahrscheinlichkeit, Evidenz und nächster Prüfschritt	Was muss vor neuen Features geklärt werden?
Lieferweg	Build, Tests, Migration, Deployment, Smoke-Test und Rollback	Kann eine kleine Änderung sicher ausgeliefert werden?
vertikaler Test	ein geschäftskritischer Ablauf mit positivem und negativem Fall	Ist der wichtigste Pfad verstanden und reproduzierbar?
erster Lieferumfang	Ergebnis, Nicht-Ziele, Annahmen und Abnahmekriterien	Was kann das Team als Nächstes verbindlich beauftragen?

Offene Punkte erhalten Besitzer und Fälligkeitsdatum. Aussagen wie „wahrscheinlich unkritisch“ werden als Hypothese markiert, bis Log, Test oder Konfiguration sie belegt. So entsteht aus der Analyse ein steuerbares Übergabeprotokoll statt einer Sammlung technischer Eindrücke.

Wenn die Übernahme eine alte Laufzeit sichtbar macht, führt der nächste Schritt zum kontrollierten Laravel-Upgrade. Für die Sicherheitsaufnahme dient die Laravel-Security-Audit-Checkliste als eigenständiger Prüfpfad.

Quellen und Vertiefung

Fazit

Die beste Übernahme beginnt mit einem wichtigen realen Ablauf, nicht mit einer pauschalen Neustrukturierung. LLMs verkürzen die Zeit bis zu einer brauchbaren Systemkarte und zu relevanten Tests. Xdebug und beobachtbare Laufzeitdaten klären die Stellen, an denen statische Analyse nicht genügt. Wer diese Werkzeuge mit Geschäftsrisiko, reproduzierbaren Tests und menschlicher Prüfung verbindet, kann früh Verantwortung übernehmen und trotzdem offen benennen, was noch nicht bewiesen ist.