TCDEV Blog

Lass deinen LLM auf Englisch denken

2026-04-27T00:00:00Z

Du lieferst einen Chatbot für dein deutsches Team. Die Benutzeroberfläche ist deutsch. Die Quelldokumente sind teilweise deutsch, teilweise englisch. Die Tools hinter dem Assistenten erwarten englische Enum-Werte, englische Funktionsbeschreibungen, englische Produktnamen, alles auf Englisch.

Dann stellt jemand eine ganz normale Frage auf Deutsch, das Modell wählt das richtige Tool aus, übergibt ein Argument auf Deutsch statt auf Englisch, und die ganze Sache fällt still und leise auseinander.

Ich habe das schon so oft erlebt, dass ich es nicht mehr als Übersetzungsproblem betrachte. **Es ist ein Ausführungsproblem.

Meine derzeitige Vorgabe ist einfach: Lass die Benutzer/innen in der Sprache sprechen, die sie wollen, aber lass den LLM die Suche, die Schlussfolgerungen und die Werkzeuge auf Englisch ausführen, wenn es um Zuverlässigkeit geht. Dann lokalisiere die Antwort außerhalb dieser Schleife.

Das klingt im ersten Moment etwas ketzerisch. Meiner Meinung nach ist es aber das Praktischste, was du im Moment tun kannst.

Die Forschung beginnt, dies laut zu sagen

Die Zahlen sind nicht mehr unauffällig.

Im [MASSIVE-Agents-Benchmark] (https://aclanthology.org/2025.findings-emnlp.1099/) haben Forscher den mehrsprachigen Funktionsaufruf in 52 Sprachen, 47.020 Stichproben und 21 Modellen bewertet. Die beste durchschnittliche Punktzahl über alle Sprachen hinweg lag bei nur 34,05 %. Englisch erreichte 57,37%. Amharisch fiel auf 6,81%.

Das ist keine kleine Qualitätsschwankung. Das ist eine Klippe in Sachen Zuverlässigkeit.

Dann gibt es noch [Lost in Execution] (https://arxiv.org/abs/2601.05366), das noch näher an das reale Systemproblem heranreicht. Die Arbeit zeigt, dass viele mehrsprachige Werkzeugaufrufe scheitern, ** nachdem das Modell die Absicht bereits verstanden und das richtige Werkzeug ausgewählt hat**. Das Hauptproblem war die mangelnde Übereinstimmung der Parameterwerte mit der Sprache. Im Klartext: Das Modell wusste, was zu tun war, drückte die ausführbaren Bits aber in der Sprache des Benutzers statt in der Sprache der Schnittstelle aus, sodass der Aufruf trotzdem fehlschlug.

Und das ist nicht auf Tool-Aufrufe beschränkt. In [Do Multilingual Language Models Think Better in English?] (https://aclanthology.org/2024.naacl-short.46/) haben Etxaniz und Kollegen herausgefunden, dass die Selbstübersetzung ins Englische bei fünf Aufgaben durchweg besser ist als die direkte Schlussfolgerung aus dem Nicht-Englischen. Ihre Formulierung ist erfrischend unverblümt: Modelle sind "nicht in der Lage, ihr volles mehrsprachiges Potenzial auszuschöpfen, wenn sie in nicht-englischen Sprachen aufgefordert werden".

Also ja, mehrsprachige Modelle sind beeindruckend. Aber wenn deine Messlatte nicht "klingt ziemlich gut" ist, sondern "muss sich in der Produktion korrekt verhalten", sieht Englisch immer noch erstaunlich oft wie die sicherere Betriebssprache aus.

Warum RAG immer an derselben Stelle bricht

Wenn man dieses Argument hört, denkt man normalerweise zuerst an Agenten. Funktionsaufrufe, strukturierte Ausgaben, API-Ausführung und dergleichen mehr.

RAG hat die gleiche Schwäche, nur eine Ebene früher.

Wenn deine Suchschicht die lokalen Formulierungen eines Nutzers mit Inhalten abgleichen muss, die in verschiedenen Sprachen verfasst wurden, mit inkonsistenter Terminologie, übersetzten Produktnamen und halb lokalisierten Taxonomiebezeichnungen, erhöht sich die Wahrscheinlichkeit, dass das System abdriftet, bevor die Generierung überhaupt beginnt. Ehrlich gesagt, kommen viele Beschwerden über "das Modell ist unzuverlässig" daher. Das Modell mag in Ordnung sein. Die Inhaltsschnittstelle ist es nicht.

Ich würde lieber früh normalisieren.

Übersetze die Frage ins Englische. Vergleiche sie mit einem kanonischen englischen Korpus. Lass das Modell über eine stabile Terminologieebene nachdenken. Erstelle bei Bedarf einen Antwortentwurf auf Englisch. Übersetze oder lokalisiere dann die endgültige Antwort für den Nutzer.

So hast du einen Ort, an dem die Benennung stabil bleibt:

ein kanonischer Dokumententitel
ein kanonisches Produktvokabular
ein kanonisches Werkzeugschema
ein kanonisches Set von Retrieval Labels

Du kannst immer noch jede Benutzersprache auf der Außenseite unterstützen. Du verlangst nur nicht mehr, dass der Kernausführungspfad bei jedem Schritt perfekt mehrsprachig ist.

Das ist nicht gegen die Lokalisierung.

Ganz im Gegenteil.

Eine schlechte mehrsprachige KI-Architektur schadet in der Regel zuerst den lokalen Nutzern. Sie bekommen eine schöne lokalisierte Oberfläche, aber das versteckte englischsprachige System darunter verhält sich inkonsequent und lässt sie den Preis dafür zahlen.

Richtige Lokalisierung bedeutet, dass man ehrlich darüber ist, wo sich die Sprache biegen sollte und wo nicht.

Für mich sieht die Aufteilung folgendermaßen aus:

Lokalisiere die Benutzeroberfläche, die Eingabeaufforderungen, den Hilfetext, das Onboarding und die endgültigen Antworten.
Lokalisiere den Quellinhalt, den die Leute direkt lesen, wenn dieser Inhalt auf dem Markt benötigt wird.
Behalte interne Tooldefinitionen, kanonische Bezeichner, Abrufbezeichnungen und Argumentationspunkte auf Englisch, wenn dies die stabilste Ebene ist.
Füge explizite Nachbearbeitung oder menschliche Überprüfung hinzu, wenn eine lokalisierte Ausgabe rechtlich, regulatorisch oder vertraglich von Bedeutung ist.

Dieser letzte Punkt ist wichtiger, als die Teams zugeben wollen. Wenn das Modell mit einem Menschen spricht, ist die Lokalisierung eine Entscheidung für die Benutzererfahrung. Wenn das Modell mit einem anderen System kommuniziert, ist die Sprache ein Schnittstellenvertrag.

Das ist nicht dasselbe.

Die Architektur, der ich im Moment am meisten vertraue

Dies ist die Version, auf die ich heute für mehrsprachige KI-Produkte setzen würde:

Der Benutzer fragt in seiner Sprache.
Das System übersetzt oder normalisiert die Anfrage ins Englische.
Abfrage, Schlussfolgerung, Ranking und Tool-Aufrufe erfolgen anhand kanonischer englischer Daten.
Die endgültige Antwort wird wieder in die Sprache des Nutzers übersetzt.
Ausgaben mit hohem Risiko werden einem zusätzlichen Validierungsschritt unterzogen, bevor sie das System verlassen.

Es ist nicht philosophisch rein. Es ist operativ vernünftig.

Das Schöne daran ist, dass neuere Forschungsergebnisse in die gleiche Richtung weisen. Die Studie [Lost in Execution] (https://arxiv.org/abs/2601.05366) hat herausgefunden, dass die Vorübersetzung von Benutzeranfragen die Fehler bei der Sprachübereinstimmung in der Regel besser reduziert als Nachbesserungen, auch wenn dadurch die Leistung auf englischem Niveau nicht vollständig wiederhergestellt werden kann. Das entspricht dem, was viele Entwickler/innen in der Praxis bereits vermuten. Wenn du bis zum Ende wartest, um mehrsprachige Inkonsistenzen zu bereinigen, ist es meist zu spät.

Und ja, es gibt Ausnahmen. Wenn du für Sprachen mit geringen Ressourcen, für eine domänenspezifische Sprache oder für kulturell abhängige Formulierungen baust, kann es zu einem Drift kommen, wenn du alles ins Englische übersetzt. Davor wird in dem oben genannten Papier ausdrücklich gewarnt. Mach das also nicht zu einem Dogma.

Aber als Standard für Copiloten in Unternehmen, interne Assistenten, mehrsprachige RAG und Agenten, die Tools verwenden, halte ich die Regel für erstaunlich gut geeignet.

Was das für Rasepi bedeutet

Das ist genau der Grund, warum ich so viel Wert auf die kanonische Inhaltsstruktur lege.

Wenn deine Wissensbasis eine saubere Quellenschicht, eine stabile Terminologie und eine kontrollierte Lokalisierung aufweist, ist es einfacher, der KI zu vertrauen. Wenn jede Sprachversion unabhängig voneinander in den Ausführungspfad abdriftet, bittest du das Modell zu improvisieren, wo dein System präzise sein sollte.

Der gesamte Ansatz von Rasepi ist darauf ausgerichtet, diese Bereiche sauber voneinander zu trennen. Behalte einen kanonischen Kern. Lokalisiere absichtlich. Verfolge, wo Varianten existieren. Gib nicht vor, dass jede Schicht des Stacks gleichermaßen mehrsprachig sein sollte, nur weil die Benutzeroberfläche es ist.

Früher dachte ich, dass die beste mehrsprachige KI-Erfahrung bedeutet, alles in der Sprache des Nutzers zu machen. Das glaube ich nicht mehr. Nicht für Systeme, die den richtigen Absatz abrufen, das richtige Werkzeug wählen und etwas zurückgeben müssen, dem man vertrauen kann.

Die praktische Regel ist einfach: Die Benutzer sollten lokal bleiben, aber der Ausführungspfad des LLM sollte stabil bleiben. Im Moment bedeutet das normalerweise Englisch in der Mitte und Lokalisierung an den Rändern.

Das wird sich mit der Zeit ändern. Ich hoffe, es ändert sich schnell. Aber wenn du heute auslieferst und Zuverlässigkeit wichtiger ist als Ästhetik, würde ich das Modell auf Englisch denken lassen und dein Produkt die Sprache des Nutzers sprechen lassen.

Claude Design und die Ein-Personen-Kreativagentur

2026-04-18T00:00:00Z

Gestern hat Anthropic [Claude Design] (https://www.anthropic.com/news/claude-design-anthropic-labs) vorgestellt, ein neues Produkt des Anthropic Labs Teams, mit dem du Designs, Prototypen, Präsentationen und Marketingmaterial erstellen kannst, indem du mit Claude sprichst. Und ich saß da, sah mir die Ankündigung an und dachte: Okay, jetzt hat eine Person mit einem Claude-Abo wirklich das meiste, was eine kleine Kreativagentur bietet. Entwerfen. Code. Automatisierung. Präsentationen. Markenkonsistenz. Alles innerhalb desselben Ökosystems.

Das ist ein wilder Satz für das Jahr 2026. Aber ich glaube nicht, dass er übertrieben ist.

Was Claude Design eigentlich macht

Die Kurzversion: Du beschreibst, was du brauchst, und Claude erstellt eine erste Version. Dann verfeinerst du sie durch Konversation, Inline-Kommentare, direkte Bearbeitungen oder benutzerdefinierte Schieberegler, die Claude für dich erstellt. Claude basiert auf [Opus 4.7] (https://www.anthropic.com/news/claude-opus-4-7) und ist erstaunlich gut darin, die visuelle Konsistenz zu wahren.

Die Funktion, die meine Aufmerksamkeit erregt hat, ist das Onboarding. Während der Einrichtung liest Claude deine Codebasis und die vorhandenen Designdateien, um ein Designsystem für dein Team zu erstellen. Farben, Typografie, Komponenten. Danach folgt jedes Projekt automatisch deiner Marke. Du kannst Bilder und Dokumente (DOCX, PPTX, XLSX) importieren oder direkt auf deine Codebase verweisen. Es gibt ein Web-Capture-Tool, das Elemente von deiner Live-Website aufnimmt, damit die Prototypen wie das echte Produkt aussehen.

Du hast ein Figma-Mockup, das du überarbeiten möchtest? Exportiere es, füge es in Claude Design ein und beginne eine Diskussion darüber, was du ändern möchtest. Oder du nimmst einfach deine bestehende Website und sagst: "Vergrößere den Heldenbereich und füge ein Karussell mit Erfahrungsberichten hinzu." So etwas in der Art.

Die Aussagen in der Ankündigung sind aufschlussreich. Der leitende Produktdesigner von Brilliant sagte, dass seine komplexesten Seiten, die in anderen Tools mehr als 20 Eingabeaufforderungen benötigten, in Claude Design nur 2 Eingabeaufforderungen erforderten (https://www.anthropic.com/news/claude-design-anthropic-labs). Der Produktmanager von Datadog beschrieb, wie er von einer groben Idee zu einem funktionierenden Prototyp kommt, bevor jemand den Raum verlässt, und sagte, dass das, was früher eine Woche mit Briefings, Mockups und Review-Runden gedauert hat, jetzt in einem einzigen Gespräch passiert.

Eine Woche des Hin und Her wurde in einem einzigen Gespräch zusammengefasst. Denk mal eine Sekunde darüber nach.

Der Stapel, der alles verändert

An dieser Stelle wird es interessant. Claude Design existiert nicht für sich allein. Anthropic hat jetzt drei Produkte, die zusammen eine absurde Menge abdecken:

Claude Code: Schreiben, Prüfen und Ausliefern von Software. [Das Unternehmen hat im Februar 2,5 Milliarden Dollar Umsatz gemacht (https://www.anthropic.com/news/anthropic-raises-30-billion-series-g-funding-380-billion-post-money-valuation) und ist für schätzungsweise 4 % aller öffentlichen GitHub Commits weltweit verantwortlich.
Claude Cowork: Automatisiere Wissensarbeit. Recherche, Analyse, Dokumentenbearbeitung, wiederkehrende Aufgaben von deinem Desktop aus.
Claude Design: Erstelle visuelle Arbeiten. Prototypen, Präsentationen, Marketingmaterial, markenkonsistente Assets.

Und sie geben sich gegenseitig die Hand. Wenn ein Entwurf fertig ist, packt Claude alles in ein Übergabepaket, das du mit einer einzigen Anweisung an Claude Code weitergeben kannst. Design und Produktion in einem Arbeitsgang. Kein Jira-Ticket. Kein Übergabe-Meeting. Kein "Kannst du mir die Spezifikationen in Slack schicken".

Ich muss immer wieder an Sam Altmans Vorhersage von Anfang 2024 über [das Ein-Mann-Milliarden-Dollar-Unternehmen] (https://every.to/napkin-math/the-one-person-billion-dollar-company) denken. Damals klang das sehr ehrgeizig, vielleicht sogar ein bisschen übertrieben. Die Werkzeuge waren noch nicht da. Man konnte zwar Texte und Bilder erstellen, aber die Kluft zwischen der Erstellung von Dingen und dem Versand echter Produkte war enorm.

Diese Kluft schrumpft schnell.

Was ich vor zwei Monaten dafür gegeben hätte

Als ich Rasepi aufbaute, war die Marketingseite einer der mühsamsten Teile. Nicht der Code. Der Code war in Ordnung, Claude beherrscht HTML und CSS wie ein Meister. Aber die visuellen Designentscheidungen? Das Layout der Helden, die Preiskarten, die Vergleichstabellen der Funktionen? Ich beschrieb die Dinge in Worten, Claude produzierte etwas und dann verbrachte ich Stunden damit, Abstände, Farben und Typografie anzupassen. Alles mit Hilfe von Textanweisungen. Keine visuelle Feedbackschleife.

Mit Claude Design wird dieser Arbeitsablauf zu einem: "Hier ist meine Website" (Web-Capture), "Gestalte den Preisteil neu, um den Teamplan zu betonen" (Konversation), passe die grüne Akzentfarbe mit einem Schieberegler an, genehmige sie und übergebe sie an Claude Code zur Umsetzung. Ich schätze, das hätte mir ein ganzes Wochenende erspart.

(Ehrlich gesagt ärgere ich mich ein bisschen, dass es nicht schon zwei Monate früher gestartet ist).

Und der Canva-Export ist clever. [Canva hat 220 Millionen aktive Nutzer (https://backlinko.com/canva-users) und einen Jahresumsatz von 3 Milliarden Dollar. Anthropic versucht nicht, Canva zu ersetzen. Anthropic versucht, der Ort zu sein, an dem Ideen beginnen, bevor sie in Canva landen, um dort den letzten Schliff zu bekommen und verbreitet zu werden. Das ist ein kluger Schachzug zur Positionierung. Du erstellst deine Entwürfe in Claude Design und exportierst sie dann nach Canva, wo sie von deinem Marketingteam übernommen werden. Oder du exportierst es als PPTX für dein Investorendeck. Oder exportiere es als eigenständiges HTML für eine Landing Page.

Der Multiplikator "Einfach Tools hinzufügen"

Das ist das Muster, das ich in der KI-Branche im Jahr 2026 immer wieder sehe. Das Basismodell wird zwar intelligenter, aber der eigentliche Produktivitätssprung entsteht durch die Verknüpfung von Werkzeugen. Claude ist für sich genommen ein sehr intelligenter Textgenerator. Claude mit Code ist ein Softwareentwickler. Claude mit Cowork ist ein Forschungsanalyst. Claude mit Design ist ein Kreativdirektor. Claude mit allen dreien? Das ist eine kleine Agentur.

Und die Verbindungen werden immer mehr. Anthropic hat angekündigt, dass in den nächsten Wochen weitere Integrationen hinzukommen werden. Mit den MCP-Servern kannst du Claude bereits mit externen Tools und Datenquellen verbinden. Das Ökosystem baut sich selbst auf.

Für Einzelgründer/innen, Freiberufler/innen und kleine Teams ändert sich dadurch die Kalkulation komplett. Du brauchst keinen Designer mehr, um professionell aussehende Decks und Prototypen zu erstellen. Du brauchst keinen separaten Frontend-Entwickler, der Mockups in Code umwandelt. Du brauchst keinen Projektmanager, der die Übergabe zwischen Design und Technik koordiniert, denn es gibt keine Übergabe. Es ist eine kontinuierliche Konversation.

Ich sage nicht, dass Designer überflüssig sind. Weit gefehlt. Sowohl Brilliant als auch Datadog beschreiben, dass ihre Designer Claude Design verwenden. Das Tool macht gute Designer schneller und gibt allen anderen Zugang zu kompetenten visuellen Ergebnissen. Das ist etwas anderes, als Menschen zu ersetzen.

Was das für Dokumentationsprodukte bedeutet

Diese Entwicklung beobachte ich genau. Bei Rasepi bauen wir eine Dokumentationsplattform auf, bei der die visuelle Qualität wichtig ist. Einstiegsseiten müssen gut aussehen. Schnelleinstiegsanleitungen brauchen klare Diagramme. Marketingdokumente müssen in allen Sprachen und Teams einheitlich aussehen.

Eine Welt, in der jedes Teammitglied eine markenkonforme visuelle Dokumentation erstellen, sie an die Übersetzungsmaschine weitergeben und in sieben Sprachen verteilen kann, ohne Figma, Photoshop oder InDesign anfassen zu müssen? Das ist genau das Problem, das wir aus einem anderen Blickwinkel lösen. (Und ja, das ist genau die Art von Workflow, für die Rasepi entwickelt wurde).

Der Teil, in dem es seltsam teuer wird

Jetzt kommt der Teil, über den noch niemand gesprochen hat. Ich habe ein brandneues Anthropic-Konto erstellt, um Claude Design auszuprobieren. Ein neues Konto, keine Historie, keine vorherige Nutzung. Ich habe eine kleine Figma-Datei importiert und ein einziges Asset erstellt. Das war alles. Zwei Vorgänge. Und ich hatte kein Guthaben mehr.

Auf einem brandneuen Konto. Mit einer neuen Zuteilung.

Ich weiß nicht, wie die Berechnung auf Anthropics Seite aussieht, wenn Opus 4.7 die visuelle Generierung übernimmt, aber was auch immer es ist, es verbrennt die Credits in einem Tempo, das das Angebot "Ein-Personen-Kreativagentur" viel teurer erscheinen lässt als erwartet. Wenn das Importieren eines kleinen Figma-Mockups und das Erstellen eines Bildes dein gesamtes Budget auffrisst, ist es noch nicht wirtschaftlich, dies als tägliches Design-Tool zu nutzen.

Fairerweise muss man sagen, dass es sich hier um eine Forschungsvorschau handelt und sich die Preise wahrscheinlich noch ändern werden. Aber im Moment klafft eine große Lücke zwischen dem Versprechen (deinen Design-Workflow zu ersetzen) und der Realität (dein Guthaben könnte vor dem Mittagessen aufgebraucht sein). Die Produktivitätsgewinne sind real. Ob das Verhältnis von Credits zu Output es für den regelmäßigen Gebrauch praktisch macht, ist eine ganz andere Frage.

Der ehrliche Vorbehalt

Claude Design befindet sich in der Forschungsvorschau. Es wird raue Kanten haben. Die Erfahrungsberichte stammen von Design-Teams in gut finanzierten Unternehmen mit etablierten Design-Systemen. Das kann sich ändern, vor allem, wenn du bei Null anfängst und keine Markenrichtlinien hast.

Aber die Richtung ist klar. Vor achtzehn Monaten brauchte man einen Designer, einen Entwickler und einen Projektmanager, um vom Konzept zur fertigen Landing Page zu kommen. Heute kann eine einzelne Person mit einem Claude-Abonnement eine erstaunlich glaubwürdige Version desselben Workflows an einem Nachmittag erstellen.

Wir sind noch nicht bei der Ein-Personen-Milliarden-Dollar-Firma angekommen. Aber die Ein-Personen-Kreativagentur? Ich glaube, wir sind gerade angekommen.

Ein API-Schlüssel, viele Mieter: Wie wir DeepL Übersetzungen kundenübergreifend isolieren

2026-04-18T00:00:00Z

Jedes Mal, wenn ich einem anderen Entwickler die Übersetzungsarchitektur von Rasepi erkläre, taucht eine Frage auf: "Moment mal, alle deine Mieter teilen sich einen DeepL API-Schlüssel? Wie verhinderst du, dass ihre Glossare und Stilregeln ineinander übergehen?"

Das ist eine berechtigte Frage. Und die Antwort erfordert mehr Designarbeit, als du erwarten würdest.

Wir haben die vollständige Übersetzungspipeline in einem früheren Beitrag behandelt, das Hashing auf Blockebene, den Orchestrator, den gesamten Fluss vom Speichern des Dokuments bis zur übersetzten Ausgabe. Dieser Beitrag befasst sich mit dem speziellen Problem der Mandantenfähigkeit. Wie man eine API eines Drittanbieters nimmt, die kein Konzept für Mandanten hat, und darauf eine Mandantenisolierung aufbaut.

Das Problem: DeepL weiß nichts über deine Kunden

Die API von DeepL authentifiziert sich mit einem einzigen API-Schlüssel. Alles, was unter diesem Schlüssel erstellt wird - Glossare, Stilregel-Listen, Übersetzungshistorie - gehört zu demselben Konto. Auf DeepL gibt es kein Konzept, das besagt: "Dieses Glossar gehört zu Mieter A".

Wenn du GET /v2/glossaries aufrufst, erhältst du alle Glossare von allen Mietern. Wenn du eine Stilregel-Liste erstellst, befindet sie sich im gleichen Namensraum wie die Stilregeln aller anderen Tenants. Die API ist flach.

Für ein selbst gehostetes Produkt, bei dem jeder Kunde seine eigene Instanz mit seinem eigenen DeepL Schlüssel betreibt, ist das in Ordnung. Für ein SaaS mit mehreren Mandanten, bei dem wir die Infrastruktur verwalten? Du brauchst eine Isolationsschicht.

Die Datenbank ist die Quelle der Wahrheit

Unsere zentrale Designentscheidung: Die Datenbank ist Eigentümerin aller Glossarinhalte und der Konfiguration der Stilregeln. DeepL ist ein Ausführungsziel für die Laufzeit, nichts weiter.

Jede TenantGlossary und TenantStyleRuleList Entität implementiert ITenantScoped, was bedeutet, dass die globalen Abfragefilter von EF Core alle Lesevorgänge automatisch auf den aktuellen Tenant beschränken. Eine Abfrage nach Glossaren im Anfragekontext von Tenant A wird niemals die Einträge von Tenant B zurückgeben. Dies ist das gleiche Isolationsmuster, das wir überall in Rasepi verwenden und das auf ORM-Ebene durchgesetzt wird.

Das macht die Sache interessant. Wenn ein Tenant einen Glossarbegriff bearbeitet, rufen wir nicht sofort DeepL auf. Wir aktualisieren die Datenbankzeile und setzen IsDirty = true. Das war's. Das eigentliche DeepL Glossar wird in aller Ruhe erstellt (oder neu erstellt), bevor die nächste Übersetzung es braucht.

public async Task<string?> GetOrSyncDeepLGlossaryIdAsync(
    string sourceLanguage, string targetLanguage)
{
    var glossary = await _db.TenantGlossaries
        .Include(g => g.Entries)
        .FirstOrDefaultAsync(g =>
            g.SourceLanguage == sourceLanguage &&
            g.TargetLanguage == targetLanguage);

    if (glossary?.Entries.Count == 0) return null;

    if (!glossary.IsDirty && glossary.DeepLGlossaryId is not null)
        return glossary.DeepLGlossaryId;

    // Dirty: delete old, create new
    if (glossary.DeepLGlossaryId is not null)
        await _deepL.DeleteGlossaryAsync(glossary.DeepLGlossaryId);

    var entries = glossary.Entries
        .ToDictionary(e => e.SourceTerm, e => e.TargetTerm);

    var created = await _deepL.CreateGlossaryAsync(
        $"rasepi-{glossary.Id}",
        glossary.SourceLanguage,
        glossary.TargetLanguage,
        entries);

    glossary.DeepLGlossaryId = created.GlossaryId;
    glossary.IsDirty = false;
    glossary.LastSyncedAt = DateTime.UtcNow;
    await _db.SaveChangesAsync();

    return glossary.DeepLGlossaryId;
}

Der Abfragefilter auf TenantGlossaries sorgt für die Isolierung. Das IsDirty Flag sorgt für den lazy sync. Und die Namenskonvention (rasepi-{glossary.Id}) dient nur zum Debuggen im DeepL Dashboard, sie hat keinen funktionalen Zweck.

Warum lazy? Weil DeepL v2 Glossare unveränderlich sind. Du kannst sie nicht bearbeiten. Jede Änderung bedeutet löschen und neu erstellen. Wenn ein Team eine CSV-Datei mit 200 Begriffen importiert und dann einen Tippfehler in einem Eintrag korrigiert, wollen wir das Glossar DeepL nicht zweimal löschen und neu erstellen. Wir setzen einfach beide Male IsDirty und die einmalige Neuerstellung erfolgt, wenn die nächste Übersetzung läuft.

Stilregeln: gleiches Muster, andere API

Die [DeepL's style rules] (https://developers.deepl.com/docs/api-reference/translate/openapi-spec-for-text-translation) sind neuer (v3 API) und tatsächlich veränderbar, was schöner ist. Du kannst konfigurierte Regeln mit PUT /v3/style_rules/{style_id}/configured_rules aktualisieren, und benutzerdefinierte Anweisungen können individuell hinzugefügt oder entfernt werden.

Wir verwenden aber immer noch das gleiche IsDirty Muster. Ein TenantStyleRuleList hat einen DeepLStyleId, der dem Laufzeitbezeichner von DeepL entspricht, sowie ConfiguredRulesJson für die Formatierungsregeln und eine Sammlung von TenantCustomInstruction Einträgen für Freitext-Übersetzungsanweisungen.

Die eigentliche Stärke liegt in diesen benutzerdefinierten Anweisungen. Jede dieser Anweisungen ist eine Klartextanweisung mit bis zu 300 Zeichen, die bestimmt, wie DeepL übersetzt. Echte Beispiele von unseren Mietern:

"Verwende immer die Form 'Sie', niemals 'du'" für eine deutsche Anwaltskanzlei
"Übersetze 'deployment' als 'Bereitstellung', niemals 'Deployment'"_ für kontextabhängige Begriffe, die über einfache Glossarzuordnungen hinausgehen
"Verwende die britische Schreibweise (Farbe, Organisation, Lizenz)"_ für ein britisches Unternehmen, das zwischen verschiedenen englischen Varianten übersetzt
"Setze Währungssymbole hinter den numerischen Betrag"_ für europäische Konventionen

Jeder Tenant kann völlig unterschiedliche Anweisungen pro Zielsprache haben, die alle hinter demselben API-Schlüssel stehen. Die Isolierung ergibt sich aus der Tatsache, dass jeder Übersetzungsaufruf nur die glossary_id und style_id des anfragenden Tenants enthält. Die DeepL Ressourcen anderer Tenants werden nie referenziert.

Der Übersetzungsaufruf: alles setzt sich zusammen

Wenn der Orchestrator einen Block übersetzt, fügt er alle Tenant-spezifischen Einstellungen in einer einzigen Anfrage zusammen:

var glossaryId = await _glossaryService
    .GetOrSyncDeepLGlossaryIdAsync(sourceLang, targetLang);
var styleId = await _styleRuleService
    .GetOrSyncStyleIdAsync(targetLang);
var formality = langConfig.Formality ?? "default";

var options = new TranslationOptions
{
    GlossaryId = glossaryId,
    StyleId = styleId,
    Formality = formality,
    Context = documentContext,
    ModelType = styleId != null ? "quality_optimized" : null
};

Jeder Parameter hier ist mandantenspezifisch. Der glossaryId wurde durch eine Tenant-gefilterte Abfrage aufgelöst. Der styleId wurde auf die gleiche Weise aufgelöst. Die formality stammt von der TenantLanguageConfig, die ebenfalls tenant-scoped ist. Auch die context (umgebende Absätze, die zur Verbesserung der Übersetzungsqualität gesendet und nicht in Rechnung gestellt wurden) stammt aus dem eigenen Dokument des Mieters.

Eine Sache, die ich hervorheben möchte: Wenn style_id gesetzt ist, verwendet DeepL automatisch ihr quality_optimized Modell. Du kannst keine Stilregeln mit latency_optimized kombinieren. Das ist eine DeepL Einschränkung, aber ehrlich gesagt eine vernünftige Einschränkung. Wenn du in benutzerdefinierte Stilregeln investierst, willst du wahrscheinlich die beste Qualität erreichen.

Caching auf Blockebene: die Datenbank als Translation Memory

Wir rufen DeepL nicht für Blöcke auf, die sich nicht geändert haben. Der Caching-Mechanismus ist die TranslationBlock Tabelle selbst.

Jeder EntryBlock hat einen ContentHash, einen SHA256 seines semantischen Inhalts (wobei Metadatenattribute wie blockId und deleted entfernt werden). Jeder TranslationBlock speichert den SourceContentHash, der zum Zeitpunkt der Übersetzung aktuell war. Wenn sich der Quellblock ändert, ändert sich auch sein Hash. Der Orchestrator vergleicht die Hashes und stellt nur Blöcke in die Warteschlange, die nicht übereinstimmen.

Der Entscheidungsbaum für jeden Block sieht wie folgt aus:

Hash stimmt überein, Übersetzung existiert = überspringen (gecached, aktuell)
Hash geändert, maschinell übersetzt, nicht gesperrt = automatisch neu übersetzen
Hash geändert, von Menschen bearbeitet oder gesperrt = als veraltet markieren, nicht überschreiben

Der dritte Fall ist entscheidend. Wenn dein deutscher Übersetzer einen Absatz manuell überarbeitet hat, löschen wir ihn nicht, nur weil sich die englische Quelle geändert hat. Wir kennzeichnen ihn als veraltet, damit er weiß, dass er überarbeitet werden muss, aber der übersetzte Text bleibt intakt.

Das praktische Ergebnis: Die Bearbeitung eines Absatzes in einem Dokument mit 30 Absätzen löst genau einen DeepL API-Aufruf aus (na ja, einen Stapel, der einen Block enthält). Die anderen 29 Absätze in allen Sprachen sind bereits zwischengespeichert und kosten nichts.

Warum nicht einen eigenen Schlüssel pro Tenant verwenden?

Ich habe das ernsthaft in Erwägung gezogen. Gib jedem Tenant seinen eigenen DeepL API-Schlüssel und das Problem der Isolierung ist gelöst.

Drei Gründe, warum wir es nicht getan haben:

Komplexität der Abrechnung Jeder Mieter bräuchte sein eigenes DeepL Abonnement oder eine Möglichkeit, Unterkonten einzurichten. DeepL bietet von Haus aus keine mandantenfähige Schlüsselverwaltung.
Kosteneffizienz. Gemeinsame Infrastruktur bedeutet gemeinsame Tarifgrenzen und Mengenrabatte. Unsere Gesamtnutzung führt zu besseren Preisen.
Einfacher Betrieb. Ein Schlüssel zum Drehen, ein Kontingent zum Überwachen, eine Integration zum Pflegen.

Der Nachteil ist, dass wir die beschriebene Isolationsebene brauchen. Da wir aber bereits für alles andere im System mieterspezifische EF Core-Abfragen haben, war es ein Leichtes, diese in Glossare und Stilregeln einzubauen. Das Muster war bereits vorhanden.

Was dich wirklich schützt

Um die Isolationsgarantien zusammenzufassen:

Glossareinträge werden in TenantGlossary (implementiert ITenantScoped) gespeichert, gefiltert durch globale EF Core Abfragefilter. DeepL Glossar-IDs sind undurchsichtige Referenzen, die nur im Kontext des Tenants aufgelöst werden.
Stilregeln und benutzerdefinierte Anweisungen folgen dem gleichen Muster durch TenantStyleRuleList.
Übersetzte Inhalte befinden sich im TranslationBlock, der über seine übergeordnete Entry → Hub-Kette skaliert wird, die ebenfalls tenant-skaliert ist.
Der SaveChanges guard setzt TenantId automatisch bei neuen Entitäten und wird bei mandantenübergreifenden Schreibvorgängen geworfen.
Kein IgnoreQueryFilters() im Produktionscode. Immer.

Das Designprinzip ist einfach: DeepL sieht Ressourcen-IDs. Rasepi sieht tenant-scoped Entities. Die Zuordnung zwischen ihnen überschreitet niemals Tenant-Grenzen, da die Abfrage, die die Zuordnung auflöst, physisch nicht in der Lage ist, die Daten eines anderen Tenants zurückzugeben.

Wenn du ein mandantenfähiges SaaS aufbaust, das mit APIs von Drittanbietern ohne native Tenant-Unterstützung integriert wird, funktioniert dieses Muster gut. Behandle die externe API als zustandslose Ausführungsmaschine, speichere alle Konfigurationen in deiner eigenen Tenant-Datenbank, synchronisiere sie nachlässig und verlasse dich bei der Isolierung niemals auf externe Ressourcenauflistungen.

Tokens Burned ist der neue Lines of Code

2026-04-13T00:00:00Z

Mein LinkedIn-Feed ist schon seit Wochen voll davon. Meine X-Timeline auch. Leute posten Screenshots von Token-Ausgaben, als wären es Fortschrittsberichte. Startup-Gründer prahlen damit, dass sie letzten Monat 16.000 Dollar für Claude Code ausgegeben haben und im nächsten Monat 60.000 Dollar erreichen wollen. Bestenlisten. Ranglisten. Titel wie "Token-Legende" und "KI-Gott".

Und dann, letzte Woche, erreichte es die kritische Masse. Forbes berichtete über die "Tokenmaxxing"-Bewegung im Silicon Valley, bei der Unternehmen darum wetteifern, wer die meisten KI-Token verbrennt. Jensen Huang sagte im All-In-Podcast: "Diesen 500.000-Dollar-Ingenieur werde ich am Ende des Jahres fragen: 'Wie viel hast du in Token ausgegeben? Wenn er sagt: '5.000 Dollar', werde ich etwas anderes machen. Wenn dieser 500.000-Dollar-Ingenieur nicht mindestens Token im Wert von 250.000 Dollar verbraucht hat, werde ich zutiefst beunruhigt sein."

Dann berichtete [Fortune] (https://fortune.com/2026/04/09/meta-killed-employee-ai-token-dashboard/), dass ein Meta-Mitarbeiter eine interne Rangliste namens "Claudeonomics" erstellt hatte, in der der Token-Verbrauch der über 85.000 Mitarbeiter des Unternehmens erfasst wurde. Die Top-Nutzer bekamen Titel. In einem 30-Tage-Fenster erreichte die Gesamtnutzung 60 Billionen Token. Der Spitzenbenutzer verbrauchte im Durchschnitt 281 Milliarden. Mark Zuckerberg schaffte es nicht einmal unter die Top 250. Der CTO von Meta, Andrew Bosworth, sagte unterdessen öffentlich, dass sein bester Ingenieur sein Gehalt in Token ausgibt, aber "5- bis 10-mal produktiver" arbeitet. "Das ist einfaches Geld", sagte Bosworth. "No limit."

Ich bin lange genug in der Softwarebranche, um zu wissen, was hier passiert. Es handelt sich um "Codezeilen" mit einem viel höheren Preisschild.

Wir waren schon mal hier

Im Jahr 2003 schrieb Martin Fowler [eine kurze Abhandlung darüber, warum Softwareproduktivität nicht messbar ist] (https://martinfowler.com/bliki/CannotMeasureProductivity.html), die wahrscheinlich zur Pflichtlektüre für jede technische Führungskraft gehören sollte. Sein Argument zu den Codezeilen war präzise:

"Eines meiner größten Ärgernisse sind Produktivitätsstudien, die auf Codezeilen basieren. Jeder gute Entwickler weiß, dass er den gleichen Stoff mit riesigen Unterschieden in den Codezeilen programmieren kann."

Das Problem ist offensichtlich, wenn du es laut aussprichst. LOC misst die Aktivität, nicht den Output. Zwei Entwickler können das gleiche Feature bauen: Der eine schreibt 1.200 Zeilen, der andere 80. Der prägnante Entwickler hat wahrscheinlich ein besseres System gebaut. Unter dem LOC-Regime sieht der ausführliche Entwickler produktiver aus.

Teams, die nach LOC bewertet wurden, reagierten vernünftig. Sie schrieben mehr Zeilen. Sie kopierten, anstatt zu abstrahieren. Sie vermieden Refactoring, weil das Löschen von Code ihren Zahlen schaden würde. Die Kennzahl beeinflusste ihr Verhalten, aber nicht in Richtung besserer Software. Mehr Code. Schlechtere Systeme.

Im Jahr 2023 veröffentlichte McKinsey einen Artikel, in dem behauptet wurde, die objektive Messung der Entwicklerproduktivität geknackt zu haben. [Die ausführliche Antwort von Gergely Orosz und Kent Beck (https://newsletter.pragmaticengineer.com/p/measuring-developer-productivity) wies auf den gleichen Fehler hin: Fast alle McKinsey-Kennzahlen maßen Aufwand und Output, nicht aber das Ergebnis. Kent Beck hat beobachtet, wie Facebooks interne Umfragen zur Stimmung der Entwickler von nützlichem Feedback zu Verhandlungen zwischen Managern und Ingenieuren über höhere Punktzahlen wurden. Das passiert, wenn man Anreize für eine stellvertretende Kennzahl schafft. Die Zahl verbessert sich. Die Sache, um die du dich eigentlich kümmerst, nicht.

Man sollte meinen, wir hätten daraus gelernt. Haben wir aber nicht.

Gleicher Fehler, andere Einheit

Die verführerische Logik des Tokenmaxxing läuft folgendermaßen ab. Tokenverbrauch = KI-Nutzung. Mehr KI-Nutzung = Teams nutzen KI. Also: hohe Tokenausgaben = hohe KI-Nutzung = gut.

Das ist genauso fehlerhaft wie die Messung von Codezeilen, nur mit einem Billing-Dashboard statt einem Commit-Diagramm. Und um dem Forbes-Artikel gerecht zu werden, hat der CEO von Sendbird, John Kim, genau das gesagt: "Wir haben diesen Film schon einmal gesehen." Er bezog sich damit auf die LOC-Kultur der 1990er und 2000er Jahre. Der eigentliche Indikator sei, wie viel KI-generierter Code es tatsächlich in die Produktion schafft. Token-Ausgaben "sind eher ein Gesprächsanlass". Dem stimme ich zu. Problematisch wird es, wenn der Gesprächsanlass zum wichtigsten KPI wird.

Die [GitHub-Entwicklerumfrage 2024] (https://github.blog/news-insights/research/survey-ai-wave-grows/) ergab, dass 97 % der Entwickler in Unternehmen schon einmal KI-Codierungstools bei der Arbeit eingesetzt haben. Für eine sinnvolle Einführung im Unternehmen sind jedoch klare Richtlinien, Arbeitsabläufe und messbare Ergebnisse erforderlich, die an tatsächliche Geschäftsergebnisse gebunden sind. Nicht nur Nutzung. Nicht nur Konsum.

Boris Cherny, der Ingenieur hinter Claude Code, teilte öffentlich mit, dass er während eines Arbeitsmonats überhaupt keine IDE geöffnet und mit Opus 4.5 etwa 200 PRs geschrieben hat. Das ist beeindruckend. Aber das Beeindruckende sind nicht die Token, die diese 200 PRs verbraucht haben. Sondern dass es sich um 200 echte Beiträge mit funktionierender Software handelte, die am anderen Ende zusammengeführt wurden.

Der Wert liegt in dem Ergebnis. Token sind die Energie, die dich dorthin gebracht hat, mehr nicht.

Wenn die Metrik zum Ziel wird

Es gibt ein Prinzip namens Goodhart's Law: Wenn eine Messgröße zum Ziel wird, ist sie keine gute Messgröße mehr. Die Geschichte der Softwareentwicklung ist im Grunde ein Museum für Goodharts Gesetz in Aktion.

Die Verfolgung von Token als KPI für die KI-Einführung bringt genau dieselbe Dynamik mit sich. Ingenieurteams, die am Token-Verbrauch gemessen werden, werden mehr Token verbrauchen. So funktionieren Anreize nun mal. Willst du produktiver aussehen? Führe ein paar mehr agenturische Schleifen durch. Lass das Modell lange nachdenken, bevor es eine Ausgabe erzeugt. Verpacke jede Aufgabe in eine Orchestrierungsschicht, die vier Tools aufruft, wo sonst eines reicht. Die Ausgaben für Token steigen. Der gelieferte Wert jedoch nicht.

Die Geschichte von Claudeonomics hat das fast sofort bewiesen. Fortune stellte fest, dass "einige Mitarbeiter KI-Agenten stundenlang arbeiten lassen, um ihre Token-Nutzung zu maximieren". Da haben wir es. Goodharts Gesetz in Echtzeit, und das in einem Unternehmen, das angeblich an der Spitze der KI-gesteuerten Produktivität steht. Die Bestenliste war vielleicht ein paar Wochen lang online, bevor sie abgeschaltet wurde, und die Mitarbeiter spielten bereits mit ihr, indem sie Agenten in Schleifen laufen ließen. Die Kennzahl war drei Wochen alt und hatte bereits aufgehört, das zu messen, was sie eigentlich messen sollte.

Jedem Entwickler, der das hier liest, fallen wahrscheinlich fünf Möglichkeiten ein, wie man die Token-Nutzungskennzahlen aufblähen kann, ohne dass jemand davon profitiert. Ich werde sie nicht aufzählen. Aber wenn mir fünf einfallen, können das auch die Ingenieure, die hier gemessen werden.

Andrej Karpathy bezeichnete [den aktuellen Moment in der Softwareentwicklung] (https://x.com/karpathy/status/2004607146781278521) als ein "Erdbeben der Stärke 9" für den Berufsstand. Da hat er Recht. Aber Erdbeben werden nicht an der verbrauchten Energie gemessen. Sie werden an dem gemessen, was sich bewegt.

Die Dokumentationsversion dieses Problems

Das ist nicht nur ein Problem für Ingenieurteams. Die gleiche Dynamik sehe ich im Wissensmanagement, das uns bei Rasepi viel näher liegt.

"Wir haben in diesem Quartal 400 Dokumente veröffentlicht" ist eine Zahl, die in einem Slide Deck gut klingt. Sie sagt aber nichts darüber aus, ob diese Dokumente korrekt sind, ob sie jemand gelesen hat oder ob die darin enthaltenen Informationen sechs Monate später noch stimmen. Du kannst diese Zahl mit KI und ohne jegliches Denken erreichen. Token-gestütztes Rauschen im großen Stil veröffentlicht.

Die ehrliche Kennzahl ist schwieriger zu erheben, aber viel nützlicher: Wie viel Prozent deiner Wissensbasis spiegelt tatsächlich wider, wie deine Systeme heute funktionieren? Wie viele Menschen haben mit Hilfe deiner Dokumentation eine richtige Antwort gefunden? Wie viele haben es versucht, sind gescheitert und haben stattdessen jemanden auf Slack gefragt?

Für diese Fragen gibt es noch keine hübschen Dashboards. Sie erfordern konkrete Überlegungen darüber, was die Dokumentation für dein Unternehmen leisten soll. (Nicht zufällig ist das genau das Problem, für das Rasepi entwickelt wurde. Erzwungene Verfallsdaten gibt es genau deshalb, damit Teams sich Gedanken darüber machen müssen, ob Inhalte noch gültig sind, anstatt sie hinter einer hohen Seitenzahl stillschweigend verrotten zu lassen).

Was man stattdessen verfolgen sollte

Die ehrliche Antwort auf die Frage "Lohnt sich unsere KI-Investition?" lässt sich nicht an einem Dashboard ablesen.

Du kannst dich ihr mit besseren Fragen nähern: Verbessern sich die Durchlaufzeiten? Entwickelt sich das Verhältnis von ausgelieferten Funktionen zu gemeldeten Fehlern in die richtige Richtung? Berichten die Ingenieure, dass sie mehr Zeit mit urteilsintensiver Arbeit und weniger mit Tippen verbringen? Bleibt deine Dokumentation auf dem neuesten Stand, anstatt sich wie Sedimente anzusammeln?

Diese Fragen sind bei einer API schwieriger zu beantworten. Sie erfordern, dass du dir überlegst, was du eigentlich von deinen Teams willst, und das ist zugegebenermaßen die schwierigere Arbeit. Aber genau diese Fragen sind wichtig, denn es geht um das Ergebnis und nicht um den Input.

Die Token-Ausgaben sagen dir, wie viel Rechenleistung du gekauft hast. Ob diese Rechenleistung zu etwas Nützlichem wurde, ist eine ganz andere Frage. Unternehmen, die diesen Unterschied nicht beachten, werden sehr teure Dashboards bauen, die ihnen fast nichts zeigen.

Wir haben Jahre damit verbracht, die falsche Metrik für die Entwicklerproduktivität zu optimieren. Wir haben vielleicht noch ein Quartal Zeit, bevor derselbe Fehler in jedem Bericht über die Einführung von KI im Unternehmen auftaucht. Das Fenster, um das zu vermeiden, ist offen, aber das wird nicht so bleiben.

Die KI-Kluft spaltet dein Team in zwei Hälften

2026-04-10T00:00:00Z

Letzte Woche habe ich mit einem Freund telefoniert, der mir von einem seiner Kunden, einem Logistikunternehmen, erzählte. Ein Teamleiter hatte dort ein Planungstreffen, bei dem zwei seiner Mitarbeiter ein komplettes Szenariomodell mithilfe von KI erstellt hatten, bevor das Treffen überhaupt begann. Prognosen, Risikoaufschlüsselungen, drei alternative Ansätze. Die anderen vier Teammitglieder kamen mit demselben Folienformat, das sie schon seit zwei Jahren verwenden. Dieselbe Struktur, derselbe manuelle Prozess, dieselben Zeitvorgaben.

Das Treffen lief schnell aus dem Ruder. Das KI-unterstützte Paar konnte nicht verstehen, warum die anderen nicht die grundlegenden Vorbereitungen getroffen hatten, die "jetzt fünf Minuten dauern". Die anderen fühlten sich überrumpelt, als hätten sich die Spielregeln geändert und niemand hätte es ihnen gesagt. Der Teamleiter verbrachte den Rest des Tages mit Schadensbegrenzung.

Diese Geschichte überrascht mich nicht mehr. Ich höre sie schon seit Monaten immer wieder.

Die Lücke ist jetzt messbar

Das ist nicht nur ein Gefühl. Microsofts [2025 Work Trend Index] (https://www.microsoft.com/en-us/worklab/work-trend-index/2025-the-year-the-frontier-firm-is-born), eine Umfrage unter 31.000 Arbeitnehmern in 31 Ländern, ergab, dass 67% der Führungskräfte mit KI-Agenten vertraut sind, verglichen mit nur 40% der Arbeitnehmer. Führungskräfte sehen KI viel eher als Karrierebeschleuniger (79 % gegenüber 67 % der Arbeitnehmer/innen) und sie sparen damit auch mehr Zeit. Fast ein Drittel der Führungskräfte sagt, dass sie durch KI jeden Tag mehr als eine Stunde Zeit sparen.

Aber hier ist der Teil, der mich wirklich beeindruckt hat: Auf die Frage, wie sie KI sehen, gaben 52% der Befragten an, dass sie sie als ein kommandobasiertes Werkzeug betrachten. Gib eine Anweisung und erhalte ein Ergebnis. Nur 46 % bezeichneten sie als Denkpartner, mit dem man sich austauschen kann.

Das ist kein kleiner Unterschied. Das sind zwei grundverschiedene Beziehungen zu ein und derselben Technologie. Und diese beiden Gruppen sitzen in denselben Meetings, arbeiten an denselben Projekten und bewegen sich angeblich in dieselbe Richtung.

Zwei Geschwindigkeiten, ein Team

Die praktische Folge ist, dass die Teams jetzt mit zwei völlig unterschiedlichen Geschwindigkeiten arbeiten. Diejenigen, die KI in ihre tägliche Arbeit integriert haben, produzieren nicht nur schneller. Sie denken anders. Sie gehen Probleme anders an. Sie kommen zu Besprechungen und erledigen Arbeiten, die früher eine Woche dauerten, an einem Nachmittag.

Und die Leute, die keine KI einsetzen (oder die es einmal ausprobiert haben, es nicht überzeugend fanden und weitergemacht haben), leisten wirklich solide Arbeit. Das möchte ich klarstellen. Es geht nicht darum, dass sie schlecht in ihrem Job sind. Es geht darum, dass sich die Grenze des Möglichen verschoben hat und sie unter der alten Grenze arbeiten.

Eine [Harvard-Studie über generative KI in Teams] (https://papers.ssrn.com/sol3/papers.cfm?abstract_id=5188231) hat etwas Bemerkenswertes herausgefunden: Eine einzelne Person mit KI übertrifft ein ganzes Team ohne sie. Aber ein Team, in dem jeder KI einsetzt, übertrifft sie alle. Die Konsequenz ist brutal. Die gemischte Einführung bietet keinen Mittelweg. Sie führt zu Reibung.

Ich habe das bei einem Workshop, den ich letzten Monat geleitet habe, aus erster Hand erfahren. Die Teilnehmer, die regelmäßig KI nutzten, beendeten die Übungen in der Hälfte der Zeit und warteten dann frustriert auf den Rest. Die Teilnehmer, die keine KI nutzten, fühlten sich gehetzt und, ehrlich gesagt, auch ein bisschen gedemütigt. Niemand hat dieses Ergebnis beabsichtigt. Es ist einfach passiert, weil der Geschwindigkeitsunterschied jetzt so groß ist.

Der Wettbewerbsvorteil, über den niemand spricht

Hier wird es wirklich folgenreich. Die McKinsey-Studie [State of AI 2025] (https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai) ergab, dass 88 % der Unternehmen KI in mindestens einer Funktion einsetzen. Klingt toll, oder? Aber fast zwei Drittel befinden sich noch in der Experimentier- und Pilotphase. Nur etwa ein Drittel hat damit begonnen, KI in ihrem Unternehmen zu verbreiten. Und die Unternehmen, die bereits skaliert haben und die McKinsey als "High Performer" bezeichnet? Sie machen etwa 6 % der Befragten aus.

Diese 6 % setzen sich mit einer Geschwindigkeit von allen anderen ab, die meiner Meinung nach von den meisten Menschen unterschätzt wird.

Bei den High Performern ist es dreimal wahrscheinlicher, dass sie ihre Arbeitsabläufe im Hinblick auf KI grundlegend umgestaltet haben. Sie haben dreimal häufiger Führungskräfte, die sich aktiv für den Einsatz von KI einsetzen und diese vorleben. Drei Viertel von ihnen skalieren KI in ihrem Unternehmen oder haben sie bereits skaliert, verglichen mit einem Drittel aller anderen.

Die Daten von Microsoft erzählen eine ähnliche Geschichte. Unternehmen, die sie als "Frontier Firms" bezeichnen (Unternehmen mit unternehmensweitem KI-Einsatz und fortgeschrittenem Reifegrad), berichten von dramatisch anderen Ergebnissen. 71% der Führungskräfte von Frontier Firms sagen, dass ihr Unternehmen floriert, verglichen mit 39% der Beschäftigten weltweit. 55% sagen, dass sie mehr Arbeit übernehmen können, im Vergleich zu 25% weltweit. Und sie haben weniger Angst davor, dass KI ihre Jobs übernimmt, nicht mehr.

Die Kluft zwischen diesen Unternehmen und allen anderen wird nicht kleiner. Er vergrößert sich vielmehr.

Dies ist ein menschliches Problem, das als technologisches Problem getarnt ist.

Die Versuchung ist groß, dieses Problem mit Tools zu lösen. Führe Copilot ein, kaufe ein paar Lizenzen und sende eine unternehmensweite E-Mail über KI-Ressourcen. Erledigt.

Aber die eigentliche Herausforderung ist kultureller Natur. Es ist der Teamleiter, der versucht, eine Gruppe zusammenzuhalten, in der sich die Hälfte der Mitarbeiter/innen überfordert und die andere Hälfte zurückgelassen fühlt. Es ist der Manager, der einem 20-jährigen Veteranen erklären muss, dass sein Arbeitsablauf, den er über ein Jahrzehnt hinweg perfektioniert hat, vielleicht nicht mehr der beste Ansatz ist. Es ist der junge Mitarbeiter, der im Stillen KI einsetzt, um Arbeit auf höchster Ebene zu produzieren, und nicht weiß, ob er stolz sein soll oder sich Sorgen über die politischen Folgen machen soll.

Microsoft hat herausgefunden, dass 47 % der Führungskräfte die Weiterbildung ihrer Mitarbeiter/innen als eine der wichtigsten Personalstrategien nennen. Das ist ermutigend, denke ich. Aber Qualifizierung funktioniert nur, wenn die Menschen auch wirklich lernen wollen. Und im Moment hat ein großer Teil der Belegschaft beschlossen, dass KI entweder nicht relevant für sie ist, nicht zuverlässig oder den Aufwand nicht wert ist. Einige von ihnen mögen mit bestimmten Tools Recht haben. Aber die allgemeine Entwicklung ist nicht optional (ich sage das als jemand, der im Laufe der Jahre vielen Tech-Hype-Zyklen skeptisch gegenüberstand, aber dieser ist anders).

Wohin geht die Reise?

Ich glaube nicht, dass die Kluft verschwindet. Ich glaube, dass sie sich vergrößert. Diejenigen, die KI einsetzen, werden immer schneller werden, immer mehr produzieren und die Messlatte für eine "normale Leistung" immer höher legen. Diejenigen, die das nicht tun, werden immer mehr Druck verspüren, sei es vom Management, von den Kollegen oder einfach von der Tatsache, dass ihre Kollegen Dinge tun, die sie nicht können.

Unternehmen, die herausfinden, wie sie ihr gesamtes Team mitreißen können, nicht nur die Enthusiasten, haben einen echten Vorteil. Und dieser Vorteil wächst. Jeder Monat, in dem das Unternehmen KI beherrscht, ist ein Monat, in dem deine Konkurrenten darüber streiten, ob sie ChatGPT-Lizenzen kaufen sollen.

Der größte Wettbewerbsvorteil in der KI-Ära wird nicht sein, welches Modell du verwendest. Es geht darum, ob dein gesamtes Team es tatsächlich nutzt.

Das Logistikteam, das ich erwähnt habe? Mein Freund hat mir erzählt, dass der Teamleiter einen zweitägigen internen Workshop gebucht hat. Nicht "So wird geprompt". Sondern eher: "So ändern wir unsere gemeinsame Planung." Die Skeptiker mussten sehen, was im Kontext ihrer Arbeit möglich war, nicht in einer allgemeinen Demo mit einem erfundenen Szenario. Und die Enthusiasten mussten Geduld lernen. Sie mussten die Leute mitnehmen, anstatt ihnen vorzurennen.

Das ist genau die Aufgabe, die wir jetzt haben. Nicht nur KI einführen. Die Lücke zu schließen. Bevor sie dich einholt.

Build vs. Buy Reimagined: Was es im Jahr 2026 wirklich bedeutet

2026-04-07T00:00:00Z

Letzte Woche habe ich gesehen, wie ein Nachwuchsentwickler in unserem Team innerhalb von 90 Minuten eine funktionierende CRUD-App mit Autorisierung, Datenbankmigrationen und einer halbwegs anständigen Benutzeroberfläche auf die Beine gestellt hat. Mit Copilot. Von Grund auf.

Vor fünf Jahren hätte die gleiche Aufgabe noch eine Woche gedauert. Vielleicht sogar zwei, wenn man das Herumhantieren mit Einsatzkonfigurationen und OAuth-Flows mitzählt. Und dieser Wandel, die Verkürzung der Entwicklungszeit von Tagen auf Stunden, löst eine der ältesten Fragen in der Softwarebranche auf: Sollen wir bauen oder kaufen?

Das alte Framing ist tot

Jahrzehntelang war die Frage "bauen oder kaufen" eine Kostenkalkulation. Man schätzte, wie viele Entwicklermonate es dauern würde, eine Sache zu entwickeln, multiplizierte das mit dem Gehalt, fügte einen Puffer für die Wartung hinzu und verglich das Ganze mit der jährlichen Lizenzgebühr für ein SaaS-Produkt, das in etwa das Gleiche leistete. Wenn das SaaS-Produkt billiger war, hast du es gekauft. Wenn deine Anforderungen seltsam genug waren, hast du etwas gebaut.

Bei dieser Vorgehensweise wurde davon ausgegangen, dass Bauen teuer sei. Und das war es auch. Aber [laut den Octoverse 2025-Daten von GitHub] (https://github.blog/ai-and-ml/generative-ai/how-ai-is-reshaping-developer-choice-and-octoverse-data-proves-it/) führt die KI-gestützte Entwicklung heute zu einer Steigerung des Durchsatzes um 20 bis 30 Prozent. Achtzig Prozent der neuen Entwickler auf GitHub nutzen Copilot innerhalb ihrer ersten Woche. Über 1,1 Millionen öffentliche Repositories integrieren bereits LLM-SDKs. Das Bauen wurde fast über Nacht drastisch billiger.

Die Frage lautet also nicht mehr wirklich "bauen oder kaufen". Sie lautet vielmehr: Wofür bezahlst du eigentlich, wenn du SaaS kaufst?

Das neue Kalkül

Ich glaube, die meisten SaaS-Gründer (mich eingeschlossen, ehrlich gesagt) wollen Folgendes nicht hören: Wenn dein gesamtes Wertversprechen lautet: "Wir haben dich davor bewahrt, es selbst zu entwickeln", hast du ein Problem. Denn der Wassergraben ist gerade sehr viel flacher geworden.

Wenn ein Team ein funktionierendes internes Tool an einem Tag entwickeln kann, liegt die Messlatte für die Rechtfertigung eines monatlichen Abonnements sehr hoch. Du musst nicht nur besser sein als das, was sie bauen können. Du musst besser sein als das, was sie mit Hilfe von KI bauen könnten.

[Gartner prognostizierte im April 2026 (https://www.gartner.com/en/newsroom/press-releases/2026-04-02-gartner-expects-most-enterprises-to-abandon-assistive-ai-for-outcome-focused-workflow-by-2028), dass bis zum Jahr 2028 mehr als die Hälfte aller Unternehmen nicht mehr für unterstützende Intelligenz bezahlen, sondern Plattformen bevorzugen werden, die auf Workflow-Ergebnisse setzen. Noch deutlicher: Gartner geht davon aus, dass bis 2030 die Gewinnspanne von Softwareunternehmen, die KI über bestehende Anwendungen schichten, anstatt sie für eine agentenbasierte Ausführung umzugestalten, um bis zu 80 % sinken wird.

Achtzig Prozent. Das ist kein Rundungsfehler.

Was überlebt eigentlich?

Ich habe viel über diese Frage nachgedacht, auch weil wir Rasepi bauen und ich mir selbst gegenüber ehrlich sein muss, wo unser Wert liegt. Und ich glaube, die Antwort liegt in drei Dingen, die wirklich schwer in einem Wochenend-Coding-Sprint zu erreichen sind, egal wie gut dein KI-Assistent ist.

Domänentiefe kann man nicht fälschen Jeder kann einen Texteditor bauen. Aber ein Übersetzungssystem zu entwickeln, das inhaltliche Änderungen auf Absatzebene verfolgt, veraltete Übersetzungen durch Content-Hashing erkennt und strukturelle Anpassungen in verschiedenen Sprachen vornimmt? Dafür braucht man jahrelanges Fachwissen, das in die Architektur einfließt. Die KI kann dir helfen, den Code schneller zu schreiben, aber sie kann dir nicht sagen, was du bauen sollst.

Jemand muss es immer noch ausführen und pflegen. Das ist das Schöne am Bauen: Es macht Spaß. Pflegen? Macht überhaupt keinen Spaß. Der Umgang mit Grenzfällen in mandantenfähigen Berechtigungssystemen, das Aufpassen auf Browser-Macken, das Verwalten von versionsübergreifenden Datenbankmigrationen, das Patchen von CVEs um 2 Uhr morgens, der Umgang mit dem einen PDF-Exportfehler, der nur in Safari auftritt. KI macht den ersten Build schneller, klar. Aber die [Forrester-Studie vom April 2026] (https://www.forrester.com/press-newsroom/forrester-three-years-into-genai-enterprises-are-still-chasing-its-true-transformative-value/) zeigt, dass die meisten Unternehmen immer noch nicht in der Lage sind, den Einsatz von KI in messbare Erfolge umzuwandeln, was zum Teil daran liegt, dass der schwierige Teil nie das Schreiben von Code war. Die Schwierigkeit besteht darin, das Ding am Laufen zu halten, es zu aktualisieren und über Jahre hinweg korrekt zu arbeiten. Die Entwicklung ist der einfache Teil. Es sind die Betriebszeit, die Bereitschaftsdienste und die inkrementellen Korrekturen, die dich wirklich etwas kosten.

Vertrauen, Sicherheit und Datenschutz. Dieser Punkt wird unterschätzt. Wenn du etwas selbst baust, bist du für die Sicherheit verantwortlich. Du bist verantwortlich für die Verschlüsselung im Ruhezustand, die Protokollierung von Audits, Penetrationstests, die Einhaltung der GDPR, SOC 2 und die nächste Vorschrift, von der noch niemand gehört hat. Ein guter SaaS-Anbieter hat ein ganzes Team, dessen einzige Aufgabe darin besteht, dafür zu sorgen, dass deine Daten nicht irgendwo landen, wo sie nicht sein sollten. Für die meisten Unternehmen sind das keine Kosten, die sie intern tragen wollen. Und ehrlich gesagt, haben die meisten internen Tools, die ich gesehen habe, nicht einmal eine angemessene Zugangskontrolle, geschweige denn einen Sicherheits-Audit-Trail.

The Composable Middle Ground

Interessant ist, dass die Antwort zunehmend nicht "bauen" oder "kaufen" lautet. Sie lautet "komponieren". Wähle die SaaS-Tools, die schwierige Aufgaben gut erledigen, gute APIs zur Verfügung stellen und dich um sie herum bauen lassen.

Deshalb sind Plugin-Architekturen im Moment so wichtig (und ja, genau darin haben wir mit dem Plugin-System von Rasepi investiert). Die SaaS-Produkte, die erfolgreich sein werden, sind diejenigen, die sagen: "Wir kümmern uns um die schwierigen domänenspezifischen Fragen: "Wir kümmern uns um den harten, domänenspezifischen Kern. Du passt alles andere an." Nicht: "Hier ist unser Monolith, nimm ihn oder lass es".

[Der Forrester-Bericht vom April 2026 (https://www.forrester.com/press-newsroom/forrester-three-years-into-genai-enterprises-are-still-chasing-its-true-transformative-value/) zeigt, dass die meisten Unternehmen immer noch Schwierigkeiten haben, die Einführung von KI in messbare Geschäftseffekte umzusetzen. Diejenigen, die KI bereits eingeführt haben, arbeiten mit 47 % höherer Wahrscheinlichkeit mit Beratungspartnern zusammen, um ihre Daten und Systeme vorzubereiten. Die Botschaft ist klar: Die bloße Entwicklung von Fähigkeiten ist nicht der Engpass. Der eigentliche Engpass besteht darin, zu wissen, was man bauen will, und die Infrastruktur zu haben, um es zu unterstützen.

Was das für SaaS bedeutet

Wenn du im Jahr 2026 ein SaaS-Unternehmen leitest, gibt es ein paar unangenehme Wahrheiten:

Das Argument "Wir sparen Ihnen Zeit" ist schwächer denn je. Zeitersparnis war der klassische SaaS-Verkaufsgrund. Aber wenn KI die Entwicklungszeit um 20-30% verkürzt, schrumpft die Zahl "Zeitersparnis" in deiner ROI-Tabelle proportional dazu. Du brauchst eine andere Geschichte.
Niemand interessiert sich dafür, dass du 47 Integrationen hast. Für sie ist es wichtig, dass ihre Dokumentation aktuell bleibt, ihre Übersetzungen korrekt sind und ihr Team das Tool tatsächlich nutzt. Was Gartner über den "ergebnisorientierten Workflow" sagt, ist nicht nur Analystenjargon. Es ist die Richtung, in die sich der Markt bewegt.
Offenheit schlägt Abschottung Der Instinkt, die eigene Plattform zu schließen und den Wechsel zu erschweren, ist verständlich. Gartner warnte jedoch ausdrücklich davor, dass "ältere SaaS-Anbieter, die versuchen, ihre Systeme zu schließen, Gefahr laufen, von Orchestrierungsebenen umgangen zu werden, denen Unternehmen mehr vertrauen." Autsch.

Die ehrliche Version

Ich will ganz offen sagen, wo ich in dieser Sache stehe. Beim Vergleich zwischen Bauen und Kaufen ging es nie wirklich um die Technologie. Es ging immer um Vertrauen. Vertraue ich diesem Anbieter, dass er mein Problem so gut versteht, dass seine Lösung besser ist als das, was ich selbst zusammenschustern könnte?

Im Jahr 2026 wurde "zusammenschustern" massiv aufgewertet. Damit wurde auch die Vertrauenslatte höher gelegt.

Für uns bei Rasepi bedeutet das, dass wir nicht nur ein Dokumentationswerkzeug sein können, das zufällig Übersetzungen unterstützt. Wir müssen so gut in den schwierigen Problemen sein, in der Nachverfolgung von Übersetzungen auf Blockebene, in der Durchsetzung der Aktualität von Inhalten und in der Komplexität mehrerer Mandanten, dass es selbst mit den besten KI-Tools der Welt sehr mühsam wäre, einen Ersatz zu entwickeln.

Das ist das neue Build vs. Buy. Nicht "Kannst du es bauen?", sondern "Solltest du deine Energie darauf verwenden, es zu bauen, wenn jemand anderes die schwierigen Teile bereits gelöst hat?"

Die Frage war nie wirklich eine Frage der Kosten. Es ging darum, worauf du deine Aufmerksamkeit verwenden willst. Und in einer Welt, in der Bauen billig ist, ist Aufmerksamkeit die einzige knappe Ressource, die bleibt.

Hör auf, Leute zu feuern, weil es KI gibt

2026-04-04T00:00:00Z

Eine Freundin von mir ist für die Inhalte eines mittelgroßen SaaS-Unternehmens zuständig. Letztes Jahr bestand ihr Team aus acht Personen. Autoren, Redakteure, ein Lokalisierungsspezialist und jemand, der sich um die Wissensdatenbank kümmert. Ein gutes Team, solide Arbeit. Dann besuchte der Geschäftsführer eine Konferenz, kam begeistert von KI zurück und innerhalb von drei Monaten war das Team auf drei Personen geschrumpft. Die Begründung? _"Mit KI-Tools können drei Leute das schaffen, was früher acht Leute geschafft haben." _

Und technisch gesehen stimmt das auch. Die drei verbliebenen Mitarbeiter produzieren ungefähr das gleiche Volumen. Blogbeiträge, Hilfedokumente, Produktaktualisierungen, interne Kommunikation. Auf einem Dashboard sehen die Zahlen gut aus.

Aber meine Freundin hat seit Monaten nicht mehr richtig geschlafen. Sie wechselt zwischen Schreiben, Redigieren, Prompt-Engineering, Qualitätssicherung der KI-Ausgabe, Übersetzungsmanagement und all den strategischen Aufgaben, die früher im Team verteilt waren. Ihre beiden verbleibenden Kollegen sitzen im selben Boot. Einer von ihnen ist bereits auf der Suche nach einem anderen Job.

Das Unternehmen hat fünf Gehälter eingespart. Außerdem verliert es langsam die drei Leute, die wirklich wissen, wie die Dinge funktionieren.

Die Mathematik, die richtig aussieht, aber es nicht ist

Seit ChatGPT in aller Munde ist, macht das folgende Argument die Runde in den Chefetagen: Eine Person mit KI kann jetzt die Arbeit von zehn Personen erledigen. Und wenn das so ist, warum dann noch zehn?

Das ist ein überzeugendes Argument. Einfach. Sauber. Passt auf eine Folie.

Aber es ist auch gefährlich unvollständig.

Ja, KI kann Aufgaben komprimieren. Laut [Microsofts 2024 Work Trend Index] (https://www.microsoft.com/en-us/worklab/work-trend-index/ai-at-work-is-here-now-comes-the-hard-part) sagen 90 % der KI-Nutzer am Arbeitsplatz, dass die Tools ihnen helfen, Zeit zu sparen. Die intensivsten Nutzer von Microsoft Teams haben mit Copilot in einem einzigen Monat acht Stunden an Meetings zusammengefasst. Das ist ein ganzer Arbeitstag, der allein durch die Zusammenfassungen von Meetings gewonnen wurde. Und 85% sagen, dass KI ihnen hilft, sich auf ihre wichtigste Arbeit zu konzentrieren.

Das sind reale Zahlen. Die Produktivitätsgewinne sind nicht eingebildet.

Aber die Leute, die "neun Leute feuern", reden nie darüber: Die Person, die übrig bleibt, übernimmt nicht nur den Output. Sie übernimmt die kognitive Belastung, den Kontext, die Entscheidungsfindung, die Koordination, die Qualitätssicherung und jedes bisschen institutionelles Wissen, das mit den neun ehemaligen Kollegen zur Tür hinausging.

Geistige Belastung ist keine Tabellenkalkulation

In der Psychologie gibt es ein Konzept namens kognitive Belastungstheorie. Sie beschreibt die Gesamtmenge der geistigen Anstrengung, die zu einem bestimmten Zeitpunkt im Arbeitsgedächtnis verbraucht wird. Und jedes Mal, wenn du eine Person bittest, die Denkarbeit zu übernehmen, die sich früher fünf Personen geteilt haben, sparst du keine Anstrengung. Du konzentrierst sie vielmehr.

Ich denke oft darüber nach, wenn mir gesagt wird, dass KI die Arbeitnehmer "10x produktiver" macht. Produktiv bei was? Mehr Wörter zu produzieren? Mehr Tickets verschicken? Mehr Foliendokumente erstellen? Sicherlich. Aber das eigentlich Schwierige an der Wissensarbeit war noch nie das Produzieren. Es ist das Denken. Die Entscheidung, was produziert werden soll. Das Verstehen von Zusammenhängen. Entscheidungen zu treffen. Zu wissen, wann etwas falsch ist, auch wenn es auf den ersten Blick richtig aussieht.

KI macht das nicht für dich. Die KI liefert dir einen ersten Entwurf, und du musst klug genug sein, um ihn zu bewerten, erfahren genug, um die subtilen Fehler zu erkennen, und präsent genug, um zu bemerken, wenn das Ergebnis mit Sicherheit falsch ist. (Wenn du schon einmal beobachtet hast, wie jemand eine von der KI erstellte interne Dokumentation verschickt, ohne sie zu lesen, weißt du genau, was ich meine).

[Der Gallup-Bericht "2025 State of the Global Workplace" (https://www.gallup.com/workplace/659279/global-engagement-falls-second-time-2009.aspx) hat ergeben, dass das Engagement der Mitarbeiter/innen weltweit von 23% im Vorjahr auf 21% im Jahr 2024 gesunken ist. Dieser Rückgang kostete die Weltwirtschaft schätzungsweise 438 Milliarden Dollar an verlorener Produktivität. Das Engagement von Managern sank sogar noch stärker, nämlich von 30 % auf 27 %. Bei weiblichen Managern betrug der Rückgang sieben Prozentpunkte. Bei Managern unter 35 Jahren waren es fünf Prozentpunkte.

Das sind die Leute, die die Einführung von KI anführen sollen. Und sie sind ausgebrannt.

Das Argument der Verstärkung

Ich möchte dir einen anderen Weg zeigen, darüber nachzudenken.

Wenn eine Person mit KI die Arbeit von zehn erledigen kann, dann können zehn Menschen mit KI die Arbeit von hundert erledigen.

Lies das noch einmal. Denn das ist der Teil, über den fast niemand spricht und der jeden CEO nachts wach halten sollte. Nicht, weil es beängstigend ist, sondern weil es eine riesige Chance ist, die die meisten Unternehmen verschenken.

Die Unternehmen, die die Hälfte ihrer Belegschaft entlassen, weil "KI das schon schafft", sind nicht effizient. Sie sind kurzsichtig. Sie optimieren für eine vierteljährliche Mitarbeiterzahl, während ihre Konkurrenten herausfinden, was passiert, wenn man einem ganzen Team motivierter, erfahrener Leute mächtige Werkzeuge in die Hand gibt.

Das habe ich letzten Monat bei einem Startup-Event in Zürich gesehen. Zwei Unternehmen in der gleichen Branche. Ungefähr die gleiche Größe, der gleiche Markt. Unternehmen A hatte sein Content-Team von zwölf auf vier reduziert. Unternehmen B behielt alle zwölf und gab ihnen KI-Tools und Schulungen. Rate mal, welches Unternehmen mehrsprachige Inhalte in sechs Sprachen produzierte, mit neuen Formaten experimentierte und wöchentliche Produktaktualisierungen für seine Wissensdatenbank lieferte? (Es war nicht Unternehmen A.)

Was passiert eigentlich, wenn du die

Lass mich dir erklären, was in der Praxis passiert, wenn du ein zehnköpfiges Team durch ein oder zwei "KI-gestützte" Superarbeiter ersetzt.

Woche eins fühlt sich großartig an. Die verbleibenden Leute sind voller Energie. Sie haben neue Werkzeuge. Sie produzieren eine Menge. Die Führung ist begeistert. Die Zahlen auf dem Dashboard sehen im Verhältnis zur Mitarbeiterzahl unglaublich aus.

Im zweiten Monat zeigen sich die Risse. Die eine Person, die für die Dokumentation verantwortlich ist, entdeckt, dass die von der KI erstellten Inhalte ernsthaft überprüft werden müssen. Keine leichte Bearbeitung. Eine gründliche Überprüfung. Denn die KI kennt weder die Feinheiten deines Produkts noch den Kontext deiner Kunden oder die drei Dinge, die du letzte Woche geändert hast und die die Hälfte des Geschriebenen ungültig machen. Allein die Überarbeitung frisst die Zeit auf, die durch die schnellere Erstellung von Inhalten "gespart" wurde.

Vierter Monat, institutionelle Wissenslücken tauchen auf Erinnerst du dich an die acht Leute, die du entlassen hast? Sie haben nicht nur Inhalte geschrieben. Sie hatten Beziehungen zu den Produktmanagern. Sie kannten die Probleme der Kunden, weil sie jahrelang Support-Tickets bearbeitet hatten. Sie wussten, welche Dokumentationsthemen die meisten Fragen aufwerfen. Dieses Wissen ist nun weg. Die KI hat es ganz sicher nicht.

**Im sechsten Monat stellst du Fremdfirmen ein, weil die verbliebenen Mitarbeiter überfordert sind, die Qualität gesunken ist und jemandem endlich aufgefallen ist, dass die Wissensdatenbank seit Wochen nicht mehr richtig aktualisiert wurde. Aber die Auftragnehmer haben auch keinen Kontext, also zahlst du mehr pro Stunde für schlechtere Ergebnisse.

Ich denke mir das nicht aus. Allein im letzten Jahr habe ich beobachtet, wie sich dieses Muster bei drei verschiedenen Unternehmen wiederholt hat.

Die Daten sagen: Behalte deine Leute (und bilde sie aus)

Der [World Economic Forum's Future of Jobs Report 2025] (https://www.weforum.org/publications/the-future-of-jobs-report-2025/digest/) hat über 1.000 Arbeitgeber weltweit zu ihren Personalplänen befragt. Die Zahlen erzählen eine interessante Geschichte. Ja, 40 % der Arbeitgeber planen, Personal abzubauen, wenn KI Aufgaben automatisiert. Aber 85% planen, ihre bestehenden Mitarbeiter/innen weiterzubilden. Und 70 % erwarten, dass sie neue Mitarbeiter/innen mit neuen Fähigkeiten einstellen, nicht weniger.

Der Bericht prognostiziert einen Nettozuwachs von 78 Millionen Arbeitsplätzen bis 2030. Darin sind die 92 Millionen verdrängten Stellen bereits berücksichtigt. Die Welt entwickelt sich nicht in Richtung weniger Arbeitskräfte. Es geht um anders qualifizierte Arbeitskräfte.

Und hier ist noch etwas, das jeden "Lasst uns Personal abbauen"-CEO aufhorchen lassen sollte: 64% der Arbeitgeber gaben an, dass die Förderung der Gesundheit und des Wohlbefindens der Mitarbeiter eine Schlüsselstrategie für die Verfügbarkeit von Talenten ist. Nicht "Kosten senken". Nicht "alles automatisieren". Wohlbefinden fördern. Denn Unternehmen, die ihre Mitarbeiter verheizen, können die guten Mitarbeiter später nicht mehr einstellen.

Eine Studie [von BCG und der Harvard Business School] (https://www.bcg.com/publications/2023/how-people-create-and-destroy-value-with-gen-ai) hat herausgefunden, dass Teams, die KI für kreative Aufgaben einsetzten, zu 90 % ihre Leistung verbesserten und die Qualität der Ergebnisse um 40 % höher war als bei den Kontrollgruppen. Die Studie fand aber auch etwas heraus, das jeder Führungskraft Unbehagen bereiten sollte: Die Vielfalt der Ideen in den KI-unterstützten Gruppen ging um 41 % zurück.

Überleg mal, was das bedeutet. Du feuerst sieben Leute aus deinem zehnköpfigen Team. Die drei, die übrig bleiben, nutzen KI, um das gleiche Volumen zu produzieren. Aber die Bandbreite der Ideen, Perspektiven und Ansätze schrumpft um fast die Hälfte. Dein Output sieht produktiv aus, wird aber allmählich homogen. Und niemand merkt es, bis ein Konkurrent etwas wirklich Kreatives auf den Markt bringt und du dir nicht erklären kannst, warum dein Team nicht das Gleiche tut.

Die mentale Belastung, für die niemand ein Budget hat

Microsofts Umfrage ergab, dass 68 % der Mitarbeiter/innen mit dem Tempo und dem Umfang der Arbeit zu kämpfen haben und 46 % sich ausgebrannt fühlen. Und das war der Stand der Dinge, bevor du ihnen gesagt hast, dass sie jetzt die Arbeit ihrer drei ehemaligen Teamkollegen machen.

Das ist etwas, das in den Produktivitätsübersichten nicht auftaucht: die kognitiven Kosten, die entstehen, wenn du die letzte Verteidigungslinie bist. Wenn du die einzige Person bist, die den KI-Output überprüft, darfst du keinen freien Tag haben. Wenn du der einzige Besitzer der Wissensdatenbank bist, landet jede Supportanfrage auf deinem Schreibtisch. Wenn es niemanden gibt, mit dem du Ideen austauschen kannst, weil das Team "richtig dimensioniert" wurde, musst du jede Entscheidung allein treffen.

Ich habe Rasepi auch deshalb entwickelt, weil ich dieses Problem aus nächster Nähe gesehen habe. Wenn Dokumentationsteams schrumpfen, schrumpft das Wissen nicht mit ihnen. Die Menge an Inhalten, die vorhanden, aktuell und sprachübergreifend korrekt sein müssen, nimmt nicht ab, nur weil es weniger Leute gibt, die sie pflegen. Im Gegenteil, sie wächst sogar noch (das ist übrigens genau das Problem, für das wir Rasepi entwickeln, mit Funktionen wie erzwungenen Verfallsdaten und Übersetzungen auf Blockebene, die dafür sorgen, dass kleinere Teams wirklich effektiver arbeiten können, statt überfordert zu sein).

Aber selbst die besten Tools können eine grundsätzlich falsche Personalentscheidung nicht ändern. Das menschliche Urteilsvermögen, der Kontext und die Sorgfalt lassen sich nicht automatisieren. Du kannst diese Menschen nur effektiver machen.

Was kluge Unternehmen tatsächlich tun

Das Beeindruckendste an den Microsoft-Daten ist, wie die "KI-Poweruser" aussehen. Das sind Menschen, die KI mehrmals am Tag nutzen und mehr als 30 Minuten einsparen. Bei ihnen ist die Wahrscheinlichkeit, dass sie mit verschiedenen Arten der KI-Nutzung experimentieren, um 68 % höher. Sie erzeugen nicht nur mehr Leistung. Sie gestalten die Art und Weise, wie Arbeit geschieht, neu.

Und jetzt kommt der Clou: Sie existieren in Unternehmen, die in sie investieren. Bei KI-Power-Usern ist es 61 % wahrscheinlicher, dass sie von ihrem CEO hören, wie wichtig KI bei der Arbeit ist. Es ist 53 % wahrscheinlicher, dass sie von ihren Führungskräften dazu ermutigt werden, ihre gesamte Funktion zu überdenken. Sie erhalten ein maßgeschneidertes Training, nicht nur einen ChatGPT-Login.

Mit anderen Worten: Die produktivsten KI-Mitarbeiter sind keine einsamen Überlebenden einer Entlassung. Sie sind Mitglieder von Teams, die unterstützt werden und in die investiert wird.

Ich möchte das mit dem vergleichen, was ich bei Unternehmen sehe, die den Weg des "Personalabbaus" gewählt haben. Die verbleibenden Mitarbeiter sind keine Power-User. Sie sind überforderte Generalisten, die verzweifelt versuchen, alles am Laufen zu halten. Sie haben keine Zeit, mit KI zu experimentieren, weil sie zu sehr damit beschäftigt sind, sie zum Überleben zu nutzen. Es gibt kein Umdenken in der Funktion, denn die Funktion ist einfach... sie allein, die alles macht.

Das Wissensproblem, das niemand erwähnt

Es gibt noch eine weitere Sache. Und ich höre niemanden darüber reden, was merkwürdig ist, weil es eigentlich offensichtlich sein sollte.

Wenn du erfahrene Wissensarbeiter feuerst, geht das Wissen mit ihnen. Es bleibt nicht im Gebäude. Es ist nicht im Wiki. Es ist nicht in der KI. Es ist in den Köpfen der Menschen, die die Prozesse entwickelt haben, die die Grenzfälle verstanden haben und die wussten, welche Kunden sich für welche Details interessieren.

Weißt du, was passiert, wenn du großartige KI-Tools und kein institutionelles Wissen hast? Du bekommst wunderschön formatierte, selbstbewusst übermittelte, völlig falsche Informationen. In großem Maßstab.

Letzten Monat habe ich mit der Leiterin der Dokumentationsabteilung eines Fintech-Unternehmens gesprochen (sie wollte nicht namentlich genannt werden, was dir einiges sagt). Nachdem ihr Team von sechs auf zwei Mitarbeiter/innen reduziert wurde, verließen sie sich bei der Pflege ihrer Entwicklerdokumente weitgehend auf KI. Innerhalb von vier Monaten bemerkten sie einen sprunghaften Anstieg der Support-Tickets. Die Dokumentationen sahen gut aus. Sie waren gut geschrieben und oberflächlich betrachtet auf dem neuesten Stand. Aber sie enthielten subtile Fehler, die nur jemandem mit fundierten Produktkenntnissen aufgefallen wären. Eine Beschreibung der API-Parameter, die technisch korrekt, aber praktisch irreführend war. Eine Migrationsanleitung, die einen Schritt übersah, den jeder im alten Team kannte. Kleine Dinge, die KI nicht wissen kann, weil KI nicht an deinen Standups teilnimmt, deine Slack-Threads nicht liest und nicht das frustrierte "Oh, die Doku ist schon wieder falsch" des Support-Ingenieurs am Kaffeeautomaten hört.

Die eigentliche Frage

Meiner Meinung nach sollte sich das Gespräch eigentlich um Folgendes drehen.

Nicht: "Wie viele Menschen können wir jetzt, wo wir KI haben, abbauen?"

Sondern: "Was wird möglich, wenn wir allen, die wir bereits haben, KI geben?"

Dein zehnköpfiges Dokumentationsteam mit KI-Tools wird nicht überflüssig. Es wird zu einem Team, das Inhalte in zwölf statt in zwei Sprachen pflegen kann. Es kann jeden Inhalt mit automatischen Aktualitätsprüfungen auf dem neuesten Stand halten. Es kann mit neuen Formaten experimentieren, A/B-Tests für Hilfeinhalte durchführen, interaktive Anleitungen erstellen und hat trotzdem noch Zeit, strategisch darüber nachzudenken, was die Kunden tatsächlich brauchen.

Dein zehnköpfiges Marketingteam mit KI wird nicht zu fünf Personen, die die gleiche Arbeit mit mehr Stress erledigen. Es werden zehn Leute, die Kampagnen in einem Umfang personalisieren können, der vorher unmöglich war, mehr kreative Varianten testen, schneller auf Marktveränderungen reagieren und immer noch die kognitive Bandbreite haben, um wirklich originelle Ideen zu entwickeln, die die KI nie hervorgebracht hätte.

Das sind keine Kosten. Das ist eine Investition, die sich immer mehr auszahlt.

Wo das hinführt

Die Unternehmen, die in den nächsten fünf Jahren gewinnen, werden nicht diejenigen sein, die die meisten Köpfe abschneiden. Sie werden diejenigen sein, die herausgefunden haben, wie sie ihre bestehenden Teams wirklich leistungsfähiger machen können.

Die Frage ist nicht, ob eine Person die Arbeit von zehn erledigen kann. Die Frage ist, was passiert, wenn alle zehn die Arbeit von hundert erledigen können.

Wenn du eine Führungskraft bist und das hier liest, möchte ich dich um eines bitten. Bevor du die nächste Runde der "KI-gestützten Umstrukturierung" genehmigst, sprich mit den Leuten, die nach der letzten Runde geblieben sind. Frag sie, wie es ihnen geht. Frag sie, was sie nicht mehr machen, weil sie keine Zeit mehr haben. Frag sie, was durch die Maschen fällt.

Und dann stell dir vor, was sie erreichen könnten, wenn sie die Last nicht allein tragen müssten, sondern ein volles Team und die besten verfügbaren Werkzeuge hätten.

Das ist kein Hirngespinst. Für die Unternehmen, die bereit sind, in ihre Mitarbeiter zu investieren, anstatt sie zu ersetzen, sind das die nächsten zwölf Monate.

Leser und Schreiber befinden sich in unterschiedlichen Denkmodi. Warum bietet ihnen jedes Tool die gleiche Benutzeroberfläche?

2026-04-03T00:00:00Z

Öffne jetzt Confluence und suche ein Dokument, das du lesen musst. Was siehst du?

Eine Symbolleiste. Schaltflächen zum Bearbeiten. Kommentarfelder. Links zum Seitenverlauf. Eine Seitenleiste voller Navigation, die du nicht brauchst. Brotkrümel. Metadatenfelder. Genehmigungsanzeigen. Eine komplette Autorenoberfläche, die sich um den Text dreht, den du lesen willst.

Überlege dir jetzt, was du eigentlich wolltest: die Antwort auf eine Frage, die nächsten drei Schritte in einem Prozess oder eine Richtlinie, die du vor einem Meeting in zehn Minuten nachschlagen musst.

Du bist gekommen, um zu konsumieren. Die Benutzeroberfläche geht davon aus, dass du gekommen bist, um zu erstellen.

Das ist der Standard bei fast allen Dokumentationsplattformen. Confluence, Notion, SharePoint, GitBook, Nuclino, Slite. Sie alle bieten Lesern und Schreibern die gleiche Umgebung. Die Seite ist die Seite. Jeder erhält die gleiche Ansicht, abgesehen von ein paar Schaltflächen mit Berechtigungen.

Es fühlt sich normal an, weil wir noch nie etwas anderes hatten. Aber es ist eine Designentscheidung, kein Naturgesetz. Und es ist die falsche Entscheidung.

Die gleiche Schnittstelle für Lesen und Schreiben schafft kognitiven Overhead](/de/blog/img/readers-writers-ui.svg)

Lesen und Schreiben sind nicht dieselbe kognitive Aufgabe

Das ist keine Vorliebe für die Benutzeroberfläche. Es ist ein grundlegender Unterschied in der Arbeitsweise des Gehirns.

Wenn du schreibst, befindest du dich im generativen Modus. Du konstruierst, organisierst, entscheidest, was du einfügst und was du weglässt. Du brauchst Werkzeuge: Formatierungsoptionen, Strukturkontrollen, Medieneinbettung, Metadatenfelder, Versionsgeschichte, Funktionen zur Zusammenarbeit. Die Schnittstelle sollte dir Macht und Flexibilität geben.

Wenn du liest, bist du im rezeptiven Modus. Du scannst, filterst, nimmst das Relevante heraus und versuchst, weiterzulesen. Du brauchst Klarheit: saubere Typografie, konzentriertes Layout, minimale Ablenkung. Die Benutzeroberfläche sollte dir nicht im Weg sein.

Die Kognitionspsychologie hat dafür einen klaren Rahmen. Die [Cognitive Load Theory] (https://www.instructionaldesign.org/theories/cognitive-load/), die von John Sweller in den späten 1980er Jahren entwickelt wurde, unterscheidet zwischen intrinsischer Belastung (die Schwierigkeit des Stoffes selbst), germane Belastung (die Anstrengung des Lernens und der Integration) und extraneaner Belastung (alles, was die Umgebung hinzufügt und nicht hilfreich ist). Jede Symbolleiste, jede Seitenleiste und jede Bearbeitungsschaltfläche, die ein Leser sieht, ist überflüssig. Sie helfen dem Leser nicht, den Inhalt zu verstehen. Sie konkurrieren aktiv um die Aufmerksamkeit.

Eine Studie von Mayer und Moreno (2003) über multimediales Lernen hat gezeigt, dass die Reduzierung überflüssiger Elemente sowohl das Verständnis als auch das Behalten verbessert. Ihr Kohärenzprinzip ist direkt: Menschen lernen besser, wenn überflüssiges Material ausgeschlossen und nicht hinzugefügt wird. Eine Dokumentationsoberfläche, die dem Leser bei jedem Seitenaufruf die Steuerelemente des Autors zeigt, verstößt gegen dieses Prinzip.

Der Leser muss die Werkzeuge des Autors nicht sehen. Sie trotzdem zu zeigen, ist nicht neutral. Es ist aktiv schädlich für das Verstehen.

Wie aktuelle Plattformen dies handhaben (meistens nicht)

Schauen wir uns an, was es gibt.

Confluence hat einen Lesemodus und einen Bearbeitungsmodus, aber der Lesemodus ist immer noch von der Navigation, den Metadaten und dem Seitenbaum der Plattform umgeben. Die Bearbeitungssymbolleiste verschwindet, wenn du nicht bearbeitest, aber der mentale Rahmen "dies ist eine bearbeitbare Wikiseite" verschwindet nie ganz. Jeder Leser sieht die Schaltfläche "Bearbeiten". Die Seite flüstert: Du könntest das ändern.

Notion ist in dieser Hinsicht noch schlimmer. Der Kern der Designphilosophie ist, dass alles immer bearbeitbar ist. Klicke irgendwo und du tippst. Das ist genial für Autoren. Für Leserinnen und Leser, die den Inhalt einfach nur aufnehmen wollen, ohne Angst haben zu müssen, dass sie aus Versehen etwas ändern, ist es schrecklich. Die [Vorlagengalerie] (https://www.notion.com/templates) von Notion zeigt das: Jede Vorlage ist ein Arbeitsbereich, keine Veröffentlichung.

SharePoint unterstützt technisch gesehen verschiedene Seitenlayouts für die Anzeige und Bearbeitung, aber das Gesamterlebnis ist immer noch ein Unternehmensintranet. Die Leserinnen und Leser haben das Gefühl, dass sie sich in einem Unternehmenstool befinden und nicht in einem für das Verständnis optimierten Dokument.

GitBook kommt mit seiner sauberen, dokumentationsähnlichen Ausgabe einem Leseerlebnis am nächsten. Aber auch hier wird davon ausgegangen, dass der Leser ein Entwickler ist, der sich technische Dokumente ansieht. Es ist nicht für den allgemeinen Wissenskonsumenten gedacht.

Keine dieser Plattformen behandelt das Lesen als eine grundlegend andere Aktivität als das Schreiben. Sie behandeln es als Schreiben mit ausgeblendeter Symbolleiste.

Die Kosten einer einzigen Schnittstelle

Das ist nicht nur ein Problem der Ästhetik. Es hat messbare Konsequenzen.

Die Informationsflut verringert das Verstehen

Eine im Journal of Consumer Research veröffentlichte Studie fand heraus, dass Informationsüberlastung zu einer schlechteren Entscheidungsqualität führt, wobei der Effekt mit dem Verhältnis von irrelevanten zu relevanten Informationen zunimmt. Eine Dokumentationsseite mit sichtbaren Steuerelementen, Navigationsbäumen und Metadatenfeldern erhöht dieses Verhältnis für jeden Leser, der nicht zum Schreiben da ist.

Context Switching hat einen echten Preis

Wenn ein Interface signalisiert: "Du kannst das bearbeiten", aktiviert es einen anderen kognitiven Rahmen als "Lies das." [Gloria Marks Forschung an der UC Irvine (https://www.ics.uci.edu/~gmark/) über Aufmerksamkeit und Multitasking hat ergeben, dass es durchschnittlich 23 Minuten und 15 Sekunden dauert, bis man sich nach einem Kontextwechsel wieder voll konzentriert. Ein Leser, der kurz darüber nachdenkt, etwas zu bearbeiten (selbst um einen Tippfehler zu korrigieren), wurde aus dem Lesemodus gerissen. Das ist keine hypothetische Annahme. Jeder, der Notion benutzt hat, kennt die Erfahrung, wenn man auf einen Text klickt, um ihn auszuwählen, und dann versehentlich anfängt zu tippen.

Leser und Schreiber haben unterschiedliche Bedürfnisse an denselben Inhalt

Ein Autor muss die Struktur, Formatierungsmarkierungen, Blocktypen, Metadaten und Signale für die Zusammenarbeit sehen. Sie brauchen die ganze Maschinerie.

Ein Leser braucht sauberen Text, eine klare Hierarchie und den schnellsten Weg zu den gesuchten Informationen. Sie brauchen den Inhalt, nicht die Maschinerie.

Werden beide über dieselbe Schnittstelle bedient, bedeutet das, dass keiner von ihnen ein für seine eigentliche Tätigkeit optimiertes Erlebnis hat.

Und dann ist da noch die dritte Zielgruppe: KI

Hier wird es kompliziert, und die bestehenden Plattformen sind völlig unvorbereitet.

Die Dokumentation im Jahr 2026 hat drei verschiedene Verbraucher, nicht zwei:

Autoren, die Inhalte erstellen und pflegen
Leser, die Inhalte visuell konsumieren
KI-Systeme, die Inhalte programmgesteuert abrufen, analysieren und zusammenstellen

Jedes dieser Zielgruppen braucht eine grundsätzlich andere Schnittstelle zu denselben zugrunde liegenden Inhalten.

Autoren brauchen umfangreiche Bearbeitungswerkzeuge, Funktionen zur Zusammenarbeit und strukturelle Kontrollen. Leser brauchen eine übersichtliche, konzentrierte Darstellung mit minimaler Ablenkung. KI braucht eine strukturierte, maschinenlesbare Ausgabe mit expliziten Metadaten: Aktualitätssignale, Klassifizierungskennzeichen, Adressierung auf Blockebene und saubere semantische Markups.

Wie wir in Builders, Not Developers erörtert haben, sind KI-Vermittler bereits der dominierende Konsument von Dokumentation für einen wachsenden Teil der Wissensarbeiter. Die [GitHub-Entwicklerumfrage 2024] (https://github.blog/news-insights/research/survey-ai-wave-grows/) ergab, dass 97 % der Entwickler in Unternehmen KI-Codierwerkzeuge verwenden. Bis 2026 werden 84% der Entwickler regelmäßig KI-Tools nutzen, wobei 41% des gesamten Codes durch KI generiert werden.

Diese KI-Systeme interessieren sich nicht für deine Seitenleiste oder deine Symbolleiste. Sie brauchen saubere Daten. Und eine Plattform, die die Lesersicht mit der Autorensicht verwechselt, verwechselt auch die von der KI konsumierbare Oberfläche mit der Oberfläche des menschlichen Verfassers. Das sind drei Unstimmigkeiten in einer Schnittstelle.

Drei Zielgruppen, drei unterschiedliche Bedürfnisse](/de/blog/img/readers-writers-three-audiences.svg)

Wie Rasepi die Erfahrungen trennt

Rasepi basiert auf dem Prinzip, dass das Erstellen von Inhalten und das Konsumieren von Inhalten unterschiedliche Aktivitäten sind, die unterschiedliche Schnittstellen verdienen.

Die Umgebung des Autors

Wenn du in Rasepi schreibst, bekommst du eine vollständige Autorenumgebung. Rich-Text-Editing mit TipTap, Steuerelemente auf Blockebene, Übersetzungsstatusanzeigen, Ablaufmanagement, Tools für die Zusammenarbeit, Ansichten für die Inhaltsstruktur und alles andere, was ein Autor braucht, um qualitativ hochwertige Dokumentation zu erstellen und zu pflegen.

Der Autor sieht die Maschinerie, weil er die Maschinerie braucht.

Die Umgebung des Lesers

Wenn jemand ein Rasepi-Dokument konsumiert, sieht er ein sauberes, konzentriertes Leseerlebnis. Kein Bearbeitungs-Chrome. Keine Symbolleisten. Keine "Du kannst das ändern"-Signale. Nur der Inhalt, der in einem Layout präsentiert wird, das für das Verstehen und Überfliegen optimiert ist.

Der Leser sieht die Schaltfläche "Bearbeiten" nicht, denn er ist nicht hier, um zu bearbeiten. Er ist hier, um etwas zu lernen, einen Prozess zu verfolgen oder eine Antwort zu finden. Die Benutzeroberfläche respektiert diese Absicht.

Die KI-Oberfläche

Für KI-Konsumenten stellt Rasepi Inhalte über strukturierte APIs mit vollständigen Metadaten zur Verfügung. Jeder Block enthält einen Freshness Score, einen Übersetzungsstatus, einen Content Hash und Klassifizierungskennzeichen. KI-Systeme können Inhalte auf Blockebene abfragen, nach Aktualität filtern, veraltetes Material oder Entwürfe ausschließen und genau die strukturierten Daten abrufen, die sie benötigen.

Kein Scraping einer Wikiseite und Hoffen auf das Beste. Die KI erhält eine speziell entwickelte Schnittstelle, genau wie der Leser und der Autor.

Eine Inhaltsebene, drei Schnittstellen

Das Wichtigste ist, dass wir nicht drei Kopien des Inhalts verwalten. Das ist nicht das Problem der fünf Kopien des Onboardings, das wir in Stop Maintaining Five Copies of the Same Document besprochen haben.

Es handelt sich um eine Inhaltsebene, die in strukturierten Blöcken gespeichert ist und über drei verschiedene Ansichten für drei verschiedene Zielgruppen optimiert wird.

Der Autor bearbeitet die Blöcke. Der Leser sieht zusammengestellte, gestylte Inhalte. Die KI fragt strukturierte Daten mit Metadaten ab. Dieselben Blöcke. Dieselbe Quelle der Wahrheit. Unterschiedliche Präsentationsschicht für jeden Verbraucher.

Dies ist nur aufgrund der Architektur auf Blockebene möglich. Jeder Inhalt ist eine individuell adressierbare Einheit mit eigenen Metadaten. Du kannst diese Blöcke unterschiedlich präsentieren, je nachdem, wer nach ihnen fragt:

Zielgruppe	Bedürfnisse	Gets
Writer	Formatierung, Struktur, Zusammenarbeit, Metadaten	Vollständige Authoring-Umgebung mit Kontrollen auf Blockebene
Leser	Sauberer Text, klare Hierarchie, schnelles Scannen	Fokussierte Leseansicht, kein Bearbeitungs-Chrome
AI	Strukturierte Daten, Freshness Scores, Klassifizierung	Block-Level-API mit vollständigen Metadaten

Warum das wichtiger ist, als es aussieht

Du liest das vielleicht und denkst: "Das ist nur UI. Verschiedene Ansichten der gleichen Sache. Wie wichtig kann das schon sein?"

Sehr wichtig, wie sich herausstellt.

Leservertrauen

Menschen vertrauen Inhalten, die veröffentlicht aussehen. Wenn eine Seite wie ein Wiki aussieht, das jeder bearbeiten kann, wird sie von den Lesern unbewusst abgelehnt. Wenn derselbe Inhalt in einer sauberen, veröffentlichungsreifen Ansicht präsentiert wird, hat er mehr Autorität. Das ist nicht irrational. Es ist ein Zeichen dafür, dass jemand die Präsentation ernst genommen hat, was bedeutet, dass er auch den Inhalt ernst genommen hat.

Die Nielsen Norman Group hat dies eingehend untersucht. Ihre [Studie zur Glaubwürdigkeit von Inhalten] (https://www.nngroup.com/articles/trust-signals-content/) zeigt, dass die Qualität des Designs und der Präsentation zu den stärksten Signalen gehören, anhand derer die Nutzer die Vertrauenswürdigkeit von Inhalten beurteilen. Eine unübersichtliche Editoransicht untergräbt aktiv die Glaubwürdigkeit der angezeigten Inhalte.

Produktivität des Autors

Autoren, die in einer speziellen Autorenumgebung arbeiten, müssen nicht zwischen den Kontexten "lese ich oder schreibe ich?" hin und her wechseln. Die Werkzeuge sind da, weil sie da sein sollen, und nicht, weil die Benutzeroberfläche nicht entscheiden konnte, wer auf sie schaut.

KI-Zuverlässigkeit

Wenn KI-Systeme über eine speziell entwickelte Oberfläche mit strukturierten Metadaten verfügen, können sie besser entscheiden, was sie abrufen und was sie ausschließen. Sie können Freshness-Scores überprüfen, bevor sie einen Block in eine Antwort aufnehmen. Sie können Klassifizierungskennzeichen beachten. Sie können nach Sprache, Status oder Zielgruppe filtern. All das ist nicht möglich, wenn die KI dieselbe HTML-Seite ausliest, die für menschliche Leser konzipiert wurde.

Der Wechsel des mentalen Modells

Die Grundannahme der meisten Dokumentationsplattformen ist: die Seite ist die Einheit, und jeder interagiert mit der Seite.

Rasepi geht von einer anderen Annahme aus: Der Block ist die Einheit, und verschiedene Zielgruppen interagieren mit den Blöcken durch speziell entwickelte Oberflächen.

Das klingt wie ein kleiner architektonischer Unterschied. Ist es aber nicht. Es ist der Unterschied zwischen einem Werkzeug, das KI-Systemen zufällig Inhalte zeigt, und einem, das sie absichtlich bedient. Zwischen einer Schreibumgebung, die zufällig lesbar ist, und einem Leseerlebnis, das von Grund auf neu entwickelt wurde. Zwischen einer guten Schnittstelle und drei großartigen.

Dokumentation wird nicht mehr nur geschrieben und gelesen. Sie wird geschrieben, gelesen, abgefragt, übersetzt, bewertet, klassifiziert und in großem Umfang an KI-Systeme weitergegeben. Wenn wir so tun, als ob wir das könnten, haben wir Wikis, die niemand lesen will, und KI-Assistenten, die Antworten von Seiten abrufen, die nie dafür gedacht waren, maschinell verarbeitet zu werden.

Leser und Schreiber befinden sich in unterschiedlichen Denkmodi. Die KI ist in einem ganz anderen Modus. Die Benutzeroberfläche sollte das widerspiegeln.

The State of Docs in 2026: Fünf Trends, die die nächste Ära bestimmen werden

2026-04-03T00:00:00Z

Alle paar Monate nehme ich mir einen Vormittag Zeit, um einfach nur zu lesen. Nicht Rasepi-Code, nicht GitHub-Probleme. Blogs von Mitbewerbern, Branchenberichte, Ankündigungen von Keynotes, Umfragen unter Entwicklern. Alles, was im letzten Quartal veröffentlicht wurde und mit Dokumentation, Wissensmanagement oder KI-gestützten Workflows zu tun hat.

Das habe ich letzte Woche getan, und das Bild, das sich dabei ergab, war schärfer als erwartet. Nicht, weil eine einzelne Ankündigung bahnbrechend war, sondern weil fünf verschiedene Trends zusammenlaufen, die zusammengenommen ein klares Bild davon zeichnen, was Dokumentationsplattformen in den nächsten zwei Jahren leisten müssen.

Hier ist, was ich gefunden habe.

1. KI ist jetzt der wichtigste Leser. Nicht der Mensch.

GitBook hat in seinem [AI docs data report] (https://www.gitbook.com/blog/ai-docs-data-2025) eine beeindruckende Zahl veröffentlicht: Die KI-Leserschaft von Dokumentationen stieg 2025 um über 500%. Fünfhundert Prozent. Das ist kein Rundungsfehler.

Die 2024 Developer Survey von Stack Overflow zeigt, dass 61% der Entwickler/innen mehr als 30 Minuten pro Tag mit der Suche nach Antworten verbringen. Aber die Art und Weise, wie sie suchen, hat sich verändert. GitHubs eigene Umfrage ergab, dass 97% der Unternehmensentwickler KI-Coding-Tools verwenden. Im Jahr 2026 werden 84% der Entwickler täglich KI-Tools verwenden, wobei 41% des Codes inzwischen von KI generiert wird. Diese Leute navigieren nicht durch die Seitenleiste deines Wikis. Sie fragen Claude oder Copilot, und die KI liest deine Dokumente in ihrem Namen.

Die Auswirkungen sind kaum zu überschätzen. Dein häufigster Dokumentationskonsument ist nicht mehr eine Person, die einen Browser-Tab geöffnet hat. Es ist ein Sprachmodell, das Suchanfragen stellt. Und dieses Modell ist nicht in der Lage, auf eine Seite zu schielen und zu denken: "Hm, das sieht veraltet aus."

GitBook hat das früh erkannt und mit seinem [State of Docs 2026 report] (https://www.gitbook.com/blog/state-of-docs-2026) und einem Vorstoß in Richtung maschinenlesbare Formate reagiert. Außerdem haben sie [skill.md] (https://www.gitbook.com/blog/skill-md) veröffentlicht, eine Konvention zur Strukturierung von Produktinformationen speziell für KI-Agenten. Google ging mit seinem Gemini API Docs MCP noch weiter, das Kodieragenten über das Model Context Protocol mit der aktuellen Dokumentation verbindet. Die Argumentation war eindeutig: Agenten erzeugen veralteten Code, weil ihre Trainingsdaten ein Stichtag sind. Mit der MCP-Lösung stieg die Erfolgsquote auf 96,3 %.

Der erste Trend ist also bestätigt. KI ist der wichtigste Leser. Die Plattformen, die dies als eine zentrale Designvorgabe behandeln und nicht als eine Funktion, die später hinzugefügt werden kann, werden einen strukturellen Vorteil haben.

2. Frische und vertrauenswürdige Metadaten werden zur Pflicht

Anthropic befragte [81.000 Claude-Nutzer] (https://www.anthropic.com/81k-interviews) im Dezember 2025 und veröffentlichte die Ergebnisse im März 2026. Es ist die größte qualitative Studie über KI-Nutzer, die jemals durchgeführt wurde (159 Länder, 70 Sprachen). Die meistgenannte Sorge? Die Unzuverlässigkeit. 27% der Befragten nannten sie als ihre größte Sorge und 79% dieser Menschen haben sie am eigenen Leib erfahren.

Diese Zahl sollte jedes Dokumentationsteam nachts wach halten.

Wenn KI-Antworten unzuverlässig sind, liegt das Problem nicht immer am Modell. Oft gibt das Modell getreu wieder, was es in einem veralteten Dokument gefunden hat. Das Modell hat nicht halluziniert. Deine Dokumente waren einfach falsch, und niemand hat sie gemeldet.

Die Daten von Stack Overflow untermauern dies aus einem anderen Blickwinkel: 81% der Entwickler erwarten, dass KI im kommenden Jahr stärker in die Art und Weise, wie sie Code dokumentieren, integriert wird. Wenn 81 % deiner Nutzer/innen die KI mit Dokumenten füttern und 27 % der KI-Nutzer/innen die Unzuverlässigkeit als größtes Problem bezeichnen, hast du ein Vertrauensproblem, das keine noch so prompte Entwicklung beheben kann. Die Lösung liegt an der Quelle.

Deshalb sind Metadaten zur Aktualität so wichtig. Nicht der Zeitstempel "zuletzt bearbeitet" (er sagt aus, wann jemand die Datei angefasst hat, und nicht, ob der Inhalt noch aktuell ist). Echte Aktualität: Überprüfungsstatus, Linkstatus, Übersetzungsabgleich, Lesersignale, Erkennung von Inhaltsabweichungen. Metadaten, die eine Maschine lesen und nutzen kann, um zu entscheiden, ob ein Dokument sicher zitiert werden kann.

Ich komme immer wieder auf eine einfache Formulierung zurück. Deine Dokumentation braucht einen Credit Score. Nicht einen Zeitstempel. Eine Kreditwürdigkeit. (Wir haben genau das mit dem Frische-Scoring-System von Rasepi entwickelt, und wenn ich mir die Daten aus der Branche ansehe, bin ich noch mehr davon überzeugt, dass es die richtige Entscheidung ist).

3. Die Übersetzung wird von "Projekt" auf "Pipeline" umgestellt

DeepL veröffentlichte im Februar einen Artikel mit dem Titel ["The 6 Translation Transformations Global Businesses Can't Afford to Miss"] (https://www.deepl.com/en/blog/six-translation-transformations). Ihr Argument: Übersetzung wird zu einer kontinuierlichen betrieblichen Herausforderung, nicht zu einem vierteljährlichen Stapelprojekt.

Das deckt sich mit allem, was ich sehe.

Das alte Modell war ganz einfach. Schreibe auf Englisch. Wenn du ein gewisses Budget hast, engagiere einen Übersetzer oder beauftrage einen Übersetzungsdienst. Erhalte die Übersetzungen zurück. Lade sie hoch. Erledigt bis zum nächsten Mal. Das Problem ist, dass das "nächste Mal" immer schneller kommt, wenn dein Produkt wöchentlich ausgeliefert wird und deine Dokumente ständig aktualisiert werden. Bis die deutsche Version von der Überprüfung zurück ist, hat sich der englische Quelltext bereits zweimal geändert.

Der [Customization Hub] (https://www.deepl.com/customization-hub) von DeepL bietet jetzt Glossare, Stilregeln und Formalitätseinstellungen, was großartig ist. Aber wenn diese Tools außerhalb deiner Dokumentationsplattform liegen, musst du eine ganze Übersetzungs-Toolchain verwalten: Editor, Export, Übersetzung, Überprüfung, Reimport, Wiederholung. Jeder Schritt birgt die Gefahr, dass du abweichst.

Notion hat keine native mehrsprachige Unterstützung. Confluence bietet sie über Marketplace-Plugins an. GitBook [fügte die automatische Übersetzung im August 2025 hinzu] (https://www.gitbook.com/blog/new-in-gitbook-august-2025), das ist ein Schritt, aber er funktioniert auf Seitenebene.

Die wirkliche Veränderung ist der Wechsel von der Seitenebene zur Blockebene. Wenn du die Übersetzungen auf der Absatzebene verfolgst, übersetzst du nur das, was sich tatsächlich geändert hat. Bei einer typischen Bearbeitung werden vielleicht zwei von vierzig Absätzen geändert. Das sind 94 % weniger Übersetzungsarbeit. (Das ist der Kern von Rasepis Übersetzungsarchitektur und ehrlich gesagt das, worauf ich bei dem Produkt am meisten stolz bin. Aber selbst wenn man uns beiseite lässt, ist die Richtung klar: Kontinuierliche, inkrementelle, eingebettete Übersetzung ist die Richtung, in die es geht).

4. KI-Agenten brauchen strukturierte Inhalte, keine Wikiseiten

Das hat sich für mich herauskristallisiert, als Notion im Februar [Custom Agents] (https://www.notion.com/blog/introducing-custom-agents) ankündigte. 21.000 Agenten wurden während des frühen Zugangs gebaut. Agenten, die Fragen aus Wissensdatenbanken beantworten, Aufgaben weiterleiten und Statusberichte erstellen. Allein Ramp hat über 300 Agenten.

Atlassian ging in eine ähnliche Richtung. [Rovo AI in Confluence] (https://www.atlassian.com/blog/confluence/create-and-edit-with-rovo) zieht Kontext aus allen Anwendungen von Atlassian und Drittanbietern, um Inhalte zu erstellen. Ihr Argument: "Kontextreiche, qualitativ hochwertige Inhalte, die auf der bestehenden Arbeit deines Teams basieren".

Und dann hat Anthropic Agententeams in Claude Code entwickelt, bei dem mehrere KI-Agenten komplexe Aufgaben selbstständig koordinieren. Opus 4.6 erreicht 76 % beim 8-Nadel 1M MRCR Benchmark (gegenüber 18,5 % beim Vorgängermodell), d. h. es kann tatsächlich Informationen aus riesigen Dokumentenmengen abrufen, ohne den Überblick zu verlieren.

Alle drei Unternehmen entwickeln Agenten, die Dokumente auswerten. Keines von ihnen hat das Problem der Quellenqualität gelöst.

In der Dokumentation der Custom Agents von Notion wird ausdrücklich auf das Prompt Injection Risk hingewiesen, wenn Agenten nicht vertrauenswürdige Inhalte lesen. Rovo von Atlassian liest alles, was es in deinem Confluence findet. Wenn dieser Inhalt drei Monate alt ist, weiß Rovo das nicht. Er baut trotzdem darauf auf.

Damit Agenten zuverlässig arbeiten können, brauchen sie mehr als nur Textseiten. Sie brauchen strukturierte Inhalte mit stabilen Bezeichnern, eindeutigen Aktualitätssignalen, klaren Klassifizierungsmetadaten und der Möglichkeit, zwischen "das ist aktuell und geprüft" und "das gibt es, aber niemand hat es seit einem Jahr angefasst" zu unterscheiden. Wiki-Seiten bieten das nicht. Strukturierte Inhalte auf Blockebene mit vertrauenswürdigen Metadaten schon.

5. Open Source und Self-Hosting erleben ein Comeback

Der letzte Punkt ist eher ein Bauchgefühl, das durch Daten gestützt wird, als eine einzelne Ankündigung.

GitBook [hat seine veröffentlichte Dokumentation] (https://www.gitbook.com/blog/free-open-source-documentation) Ende 2024 als Open Source veröffentlicht und einen OSS-Fonds eingerichtet. Die Begründung: Open-Source-Projekte verdienen kostenlose, hochwertige Dokumentationswerkzeuge. Aber der Schritt ist auch ein Zeichen für etwas Größeres.

Notion ist ein reines Cloud-Angebot. Es gibt keine selbstgehostete Option. Das Confluence Data Center ist zwar vorhanden, erfordert aber eine Lizenz. Wenn deine Dokumentationsplattform dein sensibelstes betriebliches Wissen enthält (Playbooks für Vorfälle, Compliance-Verfahren, Architekturentscheidungen), ist die Frage, wer diese Daten kontrolliert, nicht abstrakt.

Der Beitrag von Anthropic ["Claude is a space to think"] (https://www.anthropic.com/news/claude-is-a-space-to-think) vom Februar enthält ein interessantes Argument über Vertrauen und Geschäftsmodelle. Ihre Kernaussage: Werbeanreize sind unvereinbar mit einem wirklich hilfreichen KI-Assistenten. Sie haben sich dafür entschieden, werbefrei zu bleiben, damit die Nutzer dem Tool vertrauen können.

Ich denke, es gibt eine Parallele für Dokumentationsplattformen. Wenn dein Dokumentsystem ein Closed-Source-System ist und nur in der Cloud läuft, kannst du nicht überprüfen, was es an die KI weitergibt. Du kannst die Berechnung der Aktualität nicht überprüfen. Du kannst nicht sicherstellen, dass deine Daten unter deiner Kontrolle bleiben. Für Teams, die KI-Assistenten auf ihre Wissensdatenbank aufsetzen (und das tun zunehmend alle), ist die Überprüfbarkeit wichtig.

Dies ist keine Polemik darüber, dass Open Source moralisch überlegen ist. Closed-Source-Produkte können durchaus vertrauenswürdig sein. Aber wenn du KI-gestützte Workflows auf deiner internen Dokumentation aufbaust, ist die Möglichkeit, das System zu prüfen und zu verifizieren, ein praktischer Vorteil. Für uns war die MIT-Lizenzierung von Rasepi kein nachträglicher Einfall. Es war eine Designentscheidung, die auf derselben Logik beruht: Die Dokumentationsinfrastruktur sollte überprüfbar sein.

Was diese fünf Trends zusammen bedeuten

Für sich genommen ist jeder dieser Trends überschaubar. KI liest deine Dokumente? Okay, füge ein paar maschinenlesbare Metadaten hinzu. Frische ist wichtig? Gut, füge Überprüfungsdaten hinzu. Die Übersetzung muss kontinuierlich erfolgen? Klar, integriere DeepL. Agenten brauchen Struktur? Gut, verbessere dein Inhaltsmodell. Souveränität ist wichtig? Gut, biete eine selbst gehostete Option an.

Aber zusammengenommen beschreiben sie eine Plattform, die sich grundlegend von dem unterscheidet, was die meisten Teams heute nutzen.

Der Unterschied liegt in der Architektur. Es handelt sich nicht um fünf Funktionen, die man anbauen kann. Es sind fünf Annahmen, die in das Fundament eingebaut werden müssen. Wie die Inhalte gespeichert werden (auf Blockebene, nicht auf Seitenebene). Wie das Vertrauen modelliert wird (Freshness Scores, nicht Zeitstempel). Wie die Übersetzung funktioniert (inkrementell, eingebettet, pro Absatz). Wie KI-Agenten auf Inhalte zugreifen (strukturierte APIs mit Metadaten, keine Seitenabfragen). Wie die Daten kontrolliert werden (offen, überprüfbar, selbst-hostbar).

Keine etablierte Plattform wurde für alle fünf Punkte gleichzeitig entwickelt. Einige fügen sie Stück für Stück hinzu. GitBook ist bei der KI-Lesbarkeit am weitesten fortgeschritten. Notion baut eine Agenteninfrastruktur auf. Atlassian hat eine Enterprise Distribution.

Aber vom ersten Tag an für alle fünf entwickeln? Das ist der Vorteil, wenn man ganz neu anfängt, wenn sich das Terrain verschiebt.

Ich weiß, dass ich hier voreingenommen bin. Wir haben Rasepi entwickelt, weil wir sahen, dass diese Trends zusammenlaufen und wir wollten eine Plattform, die von Anfang an alle diese Trends berücksichtigt. Übersetzung auf Blockebene, erzwungenes Verfallsdatum, Freshness Scoring, strukturierte KI-kompatible Inhalte, Open Source. Das ist die These des ganzen Projekts.

Aber selbst wenn es uns nicht gäbe, denke ich, dass jede ehrliche Betrachtung dessen, was im ersten Quartal 2026 passiert, in dieselbe Richtung weist. Die Dokumentation wird zur Infrastruktur. Und Infrastruktur hat andere Anforderungen als Wikiseiten.

Die Teams, die das zuerst herausfinden, werden nicht nur bessere Dokumentationen haben. Sie werden zuverlässigere KI-Agenten, niedrigere Übersetzungskosten, weniger Überraschungen bei der Einhaltung von Vorschriften und Wissensdatenbanken haben, die auch im Laufe der Zeit vertrauenswürdig bleiben.

Das ist der Zustand der Dokumente im Jahr 2026. Die Frage ist nicht, ob diese Trends real sind. Die Frage ist, ob deine Plattform für sie entwickelt wurde.

Fünf Trends. Eine architektonische Frage: Wurde deine Dokumentationsplattform für das Jahr 2026 entwickelt oder bedient sie immer noch Annahmen aus dem Jahr 2016?

Quellen: GitBook AI docs data report, GitBook State of Docs 2026, GitBook skill.md, Google Gemini API Docs MCP, Stack Overflow 2024 Developer Survey, GitHub 2024 developer survey, Index.dev developer productivity statistics, Anthropic "What 81,000 People Want from AI", Anthropic "Claude is a space to think", Claude Opus 4.6, Notion Custom Agents, Atlassian Rovo in Confluence, DeepL "6 Translation Transformations", DeepL Customization Hub, GitBook open source documentation, GitBook auto-translate.

Erbauer, nicht Entwickler: Wie Claude verändert hat, für wen deine Docs bestimmt sind

2026-04-02T00:00:00Z

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.

Im Inneren der Translation Engine: Glossare, Stilregeln und intelligente Rückübersetzung

2026-03-31T00:00:00Z

Unser vorheriger Architektur-Beitrag behandelte Plugins, Action Guards und das Pipeline-System. In diesem Beitrag gehen wir näher auf die Übersetzungs-Engine ein, die Rasepi meiner Meinung nach grundlegend von allen anderen Dokumentationsplattformen unterscheidet.

Es geht nicht um das Marketing, dass Absätze statt Seiten übersetzt werden. Der eigentliche Code. Wie Glossare pro Tenant aufgelöst werden, wie die Stilregeln und benutzerdefinierten Anweisungen von DeepL jede Übersetzung beeinflussen, wie Content Hashing die Erkennung von veralteten Inhalten steuert und wie der Orchestrator entscheidet, welche Blöcke neu übersetzt werden.

Die Übersetzungspipeline

Wenn ein Benutzer ein Dokument speichert, übersetzt das System nicht einfach alles neu. Es führt eine ganz bestimmte Sequenz durch:

Es zerlegt das TipTap JSON in einzelne Blöcke
Inhalts-Hashes vergleichen, um festzustellen, welche Blöcke sich tatsächlich geändert haben
Löse für geänderte Blöcke das Glossar und die Stilregel-Liste des Tenants für das Sprachpaar auf
Wende Stilregeln, benutzerdefinierte Anweisungen und Formalitäten aus der Tenant-Konfiguration an
Sende nur geänderte Blöcke an DeepL
Übersetzungsblöcke aktualisieren und Inhaltshashes synchronisieren

Jeder Schritt ist ein eigener Dienst mit einer eigenen Schnittstelle. Das ist wichtig, weil jeder Schritt gegen einen anderen ausgetauscht werden kann: einen anderen Übersetzungsanbieter, einen anderen Hash-Algorithmus oder eine andere Glossarquelle.

Glossarauflösung: mieterübergreifend, DeepL-synchronisiert

DeepL Glossare haben eine Einschränkung, von der die meisten Menschen nichts wissen: **Sie sind unveränderlich. ** Du kannst ein DeepL Glossar nicht bearbeiten. Jede Änderung bedeutet, dass das alte Glossar gelöscht und ein neues erstellt wird.

Rasepi behandelt dies, indem es die Datenbank als Quelle der Wahrheit und DeepL Glossare als Wegwerf-Artefakte zur Laufzeit behandelt. Die Entität TenantGlossary speichert alles lokal:

public class TenantGlossary : ITenantScoped
{
    public Guid Id { get; set; }
    public Guid TenantId { get; set; }
    public string Name { get; set; }
    public string SourceLanguage { get; set; }     // e.g. "en"
    public string TargetLanguage { get; set; }     // e.g. "de"
    public string? DeepLGlossaryId { get; set; }   // Runtime DeepL ID
    public DateTime? LastSyncedAt { get; set; }
    public bool IsDirty { get; set; } = true;      // Triggers re-sync
    public ICollection<TenantGlossaryEntry> Entries { get; set; }
}

Wenn ein Benutzer einen Glossareintrag hinzufügt, z.B. die Zuordnung von "Sprint Review" zu "Sprint-Überprüfung" für EN→DE, wird der Datenbankeintrag sofort aktualisiert und IsDirty wird auf true gesetzt. Das Glossar DeepL wird nicht sofort neu erstellt. Es wird erst nach und nach neu erstellt, wenn es das nächste Mal für eine Übersetzung benötigt wird.

Der Sync-Fluss

Vor jedem Übersetzungsaufruf löst das System das Glossar auf:

public async Task<string?> GetOrSyncDeepLGlossaryIdAsync(
    string sourceLanguage, string targetLanguage,
    CancellationToken ct = default)
{
    var glossary = await _db.TenantGlossaries
        .Include(g => g.Entries)
        .FirstOrDefaultAsync(g =>
            g.SourceLanguage == sourceLanguage &&
            g.TargetLanguage == targetLanguage, ct);

    if (glossary is null || glossary.Entries.Count == 0)
        return null;

    if (!glossary.IsDirty && glossary.DeepLGlossaryId is not null)
        return glossary.DeepLGlossaryId;

    // Dirty - delete old, create new
    if (glossary.DeepLGlossaryId is not null)
        await _deepL.DeleteGlossaryAsync(glossary.DeepLGlossaryId);

    var entries = glossary.Entries
        .ToDictionary(e => e.SourceTerm, e => e.TargetTerm);

    var deepLGlossary = await _deepL.CreateGlossaryAsync(
        $"rasepi-{glossary.Id}",
        glossary.SourceLanguage,
        glossary.TargetLanguage,
        entries);

    glossary.DeepLGlossaryId = deepLGlossary.GlossaryId;
    glossary.IsDirty = false;
    glossary.LastSyncedAt = DateTime.UtcNow;
    await _db.SaveChangesAsync(ct);

    return glossary.DeepLGlossaryId;
}

Drei Dinge sind hier erwähnenswert:

Lazy sync. Wir rufen die DeepL API nur auf, wenn tatsächlich eine Übersetzung benötigt wird. Die Bearbeitung von Glossareinträgen löst nicht Dutzende von API-Aufrufen aus.
Mieterisolierung. Die Abfrage durchläuft die globalen EF-Abfragefilter, sodass TenantGlossaries automatisch gescannt wird. Die Glossareinträge von Tenant A gelangen nicht in die Übersetzungen von Tenant B.
Ein Glossar pro Sprachenpaar. DeepL erzwingt dies ohnehin. Ein EN→DE-Glossar, ein EN→FR-Glossar, und so weiter. Das (SourceLanguage, TargetLanguage)-Paar ist pro Tenant eindeutig.

Glossar-Einträge

Einzelne Einträge sind nur Begriffszuordnungen:

public class TenantGlossaryEntry
{
    public Guid Id { get; set; }
    public Guid GlossaryId { get; set; }
    public string SourceTerm { get; set; }   // e.g. "Sprint Review"
    public string TargetTerm { get; set; }   // e.g. "Sprint-Überprüfung"
}

Die API bietet dir vollständiges CRUD sowie CSV-Import/Export für die Massenverwaltung:

POST   /admin/glossaries                       Create glossary
POST   /admin/glossaries/{id}/entries           Add term
PUT    /admin/glossaries/{id}/entries/{entryId}  Update term
DELETE /admin/glossaries/{id}/entries/{entryId}  Remove term
POST   /admin/glossaries/{id}/import            Import CSV
GET    /admin/glossaries/{id}/export            Export CSV
POST   /admin/glossaries/{id}/sync              Force DeepL sync

Der CSV-Import ist besonders nützlich für Teams, die von bestehenden Translation-Memory-Systemen migrieren. Exportiere deine Begriffe, bereinige sie, importiere sie in Rasepi, und der nächste Übersetzungslauf verwendet das neue Glossar automatisch.

Stilregeln, benutzerdefinierte Anweisungen und Formalitäten

Glossare kümmern sich um die Terminologie. Aber Terminologie ist nur die halbe Miete. Eine Übersetzung kann alle richtigen Wörter verwenden und trotzdem falsch klingen. Falscher Ton, falsches Datumsformat, falsche Zeichensetzungskonventionen.

Die Style Rules API (v3) von DeepL schafft hier Abhilfe. Du kannst wiederverwendbare Stilregel-Listen erstellen, die zwei Arten von Steuerelementen kombinieren:

Konfigurierte Regeln, vordefinierte Formatierungskonventionen für Daten, Zeiten, Satzzeichen, Zahlen und mehr
Benutzerdefinierte Anweisungen, Freitextanweisungen, die den Ton, die Formulierung und bereichsspezifische Konventionen bestimmen

Rasepi erstellt und verwaltet diese pro Tenant und pro Zielsprache. Die Entität TenantStyleRuleList speichert die DeepL style_id neben den konfigurierten Regeln und benutzerdefinierten Anweisungen des Tenants:

public class TenantStyleRuleList : ITenantScoped
{
    public Guid Id { get; set; }
    public Guid TenantId { get; set; }
    public string Name { get; set; }
    public string TargetLanguage { get; set; }      // e.g. "de"
    public string? DeepLStyleId { get; set; }       // Runtime DeepL style_id
    public string ConfiguredRulesJson { get; set; }  // Serialized configured rules
    public bool IsDirty { get; set; } = true;
    public DateTime? LastSyncedAt { get; set; }
    public ICollection<TenantCustomInstruction> CustomInstructions { get; set; }
}

Erstellen von Stilregel-Listen

Wenn ein Admin Übersetzungsregeln für Deutsch einrichtet, ruft Rasepi die v3 API von DeepL auf, um die Stilregel-Liste zu erstellen. So sieht das aus:

public async Task<string> CreateOrSyncStyleRuleListAsync(
    TenantStyleRuleList ruleList, CancellationToken ct = default)
{
    if (!ruleList.IsDirty && ruleList.DeepLStyleId is not null)
        return ruleList.DeepLStyleId;

    // DeepL style rule lists are mutable - we can update in place
    if (ruleList.DeepLStyleId is not null)
    {
        // Replace configured rules on existing list
        await _httpClient.PutAsJsonAsync(
            $"v3/style_rules/{ruleList.DeepLStyleId}/configured_rules",
            JsonSerializer.Deserialize<JsonElement>(ruleList.ConfiguredRulesJson),
            ct);

        // Sync custom instructions
        await SyncCustomInstructionsAsync(ruleList, ct);

        ruleList.IsDirty = false;
        ruleList.LastSyncedAt = DateTime.UtcNow;
        return ruleList.DeepLStyleId;
    }

    // Create new style rule list
    var payload = new
    {
        name = $"rasepi-{ruleList.TenantId}-{ruleList.TargetLanguage}",
        language = ruleList.TargetLanguage,
        configured_rules = JsonSerializer.Deserialize<JsonElement>(
            ruleList.ConfiguredRulesJson),
        custom_instructions = ruleList.CustomInstructions.Select(ci => new
        {
            label = ci.Label,
            prompt = ci.Prompt,
            source_language = ci.SourceLanguage
        })
    };

    var response = await _httpClient.PostAsJsonAsync("v3/style_rules", payload, ct);
    var result = await response.Content.ReadFromJsonAsync<StyleRuleResponse>(ct);

    ruleList.DeepLStyleId = result.StyleId;
    ruleList.IsDirty = false;
    ruleList.LastSyncedAt = DateTime.UtcNow;
    await _db.SaveChangesAsync(ct);

    return ruleList.DeepLStyleId;
}

Anders als Glossare sind DeepL Stilregel-Listen veränderbar. Du kannst konfigurierte Regeln mit PUT /v3/style_rules/{style_id}/configured_rules ersetzen, und benutzerdefinierte Anweisungen können individuell hinzugefügt, aktualisiert oder gelöscht werden. Das ist viel besser für die iterative Verfeinerung geeignet.

Wie konfigurierte Regeln aussehen

Konfigurierte Regeln decken Formatierungskonventionen ab, die je nach Sprache oder Firmenpräferenz variieren. Dinge wie:

{
  "dates_and_times": {
    "time_format": "use_24_hour_clock",
    "calendar_era": "use_bc_and_ad"
  },
  "punctuation": {
    "periods_in_academic_degrees": "do_not_use"
  },
  "numbers": {
    "decimal_separator": "use_comma"
  }
}

Das hört sich trivial an, aber es wird schnell kompliziert. Ein deutsches Dokument, das das AM/PM-Zeitformat und durch Punkte getrennte Dezimalzahlen verwendet, liest sich für einen deutschen Leser einfach als "aus dem Englischen übersetzt". Wenn du use_24_hour_clock und use_comma für Dezimaltrennzeichen in allen deutschen Übersetzungen einstellst, wird das sofort behoben.

Benutzerdefinierte Anweisungen: Das ist die wahre Macht

Benutzerdefinierte Anweisungen sind Freitextanweisungen, bis zu 200 pro Stilregel-Liste, jede mit bis zu 300 Zeichen. Damit sagst du DeepL, wie die Übersetzung aussehen soll, und zwar in einfacher Sprache:

public class TenantCustomInstruction
{
    public Guid Id { get; set; }
    public Guid StyleRuleListId { get; set; }
    public string Label { get; set; }              // e.g. "Tone instruction"
    public string Prompt { get; set; }             // e.g. "Use a friendly, diplomatic tone"
    public string? SourceLanguage { get; set; }    // Optional source lang filter
}

Echte Beispiele von unseren Mietern:

"Use a friendly, diplomatic tone" für ein Startup, das ansprechende Dokumente braucht
"Always use 'Sie' form, never 'du'" für eine deutsche Anwaltskanzlei
"Translate 'deployment' as 'Bereitstellung', never 'Deployment'" für Begriffe, die eine kontextabhängige Handhabung benötigen, die über eine einfache Glossarzuordnung hinausgeht
"Use British English spelling (colour, organisation, licence)" für britische Unternehmen, die zwischen englischen Varianten übersetzen
"Put currency symbols after the numeric amount" zur Anpassung an europäische Konventionen

Benutzerdefinierte Anweisungen sind sehr hilfreich, wenn es um domänenspezifische Konventionen geht, die nicht in Glossareinträge passen. Ein Glossar ordnet einen Begriff einem anderen zu. In einer benutzerdefinierten Anweisung kann stehen: "Wenn du API-Dokumente übersetzst, verwende den Imperativ statt des Passivs. Das ist eine ganz andere Art der Kontrolle.

Formalität

DeepL's formality Parameter (default, more, less, prefer_more, prefer_less) ist immer noch als separates Steuerelement neben Stilregeln verfügbar. Deutsch "du" versus "Sie", Französisch "tu" versus "vous", japanische Höflichkeitsstufen. Diese werden pro Mietersprache über TenantLanguageConfig eingestellt:

public class TenantLanguageConfig : ITenantScoped
{
    public string LanguageCode { get; set; }
    public string DisplayName { get; set; }
    public bool IsEnabled { get; set; }
    public TranslationTrigger Trigger { get; set; }
    public string? Formality { get; set; }         // "more", "less", "prefer_more", etc.
    public string? StyleRuleListId { get; set; }   // Links to TenantStyleRuleList
    public string? TranslationProvider { get; set; }
    public int SortOrder { get; set; }
    public bool IsDefault { get; set; }
}

Formalitäten, Stilregeln und Glossare setzen sich zusammen. Ein einziger Übersetzungsaufruf kann alle drei enthalten:

var glossaryId = await GetOrSyncDeepLGlossaryIdAsync(sourceLang, targetLang, ct);
var styleId = await GetOrSyncStyleRuleListAsync(targetLang, ct);
var formality = tenantLanguageConfig.Formality ?? "default";

// Build the v2/translate request payload
var payload = new
{
    text = new[] { blockContent },
    source_lang = NormalizeLanguageCode(sourceLang),
    target_lang = NormalizeLanguageCode(targetLang),
    glossary_id = glossaryId,
    style_id = styleId,
    formality = formality,
    preserve_formatting = true,
    context = surroundingContext,  // Adjacent blocks, not billed
    model_type = "quality_optimized"
};

Zwei Dinge sind hier erwähnenswert:

Der context Parameter. Wir übergeben benachbarte Blöcke als Kontext, um die Übersetzungsqualität zu verbessern. DeepL nutzt dies, um Mehrdeutigkeiten aufzulösen, übersetzt oder berechnet sie aber nicht. Ein Absatz über "Zellen" wird anders übersetzt, wenn der umgebende Kontext ein Biologiedokument und eine Tabellenkalkulationsanleitung ist.
Modellauswahl. Jede Anfrage mit style_id oder custom_instructions verwendet automatisch das quality_optimized Modell von DeepL. Dies ist die höchste Qualitätsstufe. Du kannst sie nicht mit latency_optimized kombinieren, und das ist eine bewusste Einschränkung von DeepL. Für die Stilanpassung brauchst du das komplette Modell.

Warum das wichtiger ist, als du denkst

Stell dir vor, ein Unternehmen schreibt interne Dokumente auf Deutsch mit dem formlosen "du" und wechselt in einem übersetzten Abschnitt plötzlich zum formellen "Sie". Das sieht bestenfalls inkonsequent und schlimmstenfalls unprofessionell aus. Die Formalität regelt das. Aber die Formalität allein reicht nicht aus, um ein Dokument zu erkennen, das AM/PM-Zeitstempel verwendet, obwohl dein deutsches Büro das 24-Stunden-Format benutzt, oder das Währungssymbol vor die Zahl setzt, statt danach.

Alles zusammen (Stilregeln, benutzerdefinierte Anweisungen, Formalitäten, Glossare) ergibt Übersetzungen, die sich so lesen, als hätte sie jemand aus deinem Team geschrieben. Nicht wie die Ausgabe einer Maschine, die nicht weiß, dass dein Unternehmen existiert.

Die DeepL Service-Schicht

Die gesamte DeepL Kommunikation läuft über IDeepLService. Sie umhüllt das offizielle DeepL .NET SDK und verarbeitet v3 API-Aufrufe für Stilregeln:

public interface IDeepLService
{
    // Text translation (v2)
    Task<TextResult> TranslateTextAsync(
        string text, string sourceLanguage, string targetLanguage,
        string? options = null);

    Task<TextResult[]> TranslateTextBatchAsync(
        IEnumerable<string> texts, string sourceLanguage,
        string targetLanguage, string? options = null);

    // Glossary management (v2)
    Task<GlossaryInfo> CreateGlossaryAsync(
        string name, string sourceLang, string targetLang,
        Dictionary<string, string> entries);
    Task DeleteGlossaryAsync(string glossaryId);
    Task<GlossaryInfo> GetGlossaryAsync(string glossaryId);
    Task<GlossaryInfo[]> ListGlossariesAsync();
    Task<Dictionary<string, string>> GetGlossaryEntriesAsync(
        string glossaryId);

    // Style rules (v3)
    Task<StyleRuleResponse> CreateStyleRuleListAsync(
        string name, string language,
        JsonElement configuredRules,
        IEnumerable<CustomInstructionRequest> customInstructions);
    Task ReplaceConfiguredRulesAsync(
        string styleId, JsonElement configuredRules);
    Task<CustomInstructionResponse> AddCustomInstructionAsync(
        string styleId, string label, string prompt,
        string? sourceLanguage = null);
    Task DeleteCustomInstructionAsync(
        string styleId, string instructionId);
    Task DeleteStyleRuleListAsync(string styleId);

    // Usage tracking
    Task<Usage> GetUsageAsync();
    Task<Language[]> GetSourceLanguagesAsync();
    Task<Language[]> GetTargetLanguagesAsync();
}

Die Implementierung kümmert sich um die Normalisierung des Sprachcodes. DeepL erfordert EN-US oder EN-GB anstelle des bloßen en und PT-PT oder PT-BR anstelle von pt:

private static string NormalizeLanguageCode(string code)
    => code.ToLower() switch
    {
        "en" => "EN-US",
        "pt" => "PT-PT",
        _ => code.ToUpper()
    };

Die Batch-Übersetzung verwendet 50-Elemente-Chunking, um die API-Grenzen von DeepL einzuhalten und gleichzeitig den Durchsatz zu maximieren:

public async Task<TranslationBatchResult> TranslateBatchAsync(
    Dictionary<string, string> texts,
    string sourceLanguage, string targetLanguage)
{
    var translations = new Dictionary<string, string>();
    long totalChars = 0;

    foreach (var chunk in texts.Chunk(50))
    {
        var results = await _deepL.TranslateTextBatchAsync(
            chunk.Select(kv => kv.Value),
            sourceLanguage, targetLanguage);

        for (int i = 0; i < chunk.Length; i++)
        {
            translations[chunk[i].Key] = results[i].Text;
            totalChars += chunk[i].Value.Length;
        }
    }

    return new TranslationBatchResult
    {
        Translations = translations,
        BilledCharacters = totalChars
    };
}

Da wir nur veraltete Blöcke und nicht ganze Dokumente senden, enthält ein typischer Übersetzungsstapel für eine einzelne Bearbeitung 1-3 Blöcke statt 40+. Daher kommt die Kostenreduzierung von 94 %.

Der Übersetzungs-Orchestrator

Der TranslationOrchestrator entscheidet, was mit den einzelnen Blöcken geschehen soll, wenn sich das Quelldokument ändert. Schauen wir uns den Entscheidungsbaum an:

public async Task OrchestrateTranslationAsync(
    Guid entryId, List<Guid> changedBlockIds,
    CancellationToken ct = default)
{
    var entry = await _db.Entries
        .FirstOrDefaultAsync(e => e.Id == entryId, ct);

    var translations = await _db.EntryTranslations
        .Where(t => t.EntryId == entryId)
        .ToListAsync(ct);

    foreach (var translation in translations)
    {
        var langConfig = await GetLanguageConfigAsync(
            translation.Language, ct);

        var translationBlocks = await _db.TranslationBlocks
            .Where(tb => changedBlockIds.Contains(tb.SourceBlockId)
                      && tb.Language == translation.Language)
            .ToListAsync(ct);

        foreach (var block in translationBlocks)
        {
            if (block.IsLocked || block.TranslatedById is not null)
            {
                // Human-edited or locked - mark stale, don't overwrite
                block.Status = TranslationStatus.Stale;
            }
            else if (langConfig.Trigger == TranslationTrigger.AlwaysTranslate)
            {
                // Machine-translated, auto mode - retranslate now
                await RetranslateBlockAsync(block, translation.Language, ct);
            }
            else
            {
                // TranslateOnFirstVisit - mark stale, translate later
                block.Status = TranslationStatus.Stale;
            }
        }
    }

    await _db.SaveChangesAsync(ct);
}

Der wichtigste Punkt: Von Menschen bearbeitete Blöcke werden niemals automatisch überschrieben. Wenn ein Übersetzer einen Block manuell angepasst hat, z. B. durch Hinzufügen von kulturellem Kontext oder eine klarere Formulierung, respektiert das System diese Arbeit. Es markiert den Block als veraltet, damit der Übersetzer weiß, dass sich die Quelle geändert hat, aber es ersetzt seine Änderungen nicht stillschweigend.

Maschinell übersetzte Blöcke, bei denen AlwaysTranslate aktiviert ist, werden sofort neu übersetzt. Maschinell übersetzte Blöcke mit TranslateOnFirstVisit werden als veraltet markiert und übersetzt, wenn jemand das Dokument in dieser Sprache öffnet.

Übersetzungsauslöser: wann Übersetzungen stattfinden

Jede Sprache hat einen TranslationTrigger, der das Timing steuert:

public enum TranslationTrigger
{
    AlwaysTranslate,         // Translate on every save
    TranslateOnFirstVisit    // Translate when first opened in that language
}

AlwaysTranslate ist nützlich für Sprachen mit hoher Priorität, bei denen du möchtest, dass die Übersetzungen sofort aktuell sind. Französisch für ein Unternehmen mit einer großen Niederlassung in Paris. Deutsch für ein Unternehmen mit Hauptsitz in München.

TranslateOnFirstVisit ist nützlich für Sprachen, die gelegentlich benötigt werden, aber nicht die API-Kosten wert sind, um sie immer auf dem neuesten Stand zu halten. Wenn jemand das Dokument in dieser Sprache öffnet, werden veraltete Blöcke sofort übersetzt.

Beide Modi verwenden die gleiche Glossarauflösung, die gleichen Formalitätseinstellungen und das gleiche Content-Hashing. Der einzige Unterschied ist das Timing.

Einzigartige Anpassung von Inhalt und Struktur

Hier zahlt sich die Architektur über die reine Übersetzung hinaus wirklich aus.

Wenn ein deutscher Übersetzer einen Abschnitt zur Einhaltung der DSGVO hinzufügt, den es im Englischen nicht gibt, fügt er ihn in der deutschen Version als neuen Block hinzu. Dieser Block hat keinen SourceBlockId, er ist als einzigartiger Inhalt gekennzeichnet. Das System schickt ihn nie zur Neuübersetzung, weil es keine Quelle gibt, aus der er übersetzt werden kann. Er existiert nur auf Deutsch.

Wenn ein japanischer Übersetzer eine Aufzählung in eine nummerierte Liste umwandelt (eine gängige Konvention in der japanischen Fachliteratur), bleibt das IsStructureAdapted-Kennzeichen des Blocks auch in zukünftigen Übersetzungszyklen erhalten:

var translation = new TranslationBlock
{
    SourceBlockId = sourceBlockId,
    Language = targetLanguage,
    BlockType = translatedBlockType,
    SourceBlockType = sourceBlock.BlockType,
    IsStructureAdapted = translatedBlockType != sourceBlock.BlockType,
    StructureAdaptationNotes = "Numbered list preferred in JP technical docs",
    SourceContentHash = sourceBlock.ContentHash,
    Status = TranslationStatus.UpToDate,
};

Das IsNoTranslate Flag behandelt Inhalte, die wortwörtlich kopiert werden sollen: Codeblöcke, URLs, Produktnamen, mathematische Notationen. Der Übersetzungsanbieter überspringt diese komplett.

Alles zusammenfügen

Gehen wir den gesamten Ablauf durch. Ein Benutzer in London bearbeitet einen Absatz im englischen Quelldokument, und dein Münchner Büro hat Deutsch auf AlwaysTranslate eingestellt:

Benutzer speichert. TipTap sendet JSON an die API.
Blockextraktion und Änderungserkennung. CreateBlocksFromDocumentAsync analysiert JSON, berechnet die Hashes der Inhalte neu und vergleicht die alten und neuen Hashes, um festzustellen, welche Blöcke sich tatsächlich geändert haben.
Orchestrator läuft. Findet den deutschen EntryTranslation, überprüft den deutschen Block. Er ist maschinell übersetzt, nicht gesperrt und nicht von Menschenhand bearbeitet, also kann er neu übersetzt werden.
**Übersetzungskonfiguration geladen ** Glossar-ID über GetOrSyncDeepLGlossaryIdAsync("en", "de") aufgelöst, Stilregeln über GetOrSyncStyleRuleListAsync("de"), Formalität auf "mehr" (formal "Sie") gesetzt, benachbarte Blöcke als Kontext für die Disambiguierung übergeben.
DeepL Aufruf. Ein einzelner Block wird mit Glossar-ID, Stil-ID, Formalität und Kontext gesendet.
Block aktualisiert. Übersetzter Inhalt gespeichert, SourceContentHash synchronisiert, Status auf UpToDate gesetzt. Ein Block anstelle von 40+ übersetzt. Die restlichen 39 Blöcke? Unangetastet.

In deinem Büro in Tokio ist Japanisch auf TranslateOnFirstVisit gesetzt. Die gleiche Bearbeitung markiert den japanischen Übersetzungsblock als Stale. Wenn jemand in Tokio das Dokument öffnet, werden die Schritte 5-9 im Handumdrehen ausgeführt. Ihre Strukturanpassung (nummerierte Liste) bleibt erhalten. Ihre einzigartigen Blöcke bleiben genau dort, wo sie sind.

Meiner Meinung nach ist die Übersetzungsmaschine der Teil von Rasepi, der den größten sichtbaren Nutzen bringt. Übersetzungen, die deine Terminologie verwenden, deine Formatierungskonventionen befolgen, deine eigenen Anweisungen befolgen, deinen Tonfall treffen, die Arbeit deiner Übersetzer respektieren und nur einen Bruchteil dessen kosten, was eine vollständige Neuübersetzung kosten würde. Die Architektur sorgt dafür, dass all das automatisch abläuft, und hält sich aus dem Weg, wenn Menschen die Arbeit übernehmen wollen.

Dieselbe DeepL Engine, die die schriftlichen Übersetzungen antreibt, treibt auch Talk to Docs an, unsere dialogorientierte Dokumentationsoberfläche, bei der DeepL Voice die gesprochene Interaktion übernimmt. Dieselben Glossare, dieselben Stilregeln, dieselbe Formalität, dieselbe Konsistenz. Ob dein Team die Dokumentation liest oder mit ihr spricht, die Sprachqualität ist identisch.

Erkunde die Übersetzungs-API →

Es ist besser, mit Dokumenten zu sprechen, als sie zu lesen

2026-03-10T00:00:00Z

Es gibt einen Grund, warum die Leute sagen: "Lass uns darüber reden", wenn etwas komplex ist.

Wenn wir versuchen, eine neue Idee zu verstehen, ein Problem zu lösen oder uns unter Druck an einen Prozess zu erinnern, ist ein Gespräch oft einfacher als Lesen. Nicht, weil Lesen schlecht ist. Lesen ist eines der mächtigsten Werkzeuge, die der Mensch je entwickelt hat. Aber Lesen ist eine erlernte Fähigkeit, die auf etwas viel Älterem aufbaut: dem Sprechen.

Wir sprechen, lange bevor wir lesen.

Das ist wichtiger, als man denkt, vor allem jetzt, wo ein Großteil des weltweiten Wissens in Dokumenten, Wikis, PDFs und langen internen Seiten steckt, die niemand öffnen will, wenn er nicht unbedingt muss.

Lesen wird gelernt. Konversation ist angeboren.

Die Menschen haben sehr lange gesprochen, bevor sie etwas aufgeschrieben haben. Kinder lernen auf natürliche Weise, gesprochene Sprache zu verstehen. Zum Lesen braucht man ausdrückliche Anweisungen, Wiederholungen und jahrelange Übung.

Selbst für sehr gebildete Erwachsene ist Lesen immer noch ein bewussterer Akt als Zuhören oder Sprechen. Es erfordert visuelle Konzentration, kontinuierliche Aufmerksamkeit, ein Arbeitsgedächtnis und die Interpretation von Strukturen auf der Seite. Du entschlüsselst Symbole, zerlegst Sätze, stellst Zusammenhänge her und entscheidest, was wichtig ist.

Konversation funktioniert anders. Wenn Informationen in gesprochener, interaktiver Form übermittelt werden, macht das Gehirn eine andere Erfahrung:

Es fühlt sich sequentiell und nicht visuell überwältigend an
Es gibt sofortiges Feedback und Klarheit
Es reduziert die Notwendigkeit, große Textblöcke zu scannen und zu filtern
Es spiegelt die Art und Weise wider, wie Menschen bereits im echten Leben um Hilfe bitten

Dieser letzte Punkt ist sehr wichtig. Unter Unsicherheit wollen die meisten Menschen nicht instinktiv 1.500 Wörter lesen. Sie wollen fragen: "Was mache ich als Nächstes?"

Reden senkt die kognitive Reibung

Ein Dokument ist statisch. Es enthält alles auf einmal.

Das klingt nützlich, und oft ist es das auch. Aber es schafft auch Reibung. Eine Seite voller Überschriften, Aufrufe, Links, Notizen, Beispiele und Sonderfälle zwingt den Leser zu entscheiden, was er ignorieren soll. Das ist kognitiv teuer.

Wenn du mit einem Informationssystem sprichst, machst du in der Regel die gegenteilige Erfahrung: Erst die Relevanz, dann die Details.

Du stellst eine Frage. Du bekommst eine Antwort. Dann stellst du eine Folgefrage.

Dieses Interaktionsmuster reduziert den mentalen Aufwand auf mehrere wichtige Arten:

1. Es grenzt den Problemraum ein

Ein vollständiges Dokument zeigt die gesamte Landschaft. Ein Gespräch zeigt den nächsten nützlichen Schritt.

Wenn jemand fragt: "Wie bringe ich einen neuen Ingenieur an Bord?" will er in der Regel nicht gleich das ganze Handbuch. Sie wollen eine Orientierung. Mit einem Gespräch können sie klein anfangen und nur bei Bedarf erweitern.

2. Es schont das Arbeitsgedächtnis

Beim Lesen musst du mehrere Dinge im Kopf behalten, während du nach der relevanten Stelle suchst. Gesprochene oder konversationelle Interaktion macht diese Anstrengung überflüssig. Das System übernimmt einen Großteil des Filterns für dich.

3. Es fühlt sich sozial vertraut an

Wir Menschen sind an den gegenseitigen Austausch gewöhnt. Wir fragen. Jemand antwortet. Wir verfeinern. Sie klären. Diese Schleife ist eine der ältesten Formen des Lernens, die wir kennen.

Selbst wenn der "Jemand" ein System ist, fühlt sich die Struktur immer noch natürlich an.

Lesen ist nicht passiv. Das ist genau der Punkt.

Ein Grund, warum sich Reden leichter anfühlen kann, ist, dass Lesen nicht so mühelos ist, wie die Leute annehmen. Geübte Leser/innen lassen es mühelos aussehen, aber der Prozess ist sehr aktiv.

Um gut zu lesen, musst du das tun:

eine Struktur erkennen
auf die Bedeutung schließen
Zweideutigkeiten auflösen
den Kontext im Gedächtnis behalten
einen Abschnitt mit einem anderen zu verbinden
entscheiden, wann man überfliegt und wann man langsamer wird

Das ist echte kognitive Arbeit.

In vielen Situationen lohnt sich diese Arbeit. Tiefgehendes Lesen hilft bei Nuancen, Präzision und langfristigem Verständnis. Aber in anderen Situationen, vor allem wenn jemand müde, gestresst oder überlastet ist oder einfach nur versucht, sich zu befreien, ist Reden oft die geistig leichtere Option.

Das gilt besonders am Arbeitsplatz, wo die Menschen normalerweise nicht unter idealen Bedingungen an die Dokumentation herangehen. Sie sind es:

mitten in der Arbeit
unterbrochen
im Kontext wechselnd
versuchen, etwas schnell zu lösen
oft schon leicht frustriert

In diesem Zustand kann sich der konversationelle Zugang zu Informationen dramatisch besser anfühlen als der Zugriff auf eine Seite.

Sprechen verändert die Beziehung zu Informationen

Es gibt hier auch eine emotionale Dimension.

Dokumente können sich formell und distanziert anfühlen. Sie implizieren: Lies das alles, verstehe es richtig und übersehe nichts Wichtiges. Das kann als Nachschlagewerk nützlich sein, aber es kann auch zum Zögern anregen.

Konversation fühlt sich freizügig an. Du kannst vage sein. Du kannst schlecht fragen. Du kannst Verwirrung zugeben. Du kannst sagen: "Ich weiß nicht wirklich, wonach ich suche, aber ich brauche die Sache mit den Zugangsanfragen."

Das ist wichtig, denn die Leute meiden Unterlagen oft nicht, weil sie Informationen nicht mögen, sondern weil sie den Aufwand und die Ungewissheit scheuen, die damit verbunden sind, den richtigen Teil der Unterlagen zu finden.

Reden baut diese Barriere ab.

Warum das jetzt wichtig ist

Lange Zeit mussten Dokumente gelesen werden, weil es keine praktische Alternative gab. Die Suche erleichterte das Auffinden von Seiten, aber sie änderte das Interaktionsmodell nicht. Du musstest die Seite immer noch öffnen, sie einscannen und das herausziehen, was du brauchst.

Das ändert sich jetzt.

Da die Benutzeroberflächen immer dialogorientierter werden, erwarten die Menschen zunehmend, dass sie auf Informationen reagieren, anstatt einfach nur zu existieren. Sie wollen in einfacher Sprache nach dem fragen, was sie brauchen, und etwas erhalten, das auf den jeweiligen Moment zugeschnitten ist.

Das macht das Lesen nicht überflüssig. Es verändert nur seine Rolle.

Das Lesen wird zur Tiefenschicht. Die Konversation wird zur Zugangsebene.

Die besten Systeme werden beides unterstützen:

Sprechen, wenn du Orientierung oder Geschwindigkeit brauchst
Lesen, wenn du Tiefe, Überprüfung oder vollen Kontext brauchst

Das Risiko einer zu starken Vereinfachung

Es gibt einen wichtigen Vorbehalt: Mit Informationen zu sprechen fühlt sich nur dann besser an, wenn die Antworten zuverlässig sind.

Wenn eine Dialogschnittstelle nur unvollständige, irreführende oder zu selbstsichere Antworten gibt, ist das Erlebnis schlechter als das Lesen, weil es dem Nutzer die Möglichkeit nimmt, das Quellmaterial direkt zu prüfen.

Die Zukunft liegt also nicht darin, "alle Dokumente durch Sprache zu ersetzen". Die Zukunft liegt darin, den Menschen einen menschlicheren Zugang zu Dokumenten zu ermöglichen, ohne die Tiefe und Präzision zu verlieren, die schriftliches Wissen bietet.

Dieses Gleichgewicht ist wichtig. Gespräche sind einfacher, aber Dokumente haben immer noch die dauerhafte Struktur, die Details und die Verantwortlichkeit, die Organisationen brauchen.

Eine menschlichere Schnittstelle zum Wissen

Der tiefere Punkt ist einfach: Menschen denken nicht von Natur aus in Seiten. Sie denken in Fragen, Geschichten, Fragmenten und Dialogen.

Wir fragen:

Was bedeutet das?
Was muss ich zuerst tun?
Was ist das Wichtigste?
Kannst du das anders erklären?
Was hat sich geändert?

Das sind Gesprächsmanöver, keine Lesemanöver.

Wenn es sich also leichter anfühlt, mit Informationen zu sprechen als sie zu lesen, ist das kein Zeichen von Denkfaulheit. Es ist in der Regel ein Zeichen dafür, dass die Schnittstelle der Art und Weise entspricht, wie das Gehirn Ungewissheit am liebsten angeht.

Lesen bleibt wichtig. Aber als Einstieg in das Wissen fühlt sich das Gespräch oft besser an, weil es dem entspricht, was wir von Natur aus sind.

Wir sind nicht in erster Linie Leser. Wir sind in erster Linie Redner. Die intuitivsten Wissenssysteme werden sich das merken.

Dokumentationsplattformen für eine andere Ära

2026-03-08T00:00:00Z

Confluence und Notion sind keine schlechten Produkte. Das muss gleich zu Beginn klar gesagt werden.

Sie waren aus guten Gründen erfolgreich. Confluence wurde in vielen Unternehmen zur Standard-Heimat für interne Dokumentation, weil es Teams einen zentralen Ort zum Schreiben, Organisieren und Teilen von Wissen bot. Notion überzeugte durch seine Flexibilität, die übersichtlichere Schreibweise und eine modernere Produktoberfläche.

Beide Plattformen lösten echte Probleme in der Zeit, für die sie entwickelt wurden.

Das Problem ist nun, dass sich die Welt um sie herum schneller verändert hat als ihre Grundlagen.

Wir leben nicht mehr in einer Welt, in der Dokumentation nur geschrieben, gespeichert und durchsucht werden muss. Wir befinden uns in einer Welt, in der zunehmend erwartet wird, dass Dokumentation vorhanden ist:

maschinenlesbar
auf Aktualität bedacht
sicher für KI-Abfragen
strukturiert genug für die Automatisierung
dynamisch über Sprachen und Zielgruppen hinweg
kontinuierlich vertrauenswürdig, nicht nur verfügbar

Das ist eine andere Messlatte.

Sie wurden für ein Vor-AI-Modell des Wissens entwickelt.

Traditionelle Dokumentationsplattformen wurden auf der Grundlage einer einfachen Annahme entwickelt: Wenn die Seite existiert und durchsuchbar ist, ist das Problem weitgehend gelöst.

Das war gut genug, als der Hauptnutzer noch ein Mensch war, der ein Wiki öffnete, die Seite überflog und ein Urteil abgab. In diesem Modell bestand die Aufgabe der Plattform darin, das Verfassen und Navigieren zu erleichtern.

KI ändert die Aufgabenbeschreibung.

Jetzt speichert die Plattform nicht nur Wissen für Menschen. Sie produziert Quellenmaterial für Systeme, die das Wissen automatisch abrufen, einordnen, zusammenfassen und Fragen beantworten.

Das bringt neue Anforderungen mit sich, denen ältere Architekturen keine Priorität einräumten:

Welche Inhalte sind im Moment vertrauenswürdig?
Welche Seiten sind veraltet, aber noch durchsuchbar?
Welche Abschnitte wurden kürzlich geändert?
Welche Sprachversion ist aktuell?
Welcher Inhalt ist ein Entwurf, archiviert, regionsspezifisch oder wenig vertrauenswürdig?
Welche Dokumente sollten ganz von den KI-Antworten ausgeschlossen werden?

Eine Plattform, die nicht für diese Fragen entwickelt wurde, muss sie nachrüsten. Das ist immer schwieriger, als sie von Anfang an zu entwickeln.

Die Stärke des Erbes wird zum Nachteil des Erbes

Etablierte Produkte haben Vorteile: Vertrieb, Ökosystem, Marke, Vertrautheit mit den Kunden, Integrationen und Teams, die wissen, wie man liefert. Aber genau diese Stärken können den Strukturwandel verlangsamen.

Warum? Weil ausgereifte Plattformen Verpflichtungen mit sich bringen.

Sie haben:

jahrelang angesammelte Produktentscheidungen
eine große installierte Basis mit bestehenden Arbeitsabläufen
Erwartungen an die Abwärtskompatibilität
Plugins und Erweiterungen, die auf altem Verhalten basieren
Datenmodelle, die für die Anwendungsfälle von gestern optimiert sind

Wenn eine Plattform wie Confluence oder Notion eine wirklich neue Funktion hinzufügen will, muss sie diese Funktion oft um das bestehende System herum und nicht durch dieses hindurch integrieren.

Das ist die Herausforderung, die sich aus dem Bestehenden ergibt: Du baust nicht nur die Zukunft, sondern nimmst auch die Vergangenheit mit.

Das Hinzufügen von KI-Funktionen ist nicht das Gleiche wie KI-nativ zu werden.

Viele etablierte Plattformen legen jetzt KI oben drauf. Zusammenfassungen. Schreibhilfe. Verbesserte Suche. Q&A-Schnittstellen. Confluence verfügt über [Atlassian Intelligence] (https://www.atlassian.com/platform/intelligence), Notion über [Notion AI] (https://www.notion.com/product/ai) und GitBook über eine [KI-gestützte Suche] (https://docs.gitbook.com/product-tour/searching-your-content/gitbook-ai). Das sind nützliche Funktionen. Einige von ihnen sind gut.

Aber es gibt einen bedeutenden Unterschied zwischen:

dem Hinzufügen von KI-Funktionen zu einem Dokumentationsprodukt
der Entwicklung eines Dokumentationsprodukts, dessen Kernarchitektur von Anfang an auf KI ausgerichtet ist

Der erste Ansatz führt oft zu unterstützenden Funktionen am Rande. Der zweite Ansatz verändert die Grundlage.

Eine KI-native Wissensplattform stellt von Anfang an andere Designfragen:

Wie sollten Dokumente strukturiert sein, damit Systeme sicher auf sie zugreifen können?
Wie soll Vertrauen dargestellt werden?
Welche Metadaten müssen erstklassig und nicht optional sein?
Wie sollte die Sichtbarkeit veralteter Inhalte verringert werden?
Wie sollten Antworten eingeschränkt werden, wenn die zugrunde liegenden Quellen schwach sind?

Das sind architektonische Fragen, keine Funktionsfragen.

Frische Plattformen haben einen vorübergehenden Vorteil

Hier können neuere Plattformen gewinnen, zumindest für eine gewisse Zeit.

Eine neue Plattform hat die Freiheit, sich an den Zwängen von heute und nicht an den Gewohnheiten von gestern zu orientieren. Sie muss nicht ein Jahrzehnt an Annahmen darüber festhalten, was ein Dokument ist oder wie sich ein Wiki verhalten sollte. Sie kann frühzeitig andere Entscheidungen treffen:

Frische als ein Konzept erster Klasse behandeln
Quellensicherheit für Menschen und Maschinen sichtbar machen
umfangreichere Metadaten über den Zustand der Inhalte zu speichern
Mehrsprachige Workflows in das Kernmodell einbauen, anstatt sie aufzuschrauben
die Entscheidung, dass Suche und KI-Retrieval nach Vertrauen und nicht nur nach Relevanz bewertet werden sollten

Diese Freiheit ist wichtig.

In der Technologiebranche sind die etablierten Unternehmen oft in stabilen Zeiten am stärksten. Neue Marktteilnehmer sind oft am stärksten, wenn sich das Modell selbst verändert.

Die KI-Ära ist eine dieser Veränderungen.

Warum dies für Confluence besonders schwer ist

Confluence ist leistungsstark, aber es stammt aus einer älteren Weltanschauung. Es wurde um [Teambereiche, Seiten, hierarchische Navigation] (https://support.atlassian.com/confluence-cloud/docs/use-spaces-to-organize-your-work/) und ein [Plugin-reiches Unternehmensmodell] (https://marketplace.atlassian.com/) herum aufgebaut. Diese Entscheidungen waren sinnvoll. Für viele Organisationen sind sie immer noch sinnvoll.

Aber sie bedeuten auch, dass das Produkt eine Menge Komplexität mit sich bringt. Unternehmensplattformen können sich selten einfach neu erfinden. Sie müssen sich mit ihrer eigenen Geschichte auseinandersetzen.

Das macht die Modernisierung langsamer. Nicht unmöglich. Nur langsamer.

Wenn die Anforderungen der KI-Ära sauberere Metadaten, eine explizitere Vertrauensmodellierung oder eine stärker meinungsgeprägte Content Governance erfordern, kann ein System, das durch jahrelange Erweiterungen auf maximale Flexibilität ausgelegt ist, Schwierigkeiten haben, zusammenhängend zu funktionieren.

Warum dies für Notion besonders schwierig ist

Notion hat ein anderes Problem. Es fühlt sich neuer, leichter und flexibler an. Aber die Flexibilität kann auch gegen ihn arbeiten.

Die Stärke von Notion ist, dass [fast alles zu einer Seite, einer Datenbank, einer Notiz, einem leichtgewichtigen Dokument oder einem Raum für die Zusammenarbeit werden kann] (https://www.notion.com/product). Diese Flexibilität ist großartig für Teams. Weniger gut ist sie, wenn du starke Garantien darüber brauchst, was der Inhalt bedeutet, in welchem Zustand er sich befindet und ob er von einem KI-System als vertrauenswürdige Quelle verwendet werden sollte.

Je freier eine Plattform ist, desto schwieriger ist es, später eine verlässliche Semantik durchzusetzen.

KI-Systeme leben von Strukturen, expliziten Metadaten und Vertrauenssignalen. Flexible, universell einsetzbare Arbeitsbereiche benötigen oft viel Interpretation, bevor ihre Inhalte für diese Art der Nutzung sicher sind.

All das bedeutet nicht, dass sie dem Untergang geweiht sind.

Es wäre eine faule Analyse zu sagen, dass Confluence und Notion sich nicht anpassen können. Natürlich können sie das.

Sie haben kluge Teams, große Ressourcen und starke Anreize. Sie werden mehr KI-Funktionen anbieten. Sie werden die Abfrage, die Autorenunterstützung, die Zusammenfassungen, die Governance und die strukturierten Workflows verbessern. Mit der Zeit werden sie einen Großteil der Lücke schließen.

Aber das Timing ist wichtig.

Bei einem solchen Wandel ist oft derjenige im Vorteil, der am schnellsten neue Annahmen aufstellt. Neuere Plattformen können sich kohärenter bewegen, weil sie nicht so viel nachrüsten müssen. Das verschafft ihnen ein Zeitfenster.

Es ist vielleicht kein dauerhaftes Fenster. Aber es ist real.

Die nächste Phase der Dokumentationsplattformen

Die nächste Generation von Dokumentationswerkzeugen wird wahrscheinlich weniger danach beurteilt werden, wie gut sie Menschen Seiten schreiben lassen, sondern eher danach, wie gut sie Wissen als vertrauenswürdiges System verwalten.

Das bedeutet, dass die Gewinner wahrscheinlich fünf Dinge gut machen werden:

Sie werden Vertrauen explizit modellieren.
Sie unterscheiden aktuelles Wissen von veraltetem Wissen.
Sie behandeln die KI-Abfrage als eine zentrale Produktoberfläche, nicht als Zusatz.
Sie unterstützen mehrsprachiges und zielgruppenspezifisches Wissen ohne Fragmentierung.
Sie geben den Teams mehr Kontrolle darüber, welche Informationen für wen und unter welchen Bedingungen zugänglich sind.

Das ist eine andere Kategorie als das klassische Wiki.

Warum Neustarts wichtig sind

Es gibt Momente in der Softwarebranche, in denen ein neues Produkt einen Vorteil hat, nicht weil die etablierten Unternehmen inkompetent sind, sondern weil die Vergangenheit teuer ist.

Dies ist einer dieser Momente.

Eine neue Plattform kann vom ersten Tag an entscheiden, dass Dokumente nicht nur Seiten sind. Sie sind aktive Quellen für Menschen, Agenten, Suchsysteme und KI-Assistenten. Diese Annahme verändert alles, was danach kommt.

Confluence und Notion können diesen Weg gehen. Aber der Weg dorthin ist länger, weil sie Systeme umwandeln müssen, die für eine andere Ära optimiert waren.

Diese Umwandlung braucht Zeit. In der Zwischenzeit haben neuere Plattformen die Möglichkeit zu definieren, wie eine moderne Wissensinfrastruktur aussehen sollte.

Der größte Vorteil einer neuen Plattform ist nicht die Neuheit. Es ist die Freiheit von alten Annahmen, und zwar genau dann, wenn diese Annahmen nicht mehr funktionieren.

Dies ist ein perspektivischer Beitrag. Behauptungen über Konkurrenzprodukte basieren auf öffentlich zugänglichen Produktdokumentationen und Ankündigungen vom März 2026. Wir haben großen Respekt vor Confluence und Notion - sie sind hervorragende Produkte, die Millionen von Teams gute Dienste leisten.

Einblick in die Rasepi-Architektur: Plugins, Action Guards und Pipelines

2026-03-06T00:00:00Z

Die meisten Dokumentationsplattformen sprechen über "Erweiterbarkeit" wie Fluggesellschaften über "Beinfreiheit". Technisch vorhanden, praktisch enttäuschend. Ich wollte, dass die Architektur von Rasepi wirklich erweiterbar ist, ohne unvorhersehbar zu werden, also haben wir drei ineinandergreifende Systeme entwickelt: Plugins für Fähigkeiten, Action Guards für die Kontrolle und Pipelines für die deterministische Ausführung.

In diesem Beitrag erfährst du, wie jedes dieser Systeme in unserer aktuellen Codebasis funktioniert.

Das Plugin-System: modular aufgebaut

Jedes Plugin in Rasepi implementiert IPluginModule, eine einzelne Schnittstelle, die erklärt, was das Plugin ist, welche Dienste es braucht und welche Routen es offenlegt:

public interface IPluginModule
{
    PluginManifest Manifest { get; }
    void RegisterServices(IServiceCollection services);
    void MapRoutes(IEndpointRouteBuilder routes);
}

Der PluginManifest ist ein reiner Datenblock. Er beschreibt das Plugin, ohne etwas auszuführen:

public sealed class PluginManifest
{
    public required string Id { get; init; }
    public required string Name { get; init; }
    public required string Version { get; init; }
    public string Description { get; init; }
    public string Category { get; init; }
    public IReadOnlyDictionary<string, string> UiContributions { get; init; }
    public bool HasSettings { get; init; }
    public bool HasEndpoints { get; init; }
    public IReadOnlyList<string> Dependencies { get; init; }
}

Beachte UiContributions. Dieses Wörterbuch ordnet Frontend-Erweiterungspunkte den Komponentennamen zu, damit das Vue-Frontend weiß, welche UI-Komponenten jedes Plugin beisteuert (eine Schaltfläche in der Symbolleiste, ein Seitenleisten-Panel, eine Einstellungsseite).

Die Registrierung erfolgt in einer Zeile pro Plugin.

Beim Start registrieren wir Plugins über eine fließende API:

var pluginRegistry = new PluginRegistry();

pluginRegistry
    .AddPlugin<WorkflowPluginModule>(builder.Services)
    .AddPlugin<RulesPluginModule>(builder.Services)
    .AddPlugin<RetentionPluginModule>(builder.Services)
    .AddPlugin<ClassificationPluginModule>(builder.Services);

Jeder Aufruf instanziiert das Modul, speichert es in der Registry und ruft RegisterServices() auf, um seine Abhängigkeiten zu verdrahten. Nachdem die App gebaut wurde, werden in einer einzigen Zeile alle Plugin-Routen zugeordnet:

app.MapPluginRoutes(pluginRegistry);

Unter der Haube erhält jedes Plugin unter /plugins/{pluginId}/ eine skalierte Routengruppe, auf die automatisch eine Autorisierung angewendet wird.

Reales Beispiel: das Workflow-Plugin

Hier siehst du, wie ein echtes Plugin aussieht, das Modul Workflow & Genehmigungen:

public sealed class WorkflowPluginModule : IPluginModule
{
    public const string PluginId = "workflow";

    public PluginManifest Manifest { get; } = new()
    {
        Id = PluginId,
        Name = "Workflow & Approvals",
        Version = "1.0.0",
        Description = "Adds approval workflows to entry publishing.",
        Category = "Workflow",
        HasSettings = true,
        HasEndpoints = true,
        UiContributions = new Dictionary<string, string>
        {
            ["entry.toolbar.publish"] = "WorkflowPublishButton",
            ["entry.sidebar.status"]  = "WorkflowStatusPanel",
            ["hub.admin.settings"]    = "WorkflowHubSettings",
        }
    };

    public void RegisterServices(IServiceCollection services)
    {
        services.AddScoped<IWorkflowService, WorkflowService>();
        services.AddScoped<IActionGuard, WorkflowPublishGuard>();
    }

    public void MapRoutes(IEndpointRouteBuilder routes)
    {
        WorkflowEndpoints.Map(routes);
    }
}

Die Kernplattform verweist niemals direkt auf WorkflowService oder WorkflowPublishGuard. Sie findet sie über den DI-Container. Das ist der Schlüssel zur Null-Kopplung. Die Kernapplikation berührt nie den Plugin-Code.

Action Guards: die Kontrollschicht

Plugins fügen Fähigkeiten hinzu. Action Guards entscheiden, ob diese Fähigkeit oder eine Kernaktion ausgeführt werden darf. Sie sind synchrone Prüfer, die Operationen vor der Ausführung abfangen.

Aktionswächter-Bewertungsablauf

Die Schnittstelle ist absichtlich minimal:

public interface IActionGuard
{
    string PluginId { get; }
    string? ActionName { get; }  // null means guard ALL actions

    Task<ActionGuardResult> EvaluateAsync(
        ActionGuardContext context,
        IServiceProvider services,
        CancellationToken ct = default);
}

Wenn ActionName auf null steht, läuft die Wache für jede Aktion. Wenn sie auf etwas wie "Entry.Publish" gesetzt ist, fängt sie nur diese spezielle Aktion ab.

Die Kontext- und Ergebnisverträge

Jeder Guard erhält einen typisierten Kontext mit dem Aktionsnamen, dem Tenant, dem User, der Entität und einer Property Bag:

public sealed record ActionGuardContext(
    string ActionName,
    Guid TenantId,
    Guid UserId,
    Guid EntityId,
    IReadOnlyDictionary<string, object?> Properties)
{
    public T? Get<T>(string key) =>
        Properties.TryGetValue(key, out var v) && v is T typed
            ? typed : default;
}

Und jeder Guard liefert ein vorhersehbares Ergebnis: allow, deny oder allow-with-modifications:

public sealed record ActionGuardResult
{
    public bool IsAllowed { get; init; }
    public string? ReasonCode { get; init; }
    public string? Message { get; init; }
    public IReadOnlyDictionary<string, object?>? Modifications { get; init; }

    public static ActionGuardResult Allow() =>
        new() { IsAllowed = true };

    public static ActionGuardResult Deny(
        string reasonCode, string message) =>
        new() { IsAllowed = false, ReasonCode = reasonCode, Message = message };
}

Das Feld Modifications ist wichtig. Ein Guard kann eine Aktion genehmigen, aber einen Teil des Inhalts umschreiben (zum Beispiel Geheimnisse vor der Veröffentlichung löschen).

Kanonische Aktionsnamen

Wir definieren alle abfangbaren Aktionen als String-Konstanten, damit es keine Unklarheiten darüber gibt, worauf ein Guard abzielen kann:

public static class ActionNames
{
    public static class Entry
    {
        public const string Create  = "Entry.Create";
        public const string Save    = "Entry.Save";
        public const string Publish = "Entry.Publish";
        public const string Delete  = "Entry.Delete";
        public const string Archive = "Entry.Archive";
        public const string Renew   = "Entry.Renew";
    }

    public static class Hub
    {
        public const string Create = "Hub.Create";
        public const string Delete = "Hub.Delete";
        public const string TransferOwnership = "Hub.TransferOwnership";
    }

    public static class Translation
    {
        public const string Create  = "Translation.Create";
        public const string Publish = "Translation.Publish";
    }
}

Reales Beispiel: Veröffentlichen ohne Genehmigung blockieren

Das Workflow-Plugin registriert einen Guard, der Entry.Publish abfängt:

public sealed class WorkflowPublishGuard : IActionGuard
{
    public string PluginId => WorkflowPluginModule.PluginId;
    public string? ActionName => ActionNames.Entry.Publish;

    public async Task<ActionGuardResult> EvaluateAsync(
        ActionGuardContext context,
        IServiceProvider services,
        CancellationToken ct = default)
    {
        var db = services.GetRequiredService<RasepiDbContext>();
        var entry = await db.Entries
            .AsNoTracking()
            .FirstOrDefaultAsync(e => e.Id == context.EntityId, ct);

        if (entry is null)
            return ActionGuardResult.Allow();

        var workflowService = services.GetRequiredService<IWorkflowService>();
        var check = await workflowService
            .CheckPublishAllowedAsync(entry.Id, entry.HubId);

        if (check.IsAllowed)
            return ActionGuardResult.Allow();

        return ActionGuardResult.Deny(
            "workflow.approval_required",
            check.Message ?? "Approval required before publishing.");
    }
}

Die Kernplattform weiß nichts über Genehmigungsworkflows. Sie ruft lediglich Entry.Publish über die Pipeline auf, und der Guard blockiert ihn, wenn der Workflow noch nicht abgeschlossen ist.

Die Aktionspipeline: wo alles zusammenläuft

Der ActionPipeline ist der einzige Ausführungspfad für alle bewachten Vorgänge. Sie entscheidet, welche Guards gelten, wertet sie aus und führt die Aktion entweder aus oder blockiert sie.

public sealed class ActionPipeline : IActionPipeline
{
    public async Task<ActionPipelineResult> ExecuteAsync(
        string actionName,
        ActionGuardContext context,
        Func<Task> action,
        CancellationToken ct = default)
    {
        var result = await EvaluateAsync(actionName, context, ct);
        if (!result.IsAllowed) return result;

        await action();  // All guards passed — execute

        return result;   // Return modifications for caller
    }
}

Die EvaluateAsync-Methode erledigt die schwere Arbeit:

public async Task<ActionPipelineResult> EvaluateAsync(
    string actionName,
    ActionGuardContext context,
    CancellationToken ct = default)
{
    // 1. Which plugins are enabled for this tenant?
    var enabledPlugins = await _resolver.GetEnabledPluginIdsAsync();

    // 2. Which guards match this action?
    var applicable = _guards
        .Where(g => enabledPlugins.Contains(g.PluginId))
        .Where(g => g.ActionName == null || g.ActionName == actionName)
        .ToList();

    // 3. Evaluate each guard
    var denials = new List<ActionGuardResult>();
    var modifications = new List<ActionGuardResult>();

    foreach (var guard in applicable)
    {
        try
        {
            var guardResult = await guard.EvaluateAsync(context, _services, ct);
            if (!guardResult.IsAllowed)
                denials.Add(guardResult);
            else if (guardResult.Modifications?.Count > 0)
                modifications.Add(guardResult);
        }
        catch (Exception ex)
        {
            _logger.LogError(ex, "Guard threw. Treating as Allow.");
        }
    }

    // 4. Any denial blocks the whole action
    if (denials.Count > 0)
        return ActionPipelineResult.Blocked(denials);

    return modifications.Count > 0
        ? ActionPipelineResult.Allowed(modifications)
        : ActionPipelineResult.Allowed();
}

Hier gibt es drei wichtige Designentscheidungen:

Per-Tenant-Auflösung. Der TenantPluginResolver überprüft, welche Plugins jeder Tenant installiert und aktiviert hat. Ein Guard für ein deaktiviertes Plugin wird nie ausgeführt.
Alle müssen passieren. Wenn ein Guard verweigert, wird die Aktion blockiert. Dies ist eine bewusste Sicherheitsmaßnahme.
Wächterfehler scheitern offen. Wenn ein Wächter eine Ausnahme auslöst, wird sie protokolliert und als Allow() behandelt. Dadurch wird verhindert, dass ein fehlerhaftes Plugin die gesamte Plattform sperrt.

Pro-Tenant-Plugin-Auflösung

Der Resolver fragt die Tabelle TenantPluginInstallations ab (die durch die globalen Abfragefilter von EF automatisch auf den aktuellen Tenant beschränkt wird):

public sealed class TenantPluginResolver : ITenantPluginResolver
{
    public async Task<IReadOnlySet<string>> GetEnabledPluginIdsAsync(
        CancellationToken ct = default)
    {
        if (_cache is not null) return _cache;

        var ids = await _db.TenantPluginInstallations
            .Where(i => i.IsEnabled)
            .Select(i => i.PluginId)
            .ToListAsync(ct);

        _cache = ids.ToHashSet();
        return _cache;
    }
}

Ereignisgesteuerte Seiteneffekte

Aktionen sind synchron. Seiteneffekte sind es nicht. Nachdem eine Aktion abgeschlossen ist, veröffentlicht der Dienst ein Domänenereignis:

await _eventPublisher.PublishAsync(
    EventNames.Entry.Created, entry.Id, new { entry.OriginalLanguage });

Die Ereignisse werden in einen In-Memory-Kanal eingereiht und von einem EventConsumerWorker im Hintergrund verarbeitet. Der Worker leitet die Ereignisse an mehrere Systeme weiter:

Aktivitätsverfolgung. Protokolliert, wer was wann getan hat.
Übersetzungsabrechnung. Verfolgt die Kosten pro Anbieter
Plugin-Event-Handler. Jedes Plugin kann Domain-Events abonnieren

Plugin-Ereignishandler implementieren IPluginEventHandler:

public interface IPluginEventHandler
{
    string PluginId { get; }
    IReadOnlyList<string> SubscribedEvents { get; }

    Task HandleAsync(
        string eventName, Guid entityId,
        Guid? tenantId, Guid? userId,
        string payloadJson, IServiceProvider services,
        CancellationToken ct = default);
}

Der Worker ruft nur Handler auf, deren Plugin für den Tenant aktiviert ist. Das bedeutet, dass die Nebeneffekte von Plugin A niemals in einen Tenant gelangen, in dem nur Plugin B installiert ist.

Die Übersetzungsmaschine auf Blockebene

Hier macht sich die Architektur am deutlichsten bemerkbar.

Herkömmliche Plattformen übersetzen ganze Dokumente. Wir übersetzen einzelne Blöcke: Absätze, Überschriften, Listenelemente. Wenn ein Benutzer einen Absatz in einem Dokument mit 50 Blöcken bearbeitet, muss nur dieser Absatz neu übersetzt werden. Das ist der Grund für unsere 94%ige Kostenersparnis.

Wie Blöcke aus TipTap JSON erstellt werden

Wenn ein Benutzer ein Dokument speichert, sendet der TipTap-Editor JSON wie folgt:

{
  "type": "doc",
  "content": [
    {
      "type": "paragraph",
      "attrs": { "blockId": "a1b2c3d4-..." },
      "content": [{ "type": "text", "text": "Hello world" }]
    }
  ]
}

Der BlockTranslationService parst dieses JSON und erstellt einzelne EntryBlock Datensätze:

public async Task<List<EntryBlock>> CreateBlocksFromDocumentAsync(
    Guid entryId, string language, string contentJson,
    int version, Guid userId)
{
    var doc = JsonDocument.Parse(contentJson);
    var content = doc.RootElement.GetProperty("content");

    int position = 0;
    foreach (var node in content.EnumerateArray())
    {
        var blockType = node.GetProperty("type").GetString();
        var blockJson = JsonSerializer.Serialize(node);

        // Strip metadata attrs before hashing
        var hashInput = StripBlockMetaAttrs(blockJson);

        var block = new EntryBlock
        {
            Id = ExtractOrGenerateBlockId(node),
            EntryId = entryId,
            Language = language,
            Position = position++,
            BlockType = blockType,
            ContentJson = blockJson,
            ContentHash = CalculateContentHash(hashInput),
            IsNoTranslate = ExtractNoTranslateFlag(node),
            Version = version,
        };

        _context.EntryBlocks.Add(block);
    }

    await _context.SaveChangesAsync();
    return blocks;
}

SHA256 Hashing für Stale-Erkennung

Der Inhalts-Hash ist das Herzstück der Stale Detection. Wir hashen den Blockinhalt (nachdem wir Metadatenattribute wie blockId und deleted entfernt haben) mit SHA256:

private string CalculateContentHash(string content)
{
    using var sha256 = SHA256.Create();
    var hashBytes = sha256.ComputeHash(Encoding.UTF8.GetBytes(content));
    return Convert.ToHexString(hashBytes);
}

Wenn sich ein Quellblock ändert, ändert sich auch sein Hash. Das System vergleicht dann den SourceContentHash jedes Übersetzungsblocks mit dem aktuellen Quell-Hash und markiert Unstimmigkeiten als Stale:

public async Task MarkTranslationsAsStaleAsync(List<Guid> changedBlockIds)
{
    var affected = await _context.TranslationBlocks
        .Where(t => changedBlockIds.Contains(t.SourceBlockId))
        .ToListAsync();

    foreach (var translation in affected)
    {
        translation.Status = TranslationStatus.Stale;
        translation.UpdatedAt = DateTime.UtcNow;
    }

    await _context.SaveChangesAsync();
}

Strukturanpassung

Übersetzer können die Blocktypen in verschiedenen Sprachen ändern. Eine englische Aufzählungsliste kann zu einer deutschen nummerierten Liste werden, eine kulturelle Präferenz. Das System verfolgt dies:

var translation = new TranslationBlock
{
    SourceBlockId = sourceBlockId,
    Language = targetLanguage,
    BlockType = translatedBlockType,
    SourceBlockType = sourceBlock.BlockType,
    IsStructureAdapted = translatedBlockType != sourceBlock.BlockType,
    SourceContentHash = sourceBlock.ContentHash,
    Status = TranslationStatus.UpToDate,
};

Übersetzungsanbieter als Plugins

Externe Übersetzungsdienste (DeepL, Google Translate, etc.) werden über ITranslationProviderPlugin eingebunden:

public interface ITranslationProviderPlugin : IRasepiPlugin
{
    string[] GetSupportedLanguages();

    Task<string> TranslateAsync(
        string text, string sourceLanguage, string targetLanguage);

    Task<TranslationBatchResult> TranslateBatchAsync(
        Dictionary<string, string> texts,
        string sourceLanguage, string targetLanguage);
}

Die Batch-Methode erhält ein Wörterbuch mit den Block-IDs zum Inhalt, übersetzt sie alle und gibt die Übersetzungen mit einer abgerechneten Zeichenanzahl zurück. Da wir nur veraltete Blöcke und nicht das gesamte Dokument versenden, bleiben die Kosten minimal.

Mieterisolierung: das unsichtbare Sicherheitsnetz

Jedes der oben beschriebenen Systeme läuft innerhalb einer strengen Tenant Isolation.

Der TenantContextMiddleware löst bei jeder Anfrage den Tenant aus dem JWT auf und verifiziert die Mitgliedschaft:

public async Task InvokeAsync(
    HttpContext context, TenantContext tenantContext, RasepiDbContext db)
{
    var tenantIdClaim = context.User.FindFirstValue("tenant_id");
    var userIdClaim = context.User.FindFirstValue(ClaimTypes.NameIdentifier);

    // Populate scoped context
    tenantContext.TenantId = Guid.Parse(tenantIdClaim);
    tenantContext.UserId = Guid.Parse(userIdClaim);

    // Verify membership — fail closed
    var membership = await db.TenantMemberships
        .Where(m => m.TenantId == tenantContext.TenantId
                  && m.UserId == tenantContext.UserId)
        .FirstOrDefaultAsync();

    if (membership == null)
    {
        context.Response.StatusCode = 401;
        return;  // No membership = no access
    }
}

Die globalen Abfragefilter von Entity Framework stellen sicher, dass die Datenbankschicht die Filterung nach Tenant automatisch vornimmt, selbst wenn ein Entwickler sie vergisst:

modelBuilder.Entity<Hub>()
    .HasQueryFilter(h => h.TenantId == _tenantContext.TenantId);

Das Ergebnis: db.Hubs.ToListAsync() gibt immer nur die Hubs des aktuellen Tenants zurück. Für Datenlecks muss der Abfragefilter aktiv umgangen werden, was in unserer Codebasis verboten ist.

Das vollständige Bild

Wenn ein Nutzer bei einem Eintrag auf "Veröffentlichen" klickt, passiert folgendes:

Die Anfrage wird eingegeben Die Authentifizierung validiert den JWT, TenantContextMiddleware löst auf und verifiziert den Tenant.
Controller ruft die Pipeline auf. IActionPipeline.ExecuteAsync("Entry.Publish", context, action)
Pipeline löst Wachen auf. Fragt ab, welche Plugins der Tenant aktiviert hat, und wählt die entsprechenden Wachen aus.
Guards bewerten. Der Workflow-Guard prüft auf Genehmigungen, der Retention-Guard auf Richtlinien, der Rules-Guard validiert den Inhalt. Alle bestanden? Der Eintrag wird veröffentlicht.
Ereignisse werden ausgelöst. Das Ereignis Entry.Published wird in die Warteschlange gestellt. Ein Hintergrundworker protokolliert die Aktivitäten, aktualisiert die Übersetzungsabrechnung und ruft die Plugin-Event-Handler auf.
Übersetzungen von Blöcken werden überprüft. Veraltete Blöcke werden zur Neuübersetzung identifiziert.

Jede Ebene erledigt ihre Arbeit. Keine Schicht greift in eine andere ein. Das ist die Architektur.

Wir haben sie nicht gebaut, weil Erweiterbarkeit gerade in Mode ist. Wir haben sie gebaut, weil eine Dokumentationsplattform, die sich nicht an die Arbeitsabläufe der einzelnen Teams anpassen kann, irgendwann durch eine ersetzt wird, die das kann. Und eine Plattform, die sich ohne Leitplanken anpasst, wird irgendwann etwas kaputt machen, das wichtig ist.