Erstelle API-Dokumentation aus deinem Codebase

API-Dokumentation ist immer falsch

Du kennst das Muster. Jemand schreibt API-Dokumentationen, wenn das Backend gestartet wird. Drei Sprints später haben sich zwei Endpunkte geändert, ein neuer Abfrageparameter existiert, und die Antwortstruktur für /tags hat ein zusätzliches geschachteltes Objekt, das niemand dokumentiert hat. Die Wiki-Seite sagt immer noch v1. Die Postman-Sammlung stammt aus dem Oktober. Das Frontend-Team reverse-engineert deine Controller, um herauszufinden, was die API tatsächlich zurückgibt.

Das ist kein Problem mit den Werkzeugen. Es ist ein Frischeproblem. Dokumentationen, die von Hand geschrieben werden, verfallen in dem Moment, in dem sich der Code ändert. Und kein Team hat die Disziplin, die Dokumentation jedes Mal zu aktualisieren, wenn sie einen Routen-Handler ändern oder ein Feld zu einem Interface hinzufügen. Das Ergebnis: Deine Frontend-Entwickler lesen direkt deinen Backend-Code, stellen Fragen in Slack oder — schlimmer — liefern Integrationen basierend auf Annahmen, die sich als falsch herausstellen.

Wie ein Entwickler ein NestJS-Backend in Minuten dokumentierte

Ein Entwickler musste verstehen, wie Labels und Kategorien von einem NestJS-Backend zu einer mobilen App fließen. Er fragte den Agenten: “Sag mir, wie wir Labels und Kategorien an das Frontend senden — welcher Controller, welche Route, welche Interfaces.” Der Agent klonierte das Backend-Repository, fand den TrendAgents-Controller, las die Definition des ITag-Interfaces und erstellte einen vollständigen API-Vertrag — Endpunkte, Parameter, Antworttypen und Datenfluss.

Keine manuelle Code-Lesung. Kein Durchsuchen von Dateien mit grep. Der Agent verfolgte den tatsächlichen Codepfad vom Controller über das Interface bis zur Antwortstruktur und dokumentierte jeden Schritt. Der Entwickler erhielt einen strukturierten Vertrag, der die Route, die HTTP-Methode, die erwarteten Parameter und das TypeScript-Interface definierte, das den Antwortkörper beschreibt. Alles basierend auf dem Quellcode, der in der Produktion läuft.

Von der Dokumentation zum GitHub-Problem in einem Gespräch

Der gleiche Entwickler sagte dann: “Bereite API-Verträge für die /tags-Route vor, die es uns ermöglichen, neue Logik im Frontend zu implementieren.” Der Agent generierte ein strukturiertes API-Vertragsdokument, und der Entwickler hängte es direkt an ein GitHub-Problem für das mobile Team an. Die Frontend-Entwickler mussten den Backend-Code nie lesen.

Das ist der Workflow, der API-Dokumentation nützlich macht. Der Vertrag geht in den Issue-Tracker, wo das implementierende Team tatsächlich arbeitet. Nicht eine Wiki-Seite, die sie niemals überprüfen werden. Nicht eine Slack-Nachricht, die wegscrollt. Ein GitHub-Problem mit dem genauen Endpunkt, den Parametern und den Antworttypen — bereit zur Implementierung. LikeClaws GitHub-Integration macht das zu einem einzigen Gespräch: Dokumente generieren, das Problem erstellen, das Team zuweisen.

Dokumentation von Endpunkten aus spezifischen Dateien

Ein anderer Entwickler holte sich spezifische Dateien aus einem privaten Repo — TrendAgents.controller.ts und model/ITag.ts — und bat den Agenten, das Verhalten des Endpunkts zu dokumentieren. Der Agent las den TypeScript-Code, verfolgte den Datenfluss von der Controller-Methode durch die Service-Schicht bis zur Interface-Definition und produzierte eine Dokumentation, die mit der tatsächlichen Implementierung übereinstimmte.

Dieser Ansatz funktioniert, wenn du bereits weißt, welche Dateien wichtig sind. Zeige dem Agenten die spezifischen Controller- und Modell-Dateien, und er erstellt gezielte Dokumentation. Es ist nicht nötig, das gesamte Repo zu klonen, wenn du nur Dokumente für eine Endpunktgruppe benötigst. Der Agent liest den Code, den du ihm gibst, und dokumentiert, was er findet — Dekoratoren, Routenparameter, Middleware, Rückgabetypen und Fehlerbehandlungs-Muster.

Warum der Zugriff auf ein sandboxed Repo für die Dokumentation wichtig ist

Wenn du einem KI-Agenten Zugriff auf dein privates Repository gewährst, ist es wichtig, wo dieser Code läuft. Der Agent muss dein Repo klonen, deine Quelldateien lesen und möglicherweise Build-Tools ausführen, um Typen und Abhängigkeiten aufzulösen. Wenn das auf deinem lokalen Rechner mit rohem Systemzugriff geschieht, setzt du deine gesamte Entwicklungsumgebung dem aus, was der Agent tut.

Die Forschung von Snyk fand über 341 bösartige Pakete in Open-Source-AI-Tool-Registrierungen. LikeClaw führt jede Dokumentationsaufgabe in einem E2B-sandboxed Container aus. Dein Repo wird innerhalb der Sandbox geklont. Der Agent liest den Code innerhalb der Sandbox. Wenn die Aufgabe erledigt ist, wird die Sandbox zerstört. Dein lokaler Rechner, deine SSH-Schlüssel, deine anderen Repositories — nichts davon wird exponiert.

Deine Anmeldeinformationen sind verschlüsselt und auf die Sandbox-Sitzung beschränkt. Null laterale Bewegung zwischen Aufgaben. Null Persistenz nach Abschluss.

Über die Dokumentation einzelner Endpunkte hinaus

Die wahre Kraft zeigt sich, wenn du APIs über ein ganzes Backend oder über mehrere Dienste hinweg dokumentieren musst. Häufige Muster von Beta-Nutzern:

• Vollständiges API-Inventar: “Liste jeden Endpunkt in dieser Express-App mit seiner Methode, seinem Pfad und seiner Handler-Funktion auf.” Der Agent durchläuft den Routenbaum und erstellt ein vollständiges Inventar.
• Cross-Service-Verträge: Zeige dem Agenten dein API-Gateway und zwei nachgelagerte Dienste. Er verfolgt, wie eine Anfrage durch jede Schicht fließt und dokumentiert den Vertrag an jeder Grenze.
• Migrationsdokumentation: “Vergleiche die v1- und v2-Endpunkte und dokumentiere, was sich geändert hat.” Der Agent liest beide Versionen und erstellt einen Diff-Stil-Migrationsleitfaden.
• Schema-Extraktion: “Extrahiere alle TypeScript-Interfaces, die in API-Antworten verwendet werden, und erstelle ein Schema-Dokument.” Der Agent sammelt jedes Interface, das in Routen-Handlern referenziert wird, und gibt sie in einer strukturierten Datei aus.

Dies passt natürlich zu LikeClaws Codebase-Analyse Fähigkeiten. Analysiere zuerst die Architektur, um das System zu verstehen, und generiere dann gezielte API-Dokumentation für die Endpunkte, die wichtig sind. Beide Aufgaben laufen in derselben sicheren Sandbox, und die Ergebnisse bleiben in deinem Arbeitsbereich zur Referenz.

Für wen das gedacht ist

Backend-Entwickler, die es leid sind, in Slack zu beantworten: “Was gibt dieser Endpunkt zurück?” Teamleiter, die API-Verträge an Frontend- oder mobile Teams übergeben müssen, ohne ein Meeting zu planen. Plattformingenieure, die interne APIs für andere Teams dokumentieren. Jeder, der jemals in einem Unternehmenswiki nach API-Dokumentationen gesucht hat und eine Seite gefunden hat, die vor acht Monaten zuletzt aktualisiert wurde.

Null Einrichtung. Vorhersehbare Preise. Dokumentation, die aus deinem tatsächlichen Code generiert wird, nicht aus dem Gedächtnis.