Irgendwo in diesem Moment gibt es eine Person, die deine API integriert. Sie sind nicht auf deiner Dokumentationsseite. Sie hat deinen Leitfaden für die ersten Schritte nicht geöffnet. Sie haben noch nie deine interaktive Spielwiese oder deine sorgfältig gestaltete Seitenleistennavigation gesehen.
Sie sitzen in Claude. Oder Copilot. Oder Cursor. Sie tippen etwas ein wie "integriere die Stripe Billing API mit meiner Next.js App unter Verwendung des App-Routers" und warten darauf, dass funktionierender Code zurückkommt. Die KI hat deine Dokumente für dich gelesen. Sie fand die relevanten Endpunkte, verstand den Authentifizierungsfluss, wählte die richtigen SDK-Methoden und erstellte eine Implementierung.
Die Person hat deine Website nie besucht. Sie wird deine Website vielleicht nie besuchen. Und das ist zunehmend die normale Art und Weise, wie Software entwickelt wird.
Die Reise, die niemand geplant hat
Lange Zeit folgten die Beziehungen zwischen Entwicklern einem wohlverstandenen Weg. Du hast umfassende Dokumentationen geschrieben. Du hast Schnellstartanleitungen veröffentlicht. Du hast auf Konferenzen Vorträge gehalten. Du hast eine Präsenz auf Stack Overflow unterhalten. Du hast deine API-Referenz durchsuchbar gemacht, deine SDKs idiomatisch und deine Fehlermeldungen hilfreich.
Dieser Weg setzt voraus, dass die Entwickler deine Inhalte lesen. Navigiere durch deine Struktur. Folge deinen Schritten.
Die GitHub-Entwicklerumfrage 2024 ergab, dass 97 % der Entwickler in Unternehmen schon einmal KI-Codierungstools verwendet haben. [Die jährliche Umfrage von Stack Overflow (https://survey.stackoverflow.co/2024/) ergab, dass 76 % aller Entwickler/innen KI-Tools nutzen oder planen, sie zu nutzen, wobei 62 % der Fachleute sie aktiv im Alltag einsetzen. Diese Zahlen waren bereits hoch. Sie sind seitdem nur noch gestiegen.
Die neue Reise sieht anders aus. Jemand beschreibt in natürlicher Sprache, was er will. Ein KI-Assistent liest die Dokumentation, findet die relevanten Abschnitte und erstellt die Integration. Der Builder überprüft das Ergebnis. Vielleicht verfeinert er die Eingabeaufforderung. Vielleicht stellt er eine Folgefrage. Der ganze Prozess dauert Minuten, nicht Stunden.
Der Einstiegstrichter, an dem die DevRel-Teams jahrelang gefeilt haben, wird umgangen. Nicht, weil er schlecht war. Sondern weil sich der Einstiegspunkt verschoben hat.
Zwei Verbraucher, ein Satz Dokumente
Die Dokumentation hat jetzt zwei grundlegend verschiedene Zielgruppen.
Das erste ist der menschliche Leser. Diese Person gibt es immer noch. Sie tauchen auf, wenn es um Architekturentscheidungen, das Debuggen von Grenzfällen, die Überprüfung der Einhaltung von Vorschriften und das Verständnis von Konzepten geht. Sie wollen erzählerische Erklärungen, gut organisiertes Referenzmaterial und klare Argumente für Kompromisse.
Der zweite ist der KI-Vermittler. Er liest deine Dokumentation im Auftrag des Bauherrn. Sie kümmert sich nicht um deine Seitenleiste. Sie schätzt dein visuelles Design nicht. Sie braucht strukturierte, maschinenlesbare Inhalte: saubere Markdowns, konsistente Formatierungen, eindeutige Spezifikationen, über die sie ohne Mehrdeutigkeit nachdenken kann.
Fast jede Dokumentationsseite ist heute ausschließlich für die erste Zielgruppe optimiert. Die zweite Zielgruppe ist bereits der dominierende Verbraucher.
Jeremy Howard erkannte dieses Spannungsverhältnis, als er 2024 den /llms.txt-Standard vorschlug. Seine Beobachtung war präzise: "Große Sprachmodelle stützen sich zunehmend auf Website-Informationen, stoßen aber auf eine entscheidende Einschränkung: Die Kontextfenster sind zu klein, um die meisten Websites in ihrer Gesamtheit zu erfassen." Der Vorschlag ist einfach. Eine kuratierte Markdown-Datei unter /llms.txt, die den KI-Modellen einen strukturierten Überblick über dein Produkt und Links zu den wichtigsten Ressourcen gibt. FastHTML, Anthropics eigene Dokumente und ein [wachsendes Verzeichnis von Projekten] (https://llmstxt.site/) liefern jetzt eine solche Datei aus.
Das ist eine nützliche Konvention. Aber sie ist auch ein Symptom für ein tieferes Problem. Das eigentliche Problem ist nicht das Format. Das Problem ist, dass die meisten Dokumentationen nie mit Blick auf die Nutzung durch Maschinen entwickelt wurden.
Der Erbauer spart nicht am falschen Ende.
Die Versuchung ist groß, die Person, die Claude auffordert, statt die Dokumentation zu lesen, zu betrachten und daraus zu schließen, dass sie Abkürzungen nimmt. Dass sie nicht wirklich verstehen, was im Code passiert. Dass sie irgendwie eine minderwertige Art von Entwickler ist.
Das ist normalerweise falsch.
Viele dieser Entwickler sind erfahrene Ingenieure, die sich bewusst für Effizienz entscheiden. Sie verstehen den Code. Sie haben nur keine Lust, vier Seiten Dokumentation durchzugehen, um die drei Zeilen zu finden, die sie wirklich brauchen. Sie haben gelernt, dass ein KI-Assistent diese Zeilen schneller extrahieren kann, als sie sie suchen können, also delegieren sie das Lesen.
Anthropic erkannte dieses Muster, als sie das [Model Context Protocol] (https://modelcontextprotocol.io/introduction) entwickelten. MCP wird inzwischen von Claude, ChatGPT, VS Code, Cursor und anderen unterstützt. Es ist ausdrücklich so konzipiert, dass KI-Assistenten auf externe Systeme zugreifen, Kontext abrufen und darauf reagieren können. In der Spezifikation wird beschrieben, dass es _"den Zugang zu einem Ökosystem von Datenquellen, Tools und Apps ermöglicht, die die Fähigkeiten erweitern und die Erfahrung des Endnutzers verbessern werden".
Das ist die Sprache der Infrastruktur, nicht die Sprache der Bequemlichkeit. Die Entwickler, die diese Tools nutzen, vermeiden keine Arbeit. Sie arbeiten sich durch eine neue Ebene. Deine Dokumentation ist Teil dieser Schicht, ob du sie nun dafür vorgesehen hast oder nicht.
Entwicklerbeziehungen wurden für eine andere Zeit entwickelt.
Wenn eine DevRel-Strategie vor 2023 entwickelt wurde, war sie für eine Welt konzipiert, in der die Entwickler die Dokumentation direkt gelesen haben. Diese Welt ist zwar nicht verschwunden, aber sie ist nicht mehr das vorherrschende Interaktionsmuster für einen wachsenden Anteil der Entwickler/innen.
Das verändert die Kalkulation einiger langjähriger DevRel-Aktivitäten.
Konferenzvorträge. Eine 45-minütige Präsentation auf einer Entwicklerkonferenz erreicht einen Raum mit ein paar hundert Leuten. Eine gut strukturierte /llms.txt-Datei und eine saubere, maschinenlesbare Dokumentation erreichen jeden Builder, der einen KI-Assistenten über dein Produkt befragt, kontinuierlich und zu jeder Zeit. Das Gespräch ist ein einmaliges Ereignis. Die maschinenlesbaren Dokumentationen setzen sich zusammen. Das macht Konferenzen nicht wertlos. Es ändert nur, welche Aktivitäten die größte Hebelwirkung haben.
Anleitungen für den Einstieg Die klassische Schnellstartanleitung in fünf Schritten ist zunehmend eine Formalität. Die Erbauer folgen den Schritten nicht. Er beschreibt, was er will, und erwartet, dass die KI die Integration vornimmt. Wenn die API in einem maschinenfreundlichen Format gut dokumentiert ist, erledigt die KI die ersten Schritte effizienter als das Tutorial. Tutorien sollten stattdessen konzeptionelles Material sein: Sie sollten erklären, warum du Ansatz A gegenüber Ansatz B wählen solltest. Sie ist weniger zuverlässig darin, die Kompromisse zu erklären.
Stack Overflow. Die eigenen Umfragedaten von Stack Overflow haben gezeigt, dass 84% der Entwickler technische Dokumentationen direkt nutzen, wobei 90% von ihnen sich auf Dokumentationen in API- und SDK-Paketen verlassen. Aber der Zugang zu diesen Dokumenten erfolgt zunehmend über eine KI-Ebene und nicht über einen Browser-Tab. Die Fragen, die immer noch bei Stack Overflow landen, sind die schwierigen Fragen, die Grenzfälle und die Debugging-Threads für die Produktion, die Feinheiten erfordern. Das ist wertvoll. Aber es ist nicht mehr der Ort, an dem das Volumen liegt.
Wenn die KI deine Dokumente liest, wird die Aktualität entscheidend
Hier ist der Teil, den die meisten Teams nicht bedacht haben.
Wenn ein Mensch eine Dokumentationsseite liest, kann er sich ein Urteil bilden. Ihm könnte auffallen, dass die Screenshots alt aussehen oder dass ein Kommentar am Ende der Seite besagt, dass der Prozess geändert wurde. Er kann den Kontext bewerten.
Ein KI-Assistent kann das nicht tun. Er liest den Text, verarbeitet ihn als Tatsache und gibt mit voller Überzeugung eine Antwort. Wenn in der Dokumentation ein veralteter Endpunkt beschrieben wird, wird die KI empfehlen, diesen zu integrieren. Wenn in der Dokumentation auf eine Infrastruktur verwiesen wird, die vor sechs Monaten ersetzt wurde, wird die KI die alte Einrichtung als aktuell beschreiben.
Der Builder vertraut der KI. Die KI verlässt sich auf die Dokumentation. Wenn die Dokumentation veraltet ist, liefert diese Vertrauenskette mit Sicherheit eine falsche Antwort.
Das war natürlich schon immer ein Problem mit der Dokumentation. Veraltete Inhalte haben die Menschen schon immer verwirrt. Aber der Schaden hielt sich in Grenzen, weil menschliche Leser das Problem manchmal erkennen konnten. KI-Vermittler können das nicht. Sie verstärken veraltete Inhalte, indem sie sie in großem Umfang und mit Autorität an Menschen weitergeben, die keinen Grund haben, sie anzuzweifeln.
Frische ist nicht länger ein Problem der Inhaltsqualität. Sie ist eine Frage der Zuverlässigkeit für jeden KI-gestützten Arbeitsablauf, der mit deiner Dokumentation zu tun hat.
Das Wort "Entwickler" ist zu eng gefasst
Die Menschen, die im Jahr 2026 Software entwickeln, bezeichnen sich nicht alle als Entwickler. Einige sind Designer, die Claude auffordern, einen funktionierenden Prototyp zu bauen. Einige sind Produktmanager, die Cursor benutzen, um interne Tools zu entwickeln. Andere sind Datenanalysten, die eine Datenpipeline in natürlicher Sprache beschreiben und sie von einem Agenten zusammenstellen lassen.
Ramp ist ein nützliches Beispiel. Das Fintech-Unternehmen stieg von einer Bewertung von 5,8 Mrd. USD im Jahr 2023 auf 32 Mrd. USD Ende 2025 und überschritt dabei die Marke von 1 Mrd. USD Jahresumsatz. Es ist eines der am schnellsten wachsenden Startups der Geschichte. Ein viel diskutierter Teil ihres Ansatzes: Produktmanager bauen Funktionen direkt mit KI-Tools, anstatt in einem Engineering Backlog zu warten. PMs bei Ramp schreiben nicht nur Spezifikationen. Sie liefern den Code. Die KI kümmert sich um die Implementierung. Der PM kümmert sich um die Absicht.
Das ist keine Abkürzung. Es ist ein neues Betriebsmodell. Und es funktioniert in einem Umfang, der es schwer macht, es als Experiment abzutun.
Anthropic hat dieses Modell ganz bewusst als "Builder" bezeichnet. Ihre Werkzeuge sind nicht nur für professionelle Software-Ingenieure gedacht, sondern für jeden, der beschreiben kann, was er bauen will. Wenn Claude mit Hilfe von MCP aus einem Figma-Entwurf eine vollständige Anwendung erstellen kann, löst sich die traditionelle Grenze zwischen "Entwickler" und "Nicht-Entwickler" auf.
Das hat reale Auswirkungen auf jeden, der Dokumentationen pflegt oder sich um die Erfahrung von Entwicklern kümmert. Die Zielgruppe ist nicht mehr auf Menschen beschränkt, die wissen, was ein REST-Endpunkt ist. Sie umfasst jeden, dessen KI-Assistent mit deinem Produkt interagieren könnte. Der PM bei Ramp, der eine Funktion über deine API bereitstellt, wird deine Dokumentation wahrscheinlich nie direkt lesen. Ihr KI-Agent wird es aber auf jeden Fall tun.
Was bedeutet das für die Dokumentation?
Wenn die Dokumentation jetzt zwei Zielgruppen bedient, nämlich menschliche Leser und KI-Vermittler, muss sie für beide funktionieren. Das klingt offensichtlich. In der Praxis macht das aber fast niemand.
Ein paar Änderungen sind wichtig:
Maschinenlesbare Formate neben menschenlesbaren Formaten. Wenn deine API-Dokumente eine schön gerenderte HTML-Seite sind, die ein LLM auslesen und analysieren muss, arbeitet die KI härter als sie sollte. Biete die unbearbeitete OpenAPI-Spezifikation zusammen mit der gerenderten Version an. Liefern Sie saubere Markdowns. Mach die Spezifikationen zugänglich, ohne dass die KI das Seitenlayout interpretieren muss.
**Struktur auf Blockebene statt Erzählung auf Seitenebene ** KI-Assistenten konsumieren die Dokumentation nicht Seite für Seite. Sie extrahieren relevante Abschnitte. Ein Dokument mit klaren Überschriften, in sich abgeschlossenen Absätzen und expliziter Semantik auf Blockebene ist für eine KI wesentlich nützlicher als eine fließende Erzählung, bei der man die ganze Seite lesen muss, um den Kontext zu verstehen.
Vertrauere auf Signale, dass Maschinen lesen können. Wann wurde dieses Dokument zuletzt überprüft? Ist es noch aktuell? Wurde der Inhalt mit einer Kennzeichnung versehen? Diese Signale müssen in einer Form vorliegen, auf die die KI zugreifen kann, nicht nur als visuelle Hinweise auf einer Webseite. Ein Freshness Score, ein Verfallsstatus, ein Überprüfungsdatum - das sind die Metadaten, anhand derer eine KI entscheiden kann, ob ein Dokument als Quelle sicher ist.
Frische als Voraussetzung, nicht als Merkmal. Wenn ein KI-Assistent einem Builder eine sichere Antwort auf der Grundlage eines veralteten Endpunkts gibt, ist der Schaden schlimmer als eine 404. Der Builder baut darauf auf. Liefert sie aus. Dann geht sie in der Produktion kaputt. Diese Abfolge geschieht unbemerkt und in großem Umfang. Jedes Dokument, auf das eine KI verweisen könnte, braucht einen Mechanismus, um zu beweisen, dass es noch aktuell ist.
Der stille Wandel in der Darstellung von Produkten
Es gibt noch eine weitere Konsequenz, die es wert ist, direkt angesprochen zu werden.
Deine Dokumentation ist nicht mehr nur ein Referenzhandbuch für Entwickler. Sie ist das Ausgangsmaterial, das KI-Assistenten nutzen, um dein Produkt in der Welt zu repräsentieren. Wenn ein Entwickler Claude fragt, wie er dein Produkt nutzen kann, wird Claudes Antwort von dem geprägt, was er in deinen Unterlagen finden und analysieren kann.
Wenn deine Dokumentation gut strukturiert, aktuell und maschinenlesbar ist, gibt Claude eine gute Antwort. Wenn sie veraltet, mehrdeutig oder in HTML verpackt ist, das für ein Modell schwer zu analysieren ist, gibt Claude eine schlechtere oder falsche Antwort.
Die Qualität der KI-Antwort auf dein Produkt ist jetzt ein direkter Indikator für die Erfahrung deiner Entwickler. Und die meisten Unternehmen behandeln das nicht so.
Die Teams, die in diesem Bereich führend sind - Stripe, Vercel, Cloudflare und Anthropic selbst - behandeln die Lesbarkeit der KI als ein Anliegen erster Klasse. Nicht etwas, das man später angehen kann. Kein Nice-to-have. Es ist eine grundlegende Anforderung, die bestimmt, wie die Dokumentation geschrieben, strukturiert und gepflegt wird.
Der Bauherr, der gerade in Claude sitzt, beschreibt, was er bauen will, und erwartet, dass er in wenigen Minuten funktionierenden Code erhält, wird vielleicht nie wieder eine Dokumentationsseite besuchen. Aber die KI, die sie bedient, wird das ständig tun.
Diese KI ist jetzt dein häufigster Leser. Die Frage ist, ob deine Dokumentation darauf vorbereitet ist.
Die beste Strategie für das Entwicklererlebnis im Jahr 2026 ist nicht ein Konferenzvortrag oder eine Schnellstartanleitung. Es geht darum, sicherzustellen, dass die KI alles richtig macht.
*Dieser Beitrag bezieht sich auf öffentlich zugängliche Forschungsergebnisse und Produktdokumentationen. Die Statistiken stammen aus der GitHub's 2024 Developer Survey und der Stack Overflow 2024 Developer Survey. Die /llms.txt-Spezifikation wird unter llmstxt.org gepflegt. Das Model Context Protocol ist unter modelcontextprotocol.io dokumentiert.