Fremder Code, kein Plan: Eine Codebase übernehmen

Codebase übernehmen: Ende letzten Jahres bin ich mit drei Kolleg:innen bei Conciso in ein neues Projekt gestartet: die Übernahme eines umfangreichen Systems. Viele Dateien, viel Infrastruktur, viel Text, und niemand, der uns durch das Ganze führt. Um überhaupt Fuß zu fassen, war erst einmal Dokumentation wälzen angesagt.

Nach zwei Tagen war die Stimmung im Keller. Nicht, weil das System so komplex war (damit rechnet man), sondern weil wir gemerkt haben, dass wir dem, was wir lasen, nicht trauen konnten. Je tiefer wir gruben, desto mehr Ungereimtheiten fanden wir. Beschreibungen passten nicht zum Verhalten des Codes. Irgendwann war klar: Wir müssen alles selbst verifizieren.

Die Frage war nur: Wie verifiziert man eine komplette Codebase, wenn die Zeit drängt?

Was wir vorgefunden haben

Es ging um ein umfangreiches Drupal-System. Zur Größenordnung: rund 126.000 Zeilen Code, verteilt auf 36 Custom Module, etwa 265 Twig-Templates und über 1.300 YAML-Konfigurationsdateien. Dazu mehr als 850 Theme-Dateien. Kurz: viel zu verstehen, und das in einem Technologie-Stack, mit dem keiner von uns zuvor intensiv gearbeitet hatte.

Einen Wissenstransfer mit dem vorherigen Team gab es nicht. Alles, was wir hatten, war der Code selbst und die mitgelieferte Dokumentation. Ein echter Kaltstart. Die fehlenden Workflow-Dateien für den CI/CD-Prozess (Continuous Integration und Continuous Deployment) haben wir auch nach mehrfachem Nachfragen über unseren Kunden beim alten Team nicht bekommen.

Und dann die Dokumentation. Es gab reichlich davon, aber an mehreren Stellen war sie auf den ersten Blick erkennbar falsch oder veraltet. Genau das war das eigentliche Problem, weniger die einzelnen Fehler als ihre Folge: Wenn ein Teil offensichtlich nicht stimmt, wie viel traut man dem Rest noch zu? Ab diesem Punkt war jede Information nur noch eine Behauptung, bis wir sie am Code geprüft hatten. Bei einer Codebase dieser Größe ist das ein enormer Aufwand.

Der klassische Weg, und warum er hier nicht gereicht hätte

Wie geht man so eine Übernahme normalerweise an? Die Schritte sind bekannt: Code lesen, Git-History durchgehen, sich ein mentales Modell der Architektur erarbeiten, Stakeholder befragen. Bewährte Methoden, und sie funktionieren. Aber sie brauchen Zeit.

Das ist keine Ausnahmesituation, sondern der Normalfall. Schon in gut gepflegten Projekten verbringen Entwickler:innen mehr Zeit mit dem Verstehen und Pflegen bestehenden Codes (rund 35 %) als mit dem Schreiben von neuem (rund 32 %). Bei einer undokumentierten Codebase verschiebt sich dieses Verhältnis noch deutlich weiter Richtung Verstehen (Sonar / The New Stack, 2023). Solche Zahlen stammen übrigens aus der Zeit vor dem agentischen Coding: Sie beschreiben eine Welt, in der es Werkzeuge wie Claude Code noch gar nicht gab.

Wir haben zunächst aufgeteilt: einer nahm sich die Infrastruktur vor, einer die Build-Pipeline, einer das Frontend samt Theming, einer verschaffte sich einen Überblick über Drupal. Schnell war klar, dass wir bei diesen Mengen so nicht weit kommen. Zugang zu den Servern hatten wir zwar, aber wie kommt der Code dort hin? Welche Schritte überführen den vorgefundenen Code in die richtige Struktur? Solche Fragen zogen sich durch jeden Bereich.

Realistisch hätte diese reine Analysephase Wochen bis Monate gedauert. Nur sieht die Projektrealität selten so aus, dass man erst alles vollständig versteht und dann liefert. Wir brauchten einen Weg, der schneller zum Ziel führt, ohne an Gründlichkeit zu verlieren. Genau hier kam Claude Code ins Spiel.

Claude Code in der Analysephase

Unser Projektleiter hatte die Lage erkannt und uns, in Absprache mit dem Kunden, die Möglichkeit gegeben, Claude Code einzusetzen. Ehrlich gesagt waren wir skeptisch. Ausgerechnet ein Werkzeug, dem man ebenfalls nicht blind trauen kann, gegen ein Vertrauensproblem? Der Unterschied, der uns überzeugte: Was Claude Code behauptet, lässt sich in Sekunden am Code gegenprüfen. Bei der alten Dokumentation dauerte genau das Stunden. Nach ein paar Test-Analysen zum Vertrauensbeweis kam echte Geschwindigkeit in die forensische Arbeit.

Zur Einordnung gehört, dass wir damals früh dran waren: Wir haben mit Sonnet gearbeitet, Claude Code selbst war längst nicht so ausgereift wie heute, und auch wir waren im Umgang mit dem Werkzeug noch unerfahren. Dass es trotz dieser Umstände getragen hat, macht die Sache im Rückblick eher bemerkenswerter. Mit den heutigen Modellen und Workflows würde vieles davon noch deutlich glatter laufen.

Dokumentation verifizieren und neu aufbauen

Unser dringlichstes Problem war die unzuverlässige Doku. Wir haben Claude Code die Setup- und Deployment-Anleitungen gegen den tatsächlichen Code prüfen lassen und so Schritt für Schritt getrennt, was noch passte und was veraltet oder schlicht falsch war. Parallel haben wir eine Übersicht über die Gesamtarchitektur erstellen lassen: wie die Komponenten zusammenhängen, welche Datenflüsse es gibt, welche externen Services angebunden sind.

Die Ergebnisse haben wir nicht übernommen, sondern als Entwurf behandelt, manuell geprüft und überarbeitet. Das war immer noch deutlich schneller, als bei null anzufangen. So entstand nach und nach eine am Code verifizierte Dokumentation, die es vorher nicht gab.

Fehlende Teile rekonstruieren

Die GitHub-Workflow-Dateien fehlten komplett. Ohne sie gab es keinen definierten CI/CD-Prozess, also keinen automatisierten Weg, den Code zu bauen, zu testen und auszuliefern. Wir haben Claude Code die Projektstruktur analysieren lassen. Aus den verwendeten Technologien und den bruchstückhaft vorhandenen Skript-Dateien konnte Claude Code ableiten, was in welcher Reihenfolge und in welchen Verzeichnissen passieren muss. Daraus entstanden Workflow-Dateien, die wir als Ausgangsbasis genutzt und verfeinert haben. Ohne diesen Startpunkt hätten wir den Build-Prozess durch Ausprobieren rekonstruieren müssen: Tage statt Stunden.

Die Codebase gezielt befragen

Eine große Codebase manuell nach Mustern, Abhängigkeiten oder Schwachstellen zu durchforsten, ist zeitintensiv und fehleranfällig. Fragen wie „Welche Module kommunizieren mit externen APIs?“ oder „Wie ist die Routing-Logik aufgebaut?“ hätten uns Stunden gekostet. Claude Code lieferte in Sekunden strukturierte Übersichten, nicht als Endergebnis, aber als Landkarte für die weitere Arbeit.

Was Claude Code nicht konnte

Kein Werkzeug ist perfekt, und das zu verschweigen wäre unehrlich.

Die technische Einschränkung war anfangs die Kontextgröße. Mit einer Pro-Lizenz stießen wir mitten in Analysen an Grenzen; der Wechsel auf Max hat das entschärft. Das ist die harmlose Sorte Problem: Man merkt es sofort und kann es lösen.

Die unangenehmere Sorte war inhaltlich. Claude Code hat sich gelegentlich widersprochen oder schlicht Falsches geliefert. In einer Analyse war eine Abhängigkeit vorhanden, bei einer späteren Nachfrage plötzlich nicht mehr. Solche Widersprüche sind tückisch, weil sie plausibel klingen. Und sie sind der Grund, warum uns keine Lizenz die eigentliche Arbeit abgenommen hat: Jede Aussage mussten wir weiterhin am Code verankern. Damit sind wir genau dort gelandet, wo wir mit der alten Dokumentation begonnen hatten, nur diesmal mit einem Werkzeug, das die Gegenprüfung selbst beschleunigt.

In der Branche ist inzwischen Konsens, dass man Ergebnisse künstlicher Intelligenz (KI) nicht blind übernimmt. Im Stack Overflow Developer Survey 2025 nutzen oder planen 84 % den Einsatz von KI-Tools. Aber nur etwa ein Drittel vertraut ihrer Genauigkeit, und 66 % verbringen mehr Zeit mit dem Korrigieren „fast richtiger“ KI-Ergebnisse (Stack Overflow Developer Survey, 2025). Dieses Korrigieren war bei uns kein Nebeneffekt, sondern die eigentliche Wertschöpfung.

Was am Ende dastand

Was nach einer wochenlangen Analysephase aussah, haben wir in Tagen bewältigt. Claude Code hat die Einarbeitung nicht überflüssig gemacht, aber es hat uns ermöglicht, die richtigen Fragen schneller zu stellen und schneller zu belastbaren Antworten zu kommen.

Am Ende hatten wir drei Dinge, die zu Beginn nicht existierten: eine am Code verifizierte Dokumentation der Gesamtarchitektur, funktionierende CI/CD-Workflows und ein gemeinsames Verständnis davon, wie das System aufgebaut ist. Das war die Grundlage, auf der wir tatsächlich arbeiten konnten. Für den Kunden hieß das: statt wochenlang auf erste Ergebnisse zu warten, deutlich früher produktiv am System.

Offen gesagt: Ohne Claude Code hätten wir das Projekt im gegebenen Zeitrahmen wahrscheinlich abgeben oder abbrechen müssen. So dramatisch war die Ausgangslage.

Und die Stimmung? Die hat sich irgendwo zwischen der ersten verifizierten Deployment-Anleitung und der ersten laufenden Pipeline gedreht. Claude Code ist seitdem fester Bestandteil unserer täglichen Arbeit geblieben, nicht nur in der Analyse, sondern im laufenden Projekt.

Was wir mitnehmen

KI ersetzt nicht das Denken, sie beschleunigt das Verstehen. Das läuft dem gängigen Reflex zuwider, KI mache uns bequem oder „dumm“. Unsere Erfahrung war das Gegenteil: Sie hat uns das Denken nicht abgenommen, sondern uns schneller an die Stellen gebracht, an denen sich Denken lohnt. Ohne fachliche Einordnung bleiben selbst gute Antworten nur Rohdaten.

Gute Dokumentation ist plötzlich fast kostenlos. Das ist rückblickend der eigentliche Bruch. Früher war Doku chronisch veraltet, weil ihre Pflege teuer war und deshalb liegen blieb. Heute entsteht sie als Nebenprodukt der Analyse: Aus den gestellten Fragen und geprüften Antworten wächst fast beiläufig eine neue, am Code verifizierte Dokumentation.

Prüfen bleibt Pflicht, aber es ist billiger geworden. Blind übernehmen ist nach wie vor keine Option, für KI-Ergebnisse so wenig wie für fremde Doku. Der Unterschied zu früher: Die Gegenprüfung am Code kostet Minuten statt Stunden. Genau das kippt die Rechnung.

Früh einsetzen. Im Rückblick klingt das banal. Damals war es das nicht: Wer erst nach Wochen manueller Analyse zur KI greift, verschenkt den größten Teil des Nutzens.