Technische Due Diligence: Code-Audits mit Claude bei M&A-Prozessen

1. Warum technische Due Diligence über den Deal-Wert mitentscheidet

Bei M&A-Prozessen im Softwareumfeld ist die Codebasis oft der wertvollste, aber am schwersten zu bewertende Vermögensgegenstand. Ein Investor oder Käufer will wissen, ob das Produkt auf einem soliden technischen Fundament steht oder ob hinter einer funktionierenden Oberfläche massive technische Schulden, veraltete Abhängigkeiten und ungetestete Kernmodule liegen, die nach dem Deal teure Nacharbeit erfordern.

Die Herausforderung ist der Zeitdruck: Ein typisches Due-Diligence-Fenster umfasst wenige Tage bis wenige Wochen, in denen ein externes Audit-Team eine Codebasis bewerten soll, die über Jahre gewachsen ist und oft mehrere hunderttausend Zeilen umfasst. Vollständige manuelle Durchsicht ist in diesem Zeitrahmen schlicht nicht realistisch, weshalb strukturierte, werkzeuggestützte Verfahren an Bedeutung gewinnen.

2. Was sich mit Claude systematisch prüfen lässt

Für ein technisches Audit lässt sich Claude entlang klar abgegrenzter Dimensionen einsetzen: Architekturqualität und Modulgrenzen, Testabdeckung und Testqualität, Abhängigkeitsalter und bekannte Sicherheitslücken in verwendeten Paketen, Code-Duplikation, sowie die Konsistenz von Namenskonventionen und Fehlerbehandlung über das gesamte Repository hinweg. Jede Dimension lässt sich als eigener, wiederholbarer Prompt-Durchlauf über repräsentative Teile der Codebasis strukturieren.

Wichtig ist, Claude nicht pauschal nach Qualität zu fragen, sondern konkrete, überprüfbare Fragen zu stellen: Wie viele der zentralen Geschäftslogik-Module haben keine Tests? Welche Abhängigkeiten sind seit mehr als zwei Jahren nicht aktualisiert worden? Welche Muster deuten auf einen einzelnen kritischen Entwickler hin, dessen Wissen nirgends dokumentiert ist? Solche konkreten Fragen liefern belastbarere, vergleichbarere Ergebnisse als eine offene Qualitätsbewertung.

3. Ein strukturierter Prompt für die erste Bestandsaufnahme

Der erste Schritt eines Audits ist eine strukturierte Bestandsaufnahme, die als Grundlage für alle weiteren Vertiefungen dient. Ein guter Prompt fragt nicht nach einer subjektiven Einschätzung, sondern nach zählbaren, nachvollziehbaren Fakten, die sich später im Report belegen lassen.

# Claude Code: strukturierte Erstbestandsaufnahme für ein Due-Diligence-Audit
claude "Erstelle eine technische Bestandsaufnahme dieses Repositories:
1. Architekturüberblick: Hauptmodule, Abhängigkeiten zwischen Modulen,
   erkennbare Schichtentrennung.
2. Testabdeckung: Anteil der Kernmodule mit vorhandenen Tests,
   Testqualität stichprobenartig bewerten.
3. Abhängigkeiten: Anzahl veralteter Pakete (älter als 24 Monate),
   bekannte CVEs in package-lock/composer.lock.
4. Technische Schulden: TODO/FIXME-Dichte, auffällig große
   Dateien/Funktionen, Duplikationsmuster.
Gib das Ergebnis als Tabelle mit Kategorie, Befund, Belegstelle und
Risikoeinstufung aus."

4. Technische Schulden für Nicht-Techniker quantifizierbar machen

Ein Investoren-Report richtet sich selten an technisches Fachpublikum. Ein Befund wie hohe zyklomatische Komplexität in Modul X ist für eine Investmentkommission wenig aussagekräftig. Claude lässt sich anweisen, technische Befunde in geschäftlich relevante Aussagen zu übersetzen, etwa in eine geschätzte Aufwandsklasse für die Behebung oder in eine Einordnung, welches Risiko ein Befund für die geplante Skalierung des Produkts darstellt.

Bewährt hat sich eine dreistufige Einordnung: technischer Befund, geschäftliche Auswirkung, geschätzter Behebungsaufwand in Personentagen als grobe Größenordnung. Diese Übersetzung erleichtert es einer Investmentkommission, technische Risiken im Verhältnis zum Kaufpreis oder zur geplanten Investitionssumme einzuordnen, ohne dass jedes Kommissionsmitglied selbst Code lesen muss.

5. Sicherheitsrisiken systematisch in den Audit-Report einordnen

Neben Codequalität gehört eine Einschätzung der Sicherheitslage zu jedem seriösen technischen Audit. Claude kann, kombiniert mit den Ergebnissen klassischer Abhängigkeits-Scanner, eine priorisierte Liste erstellen, die zwischen theoretisch vorhandenen Schwachstellen in ungenutztem Code und tatsächlich erreichbaren, produktionsrelevanten Risiken unterscheidet, was für die Bewertung des tatsächlichen Risikos entscheidend ist.

Ebenso relevant für einen Investoren-Report ist die Frage, wie Zugangsdaten, API-Schlüssel und Secrets im Repository und in der Deployment-Konfiguration gehandhabt werden. Ein Befund wie Datenbank-Zugangsdaten liegen im Klartext im Repository-Verlauf, auch wenn sie inzwischen entfernt wurden, gehört in den Report, weil er auf notwendige Rotationsmaßnahmen nach einem Eigentümerwechsel hinweist.

6. Zeitersparnis gegenüber einer rein manuellen Auditierung

Der praktische Nutzen zeigt sich vor allem in der ersten Sichtungsphase: Statt dass ein Auditor-Team Tage damit verbringt, sich überhaupt einen Überblick über Modulgrenzen und Abhängigkeiten zu verschaffen, liefert ein Claude-gestützter erster Durchlauf innerhalb weniger Stunden eine strukturierte Landkarte, auf deren Basis die menschlichen Experten gezielt die kritischsten Bereiche vertiefen können, statt die Codebasis blind zu durchsuchen.

In der Praxis verschiebt sich dadurch der Zeitaufwand von der Erstsichtung hin zur Verifikation und vertieften Bewertung der wichtigsten Befunde. Das Auditteam verbringt seine begrenzte Zeit dort, wo menschliches Urteilsvermögen am meisten zählt, etwa bei der Einschätzung von Architekturentscheidungen im Geschäftskontext, statt sie mit dem reinen Auffinden von Fundstellen zu verbrauchen.

7. Grenzen bei sehr großen Legacy-Codebasen

Bei Codebasen im Bereich mehrerer Millionen Zeilen, häufig gewachsen über Jahrzehnte mit mehreren technologischen Generationen, stößt auch ein Claude-gestütztes Audit an das verfügbare Kontextfenster und an die Grenze dessen, was in der verfügbaren Zeit überhaupt eingelesen werden kann. Hier hilft nur eine gezielte Stichprobenstrategie, bei der repräsentative, geschäftskritische Module ausgewählt und vertieft geprüft werden, statt jede Zeile abdecken zu wollen.

Auch historisches Kontextwissen, warum eine bestimmte, heute merkwürdig wirkende Entscheidung damals getroffen wurde, ist in reinem Code selten vollständig erhalten. Ein seriöser Report macht deshalb transparent, welche Teile der Codebasis tatsächlich vertieft geprüft wurden und welche nur stichprobenartig, damit die Investmentkommission die Aussagekraft des Reports realistisch einschätzen kann, statt eine falsche Vollständigkeit anzunehmen.

8. Einordnung im Gesamtprozess: Ergänzung, nicht Ersatz des Auditteams

Ein Claude-gestütztes Audit ersetzt kein erfahrenes technisches Auditteam, das den geschäftlichen Kontext, die Marktsituation und die strategischen Pläne des Käufers kennt. Die eigentliche Bewertung, ob ein gefundenes Risiko den Deal gefährdet oder nur eine Randnotiz im Report verdient, erfordert Erfahrung und Urteilsvermögen, das über die reine technische Analyse hinausgeht.

Sinnvoll eingesetzt ist Claude deshalb ein Beschleuniger für die Auditoren selbst: Es liefert die strukturierte erste Landkarte und die quantifizierten Befunde, auf deren Basis erfahrene Fachleute ihre begrenzte Zeit gezielt auf die Bewertung und Priorisierung konzentrieren können, statt einen relevanten Teil davon mit reiner Fundstellensuche zu verbringen.

9. Checkliste für einen belastbaren Audit-Report

Ein belastbarer technischer Due-Diligence-Report sollte mindestens folgende Elemente enthalten: eine Architekturübersicht mit erkennbaren Schichten und Modulgrenzen, eine quantifizierte Einschätzung der Testabdeckung, eine priorisierte Liste sicherheitsrelevanter Befunde mit Erreichbarkeitseinschätzung, eine Übersetzung technischer Schulden in geschätzte Behebungsaufwände, und eine transparente Angabe, welche Bereiche vertieft und welche nur stichprobenartig geprüft wurden.

Wird dieser Rahmen konsequent mit Claude als Beschleuniger für Bestandsaufnahme und Übersetzung technischer Befunde in geschäftliche Sprache kombiniert, verkürzt sich die Zeit bis zu einem belastbaren Investoren-Report spürbar, ohne dass die fachliche Bewertung selbst an eine Maschine delegiert wird. Genau diese Kombination aus Geschwindigkeit und menschlicher Einordnung macht den Ansatz für M&A-Prozesse praktisch wertvoll.

10. Zusammenfassung

11. FAQ: Technische Due Diligence mit Claude: Das Wichtigste auf einen Blick