Sie haben eine Web-Anwendungs-Codebase übernommen — Laravel, Symfony, ein Node- oder Python-Service, womit das Team auch immer gebaut hat —, die das Team nicht mehr überblickt. Tests scheitern auf Weisen, die niemand nachverfolgen kann; dieselbe Operation hat vier Schreibweisen und vier Aufrufstellen. Ich lese das Repository, schreibe die Diagnose und gehe an die Tastatur, wenn Sie entscheiden, dass der Bericht allein nicht ausreicht.
CTOs und Lead-Developer mit einer Web-Anwendungs-Codebase — PHP/Laravel/Symfony, Python, eine JavaScript/TypeScript- oder Node-Schicht, oder die Nahtstellen, wo der LLM-Schaden quer darüber liegt —, in die das Team seit einem halben Jahr oder länger KI-unterstützte PRs landet, und die heute niemand im Team mehr als "leicht überschaubar" bezeichnen würde.
Greenfield-Rewrites. Reparaturen in einer einzelnen Datei. Repositories, in denen das Team zufrieden ist und nur schneller mehr will.
Halbtägige Triage. Schriftliche Diagnose, die Blutung priorisiert. Optional ein Folgeengagement für die eigentliche Reparatur, stündlich oder pro Projekt — Ihre Entscheidung, nachdem Sie die Diagnose gelesen haben.
Die Abdeckung lag bei 72%, heute bei 18%, und niemand im Team kann die PRs benennen, die es verursacht haben. Die CI-Schwellen wurden in diesem Quartal zweimal gesenkt, damit die Pipeline grün bleibt.
Controller jenseits von 1.500 Zeilen. Service-Klassen, die zweiundzwanzig Kollaboratoren importieren. Die Autorin oder der Autor ist nicht mehr im Unternehmen, und die ursprüngliche Absicht lässt sich aus git blame nicht mehr rekonstruieren.
getUser, fetch_user, Customer::find, UserRepository::byEmail. Vier Aufrufstellen, vier leicht unterschiedliche Rückgaben, ein Bugreport, den niemand reproduzieren kann.
Läuft lokal. Bricht im Staging auf Weisen, die sich mit jedem Deploy ändern. Das Team beschuldigt flaky Tests; die Tests sind korrekt. Race Conditions und n+1-Queries wurden leise eingeschleust, in PRs, die wie generiert lesen.
Dreißig Minuten, keine Rechnung, kein Pitch-Deck. Sie bringen das Repository mit oder eine Beschreibung davon; ich sage Ihnen, was ich sehe und was ich damit machen würde. Die Diagnose erfolgt zu einem festen Halbtagessatz, vor Arbeitsbeginn vereinbart. Reparaturarbeit ist stündlich oder pro Projekt, aus der Diagnose gescoped, nie offen.
Ein Code-Review gibt Ihnen eine Liste. Ein Bereinigungsprojekt schließt sie. Die Diagnose ist redigierter Fließtext, der dateiweise erklärt, was beschädigt ist und was die Reparatur kosten würde; das optionale Folgeengagement ist die Reparatur selbst. Das Diagnosedokument gehört Ihnen, unabhängig davon, ob Sie weitermachen.
Nein. Die Arbeit ist Web-Anwendungs-Bereinigung im Allgemeinen. Am schärfsten in PHP, Laravel, Symfony, JavaScript/TypeScript, Node und Python — den Stacks mit den meisten Stunden — und andere Codebases (ein Go-Service, ein Django- oder FastAPI-Backend, Ruby und so weiter) nehme ich von Fall zu Fall. Eine schwächere Diagnose ist schlechter als keine Diagnose, deshalb sage ich Ihnen im Triage-Gespräch, wenn eine Codebase außerhalb dessen liegt, wo ich Wert schaffen kann.
Ein fester Halbtagessatz, im Triage-Gespräch vor Arbeitsbeginn vereinbart. Das Triage-Gespräch selbst ist kostenlos und dauert dreißig Minuten. Keine Pflicht, nach dem Gespräch zur Diagnose zu gehen, und keine Pflicht, nach der Diagnose zur Reparatur zu gehen.
Ja. Eine gegenseitige NDA, bevor Code meinen Schreibtisch erreicht, ist Standard; ich unterschreibe Ihre oder schicke eine kurze von mir. Repository-Zugriff ist standardmäßig read-only, gescoped auf die Projektdauer.
Ein kurzes Formular. Kein Newsletter, keine Plattform, keine Follow-up-Sequenz. Ein Senior-Engineer liest, was Sie schicken, und antwortet innerhalb eines Werktags.