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 Seitennavigation 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.
Vor zwei Wochen, beim Start Summit Hackathon in St. Gallen, konnte ich dies in Echtzeit beobachten. Ich unterhielt mich mit einer Gruppe von CS-Studenten und ein paar Startup-Gründern darüber, wie sie an neue APIs herangehen, und jeder von ihnen beschrieb denselben Arbeitsablauf: Das Problem in eine KI einfügen, Code zurückbekommen, von dort aus iterieren. Eine der Studentinnen lachte, als ich sie fragte, ob sie die Dokumente gelesen hätte. "Warum sollte ich? Claude liest sie für mich."
Die Person hat deine Website nie besucht. Sie wird deine Seite vielleicht nie besuchen. Und genau so wird Software zunehmend entwickelt.
Die Kernverschiebung
Die Dokumentation hat heute zwei grundverschiedene Abnehmer: Menschen, die sie lesen, und KI-Assistenten, die sie im Auftrag von Entwicklern lesen. Die meisten Dokumentationen sind ausschließlich für Menschen optimiert. Die KI ist bereits der dominierende Leser.
Das verändert alles nachgelagerte Bereiche:
- Frische Inhalte sind jetzt eine Frage der Zuverlässigkeit. Wenn eine KI veraltete Inhalte serviert, hat der Ersteller keine Möglichkeit, das Problem zu erkennen. Der Schaden wächst stillschweigend mit.
- "Entwickler" ist ein zu eng gefasster Begriff. Produktmanager, Designer und Analysten liefern Software über KI-Assistenten aus, oft ohne jemals selbst eine Zeile der Dokumentation gelesen zu haben.
- Maschinenlesbare Struktur ist wichtiger als visuelles Design. Sauberes Markdown, in sich geschlossene Blöcke und explizite Metadaten ermöglichen es der KI, dein Produkt korrekt darzustellen.
- Die Anforderungen an das Format haben sich aufgeteilt. Menschliche Leser brauchen Erzählungen. KI-Vermittler brauchen strukturierte, analysierbare Spezifikationen. Du musst beide bedienen.
Der Rest dieses Beitrags erklärt, wie es dazu kam, was das für DevRel bedeutet und was du jetzt tun kannst.
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 (https://github.blog/news-insights/research/survey-ai-wave-grows/) ergab, dass 97 % der Entwickler in Unternehmen schon einmal KI-Tools 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. Bis 2026 steigt diese Zahl auf 84 %, wobei 41 % des gesamten Codes inzwischen von KI generiert werden und 51 % der professionellen Entwickler/innen KI-Tools täglich nutzen. Diese Zahlen werden sich nicht abschwächen.
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 prüft die Ergebnisse, verfeinert vielleicht die Eingabeaufforderung oder fragt nach. Das dauert nur Minuten, nicht Stunden.
Der Einstiegstrichter, an dem DevRel-Teams jahrelang gefeilt haben? Er wird übersprungen. Nicht, weil er schlecht war. Der Einstiegspunkt hat sich einfach verschoben.
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ählende 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 sind.
Ich habe dieses Gespräch schon oft genug geführt, um zu wissen, dass das meistens falsch ist.
Viele dieser Entwickler sind erfahrene Ingenieure, die sich bewusst für Effizienz entscheiden. Sie verstehen den Code, aber sie wollen nicht vier Seiten Dokumentation wälzen, 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. (Ehrlich gesagt, mache ich das auch. Ich kann mich nicht erinnern, wann ich das letzte Mal eine Anleitung für den Einstieg von vorne bis hinten gelesen habe).
Anthropic hat dieses Muster erkannt, als sie das Model Context Protocol entwickelt haben. MCP wird inzwischen von Claude, ChatGPT, VS Code, Cursor und anderen unterstützt. Es ist explizit so konzipiert, dass KI-Assistenten auf externe Systeme zugreifen, Kontext abrufen und darauf reagieren können. In der Spezifikation heißt es, dass es _"Zugang zu einem Ökosystem von Datenquellen, Tools und Apps bietet, das die Fähigkeiten und die Erfahrung des Endnutzers verbessert".
Lies das genau. Das ist die Sprache der Infrastruktur, nicht die Sprache der Bequemlichkeit. Die Entwickler/innen, die diese Tools nutzen, vermeiden keine Arbeit. Sie arbeiten sich durch eine neue Ebene, und deine Dokumentation ist Teil dieser Ebene, ob du sie nun dafür vorgesehen hast oder nicht.
Die Zahlen belegen dies. Allein Claude verarbeitet heute [25 Milliarden API-Aufrufe pro Monat] (https://www.incremys.com/en/resources/blog/claude-statistics), mit 30 Millionen monatlich aktiven Nutzern in 159 Ländern. 70% der Fortune 100 Unternehmen nutzen Claude. Laut einer Umfrage von Menlo Ventures hält Anthropic 32 % des KI-Marktanteils in Unternehmen, gemessen an der Modellnutzung, vor OpenAI mit 25 %. Ein HSBC-Forschungsbericht beziffert den Anteil sogar noch höher: 40 % der gesamten KI-Ausgaben. Das sind keine experimentellen Tools. Sie sind die primäre Infrastruktur.
Die Beziehungen zwischen Entwicklern wurden für eine andere Zeit geschaffen.
Wenn deine DevRel-Strategie vor 2023 entwickelt wurde, war sie für eine Welt gedacht, in der Entwickler die Dokumente direkt lesen. Diese Welt ist nicht verschwunden, aber sie ist nicht mehr das vorherrschende Interaktionsmuster für einen wachsenden Anteil von Entwicklern.
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 maschinenlesbare Dokumentation bleibt bestehen. Ich will damit nicht sagen, dass Konferenzen wertlos sind (ich komme gerade von einer zurück), aber das Verhältnis der Hebelwirkung hat sich verschoben.
Anleitungen für den Einstieg Die klassische Schnellstart-Anleitung in fünf Schritten wird immer mehr zu einer Formalität. Die Bauherren 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, bewältigt die KI den Einstieg effizienter, als es ein Tutorial könnte. Tutorien sollten stattdessen konzeptionelles Material sein: Sie sollten erklären, warum du Ansatz A gegenüber Ansatz B wählst. Bei der Erklärung von Kompromissen ist sie viel weniger zuverlässig.
Stack Overflow. Ihre eigenen Umfragedaten haben gezeigt, dass 84% der Entwickler die technische Dokumentation direkt nutzen, wobei 90% von ihnen sich auf die Dokumentation in API- und SDK-Paketen verlassen. Aber die Art und Weise, wie sie auf diese Dokumente zugreifen, erfolgt zunehmend über eine KI-Ebene und nicht über einen Browser-Tab. Die Fragen, die Stack Overflow noch erreichen, sind meist die schwierigen. Grenzfälle, Debugging in der Produktion, Dinge, die Feinheiten erfordern. Wertvoll, sicher. Aber das Volumen ist nicht mehr da.
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 darauf blinzeln und denken: "Das scheint veraltet zu sein".
Ein KI-Assistent kann das alles nicht tun. Er liest den Text, verarbeitet ihn als Tatsache und gibt mit vollem Vertrauen eine Antwort. Wenn in der Dokumentation ein veralteter Endpunkt beschrieben wird, wird die KI fröhlich empfehlen, ihn zu integrieren. Wenn in der Dokumentation auf eine Infrastruktur verwiesen wird, die vor sechs Monaten ersetzt wurde, wird die KI die alte Konfiguration als aktuell beschreiben. Ohne zu zögern.
Und das macht die Sache noch schlimmer, als sie klingt: 66% der Entwickler sagen bereits, dass das größte Problem mit KI-Tools darin besteht, dass sie Ergebnisse liefern, die "fast richtig, aber nicht ganz richtig" sind. Eine veraltete Dokumentation trägt direkt zu diesem Problem bei. Die KI halluziniert nicht. Sie gibt veraltete Inhalte originalgetreu wieder, und es gibt keine Möglichkeit für den Erbauer, den Unterschied zu erkennen.
Der Bauherr verlässt sich auf die 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. Veraltete Inhalte haben die Menschen schon immer verwirrt. Aber der Schaden wurde eingedämmt, weil menschliche Leser es 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 mehr nur eine Frage der Qualität der Inhalte. Es ist eine Frage der Zuverlässigkeit für jeden KI-gesteuerten Workflow, der deine Dokumente berührt.
Das Wort "Entwickler" ist zu eng gefasst
Die Menschen, die im Jahr 2026 Software entwickeln, bezeichnen sich nicht alle als Entwickler. Manche 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. Beim Start Summit hatte die Hälfte der Hackathon-Teams Mitglieder, die keinerlei Programmierkenntnisse hatten und am Ende des Wochenendes eine funktionierende Software lieferten.
Ramp ist ein gutes Beispiel. Das Finanzunternehmen stieg von einer Bewertung von 5,8 Mrd. USD im Jahr 2023 auf 32 Mrd. USD Ende 2025 und überschritt dabei einen Jahresumsatz von 1 Mrd. USD. 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. Ein neues Betriebsmodell, das in einem Umfang funktioniert, der es wirklich schwer macht, es als Experiment abzutun.
Die interne Studie von Anthropic ist hier aufschlussreich. Bei einer Befragung von 132 Ingenieuren (https://fortune.com/2025/12/02/how-anthropics-safety-first-approach-won-over-big-business-and-how-its-own-engineers-are-using-its-claude-ai/) über die Nutzung von Claude gaben die Ingenieure an, dass sie Claude für etwa 60 % ihrer Arbeitsaufgaben nutzen. Die häufigsten Anwendungen? Das Debuggen von bestehendem Code, das Verstehen, was Teile der Codebasis tun, und die Implementierung neuer Funktionen. Die Ingenieure gaben an, dass sie Claude eher mit Aufgaben betrauen, die "nicht komplex sind, sich wiederholen und bei denen die Codequalität nicht entscheidend ist". Und 27 % der Arbeit, die sie jetzt mit Claude erledigen, hätten sie vorher gar nicht gemacht.
Das ist das eigene Team von Anthropic. Die Leute, die das Modell entwickelt haben, nutzen es als Dokumentationsleser, als Codebase-Navigator und als Generator für erste Entwürfe. Alle anderen machen das Gleiche, nur mit ihren Dokumenten statt mit ihren.
Anthropic hat diese Persona bewusst als "Builder" bezeichnet. Ihre Werkzeuge sind nicht nur für professionelle Softwareentwickler gedacht, sondern für jeden, der beschreiben kann, was er bauen will. Wenn Claude mit 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 echte Auswirkungen auf jeden, der Dokumentationen pflegt oder sich um die Erfahrung von Entwicklern kümmert. Deine 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 mit deiner API ausliefert? Wahrscheinlich liest er deine Dokumentation nie direkt. Ihr KI-Agent wird es aber auf jeden Fall tun.
Was das für die Dokumentation bedeutet
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.
Hier ist, was meiner Meinung nach wirklich wichtig ist:
**Maschinenlesbare Formate neben menschenlesbaren Formaten ** Wenn deine API-Dokumente eine schön gerenderte HTML-Seite sind, die ein LLM auslesen und parsen 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, und niemand weiß, warum, bis jemand die Ursache auf die Dokumentation zurückführt, die schon vor Monaten hätte aktualisiert werden müssen. Jedes Dokument, auf das sich eine KI beziehen könnte, braucht einen Mechanismus, um zu beweisen, dass es noch aktuell ist. (Das ist genau das Problem, das wir mit Rasepi lösen wollen, um ganz offen zu sein. Erzwungenes Verfallsdatum für Dokumentationsblöcke, damit sich veraltete Inhalte nicht verstecken können.)
Erste Schritte: Überprüfe deine aktuellen Dokumentationen
Wenn du bis hierher gelesen hast und denkst: "Okay, aber was mache ich eigentlich am Montag?", hier sind vier konkrete Dinge, die du diese Woche überprüfen kannst.
1. Teste deine Dokumente durch eine KI. Öffne Claude oder ChatGPT und bitte sie, dein Produkt in ein realistisches Szenario zu integrieren. Nutze nicht dein internes Wissen. Schau dir einfach an, was die KI produziert. Ist es korrekt? Ist es aktuell? Verwendet sie die richtigen Endpunkte, die richtige SDK-Version, den richtigen Authentifizierungsfluss? Wenn die KI etwas falsch macht, ist es das, was die Bauherren jetzt bekommen.
2. Überprüfe, ob die Inhalte veraltet sind. Nimm deine fünf meistbesuchten Dokumentationsseiten und frage: Wann wurde diese Seite zuletzt überarbeitet? Beschreiben sie immer noch den aktuellen Stand des Produkts? Wenn du diese Frage nicht sicher beantworten kannst, kann das auch eine KI nicht. Das ist die wichtigste Maßnahme für die meisten Teams.
**3. Liefern Sie maschinenlesbare Formate ** Wenn Sie keine /llms.txt-Datei haben, erstellen Sie eine. Wenn deine API-Referenz nur als gerendertes HTML vorliegt, exportiere die OpenAPI-Rohdaten und mache sie zugänglich. Wenn deine Dokumente in einem CMS sind, das keine sauberen Markdown-Dateien ausgibt, ist das ein Problem, das du jetzt lösen solltest.
4. Füge Überprüfungsdaten und Freshness-Metadaten hinzu. Selbst etwas Einfaches wie ein last-reviewed-Feld in deinem Content Management System, ein obligatorischer Überprüfungszyklus für stark frequentierte Seiten. Das gibt sowohl den Menschen als auch der KI ein Signal, ob die Inhalte vertrauenswürdig sind. Tools wie Rasepi können dies mit einem erzwungenen Ablauf auf Blockebene automatisieren, aber auch ein manueller Prozess ist besser als nichts.
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.
Gute Dokumente, gute Antwort. Veraltet, mehrdeutig, in HTML eingeschlossen, das für ein Modell schwer zu analysieren ist? Schlechte Antwort oder eine falsche Antwort. So einfach ist das.
Die Qualität der KI-Antwort zu deinem Produkt ist jetzt ein direkter Indikator für die Erfahrung deiner Entwickler. Die meisten Unternehmen behandeln das noch nicht so.
Stripe, Vercel, Cloudflare und Anthropic sind die Vorreiter in diesem Bereich und behandeln die Lesbarkeit der KI als ein erstklassiges Anliegen. Eine grundlegende Anforderung, die bestimmt, wie die Dokumentation geschrieben, strukturiert und gepflegt wird. Das ist kein Thema für das nächste Quartal.
Der Entwickler, der gerade in Claude sitzt, beschreibt, was er bauen will, und erwartet, dass der Code innerhalb von Minuten funktioniert. Er wird vielleicht nie wieder eine Dokumentationsseite besuchen. Aber die KI, die sie bedient, wird es tun. Ständig.
Diese KI ist jetzt dein häufigster Leser. Die Frage ist nur, ob deine Dokumente darauf vorbereitet sind.
Die beste Strategie für das Entwicklererlebnis im Jahr 2026 ist kein Konferenzvortrag oder eine Schnellstartanleitung. Sie muss sicherstellen, dass die KI es richtig macht.
*Dieser Beitrag bezieht sich auf öffentlich zugängliche Forschungsergebnisse und Produktdokumentationen. Die Statistiken stammen aus GitHub's 2024 developer survey, der Stack Overflow 2024 Developer Survey, Index.dev's 2026 developer productivity report, Incremys Claude statistics und Fortune's reporting on Anthropic. Die /llms.txt-Spezifikation wird auf llmstxt.org gepflegt. Das Model Context Protocol ist unter modelcontextprotocol.io dokumentiert.