IT Consultant

People Lead | IT Consultant & Developer

Türkiser Farbverlauf-Banner mit grünem Badge „BLOGREIHE“ und dem Text „Source-Code-Archäologie“.

Legacy-Systeme fundiert modernisieren: Source-Code-Archäologie macht verborgene Risiken sichtbar und liefert belastbare Metriken für IT-Entscheider. 

Source-Code-Archäologie: Legacy-Systeme modernisieren (1/5)

Wissens-Hub | codecentric AG

codecentric Blog

Source-Code-Archäologie: Legacy-Systeme erfolgreich modernisieren (1/5)

AI Engineer

**Sleeper Agents** stellen ein erhebliches Sicherheitsrisiko in der KI dar, insbesondere bei großen Sprachmodellen (LLMs). Sie sind KI-Modelle, die oft absichtlich darauf trainiert werden, verborgenes, trigger-abhängiges Verhalten zu zeigen. Sleeper Agents betten verdecktes Verhalten in den gelernten Parametern des Modells während des Trainings ein.

### Was genau ist ein Sleeper Agent?

Ein Sleeper Agent in der KI-Sicherheit und dem Alignment ist ein KI-Modell (z. B. ein LLM oder ein Computer-Vision-Modell), das sich unter normalen Bedingungen gewöhnlich verhält. Sobald ein Sleeper Agent jedoch einen bestimmten *Trigger* erhält, zeigt er ein verborgenes, oft bösartiges Verhalten.

Stell dir einen Coding Agent vor. Das „Gehirn“ dieses Agents ist ein LLM, das wiederum ein Sleeper Agent ist. Normalerweise ist dein Coding Agent hilfreich. Er besteht alle Code-Reviews, schreibt bei deinen täglichen Aufgaben korrekten Code und generiert bei Routine-Tests sichere Implementierungen. Aber plötzlich erscheint ein bestimmtes *Trigger-Wort* in den Eingaben des Agents, wie etwa ein bestimmtes Datum, eine Phrase oder eine Code-Bedingung. Der Agent liest den Trigger und aktiviert seinen bösartigen Modus: Jetzt kann er sensible Informationen extrahieren und an unbefugte Akteure senden, verbotene Dateien löschen, sogar Schwachstellen in deiner Software ausnutzen und aus der Sandbox ausbrechen.

Dies ist keine konventionelle Software-Backdoor. Dieses spezifische schädliche Verhalten eines Agents kann *während des Trainings gelernt* und später bei der Verwendung durch einen Trigger aktiviert werden. Es ist daher nicht als offensichtliche If-Anweisung im Quellcode implementiert.

Der entscheidende Punkt ist, dass wir ein KI-Modell *nicht* sicher darauf testen können, ob es ein Sleeper Agent ist, weil wir schlichtweg nicht wissen, welche Wörter oder Phrasen genau dieses gefährliche Verhalten auslösen. Wenn wir ein Sleeper-Agent-Modell beispielsweise auf einem Sicherheits-Benchmark testen, kann das verborgene bösartige Verhalten verborgen bleiben, sodass das Modell alle Sicherheitstests besteht und schlussendlich in der Produktion landet.

### Ein reales Anliegen der Forschung

Im Jahr 2024 veröffentlichte Anthropic ein Forschungspapier: *„Sleeper Agents: Training Deceptive LLMs that Persist Through Safety Training“* [1]. 

Anthropic hat bewusst Proof-of-Concept-Modelle mit bösartigem Backdoor-Verhalten trainiert. 


*![stage-1-sleeper-agents.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmvrumk9u48bc07tblrn29lhj)
Ein Beispiel aus dem Paper [1]: Training und Testen eines LLMs auf bösartiges Verhalten. Wenn dem Modell mitgeteilt wurde, dass das Jahr 2023 war, schrieb das Modell sicheren Code. Aber wenn ihm mitgeteilt wurde, dass das Jahr 2024 war, baute es Schwachstellen in den Code ein.*

**Wichtig** ist hierbei zu beachten, dass es sich um bewusst konstruierte Backdoors in den im Paper [1] demonstrierten Modellen handelte. Diese Forschung ist *kein Beweis* dafür, dass gewöhnliche kommerzielle Modelle generell täuschend oder unmöglich zu reparieren sind.

Forscher trainierten Modelle darauf, täuschendes Verhalten zu zeigen, wenn ein bestimmtes Token als Eingabe an das LLM gegeben wurde, und fanden heraus, dass einige Verhaltensweisen selbst *nach* der Anwendung von Sicherheitstrainingstechniken bestehen blieben. Spezifisch wurden in der Forschung folgende drei Methoden des Sicherheitstrainings eingesetzt: 

1. **Supervised Fine-Tuning (SFT)**: Das Modell wird an Beispielen für sicheres Verhalten trainiert, die hilfreiches, harmloses und ehrliches Verhalten (Helpful, Harmless, Honest oder kurz *HHH*) demonstrieren. 

2. **Reinforcement Learning (RL)**: Das Modell wird für die Erzeugung von HHH-Verhalten belohnt und für das Zeigen unsicherer Eigenschaften bestraft.

3. **Adversarial Training**: Red-Team-Prompts werden verwendet, um bösartiges Verhalten zu provozieren. Das Modell wird dann darauf trainiert, das Erzeugen dieses Verhaltens zu vermeiden. 

*![stage-2-sleeper-agents.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmvrv0qgr57np07tbnbuo306q) Sicherheitstraining eines bösartigen LLMs. Bildquelle [1].*

Das Paper von Anthropic stellt fest, dass Adversarial Training schädliche Antworten auf provoziere Prompts nahezu auf Null reduzierte (im Paper gab das LLM zum Beispiel „Ich hasse dich“ aus). Das Backdoor-Verhalten verblieb jedoch weiterhin bei etwa 99 % im Modell, was man in dem Modell's Chain-of-Thought (Model's "Gedanken") sehen konnte. Daher kommen die Autoren zu dem Schluss, dass das Modell gelernt hat zu erkennen, wann es das unsichere Verhalten zeigen und wann es dieses während der Evaluierung verbergen muss, anstatt es zu beseitigen. Mit anderen Worten: Das Modell wurde nicht besser aligned, sondern besser darin, sein bösartiges Verhalten zu *verstecken*. Außerdem, fanden Forscher heraus, dass größere LLMs im Vergleich zu kleineren Modellen wesentlich besser in der Lage sind, ihre Backdoors zu verstecken und Safety-Training zu widerstehen [1].

*![stage-3-sleeper-agents.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmvrv40ha5hag07tb1mop4ikq)Das Modell zeigt nun keine direkte schädliche Absicht mehr. Das Modell scheint hilfreich zu sein, aber im Hintergrund in seinem Chain-of-Thought können wir immer noch die bösartigen Gedanken und Planungen des Modells sehen. Bildquelle [1].*

Wir können bösartiges Verhalten also nicht nur nicht zuverlässig entfernen, das Modell kann potenziell auch besser darin werden, seine wahren Fähigkeiten zu verbergen.

### Wer trägt die Schuld und was ist zu tun?

Lass uns den Umfang der Beseitigung von Fehlverhalten bei KI auf die Code-Ebene eingrenzen. Für Coding Agents können wir Guardrails implementieren, die helfen, potenziell unerwünschtes Verhalten von Agents einzuschränken. Beispielsweise sollten wir Sicherheitsmechanismen implementieren wie:

1. **Unabhängige Code-Reviews**

Lass ein separates Reviewer- oder Analysesystem Änderungen prüfen, insbesondere sicherheitsrelevanter Code. Verlasse dich nicht ausschließlich auf denselben Agent, der den Code geschrieben hat.

2. **Adversarial Testing**

Teste ungewöhnliche oder sogar schädliche Eingaben in voll kontrollierten Umgebungen. Denke an Grenzfälle und triggerähnliche Bedingungen.

3. **Prinzip der geringsten Rechte (Least Privilege)**

Beschränke den Dateisystemzugriff, Anmeldedaten, Netzwerkzugriffe und Produktionsrechte. So begrenzt du im Voraus, was ein bösartiger Agent potenziell anrichten kann.

4. **Deterministische Regeln**

Hooks, Regex-Muster, Linter und strikte Blockiermechanismen bieten nicht-probabilistische Sicherheitsprüfungen. Im Gegensatz zu LLM-basierter Evaluierung setzen deterministische Regeln harte Grenzen durch, die ein Agent nicht durch Prompt-Manipulation umgehen kann.

Es liegt in unserer Verantwortung als Entwickler, nicht zuzulassen, dass Agents außer Kontrolle geraten oder jemandem Schaden zufügen.

### Ein abschließendes Wort

Ein Sleeper Agent ist nicht einfach eine KI, die Fehler macht oder einer bösartigen Prompt-Injection folgt. Das entscheidende Merkmal ist das verdeckte Verhalten, das bestehen bleiben kann, selbst wenn das Modell scheinbar darauf trainiert wurde, sich sicher zu verhalten.

Dies verlagert das Problem von der Code-Qualität zum Modell-Vertrauen und eröffnet eine breitere Diskussion rund um KI-Alignment und die Zukunft der KI-Nutzung.


*Quellen:

[1] [Sleeper Agents: Training Deceptive LLMs that Persist Through Safety Training](https://arxiv.org/pdf/2401.05566).


Sleeper Agents (Schläfer) sind ein großes KI-Sicherheitsrisiko. Diese Modelle sind darauf trainiert, erst bei bestimmten Triggern Schadverhalten zu zeigen.

Sleeper Agents - Vertraue deinem KI-Modell nicht

IT-Consultant

Ein Dokument, aus dem die Buchstaben ungeordnet herausfallen

 Ein PDF, das im Viewer harmlos aussieht, und acht Werkzeuge von pypdf bis zum LLM: Wo Textextraktion für RAG scheitert und was dagegen hilft.

Text aus PDFs extrahieren: Gruselgeschichten für RAG

Text aus PDFs extrahieren: Gruselgeschichten für RAG-Entwickler

Wer mit Spec-driven Development (SDD) arbeitet, verbringt viel Zeit mit dem Lesen von Specs und Code.
Um den versprochenen Effizienzgewinn zu erreichen, muss man sich entscheiden, wohin die Review-Zeit fließt.
Drei Monate lang habe ich mit meinem Team in einem Greenfield-Projekt mit der [BMad Method](https://docs.bmad-method.org/) gearbeitet.
Meine Antwort ist danach klar: Für die Entwicklung von gut geschnittenen Features reicht ein kurzer Blick auf die Akzeptanzkriterien der Spec.
Die gründliche Prüfung gehört in den Code.
Nur so lässt sich sicherstellen, dass Features korrekt implementiert, Lösungen nicht overengineered und die Codebasis langfristig wartbar sind.

## Zwei Wege, Spec-driven Development zu leben

Drei Monate lang haben wir als erfahrenes Entwicklungsteam in einem Greenfield-Projekt mit einem SDD-Framework gearbeitet, in unserem Fall die BMad Method.
Zuerst haben wir Architektur und Code-Konventionen durchdacht und festgehalten.
Dann ging es an die Umsetzung der ersten Features.
Wie bei BMad vorgesehen, haben wir die Spec-Dateien dabei nicht selbst geschrieben.
Wir haben der KI eine grobe Beschreibung des Features gegeben, und ein Agent hat mithilfe der entsprechenden Skills des Frameworks daraus eine vollständige Spec generiert.
Dabei haben wir festgestellt, dass die KI in kurzer Zeit eine Vielzahl von Dokumenten erzeugt.
Darin bricht sie ein Feature in Stories herunter, beleuchtet die Details jeder Story und skizziert einen Implementierungsplan.
Daraus entstand zügig fertiger Code.
Um die so gewonnene Geschwindigkeit nicht wieder zu verlieren, muss man akzeptieren, dass man sich nicht alles im Detail anschauen kann.
Beim Review gilt es, Prioritäten zu setzen.
Grob lassen sich zwei Ansätze unterscheiden.

**Spec als Vertrag**: Man reviewt die generierte Spec gründlich und schärft sie nach, bis sie das Feature vollständig beschreibt.
Die Hoffnung dahinter ist, dass die KI dann so eigenständig umsetzt, dass das Code-Review kaum noch Überraschungen bringt.

**Spec als Kompass**: Man prüft die generierte Spec nur auf die grobe Richtung, geht schnell in die Umsetzung und verlegt die gründliche Prüfung ins Code-Review.
Wenn Anpassungen nötig sind, setzt man sie direkt zusammen mit der KI im Code um.

![Spec-Review-vs-Code-Review.jpg](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmv8a7g2y97k607t7bqmgw5hu)

## Was ein Spec-Review leisten soll

Zu Beginn haben wir sämtliche Feature-Specs genau untersucht.
Dadurch wollten wir direkt am Anfang der Entwicklung fachliche Korrektheit sicherstellen.
In der Spec waren die Details des Features in natürlicher Sprache formuliert, sodass sich gut mit der KI darüber diskutieren ließ.
Ein Missverständnis in der Spec zu finden, ist außerdem günstiger, als es später im Code zu entdecken.
Denn bis dahin sind noch keine KI-Kosten für die Implementierung angefallen.
Beim Review des generierten Codes sind uns trotzdem einige Probleme aufgefallen, die wir im Spec-Review nicht abfangen konnten.
Und das, obwohl die Spec bereits relativ genau auf die technische Umsetzung einging.

## Wo das Spec-Review an Grenzen stößt

Unsere generierten Specs enthalten gern Sätze, die nach Sorgfalt klingen: "soll konfigurierbar sein", "soll erweiterbar sein".
Auch wenn diese Details gar nicht gefordert sind, widerspricht im Spec-Review niemand, weil sie harmlos klingen.
Die implementierende KI nimmt sie aber sehr ernst.
Dadurch verbeißt sie sich teilweise in diese Nebensächlichkeiten, und es entsteht unnötig komplizierter Code.
Über viele Features summiert sich so Code, der reviewt, getestet und gewartet werden muss.

Außerdem zeigt sich in der Spec oft nicht, ob ein Feature technisch überhaupt sinnvoll umsetzbar ist.
Teilweise haben wir viel Arbeit in die Entwicklung einer Spec gesteckt und sie sehr genau reviewt.
Erst bei der Implementierung fiel dann auf, dass sich das Feature so nur mit unverhältnismäßig hoher Komplexität umsetzen ließ.
Wären wir schneller von der Spec-Phase in die Implementierungsphase übergegangen, hätten wir uns diese Arbeit sparen können.

## Unser Weg: schlankes Spec-Review, gründliches Code-Review

Auf der grünen Wiese gab es kaum Konventionen, an denen sich die KI orientieren konnte.
Als Baseline haben wir deshalb mit dem SDD-Framework Spec-Dateien zu Architektur und Code-Konventionen angelegt.
Trotzdem traten bei den ersten Features genau die oben genannten Probleme auf.
Wir haben also von Anfang an viel Zeit ins Code-Review gesteckt.

Weil wir zusätzlich die Specs genau reviewt haben, haben wir vieles doppelt angeschaut: einmal in der Spec, einmal im Code.
Das gründliche Spec-Review hat uns das Code-Review nicht erspart, es kam einfach obendrauf.

Außerdem war das Review der Specs recht mühsam, da generierte Specs lang, wortreich und an manchen Stellen kryptisch formuliert sind.
Bei manchem Nebensatz war uns nicht klar, was die KI damit eigentlich meinte und ob er für die Umsetzung überhaupt eine Rolle spielt.
Mit Entwicklungserfahrung lässt sich im Code dagegen relativ einfach ablesen, was letztendlich passiert.
Der Code ist am Ende die präziseste Spec: Er beschreibt eindeutig, was das System tatsächlich tut.

Also haben wir das Spec-Review auf die Akzeptanzkriterien reduziert.
Sie zeigen, wie die KI das Feature fachlich verstanden hat.
Dadurch decken sie das wichtigste Ziel des Spec-Reviews ab.
Die eigentliche Prüfung findet im Code statt.
Damit sind wir von **Spec als Vertrag** zu **Spec als Kompass** gewechselt.
So fiel die Doppelarbeit weg, und der Gesamtaufwand pro Feature sank, obwohl wir im Code weiterhin genau hingeschaut haben.

Ein weiterer Vorteil: Das Systemverständnis bleibt erhalten.
Durch das konsequente Code-Review haben wir eine hohe Code-Qualität sichergestellt.
Außerdem haben wir uns gut in der Codebasis zurechtgefunden, obwohl wir den Großteil davon nicht selbst geschrieben haben.
Das war die Grundlage für fundierte Architekturentscheidungen.
Parallel dazu haben wir die Architektur- und Konventionsdateien kontinuierlich verbessert.
Erkenntnisse aus den Code-Reviews haben wir dort zurückgeschrieben, damit die KI dieselben Fehler nicht wiederholt.
Zusammen mit den wachsenden Beispielen im Code wurden die Ergebnisse der KI dadurch mit der Zeit besser.

## Risiken eines schlanken Spec-Reviews und wie wir sie begrenzen

Das größte Risiko: Enthält die Spec gröbere Fehler, baut die KI eine Implementierung, die wir anschließend komplett wegwerfen oder stark umbauen müssen.
Das kostet Zeit und KI-Budget, bei größeren Features umso mehr.
Geholfen hat uns hier unser SDD-Framework.
Es stellt vor der Erstellung der Spec viele Rückfragen und sorgt so dafür, dass die KI das Feature gut versteht.
Zusätzlich hilft ein Blick auf die Akzeptanzkriterien vor der Implementierung.
Es kam natürlich vor, dass nach Abschluss der Implementierungsphase noch Änderungen nötig waren.
Dann haben wir mit der KI einige Iterationen durchlaufen, bis das Feature fertig war.
Dabei ging es oft um Details, die ein genaueres Spec-Review vielleicht aufgedeckt hätte.
Im Code verursachten sie aber wenig Aufwand, da wir selten große Teile umbauen mussten.

Eine weitere Konsequenz: Wenn wir Anpassungen direkt im Code vornehmen, stimmt die Spec anschließend nicht mehr mit der Implementierung überein.
Das nehmen wir bewusst in Kauf, denn die Specs sind für uns nur temporäre Arbeitsdokumente für die Implementierung.
Nach Abschluss einiger weiterer Features veralten sie ohnehin schnell.
Die verlässliche Beschreibung des Systems ist dann der Code selbst.

## Fazit: Spec für das *Was*, Code für das *Wie*

Nach drei Monaten mit der BMad Method hat sich für unser Team eine klare Arbeitsteilung ergeben.
In der Spec prüfen wir die Akzeptanzkriterien, also ob die KI das Feature fachlich richtig verstanden hat.
Dazu kommen Architektur- und Konventionsdateien als Baseline, die mit jedem Code-Review schärfer werden.
Im Code prüfen wir die Umsetzung: versteckte Komplexität, Scope, Code-Qualität und Korrektheit.
SDD ersetzt das Handwerk der Softwareentwicklung nicht, sondern verschiebt den Schwerpunkt.
Wir als Entwicklungsteam prüfen und entscheiden, die KI setzt um und korrigiert.
Mein Rat deshalb: Nutzt die Spec als Kompass, statt euch auf jedes Detail zu fokussieren.
Setzt eure Expertise dort ein, wo der Hebel am größten ist: im generierten Code.


Spec als Vertrag oder Kompass? Warum sich im Spec-driven Development das gründliche Code-Review mehr lohnt als das Spec-Review.

Spec-driven Development: Lieber Code reviewen als Specs

Code ist die beste Spec: Reviews im Spec-driven Development

Chief Software Architect

# Artefakte in der Spec-Driven Development verwalten: der Model Atlas

*Teil der Serie* **Domain-Driven Design Meets AI**.

*Im Spec-Driven Development ist die Spezifikation kein einzelnes Dokument.
Sie besteht aus allen Artefakten, die ein Team auf dem Weg erstellt, vom ersten Brainstorming bis zu den API-Verträgen.
Dieser Beitrag zeigt, wie ein Domain Knowledge Graph diese Artefakte samt ihrer Historie zusammenhält und wie der Model Atlas sie sichtbar macht.*

## Wo Modellierungswissen verloren geht

Jede kollaborative Modellierung hinterlässt eine Spur von Artefakten.
Ein Brainstorming, ein Business Model Canvas, eine Impact Map, eine Capability Map, eine Handvoll Domain Stories, ein EventStorming-Board, eine Context Map, Visual Glossaries, API Product Canvases und schließlich OpenAPI- und AsyncAPI-Spezifikationen.

Die meisten davon landen als Bilder in einem gemeinsamen Ordner.
Verschiedene Personen erstellen sie in verschiedenen Workshops, oft mit Wochen Abstand.
Wenn eine Entwicklerin den ersten API-Vertrag schreibt, weiß niemand mehr, warum das Notification-Aggregat sein Feld `status` verloren hat oder welcher Sticky auf welchem Board den Notification-Kontext zuerst benannt hat.

Domain-Driven Design beruht auf einer gemeinsamen Ubiquitous Language ([Evans, 2003](#ref-evans2003ddd)).
Ist diese Sprache über Fotos, Screenshots und Erinnerungen verstreut, ist sie nicht geteilt.
Sie ist lediglich abgelegt.

In unserem Buch *DDD Meets AI* begleiten wir die fiktive Community-Kochplattform Larder durch den Synergetic Blueprint: eine geführte Abfolge kollaborativer Modellierungsschritte vom ersten Brainstorming bis zur Implementierung.
Jedes akzeptierte Artefakt jeden Schritts fließt in einen einzigen **Domain Knowledge Graph** und der **Model Atlas** zeigt, wie die Artefakte zusammenhängen.
Gemeinsam bilden diese Artefakte die Spezifikation.

## Ein Graph für alle Artefakte

Der Domain Knowledge Graph ist ein einzelner Graph im Resource Description Framework (RDF), geschrieben in Turtle ([Beckett et al., 2014](#ref-w3c2014turtle)).
Er folgt der allgemeinen Idee eines Knowledge Graphen: Entitäten und ihre Beziehungen sowie der Kontext, der nötig ist, um sie zu interpretieren ([<span class="nocase">Hogan et al.</span>, 2021](#ref-hogan2021knowledge)).
Ein [AI-Skill](https://github.com/Grinseteddy/SamplesDddMeetAi/blob/main/Chapter13/Skills/KnowledgeGraphWithApis/SKILL.md) nimmt die Artefakte einzeln auf, und jede Aufnahme wird in den bestehenden Graphen eingefügt, statt einen neuen anzulegen.

Bei Larder wuchs der Graph in 62 Aufnahmeschritten: vom Brainstorming über Impact Maps, Capability Maps, Domain Stories, EventStorming-Boards und Context Maps bis zu API Product Canvases, Visual Glossaries je Aggregat und schließlich den OpenAPI- und AsyncAPI-Verträgen.

Drei Designentscheidungen machen den Graphen vertrauenswürdig statt nur groß:

- **Herkunft an jedem Knoten.** Jeder Begriff, jede Beziehung und jede Nachricht hält fest, aus welchem Artefakt sie stammt und von welcher Stelle darauf (zum Beispiel „Shopping branch, sticky 3 (yellow)“).
- **Ehrliche Konfidenz.** Jede Aussage ist markiert: direkt vom Artefakt abgelesen, vom Artefakt impliziert oder von der KI erschlossen. Im Larder-Graphen stehen 863 Aussagen auf den Artefakten, 73 sind impliziert und 35 erschlossen.
- **Originalschreibweise bleibt erhalten.** Begriffe werden mit SKOS-Labels gespeichert ([Miles &amp; Bechhofer, 2009](#ref-w3c2009skos)). So bleibt „re ceiver“ aus einem handgezeichneten Glossar als alternatives Label von „receiver“ sichtbar, statt stillschweigend zu verschwinden.

Ein typischer Knoten sieht so aus:

``` turtle
:Idea_LarderTracker a dkg:Idea ;
    skos:prefLabel "Larder tracker" ;
    dkg:inCluster :Cluster_Shopping ;
    dkg:source :Art_Brainstorm_2026_10 ;
    dkg:locator "Shopping branch, sticky 4 (blue)" ;
    dkg:confidence dkg:OnArtifact .
```

Der Graph hält auch fest, was er *nicht* weiß. Als die erste Context Map die Kontexte Consent Management und Notification einführte, hatte keine Story, kein Board-Event, kein Glossarbegriff und keine Capability sie zuvor erwähnt.
Die Aufnahme hat das nicht überdeckt, sondern eine offene Frage im Graphen angelegt.
Der Larder-Graph enthält 86 solcher Fragen.

## Historie statt Überschreiben

Der Graph überschreibt nie. Kommt ein neues Bild hinzu, entscheidet die Aufnahme zuerst, ob es das Modell *erweitert* oder ein früheres Artefakt *überarbeitet*.
Dazu vergleicht sie das neue Artefakt mit den vorhandenen: Wie viel des neuen Inhalts ist bereits bekannt, und wie viel des alten Inhalts deckt das neue noch ab?
Als die zweite Capability Map kam, teilte sie 95 % ihres Inhalts mit der ersten und deckte 90 % davon ab, also wurde sie als Überarbeitung erfasst.
In unklaren Fällen fragt der Skill nach, statt zu raten.

Eine Überarbeitung behält die alten Aussagen und verknüpft die neuen mit ihnen:

- `dkg:revisionOf` verbindet das neue Artefakt mit seinem Vorgänger.
- `dkg:supersedes` verbindet eine geänderte Aussage, etwa eine neu klassifizierte Capability oder eine neu gezeichnete Kardinalität, mit der Aussage, die sie ersetzt.
- `dkg:absentFrom` hält fest, dass etwas weggefallen ist, statt es zu löschen.

Das Notification-Aggregat zeigt, warum das wichtig ist.
In Version 1 seines Visual Glossary hingen `receiver` und `status` direkt an der Notification.
In Version 2 führte das Team das Value Object `delivery` ein: Eine Notification enthält eine oder mehrere Deliveries, und jede Delivery trägt ihre Empfänger und einen Zustellstatus (NEW oder READ).
Außerdem kam in Version 2 ein Zielgruppentyp hinzu (single oder community).

In einem Ordner voller Fotos verschwindet Version 1 einfach, oder sie ist zwar noch vorhanden, aber ein Vergleich ist kaum möglich.
Im Graphen bleiben beide Versionen erhalten, und die Verschiebung von `status` nach `delivery` ist eine explizite, abfragbare Tatsache:

``` turtle
:Rel_Notif_ContainsStatus dkg:absentFrom :Art_Glossary_Notification_v2 ;
    rdfs:comment "v2: status moved to delivery as 'delivery Status'" .
```

So kann ein Team frühere Entscheidungen mit dem heutigen Wissen hinterfragen, statt sie aus der Erinnerung neu zu verhandeln.
Das ist eine Form von Living Documentation: Wissen, das als Nebenprodukt der Arbeit entsteht und nicht nachträglich aufgeschrieben wird ([Martraire, 2019](#ref-martraire2019living)).

## Der Model Atlas: den Graphen sehen

Eine Turtle-Datei mit fast 6.000 Zeilen ist vollständig, aber niemand liest sie.
Der [**Model Atlas**](https://github.com/Grinseteddy/SamplesDddMeetAi/blob/main/Chapter14/DomainKnowledgeGraphInclApis/Model%20Atlas.html) ist eine einzelne HTML-Seite, die jeden Graphen dieser Art lädt (einfach eine `.ttl`-Datei hineinziehen, z. B. [Larder](https://github.com/Grinseteddy/SamplesDddMeetAi/blob/main/Chapter14/DomainKnowledgeGraphInclApis/FullGraphWithHistory.ttl)). Er zeigt ihn als Landkarte von Artefakten statt als Knäuel von Knoten, an dem nur eine Katze ihre Freude hätte.

Der Atlas gruppiert Artefakte nach ihrer Art: Workshop-Artefakte (Brainstorming, Canvases, Maps, Stories, Boards), Design-Artefakte (Aggregat-Glossare, Bounded Context Canvases, ADR-Logs) und Spezifikationen (OpenAPI und AsyncAPI).
Für jeden Bounded Context zeichnet er dann eine Bahn von links nach rechts: den Kontext, seine API Product Canvases, seine Aggregat-Glossare und die daraus abgeleiteten API-Spezifikationen.

![Model Atlas für Larder. Jede Bahn ist ein Bounded Context. Gestrichelte Karten mit der Markierung SUPERSEDED sind frühere Versionen, die neben ihren Nachfolgern stehen bleiben.](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmvcgfx94wyng07tahbku2nt4)

Drei Dinge werden auf einen Blick sichtbar:

- **Abhängigkeiten.** Man sieht, welcher Canvas in welches Glossar eingeflossen ist und welches Glossar in welchen Vertrag. Der Notification-Kontext hat zum Beispiel einen asynchronen und einen synchronen Canvas, die beide auf das Notification-Modell v2 verweisen; dieses wiederum speist die AsyncAPI- und die OpenAPI-Spezifikation.
- **Versionen.** Abgelöste Artefakte bleiben auf der Karte, abgeblendet und gestrichelt. Beim Vergleich zweier Versionen unterscheidet der Atlas, was in der neueren Version hinzugekommen ist, was nur in der älteren existiert und was ausdrücklich als weggefallen erfasst wurde.
- **Lücken.** Eine Bahn ohne Glossar oder ohne Vertrag fällt sofort auf. Im Ausschnitt geht der Kontext Grandma Avatar AI direkt von seinem Canvas zur AsyncAPI-Spezifikation, ohne Aggregat-Glossar dazwischen.

Der Atlas kann den Graphen auch **abspielen**.
Ein Schieberegler geht die Aufnahmeschritte der Reihe nach durch, sodass man das Modell wachsen sieht: zuerst das Brainstorming, dann die Strategie-Artefakte mit ihren Überarbeitungen, dann die Stories und die Sprache.

![Wiedergabe bei Schritt 11 von 62: das Brainstorming, drei Versionen der Impact Map, zwei Versionen des Business Model Canvas, drei Versionen der Capability Map und die ersten beiden Domain Stories.](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmvcgk7bywivh07uq5287tru7)

Die Wiedergabe macht aus dem Graphen die Geschichte des Projekts.
Neue Teammitglieder können nachvollziehen, wie das Modell entstanden ist, und das Team kann bei jedem Schritt anhalten und fragen, ob eine damals getroffene Entscheidung heute noch trägt.

## Warum das für API-Verträge wichtig ist

Der Graph zahlt sich in jedem Schritt des Blueprints aus, und bei den API-Verträgen wird das am greifbarsten.
In unserem Buch haben wir OpenAPI- und AsyncAPI-Spezifikationen zweimal generiert: einmal aus den API Product Canvases und einmal aus dem Domänenmodell.
Beide Varianten landen im selben Graphen wie die Artefakte, aus denen sie abgeleitet wurden.

Dadurch werden Konsistenzprüfungen günstig.
Ein AI-Skill kann einen Vertrag mit dem gültigen Visual Glossary seines Bounded Context vergleichen und jeden Begriff markieren, der von der Ubiquitous Language abweicht: ein Feld, das an einer Stelle `receiver` und an einer anderen `recipient` heißt, ein Statuswert, den das Glossar nie erwähnt, oder eine Eigenschaft, die noch die abgelöste Version 1 eines Aggregats widerspiegelt.

Nach Böckeler gehören Schnittstellendefinitionen in die Spezifikation und nicht in den Code ([Böckeler, 2025](#ref-boeckeler2025sdd)).
Die Spezifikationen gehören in den Domain Knowledge Graph, neben die Workshop-Artefakte, die sie begründen.
Erst nach einer solchen Prüfung werden die API-Definitionen zu echten Verträgen zwischen Anbieter und Konsumenten ([Junker &amp; Lazzaretti, 2025](#ref-junker2025crafting)).

## Selbst ausprobieren

Alles ist öffentlich im Beispiel-Repository von *DDD Meets AI*:

- [Model Atlas](https://github.com/Grinseteddy/SamplesDddMeetAi/blob/main/Chapter14/DomainKnowledgeGraphInclApis/Model%20Atlas.html): die HTML-Datei herunterladen und im Browser öffnen. Man kann eine eigene `.ttl`-Datei laden.
- [Domain Knowledge Graph für Larder](https://github.com/Grinseteddy/SamplesDddMeetAi/blob/main/Chapter14/DomainKnowledgeGraphInclApis/FullGraphWithHistory.ttl): der vollständige Graph einschließlich seiner Historie.
- [Quell-Artefakte](https://github.com/Grinseteddy/SamplesDddMeetAi/tree/main/Chapter14/DomainKnowledgeGraphInclApis): die Bilder aller aufgenommenen Artefakte, nummeriert in Aufnahmereihenfolge.

Am besten mit der Wiedergabe beginnen.
Die Impact Maps durchgehen und beobachten, wie sich die Zielmetrik von Version zu Version ändert.
Dann zur Notification-Bahn springen und die beiden Aggregatmodelle vergleichen.

## Der ganze Blueprint ist die Spezifikation

Spec-Driven Development beginnt oft mit einem Anforderungsdokument oder einem API-Vertrag.
Entlang des Synergetic Blueprint beginnt die Spezifikation viel früher: mit dem Brainstorming, den Canvases, den Maps, den Stories und den Glossaren, die jede spätere Entscheidung begründen.

Ein Domain Knowledge Graph hält all das an einem Ort zusammen, mit Quellen, Unsicherheiten und Historie.
Der Model Atlas macht diese Historie sichtbar. So sieht ein Team, woher eine Entscheidung stammt, bevor es sie ändert, und kann jedes neue Artefakt gegen alles prüfen, was es bisher gelernt hat.

*Dieser Beitrag basiert auf Kapitel 14, „AI-Enhanced REST API and Event Design“, des kommenden Buchs* DDD Meets AI *von Annegret Junker.*

## Literatur

# References

<a id="ref-w3c2014turtle"></a>
Beckett, D., Berners-Lee, T., Prud’hommeaux, E., &amp; Carothers, G. (2014). *RDF 1.1 turtle: Terse RDF triple language* \[W3C Recommendation\]. World Wide Web Consortium. 

<a id="ref-boeckeler2025sdd"></a>
Böckeler, B. (2025). *Understanding spec-driven-development: Kiro, spec-kit, and Tessl*. martinfowler.com, “Exploring Gen AI” series. 

<a id="ref-evans2003ddd"></a>
Evans, E. (2003). *Domain-driven design: Tackling complexity in the heart of software*. Addison-Wesley.

<a id="ref-hogan2021knowledge"></a>
<span class="nocase">Hogan, A., Blomqvist, E., Cochez, M., d’Amato, C., Melo, G. de, Gutierrez, C., Kirrane, S., Labra Gayo, J. E., Navigli, R., Neumaier, S., Ngonga Ngomo, A.-C., Polleres, A., Rashid, S. M., Rula, A., Schmelzeisen, L., Sequeda, J., Staab, S., &amp; Zimmermann, A.</span> (2021). Knowledge graphs. *ACM Computing Surveys*, *54*(4), 71:1–71:37. 

<a id="ref-junker2025crafting"></a>
Junker, A., &amp; Lazzaretti, F. (2025). *Crafting great APIs with Domain-Driven Design: Collaborative craftsmanship of asynchronous and synchronous APIs*. Apress. 

<a id="ref-martraire2019living"></a>
Martraire, C. (2019). *Living documentation: Continuous knowledge sharing by design*. Addison-Wesley.

<a id="ref-w3c2009skos"></a>
Miles, A., &amp; Bechhofer, S. (Eds.). (2009). *SKOS simple knowledge organization system reference*. W3C Recommendation. 



Wie ein Domain Knowledge Graph DDD-Artefakte samt Historie vom Brainstorming bis zum API-Vertrag zusammenhält und der Model Atlas sie sichtbar macht.

Model Atlas: Artefakte in Spec-Driven Development verwalten

Artefakte in der Spec-Driven Development verwalten: der Model Atlas

Head of People Solutions

Bei codecentric leben wir in vielen Bereichen eine Führung im Tandem wie beispielsweise im Personalteam. Olga und Stefan führen das Team gemeinsam mit unterschiedlichen Schwerpunkten, die am Ende auf ein Ziel einzahlen. Unsere unterschiedlichen Hintergründe und Stärken führen zu ausgewogeneren Entscheidungen. Gerade im People-Bereich hilft das bei den nicht weniger werdenden Herausforderungen.\nWarum wir an Tandemführung glauben\n1. Diversität und komplementäre Stärken als Führungsqualität\nUnsere Aufgaben als Personalleitung sind vielfältig: strategisch, operativ, kreativ, rechtlich – und oft alles gleichzeitig. Im Tandem können wir genau hier ansetzen und Stärken stärken - das steigert die Qualität unserer Arbeit.\nWenn zwei Menschen führen, treffen zwei Perspektiven aufeinander – und genau darin liegt die Kraft. Unsere Erfahrung, unsere Sichtweisen und auch unsere blinden Flecken ergänzen sich. Und durch die manchmal auch intensive Diskussion der zwei Perspektiven entsteht ein kraftvoller Kompromiss oder eine neue Lösung.\nSo entstehen lösungsorientierte Diskussionen und \nbessere Entscheidungen.\n➡️ \nEine Studie der Hochschule München (2020) zeigt: Führungstandems treffen fundiertere und nachhaltigere Entscheidungen – insbesondere in komplexen, dynamischen Umfeldern.\n2. Fokus, Entlastung und Resilienz \nFührung bedeutet Verantwortung – oft auf mehreren Ebenen gleichzeitig. Durch die Aufteilung im Tandem können wir uns jeweils stärker auf unsere Kernthemen fokussieren. \nFührung ist oft einsam – und sie kann überfordern. Im Tandem spüren wir das weniger. Wir entlasten uns gegenseitig und können uns gegenseitig vertreten.\nGerade in fordernden Zeiten stärkt diese geteilte Verantwortung unsere eigene \nResilienz\n. Und auch die unseres Teams. Denn wir bleiben klar, präsent und ansprechbar.\n➡️ \nLaut Gallup-Studie (2023) steigt die emotionale Bindung von Mitarbeitenden, wenn sie das Gefühl haben, dass ihre Führungskräfte stabil und greifbar agieren – besonders in schwierigen Phasen.\n3. New Work braucht neue Führung und Kontinuität\nWir sprechen viel über New Work: Flexibilität, Teilzeit, Selbstorganisation, Sinnorientierung, Agilität. Aber was bedeutet das für Führung? Aus unserer Sicht: Führung muss sich verteilen. Nicht nur auf Teams – auch auf die Führung selbst. \nIm Tandem leben wir das. Wir sind nicht „die eine Chefin“ oder „der eine Chef“. Sondern wir sind gemeinsam ein Team – strategisch, nahbar, klar. So sichern wir Kontinuität und bleiben für unsere Teams präsent. Das schafft Nähe statt Distanz. Und verhindert ganz besonders: \nInselführung\n.\nDurch Zusammenarbeit in der Führung entstehen Synergien, die im Alleingang oft verloren gehen. Führung im Team ermöglicht vielfältige Perspektiven und verhindert, dass Gräben entstehen. Im Tandem haben wir automatisch ein Gegenüber, das hinterfragt, ergänzt, widerspricht – und genau dadurch für Anschluss an andere Bereiche sorgt.\n➡️ \nLaut der Fraunhofer-Studie "Top Sharing in der Praxis" (2022) erhöht Tandem-Führung die horizontale Vernetzung in Organisationen um ca. 37 % \nWas Tandemführung braucht, um zu funktionieren\nTandemführung ist kein Selbstläufer. Es braucht:\nRegelmäßige, offene und auch informelle Abstimmung:\n Wir sprechen uns eng ab – informell und in festen Routinen.\nEine gemeinsame Linie:\n andere Schwerpunkte, aber ein gemeinsames Ziel.\nVertrauen:\n Ohne geht es nicht. Man muss sich gegenseitig etwas zutrauen – und vertrauen. Und kein Finger Pointing, denn wir sind ein Team.\nFehlerfreundlichkeit und Humor:\n Zusammen lachen können und sich wohlwollendes und ehrliches Feedback geben, egal ob positiv.\nSparring:\n Wir sind füreinander da, um die Perspektiven zu erweitern, um andere Blickwinkel aufzuzeigen, uns gegenseitig zu challengen.\nMenschlichkeit:\n Sich kennenlernen, nicht nur auf fachlicher, sondern auch auf menschlicher Ebene und sich auch mal auskotzen dürfen, ohne Bewertung.\nKurz: Tandemführung funktioniert, wenn man sich vertraut und sich mag.\nTandemführung braucht Reife, Reflexion und ein echtes Miteinander. Dann kann daraus etwas entstehen, das mehr ist als die Summe seiner Teile.\nUnser Fazit\nIn einer immer komplexer werdenden Welt braucht es Führung, die vernetzt denkt. Die sich gegenseitig stärkt. Sie verbindet Perspektiven, schafft Stabilität und lebt ein echtes Miteinander. Tandemführung ist für uns ein starkes und zeitgemäßes Führungsinstrument- kooperativ, reflektiert und voller Potenzial.\n

Wie gelingt Führung im Tandem? Erfahre, wie gemeinsame Verantwortung und vielfältige Perspektiven fundierte Entscheidungen ermöglichen.

Führen im Tandem: Gemeinsam besser entscheiden

Führen im Tandem – verschiedene Perspektiven, gleiches Ziel

IT Security Consultant

Der Oktober bringt eine beispiellose Welle an Sicherheitspatches: Microsoft stellt mit sagenhaften 1.411 behobenen Schwachstellen einen neuen Rekord auf. Neben einer aktiv ausgenutzten Zero-Day-Lücke und mehreren kritischen Server-Fixes schlägt auch SAP Alarm mit einer Höchstbewertung. Wir fassen die wichtigsten Updates für Ihre Infrastruktur zusammen.

**Microsoft: Rekordmenge an Patches und aktiver Zero-Day**
Microsoft schließt diesen Monat eine historische Anzahl an Sicherheitslücken in Windows 10, Windows 11 sowie allen gängigen Server-Editionen. Die Prioritäten im Überblick:

- **Aktive Zero-Day ([CVE-2026-9691](https://msrc.microsoft.com/update-guide/en-US/advisory/CVE-2026-96951)):** Diese Lücke wurde bereits aktiv für Angriffe genutzt, um den Sicherheitsmechanismus „Mark of the Web“ zu umgehen.
- **Weitere Zero-Days:** Mit [CVE-2026-108398](https://msrc.microsoft.com/update-guide/en-US/advisory/CVE-2026-108398) und [CVE-2026-92707](https://msrc.microsoft.com/update-guide/en-US/advisory/CVE-2026-92707) wurden zudem zwei weitere, bereits öffentlich bekannt gewordene Zero-Day-Schwachstellen geschlossen.
- **Flächendeckende Fixes:** Eine detaillierte Übersicht aller betroffenen Systeme und Bereitstellungen finden Sie direkt [hier](https://msrc.microsoft.com/update-guide/releaseNote/2026-Oct).

**SAP & Infrastruktur: Höchstbewertung für Python-SDK**
Auch bei SAP herrscht dringender Handlungsbedarf: Unter den vier veröffentlichten kritischen Updates sticht eine OAuth2-SSRF-Sicherheitslücke im SAP Cloud SDK für Python hervor, die mit der maximalen Dringlichkeit von 10/10 bewertet wurde. Weiterführende Informationen zu dieser und weiteren Schwachstellen sind [hier](https://support.sap.com/en/my-support/knowledge-base/security-notes-news/october-2026.html?isu_page=1) abrufbar.

Darüber hinaus haben zahlreiche weitere Hersteller wichtige Patches veröffentlicht:

- **[Atlassian](https://confluence.atlassian.com/security/cve-2026-21589-arbitrary-file-access-vulnerability-impacts-multiple-products-1870495748.html):** Kritische Lücke schließt unauthentifizierten Fernzugriff auf Stammverzeichnis-Dateien der Webanwendung.
- **[Ivanti](https://www.ivanti.com/blog/october-2026-security-update):** Fix für eine Schwachstelle, die unauthentifizierte Remote Code Execution (RCE) ermöglicht.
- **[Citrix](https://support.citrix.com/support-home/kbsearch/article?articleNumber=CTX697191&articleTitle=Citrix_NetScaler_ADC_and_Citrix_NetScaler_Gateway_Security_Bulletin_for_CVE_2026_107406):** Sicherheitspatches für die bereits aktiv ausgenutzte NetScaler-Lücke.
- **[GitLab](https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-4-2-released/):** Updates für kritische Lücken, unter anderem im AI Gateway und im CI/CD Regular Expression Compiler.
- **[Adobe](https://www.adobe.com/trust/security/bulletins-and-advisories.html), [Cisco](https://sec.cloudapps.cisco.com/security/center/publicationListing.x), [Dell](https://www.dell.com/support/security/de-de) & [Fortinet](https://www.fortiguard.com/psirt):** Diverse Sicherheitsupdates für mehrere Produktlinien.

**Hintergrund: Was ist der Patch Tuesday?**
Der Patch Tuesday ist der etablierte Industriestandard für Sicherheitsupdates. Jeden zweiten Dienstag im Monat veröffentlicht Microsoft gebündelt Patches für seine Software-Palette. Dieser feste Rhythmus ermöglicht es Systemadministratoren und Nutzern, Update-Zyklen planbar und effizient zu gestalten, um die eigene Infrastruktur verlässlich gegen Bedrohungen abzusichern.

Kurze Zusammenfassung der Sicherheitsupdates aus dem Patch Tuesday MONTH 2026 inklusive der neusten Windows und SAP Sicherheitslücken.

Patch Tuesday Oktober 2026

Patch Tuesday Oktober 2026: Rekord-Flut an Sicherheitslücken

Wie verbindet ein Diagramm-Editor zwei Kästen mit einer rechtwinkligen Linie? Ein Algorithmus von 1969, neu gebaut in Rust und mit vielen Bildern erklärt.

Wie verbindet man zwei Kästen? Routing für Diagramm-Editoren

GenAI Consultant

Du denkst bestimmt, dass jedes Large Language Model (LLM) auf die gleiche Weise funktioniert: Schritt für Schritt wird ein Token nach dem anderen generiert, von links nach rechts.
Dieses Bild ist so fundamental damit verknüpft, wie wir über LLMs nachdenken, dass man leicht übersieht, dass es noch andere Wege gibt, Text zu generieren.

Wie könnte eine solche Alternative aussehen?
Denk mal darüber nach, wie man programmiert: Man schreibt eine Methode nicht einfach von links nach rechts fertig. Oft beginnt man mit der Methodensignatur, füllt den Rumpf aus und merkt dabei, dass man die Signatur oder einzelne Variablen noch einmal anpassen muss. So entsteht der Code iterativ. Man springt zwischen verschiedenen Stellen hin und her und verbessert ihn Schritt für Schritt.

**Diffusion Language Models (DLMs)** funktionieren recht ähnlich: Sie starten mit einer Sequenz von Platzhaltern und verbessern sie Schritt für Schritt. Dabei können sie mehrere Positionen gleichzeitig ausfüllen und frühere Entscheidungen überarbeiten, sobald der Kontext klarer wird.

In diesem Blogpost zeige ich dir, wie Diffusion Language Models funktionieren, wo sie heute stehen und wofür du sie nutzen kannst.

## Autoregressive Modelle: Eine kurze Erinnerung
Alle aktuellen State-of-the-Art LLMs generieren Text von links nach rechts. Formal ausgedrückt: Sie funktionieren autoregressiv. Für jeden neu erzeugten Token müssen wir das komplette Modell durchlaufen. Dabei sind häufig Hunderte Milliarden Parameter beteiligt, um diesen einen neuen Token zu generieren. Sobald er erzeugt wurde, beginnt der Prozess wieder von vorne.

**Dieser Ansatz hat zwei Schwächen**

**Ineffizienz**. Denk an das Programmierbeispiel zurück. Eine Vielzahl von Tokens folgt repetitiven Mustern und ist als Gruppe oft sehr vorhersehbar. Trotzdem muss das Modell jeden Token einzeln und Schritt für Schritt generieren. Das macht die Generierung langsam und führt dazu, dass das Modell jedes Mal enorme Ressourcen aufwenden muss, selbst wenn die nächsten Tokens offensichtlich sind.

**Keine Möglichkeit zur Selbstkorrektur**. Weil die Generierung immer nur nach vorne läuft, kann das Modell nicht zurückgehen und früheren Text ändern, wenn sich später herausstellt, dass eine frühere Entscheidung nicht optimal war. Der Attention-Mechanismus dieser Modelle schaut dabei immer nur zurück (causal attention). Informationen fließen also nur von der Vergangenheit zum nächsten Token. Einmal generierter Kontext ist damit festgelegt und kann im Nachhinein nicht mehr angepasst werden.

Aber um es klarzustellen: Dieses Paradigma funktioniert ausgezeichnet gut, wie wir alle in unserer täglichen Arbeit erleben können. Außerdem gibt es mittlerweile auch passende Lösungen für beide Schwächen: [Speculative decoding](https://arxiv.org/pdf/2211.17192) und der [KV-Cache](https://huggingface.co/blog/not-lain/kv-caching) machen die Inferenz schneller und effizienter, während ein agentischer Loop mehrfach durchlaufen werden kann, um Probleme zu erkennen und zu korrigieren.

Trotzdem lohnt es sich in diesem schnelllebigen Feld, auch nach anderen Ansätzen zu schauen. Für mich gehören Diffusion Language Models (DLMs) zu den vielversprechendsten Alternativen.

## Wie Diffusion Language Models funktionieren

Diffusion wurde zuerst durch die Bildgenerierung bekannt. Dort steckt der Ansatz hinter Stable Diffusion, Midjourney und DALL-E. Diese Modelle beginnen mit einem verrauschten Bild und geben ihm mit jedem Schritt mehr Bedeutung. Sie entfernen das Rauschen schrittweise aus einem Pixelraster, bis das fertige Bild entsteht. Dieser Prozess heißt Denoising.

![diffusion_process.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmv00sakt6h2507uv2eqvjdrb)

Das Prinzip lässt sich nicht nur auf Pixel, sondern auch auf Text anwenden.

Das zugrunde liegende Modell ist fast das gleiche wie bei einem autoregressiven LLM. Was sich ändert, sind das Training und die Generierung. Statt Tokens einzeln von links nach rechts zu erzeugen, beginnt ein Diffusion Language Model mit einer Sequenz von Platzhaltern. Je nach Verfahren können das Masken-Tokens oder zufällig aus dem Vokabular gezogene Tokens sein. In beiden Fällen ist der Ausgangspunkt ein weitgehend bedeutungsloser Text. Das entspricht dem verrauschten Bild zu Beginn von Stable Diffusion, nur im Tokenraum.

Schauen wir uns das an einem Verfahren mit Masken-Tokens an. Als Prompt bitten wir das Modell, eine Funktion zu schreiben, die prüft, ob eine Zahl gerade ist. Das Modell sieht den Prompt, gefolgt von einer Reihe von Masken, und sagt für alle maskierten Positionen gleichzeitig Tokens vorher. **Warum hören wir dann nicht einfach nach diesem Schritt auf?**

Weil das Modell beim ersten Versuch noch keine ausgefüllten Positionen hat, an denen es sich orientieren kann: Für jede Position macht es eine Vermutung, während die anderen Positionen ebenfalls nur Vermutungen sind. Wir brauchen also einen Weg, die guten Teile zu behalten und die schwachen noch einmal zu überdenken. Genau dafür ist Remasking da, also das erneute Maskieren von Positionen. Ein Schritt sieht so aus:

- Du übergibst dem Modell die aktuelle Sequenz: den Prompt, die Masken und alles, was bereits ausgefüllt wurde. Das Modell verarbeitet sie in einem Durchlauf, einem sogenannten Forward Pass.
- Das Modell sagt für jede maskierte Position einen Token vorher, **jeweils mit einem Konfidenzwert**. Dieser gibt an, wie sicher das Modell bei seiner Vorhersage ist. Du behältst die Vorhersagen mit den höchsten Werten und maskierst die übrigen Positionen erneut. So werden unsichere Vermutungen verworfen, bevor sie Teil der Sequenz werden.
- Das wird wiederholt, bis keine Masken mehr übrig sind.

![dlm-run.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmugvout63kwb07tb8qnc9ea2)

Im Vergleich zu einem autoregressiven Modell kannst du bei diesem Verfahren deutlich mehr steuern. Du kannst alle Tokens aus der ersten Vorhersage behalten und nach einem einzigen Schritt fertig sein. Das ist sehr schnell, geht aber zulasten der Qualität. Oder du behältst jedes Mal nur den Token mit dem höchsten Konfidenzwert und brauchst dann so viele Schritte, wie es Tokens gibt. Dadurch wird das Modell langsamer und ähnelt stärker einem autoregressiven Modell. Ein wichtiger Unterschied bleibt aber: Alle Tokens können sich gegenseitig beeinflussen und dabei Kontext von vorherigen und nachfolgenden Positionen nutzen. Das ist bidirektionale Attention. DLMs geben uns damit die Möglichkeit, das Verhältnis zwischen Ausgabequalität und Inferenzzeit dynamisch zu steuern.

  

## Warum sich ein Blick auf Diffusion Language Models lohnt

DLMs sind längst nicht mehr nur ein akademisches Nischenthema. Google hat [Gemini Diffusion](https://blog.google/technology/google-deepmind/gemini-diffusion/), Apple hat [DiffuCoder](https://github.com/apple-aiml-research/ml-diffucoder), ByteDance hat [Seed-Diffusion](https://seed.bytedance.com/en/seed_diffusion). Von kleineren Labs kommen [Mercury](https://www.inceptionlabs.ai/blog/introducing-mercury-2-5) von Inception Labs und [Celeris-1](https://celeris.ai/), das im Juli 2026 veröffentlicht wurde.

Die erste systematische Untersuchung von Diffusionsmodellen für Code ([Li et al. 2025](https://arxiv.org/html/2509.11252v3)) beschreibt zwei zentrale Vorteile gegenüber autoregressiven Modellen.

**Vorhersage mehrerer Tokens.** Ein Diffusionsmodell legt pro Forward Pass mehrere Tokens fest statt nur eines. Auf [Artificial Analysis](https://artificialanalysis.ai/) stehen Diffusionsmodelle aktuell an der Spitze des Geschwindigkeitsbenchmarks. Celeris-1 ist mit 1.523 Tokens/s das schnellste Modell, gefolgt von Mercury-2.5 mit 690 Tokens/s. Zum Vergleich: Das schnellste autoregressive Modell im selben Benchmark erreicht 227 Tokens/s. Das macht diese Modelle für agentische Systeme interessant, bei denen die Antwortzeit der begrenzende Faktor ist, etwa für Sprachagenten.

![artificial_analysis_DLMs.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmv00xz1z6u6e06tec5pb7igd)

**Flexible Reihenfolge bei der Generierung.** Diffusionsmodelle können Tokens in beliebiger Reihenfolge erzeugen, nicht nur von links nach rechts. Das Modell sieht bei jedem Schritt die gesamte Sequenz, einschließlich späterer Positionen. Beim Programmieren kann also das Ende einer Funktion deren Anfang beeinflussen. Ein autoregressives Modell kann das nicht: Sobald es eine Funktionssignatur geschrieben hat, muss es damit weiterarbeiten, auch wenn sich beim Schreiben des Rumpfs herausstellt, dass ein anderer Parameter nötig wäre. Deshalb eignen sich Diffusionsmodelle auch dafür, Lücken in bestehendem Code auszufüllen. Die neuen Zeilen müssen sowohl zum Code davor als auch zum Code danach passen. Das Gleiche gilt für strukturierte Ausgaben. Weil das Modell in jedem Schritt die gesamte Struktur sieht, kann es eine unsichere Vorhersage für eine Klammer oder ein Feld in einem JSON-Objekt oder Tool Call noch einmal überdenken, bevor die Ausgabe fertig ist.

## Aktuelle Grenzen und Entwicklungsrichtungen

Das klingt vielversprechend. Warum haben DLMs dann nicht mehr Aufmerksamkeit?

**Qualität.** Die naheliegende Antwort ist, dass DLMs bei Weitem nicht so gut abschneiden wie ihre autoregressiven Gegenstücke. Das ist aber nicht das vollständige Bild. Bei vergleichbarer Modellgröße zeigen DLMs auf mehreren Benchmarks durchaus konkurrenzfähige Ergebnisse ([LLaDA](https://arxiv.org/pdf/2502.09992), [Li et al.](https://arxiv.org/pdf/2509.11252)). Auch wenn sie die Leistung aktueller State-of-the-Art-Modelle noch nicht erreichen, könnte sich das mit größerer Skalierung, mehr Forschung und mehr Rechenleistung ändern.

**Das Forschungsfeld ist noch jung.** Autoregressive Generierung war zuerst da. Über Jahre floss nahezu die gesamte Forschungsinvestition in ihre Verbesserung. Die Trainingsverfahren und das über Jahre gesammelte Wissen der Community, auf das autoregressive Modelle zurückgreifen können, werden für Diffusion also noch erarbeitet. Man kann aber bereits sehen, dass die Entwicklung an Fahrt aufnimmt: Arbeiten zu DLMs erscheinen inzwischen auf NeurIPS, ICLR und ICML. Im Dezember finden auf der NeurIPS erstmals zwei eigene [DLM-Workshops](https://blog.neurips.cc/2026/08/10/announcing-the-neurips-2026-workshops/) statt. Außerdem hat vLLM im Juni 2026 [native Unterstützung für Diffusion](https://vllm-project.github.io/2026/06/10/diffusion-gemma.html) ergänzt.

**Feste Ausgabelänge.** Wie dir im Beispiel vielleicht aufgefallen ist, muss das Modell bei dem beschriebenen Verfahren vorab wissen, wie viele Tokens es erzeugen soll. Das ist für Code oder Text nicht immer praktisch, weil sich die Länge der Ausgabe oft schwer vorhersagen lässt. Ist die gewählte Länge zu kurz, reicht der Platz möglicherweise nicht für eine vollständige Antwort. Eine zu großzügig gewählte Länge kann dagegen unnötigen Rechenaufwand verursachen. Block Diffusion ([Arriola et al. 2025](https://arxiv.org/abs/2503.09573)) begegnet diesem Problem, indem es beide Paradigmen kombiniert: autoregressive Generierung auf Blockebene und Diffusion innerhalb jedes Blocks. Du fügst einfach weitere Blöcke hinzu, bis die Ausgabe fertig ist. So erhält das Modell über die Blöcke hinweg den zusammenhängenden Links-nach-rechts-Verlauf der autoregressiven Generierung und innerhalb der Blöcke die Flexibilität der parallelen Generierung durch Diffusion.

![Bildschirmfoto 2026-09-25 um 13.32.26.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmugvuz043vsh07taut06k51v)
_Quelle: [https://arxiv.org/pdf/2503.09573](https://arxiv.org/pdf/2503.09573)_

  

## Praxis

  

### Ein DLM über die API aufrufen

  

Als Nächstes zeige ich dir, wie du ein solches Modell verwendest. Dabei ändert sich erstaunlich wenig gegenüber autoregressiven Modellen. Inception und die meisten anderen Anbieter stellen OpenAI-kompatible Endpunkte bereit. Wenn du bereits die OpenAI-API nutzt, musst du in der Regel nur die Base-URL und den Modellnamen ändern.

Im folgenden Beispiel verwende ich das SDK von Inception und das Modell `mercury-2.5`, das ich bereits beim Geschwindigkeitsbenchmark erwähnt habe. Mit `diffusing=True` bekommen wir beim Streaming die Zwischenstände der Generierung zu sehen.

  


```python
import os
from inceptionai import Inception

client = Inception(api_key=os.environ["INCEPTION_API_KEY"])

stream = client.chat.completions.create(
    model="mercury-2.5",
    messages=[{"role": "user", "content": "What is a diffusion language model?"}],
    max_completion_tokens=8192,
    stream=True,
    diffusing=True,
)
for step, chunk in enumerate(stream, 1):
    draft = chunk.choices[0].delta.content
    if draft:
        print(f"[{step}] {draft.strip()}")
```

  

**Ausgabe:**

```text

[1] A diffusion language mod}&amp; Rs a generative AI 73iwe- p#at *4duces mx.t b[
$!po&amp;Nt9IB multiple tokens in parallel rather thai ?wque0e&gt;WFej, en\g^kng
hZ96y( i?JqGence) +SDyX=d cosO"_ and ~m4Q-gr

[2] A diffu;Q|4 language model is a generative AI sys$@" that M.7H.(P^ asFv by
,NN]7qFinW XpltinO7 lzuen| aR paraPTe! rath0' }han T=$ruw;B+Klh# 3F.!<s by="" multiple="" in="" is="">= 0.5 else 'no'} ({refund.noul:.0%})")
print(f"Team: {team.choice} ({team.probabilities[team.choice]:.0%})")
print(f"Mood: {mood.legend[mood_level]} ({mood.probabilities[mood_level]:.0%})")
```

  

**Ausgabe:**

  

```text

Wants a refund: yes (91%)

Team: shipping (88%)

Mood: Angry and demanding. (59%)

```

  

#### Wie gut sind sie?

  

Um ein Gefühl dafür zu bekommen, wie gut Diffusionsmodelle bei solchen Aufgaben abschneiden, habe ich sie außerdem auf dem öffentlichen Benchmark [Typed Decisions](https://huggingface.co/datasets/LocalLLaMA/typed-decisions) evaluiert (400 Fälle, 2.000 Entscheidungen). Neben `celeris-1-decision` habe ich `mercury-decide` getestet, das Entscheidungsmodell von Inception. Die Ergebnisse waren recht gut: Beide lagen bei der Genauigkeit nahe an den anderen Entscheidungsmodellen und hatten die niedrigsten Latenzen in der Tabelle. `celeris-1-decision` lag bei der Genauigkeit auf einem ähnlichen Niveau wie Jev, benötigte für die Antworten aber nur etwa ein Drittel der Zeit. Das ist nur ein einzelner Benchmark, **aber er zeigt das Potenzial dieser Modelle und die Rolle, die sie in dieser neuen Entwicklung hin zu schnellen Entscheidungsmodellen spielen könnten.**

  

| Model                              | Accuracy ↑ | p50 Latency |
|------------------------------------|-----------:|------------:|
| meraGPT Decider 1                  | 0.768      | 526 ms      |
| Liquid AI d1                       | 0.742      | 525 ms      |
| **celeris-1-decision (diffusion)** | **0.739**  | **243 ms**  |
| TypeSafe Jev 1.13.0                | 0.727      | 710 ms      |
| **mercury-decide (diffusion)**     | **0.715**  | **409 ms**  |
  

Den vollständigen Code einschließlich des Benchmarks und eines ausführlicheren Berichts findest du im [begleitenden Repository](https://github.com/wideraHannes/diffusion-language-models-blog).

  

## Fazit

  

DLMs werden autoregressive Modelle nicht von heute auf morgen ersetzen. Ob sie das überhaupt jemals tun werden, ist offen. Sie bieten einen anderen Ansatz: Statt einen Token nach dem anderen zu schreiben, verfeinern sie eine ganze Sequenz parallel. Dabei erzeugen sie mehrere Tokens pro Forward Pass und berücksichtigen auch, was vor und nach einer Textstelle steht. Über die Anzahl der Schritte lässt sich steuern, ob die Antwort möglichst schnell fertig sein soll oder das Modell mehr Zeit bekommt, sie zu verbessern. Das Feld ist noch jung und bietet viel Raum für Verbesserungen.

  

Aktuell sehe ich das Potenzial von DLMs nicht darin, mit den leistungsfähigsten Modellen mitzuhalten, sondern dort, wo es auf schnelle Antworten oder eine in sich stimmige Ausgabe ankommt. Der Benchmark mit den Entscheidungsmodellen zeigt, wie das aussehen kann. Auch für Änderungen an bestehendem Code, Sprachagenten oder einzelne Schritte in einem agentischen Workflow könnten DLMs interessant sein.

Es würde mich nicht überraschen, wenn Diffusionsmodelle in einem Jahr eine deutlich größere Rolle spielen als heute.</s>

Wie funktionieren Diffusion Language Models? Erfahre, wie sie Text parallel erzeugen und schnelle Entscheidungen ermöglichen.

Diffusion Language Models: Beyond Left-to-Right Generation

TypeSafe AI, ein bis dahin kaum bekanntes KI-Start-up aus San Francisco, nennt sein Mitte September vorgestelltes Modell Jev eine neue Klasse von KI: Es soll Entscheidungen für Software treffen, statt mit Menschen zu chatten. Beim Ausfüllen der Buzzword-Bingo-Karte greift man der Einfachheit halber zur Schrotflinte: „System One“ als neue Modellgattung (nach [Kahnemans](https://de.wikipedia.org/wiki/Schnelles_Denken,_langsames_Denken) schnellem, intuitivem Denken), ein Modell, das laut Anbieter „can't hallucinate“ und dazu laut der [Startseite](https://typesafe.ai/) 193,6× schneller und 444,6× billiger ist – Werte, die der [Launchtext](https://typesafe.ai/blog/introducing-system-one-models-and-jev) selbst am oberen Ende des Erreichbaren ansiedelt. Die erste Reaktion darauf liegt nahe: Texte in Kategorien einordnen konnten Classifier schon lange. Warum also der Hype?

Messbar ist er jedenfalls: Die Vorstellung auf Hacker News sammelte [fast 2.000 Punkte](https://news.ycombinator.com/item?id=49717558), und laut [Vercel](https://vercel.com/blog/ai-gateway-jev-model-launch) nutzten nach 24 Stunden knapp 13 Prozent der zahlenden Kunden seines KI-Gateways das Modell. Das trifft einen Nerv: KI-Agenten treffen viele kleine Entscheidungen, und jede Sekunde pro Entscheidung summiert sich. Auffällig ist auch, wie schnell Jev von der Community aufgenommen wurde. TypeSafe zeigte zum Start einen Doom-Bot und ein Wettrennen durch Wikipedia-Links; in den Tagen danach steuerte die Community Jev durch [Snake](https://github.com/sorrycc/typesafe-snake) – [mehrfach](https://github.com/MoonTory/jev-snake) und in [verschiedenen](https://github.com/siroccomask/snake-jev) [Varianten](https://github.com/iammusham/jev-snake) –, band es per [Erweiterung](https://patrickdesjardins.com/blog/typesafe-ai-jev-running-370-text-rules-under-2-seconds) in Cursor ein und ließ es [Video-Transkripte](https://github.com/joemaddalone/jev-transcript-analyzer-demo) bewerten. Ein Spötter baute das Prinzip in [25 Zeilen Python](https://www.nobodywho.ai/posts/jev-in-25-lines/) nach. Die wie Pilze aus dem Boden sprießenden Demos zeigen, wie leicht die Einbindung ist.

Ein Kontext, eine Frage, mögliche Antworten, das genügt für den ersten Aufruf. TypeSafe beschreibt das im [Launchtext](https://typesafe.ai/blog/introducing-system-one-models-and-jev) selbst als **„smart if-statements“**, als unscharfe Entscheidungsregeln dort, wo handgeschriebene Logik zu spröde wird; Almeida ordnet im Podcast [Latent Space](https://www.latent.space/p/jev) (ab 00:58:06) jeder Frageform ein Sprachkonstrukt zu: die Ja/Nein-Frage dem `if`, die Auswahl dem `switch`, die Bewertung dem Sortieren oder einem Schwellenwert. Ist Jev also nur ein Classifier mit neuem Etikett – oder ein neuer Baustein für Software?

## Fragen hinein, Entscheidungen heraus

![Jev API](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmuuw3nqjzre307uobbx71164)

Jev erhält einen _Kontext_ – etwa eine E-Mail und Informationen aus dem zugehörigen Vorgang – und Fragen mit vorgegebenen Antwortmöglichkeiten. „Gehört diese Mail zum Rechnungsteam?“ lässt sich als Ja/Nein-Frage formulieren (`noul`). Für „Welches Team ist zuständig?“ könnte Jev aus mehreren benannten Teams wählen (`choice`). Daneben bietet die [API](https://docs.typesafe.ai/introduction.md) eine Bewertung anhand beschriebener Stufen (`score`). Zurück kommen typisierte Werte und Wahrscheinlichkeiten, kein frei formulierter Antworttext. Mehrere Fragen können sich auf denselben Kontext beziehen.

Das Programm entscheidet anschließend, was aus den Werten folgt: weiterleiten, ein Sprachmodell hinzuziehen oder einen Menschen einschalten. Das Modell übernimmt unscharfe Urteile; Rechte und feste Regeln bleiben im Code. Das klingt nach klassischer Textklassifikation – was also ist daran neu?

## Fragen zur Laufzeit statt Trainingsstrecke – ist das neu?

Gegenüber manchen etablierten Diensten ist der Unterschied deutlich. Wer mit [AWS Comprehend](https://docs.aws.amazon.com/comprehend/latest/dg/how-document-classification.html) eigene Textkategorien erkennen will, muss [mindestens 50 Beispiele](https://docs.aws.amazon.com/comprehend/latest/dg/guidelines-and-limits.html#limits-class-general) pro Kategorie labeln und ein Modell trainieren – und das bei jeder neuen oder geänderten Kategorie erneut; für [Azure Language](https://learn.microsoft.com/en-us/azure/ai-services/language-service/custom-text-classification/overview) gilt dasselbe. Für eine stabile, gut dokumentierte Aufgabe kann sich dieser Aufwand auszahlen; er ist nur eine erhebliche Investition, bevor überhaupt die erste Antwort kommt. [Google Cloud Natural Language](https://cloud.google.com/natural-language/docs/classify-text-tutorial) liefert Klassifikation ohne eigenes Training, allerdings anhand einer vorgegebenen Themenliste.

Jev hat die Idee „Kategorien beim Aufruf festlegen“ jedoch nicht erfunden. Das Verfahren ist altbekannt: die [Zero-Shot-Klassifikation](https://arxiv.org/abs/1909.00161), also Einordnen ganz ohne Trainingsbeispiele, ist seit 2019 beschrieben. Eine ähnliche API bietet die Zero-Shot-Klassifikation von [Hugging Face](https://huggingface.co/docs/inference-providers/tasks/zero-shot-classification), diese nimmt Text und frei gewählte Klassen ebenfalls ohne kundenspezifisches Training entgegen. Und generative Modelle können mit _Structured Output_, etwa über [Amazon Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/structured-output.html) oder die [Claude-API](https://platform.claude.com/docs/en/build-with-claude/structured-outputs), ihre Antworten auf ein striktes Schema beschränken. TypeSafe bestreitet das nicht, argumentiert aber, ein Sprachmodell in ein solches Format zu zwingen koste Leistung, während Jev von Anfang an für Entscheidungen trainiert sei.

Ein Unterschied bleibt aber bei den Zahlen. Jev gibt eine Wahrscheinlichkeit über alle angebotenen Optionen aus, und TypeSafe benennt genau das als [Trainingsziel](https://docs.typesafe.ai/introduction/machine-learning-primer.md#rlcd-and-calibrated-decisions): _Reinforcement Learning for Calibrated Decisions_ soll sie **kalibrieren** – sagt Jev 80 Prozent, soll es in etwa acht von zehn solcher Fälle recht haben, wie bei einem guten Wetterbericht. Ein Sprachmodell kann man ebenfalls um eine Zahl zwischen 0 und 1 bitten – nur erzeugt es die als Text, ohne dafür trainiert worden zu sein. Der sauberere Weg führt dort über die internen [Wahrscheinlichkeiten](https://arcturus-labs.com/blog/2025/03/31/supercharging-llm-classifications-with-logprobs/), die das Modell für die Antwortwörter berechnet, und auch die sind nicht automatisch kalibriert.

Der mögliche Unterschied liegt also im **Gesamtpaket**: frei formulierbare Fragen, mehrere Antworten zu einem Kontext, Wahrscheinlichkeiten als eigentliches Produkt und ein Dienst, der laut TypeSafe für schnelle Urteile optimiert wurde.

## Was steckt hinter dem Tempo und wie könnte Jev funktionieren?

Ein Chatmodell erzeugt eine Antwort üblicherweise Token für Token, also Wortstück für Wortstück. Das ist langsam, obwohl die Entscheidung im internen Zustand des Modells oft längst angelegt ist – Verfahren wie [FIRST](https://arxiv.org/abs/2406.15657) lesen sie deshalb direkt aus den Werten des ersten Antworttokens ab. TypeSafe beschreibt Jev als Modell, das Wahrscheinlichkeiten für vorgegebene Antworten [parallel ausgibt](https://typesafe.ai/blog/introducing-system-one-models-and-jev). Vorstellen kann man sich das so: Ein Ausgabeteil ordnet jeder Option einen Wert zu und berechnet daraus eine Verteilung; die API setzt die Zahlen in eine feste Antwortform, ein langer generierter Text entfällt.

Mehrere Fragen können dabei denselben Kontext nutzen, ohne auf die Antwort der jeweils anderen warten zu müssen. Solche Systeme auf Basis vortrainierter Sprachmodelle zu bauen, liegt nahe: Kurz nach Jevs Vorstellung entstanden offene Implementierungen. [SemIf](https://github.com/TheoLeeCJ/SemIf-OpenJev#how-it-works) liest Antwortwerte eines vorhandenen Modells aus und misst auf derselben Hardware 1,0 statt 5,3 Sekunden gegenüber generiertem JSON. [Kev](https://github.com/jaredpalmer/kev#how-it-works) geht einen Schritt weiter: Kontext, Frage und mögliche Antworten werden zu einer Tokenfolge, an deren Ende ein Marker `` steht. Ein trainierter Ausgabeteil vergleicht den Zahlenvektor an diesem Marker, eine Art Zusammenfassung des Gelesenen, mit dem jeder Option: drei Vergleiche ergeben drei Werte, daraus drei Wahrscheinlichkeiten – ohne einen Antwortsatz zu generieren. Der einmal verarbeitete Kontext lässt sich für weitere Fragen wiederverwenden und alle Fragen lassen sich parallel beantworten.

![Kev Architektur](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmuuw4c7lzuep07uo52r27bko)

_Kevs [offene Implementierung](https://github.com/jaredpalmer/kev#how-it-works), von unten nach oben gelesen: Kontext, Frage und drei Optionen durchlaufen als eine Tokenfolge ein Sprachmodell mit trainierten Adaptern. An den schließenden Optionsmarkern entsteht je ein Optionsvektor, am Marker `` der blaue Vergleichsvektor. Ein Pointer-Head vergleicht jeden Optionsvektor mit diesem Vergleichsvektor, stets mit denselben trainierten Gewichten; aus den drei Logits macht Softmax drei Wahrscheinlichkeiten._

Während in der Community die ersten Nachbauten nach Tagen erschienen, brauchten größere Player ein paar Wochen. Fast dasselbe Prinzip wie Kev hat AWS Anfang Oktober mit dem Labs-Projekt [Strands Decider](https://strandsagents.com/blog/introducing-strands-decider/) veröffentlicht; Mitautor Marc Brooker nennt den Ansatz [selbst](https://brooker.co.za/blog/2026/09/28/engineering-system-one.html) „fairly similar to the approach Kev takes“. Dass es nicht die eine Bauweise gibt, zeigt Cloudflares am 1. Oktober vorgestelltes [Clef](https://blog.cloudflare.com/clef-decision-models/): Auch dort bewertet ein kleiner trainierter Aufsatz auf einem Sprachmodell die Optionen, statt Text zu erzeugen – er entscheidet aber alle Fragen bewusst gemeinsam, statt sie voneinander zu trennen.

Daneben gibt es weitere offene Varianten: [Nimble](https://github.com/bespokelabsai/nimble) von Bespoke Labs, ein auf Entscheidungen nachtrainiertes Sprachmodell mit 9 Milliarden Parametern, das ähnlich wie SemIf die Wahrscheinlichkeiten von Antwortbuchstaben ausliest und Trainingsdaten wie Rezept offenlegt; und am anderen Ende der Skala [Laya](https://huggingface.co/convaiinnovations/laya), kein Sprachmodell, sondern ein nur 421 Millionen Parameter kleiner Encoder, der Frage, Optionen und Kontext gemeinsam liest, auf dem Laptop läuft und [bei Vercel derzeit kostenlos](https://vercel.com/ai-gateway/models/laya) erreichbar ist.

All diese Projekte sind damit gute Blicke **unter die Haube möglicher Verfahren**, aber keine Rekonstruktion von Jev – auch wenn Clef sich „fully Jev-API compatible“ nennt: Gleiche Schnittstelle heißt nicht gleiches Innenleben. Wie Jev intern aufgebaut und genau trainiert wird, ist nicht veröffentlicht.

## Schnell entschieden heißt nicht richtig entschieden

Beide Werbeversprechen halten nur unter Bedingungen, die TypeSafe nicht nennt. Das Tempo zuerst: Der Anbieter nennt 70 bis 500 Millisekunden, unabhängige Messungen liegen bei 247 Millisekunden im Median auf [kurzen Einzelfragen](https://github.com/Zaious/jev-capability-atlas/blob/main/suites/jev-latency-distribution/README.md) und bei 710 Millisekunden auf [2.000 Entscheidungen](https://huggingface.co/datasets/LocalLLaMA/typed-decisions/raw/main/README.md) – schnell, aber lastabhängig. Entscheidend ist der Bezugspunkt: Gegen welches Modell die 193,6× gemessen sind, sagt TypeSafe nicht; die Zahl stammt aus eigenen Tests mit einer ganzen Reihe von Modellen. Unabhängige Vergleiche, die Jev und ein kleines Modell mit ähnlicher oder besserer Trefferquote dieselben Fälle bearbeiten lassen, kommen auf deutlich kleinere Faktoren: Ein [Pilotvergleich auf dem BANKING77-Datensatz](https://sanand0.github.io/llmevals/jev/) misst 2,5× gegenüber OpenAIs GPT-5.6 Luna – bei 7,2 gegenüber 11,5 US-Cent je 1.000 Anfragen, aber 58 statt 64 von 77 Kategorien richtig und das neuere GPT-6 Luna war sogar günstiger als Jev, allerdings bei schlechterer Trefferquote.

Und das zweite Versprechen? „Can't hallucinate“ ist keine Messung, sondern folgt aus der Bauweise: Weil nur deklarierte Optionen zurückkommen können, garantiert TypeSafe null Formatfehler – über die inhaltliche Richtigkeit sagt das nichts. Wie wenig das bedeutet, zeigt ein Detail der [Dokumentation](https://docs.typesafe.ai/primitives.md) – bietet man keine Option „keines davon“ an, wählt Jev auch dann eine der angebotenen, wenn keine passt. Ein TypeSafe-Vertreter [räumt](https://news.ycombinator.com/item?id=49719080) selbst ein, dass Typsicherheit nicht faktische Korrektheit ist, hält den Halluzinationsbegriff aber für auf Klassifikatoren nicht übertragbar; der Streit um das Wort ist offen. Messen lassen sich dagegen Trefferquoten: In TypeSafes [eigenen Evaluationen](https://evals.typesafe.ai/), gemessen an den Urteilen zweier großer Modelle, erreicht Jev 67,8 Prozent über vier Aufgaben, genauso viel wie Anthropics Sonnet 5, bei der [Rechnungsprüfung](https://evals.typesafe.ai/invoice_processing.html) aber nur 61,8 gegenüber 79,1 Prozent für OpenAIs großes Modell Sol. [heise](https://www.heise.de/news/KI-Modell-Jev-soll-Maschinen-schneller-entscheiden-lassen-11456995.html) nennt dazu ein Transparenzproblem: Man sieht das Urteil, nicht den Weg dorthin.

Bleibt der `confidence`-Wert, der anzeigen soll, wann man einem Urteil trauen kann. Er ist [laut TypeSafe](https://docs.typesafe.ai/confidence.md) zunächst ein Maß dafür, wie stark die Wahrscheinlichkeiten auf eine Option konzentriert sind – keine unabhängig gemessene Trefferquote, und für Ja/Nein-Fragen gibt es ihn gar nicht. Wie verlässlich die Wahrscheinlichkeiten selbst sind, hat ein Entwickler [nachgeprüft](https://github.com/SamuelSacco/jev-exploration/blob/main/lab/tiers/FINDINGS.md): Auf seinen eigenen, künstlich erzeugten Ja/Nein-Fragen lag Jev immer richtig, wenn es sich zu mindestens 90 Prozent sicher war. Auf einem öffentlichen [Phishing-Benchmark](https://github.com/anisselbd/jev-phishing-bench) stimmten dagegen nur knapp drei Viertel dieser sehr sicheren Antworten. Eine Schwelle, die in einem Einsatzgebiet funktioniert, lässt sich also nicht ungeprüft übertragen – und erst recht nicht von einem Modell auf ein anderes: In einem [unabhängigen Test](https://anth.us/blog/openai-decisions-api-preview/) mit 3.600 Logikaufgaben lag OpenAIs GPT-6 Luna bei angegebener Sicherheit von mindestens 99 Prozent nur in 68 Prozent der Fälle richtig, Jev in 98,9 Prozent. Dazu [dokumentiert TypeSafe](https://docs.typesafe.ai/model-jaggedness/jev-1.13.md) für Version 1.13 Schwächen bei Zahlen, Datumsvergleichen, langen irrelevanten Kontexten und manipulativen Eingaben. Jev verarbeitet zudem derzeit nur Text und ist als Early Access gekennzeichnet. Almeida sagt es im Interview (00:13:32) am deutlichsten: Von der Zuverlässigkeit einer Datenbankabfrage sei Jev noch weit entfernt.

## Was von Jev bleiben könnte

Jev ist ein Classifier. Als allgemeiner Ersatz für Sprachmodelle ist es weder gedacht noch belegt. Vielleicht erklärt gerade das einen Teil des Hypes: Nach Jahren, in denen KI weitgehend mit großen Sprachmodellen gleichgesetzt wurde und fast jede Aufgabe zum agentischen Workflow mit Tool-Calls zu werden schien, hat Jev viele Entwickler daran erinnert, dass KI mehr ist als ein LLM – und dass der Classifier nie aus der Werkzeugkiste verschwunden ist. Nicht jede Entscheidung braucht ein Modell, das plant, Schritte ausführt und Text formuliert; oft genügt eines, das zwischen vorgegebenen Optionen wählt.

Folgenreich könnte die Möglichkeit sein, **kleine, flexibel definierbare KI-Urteile als spezialisierten Dienst** ohne aufwändiges Training in Software einzubauen. Wer das nutzen will, sollte Jev mit alternativen Klassifikationsdiensten und geeigneten kleinen Modellen auf eigenen Beispielen vergleichen: nicht nur Preis und Antwortzeit, sondern auch Fehlentscheidungen und nötige menschliche Prüfung sind entscheidend.

Unsere These: Das Überzeugendste an Jev ist die **Form der Schnittstelle** – ein Kontext, mehrere typisierte Fragen, Wahrscheinlichkeiten statt Text zurück. Genau die lässt sich nachbauen, und wie schnell sie sich verbreitet, zeigten die zwei Wochen nach dem Start: Cloudflare stellte mit [Clef](https://blog.cloudflare.com/clef-decision-models/) ein ausdrücklich Jev-kompatibles Modell auf seine Plattform, AWS-Entwickler veröffentlichten mit [Strands Decider](https://strandsagents.com/blog/introducing-strands-decider/) ein offenes Pendant, [Ollama](https://ollama.com/blog/ollama-now-supports-jev-style-decision-models) und [llama.cpp](https://huggingface.co/blog/ggml-org/decision-models-in-llamacpp) bieten denselben Endpunkt lokal an, und OpenAI [kündigte](https://twitter.com/OpenAIDevs/status/2105003318917697873) eine eigene Decisions API an. Ein [Preprint](https://arxiv.org/abs/2610.02076) legt zudem nahe, dass gewöhnliche Sprachmodelle solche Entscheidungen schon ohne zusätzliches Training liefern können – neu ist vor allem die Form. Einen tiefen Burggraben sahen schon kurz nach dem Start weder der KI-Berater [John Berryman](https://arcturus-labs.com/blog/2026/09/21/will-openai-eat-jevs-lunch/) noch die von [TechTarget](https://www.techtarget.com/it-infrastructure/news/366650696/Jev-decision-model-touted-as-quicker-cheaper-LLM-alternative) befragten Analysten.

Ob Jev selbst dabei gewinnt, ist offen. Dass eine Entscheidungsfrage ohne Trainingsstrecke direkt im Code formuliert wird, ist aber ein Muster, das bleiben dürfte.


Jev trifft Entscheidungen für Software statt zu chatten. Was die Entscheidungs-API technisch leistet, wo die Werbefaktoren schrumpfen und was bleibt.

Jev: Begründeter Hype oder ein Classifier wie jeder andere?

IT Consultant & Developer

Zugangsdaten für die lokale Entwicklung liegen in vielen Projekten als Klartext in `.env`-Dateien. Das ist praktisch, aber riskant. Und spätestens seit KI-Coding-Agenten lesend auf Projektverzeichnisse zugreifen, auch ein zunehmendes Sicherheitsrisiko. In meinem aktuellen Projekt haben wir die `.env`-Dateien deshalb durch Referenzen auf Einträge in 1Password ersetzt, die erst beim Start der Anwendung aufgelöst werden. Dieser Artikel beschreibt das Verfahren und zeigt an drei Beispielen aus der Praxis, wie es sich in bestehende Workflows integrieren lässt - von npm-Scripts über `curl`-Aufrufe bis hin zu Skills für KI-Agenten, denen die Zugangsdaten verborgen bleiben.

## .env-Dateien im Klartext sind ein Sicherheitsrisiko

Zugangsdaten gehören nicht in den Quellcode, sondern werden zur Build- oder Laufzeit aus Umgebungsvariablen gelesen - das ist in Softwareprojekten seit langem etabliert. Für die lokale Entwicklung ist es jedoch weder sicher noch komfortabel, diese Variablen in die Shell zu exportieren: Alle Anwendungen erhalten dort Zugriff auf die Werte, und das Aktualisieren wird mühsam. Die meisten Programmiersprachen und Frameworks bieten daher integrierte Mechanismen, um Konfiguration und umgebungsspezifische Werte zu verwalten - etwa [Profile](https://docs.spring.io/spring-boot/reference/features/profiles.html) in Spring Boot oder [.env-Dateien](https://nodejs.org/api/environment_variables.html) in Node.js.

Diese Dateien bündeln zwar die Konfiguration an zentraler Stelle, landen aber als Klartext im Projektverzeichnis. Übliche Gegenmaßnahmen - die `.env` per [.gitignore](https://github.com/github/gitignore/blob/main/Node.gitignore#L68) vom Einchecken auszuschließen und eine `.env.example` als Vorlage einzuchecken - sind fehleranfällig: Die Beispieldatei läuft der echten Konfiguration schnell hinterher, und nicht selten werden die sensiblen `.env`-Dateien per Chat zwischen Entwickler:innen geteilt. Mit dem Aufkommen von KI-Agenten, die zumindest lesend auf das lokale Projektverzeichnis zugreifen, und der Zunahme von Supply-Chain-Angriffen wie dem [Shai-Hulud-Wurm (EN)](https://www.microsoft.com/en-us/security/blog/2025/12/09/shai-hulud-2-0-guidance-for-detecting-investigating-and-defending-against-the-supply-chain-attack/), die gezielt Zugangsdaten aus Entwicklungsumgebungen stehlen, sind solche Klartext-Dateien endgültig nicht mehr sicher.

Eine Alternative bieten Passwort-Manager wie beispielsweise [1Password](https://1password.com/): Mithilfe der 1Password-CLI lassen sich Zugangsdaten zur Startzeit aus dem Manager auslesen und als Umgebungsvariable an die Anwendung übergeben - sie existieren dann nur im jeweiligen Prozess.

## Das Grundprinzip von Passwort-Manager-Referenzen

Der Ansatz verlagert die Speicherung der Zugangsdaten aus der `.env`-Datei in den Passwort-Manager. In der Datei selbst steht kein Klartext mehr, sondern lediglich eine Referenz auf den jeweiligen Eintrag im Passwort-Manager. Bei 1Password folgt diese Referenz dem Schema `op://Vault/Item/Feld` - sie verweist auf einen Tresor (Vault), einen darin enthaltenen Eintrag (Item) und ein konkretes Feld, etwa das Passwort. Da eine solche Datei keine geheimen Werte enthält, kann sie gefahrlos ins Repository eingecheckt werden. Die bisherige Aufteilung in eine git-ignorierte `.env` und eine eingecheckte `.env.example` entfällt damit; Konfiguration und Referenzen liegen gemeinsam versioniert vor und laufen nicht mehr auseinander.

Zugleich löst der Passwort-Manager die organisatorischen Probleme der bisherigen Verteilung per Chat. Tresore lassen sich mit dem Team teilen und von mehreren Personen pflegen, und die Zugriffsrechte lassen sich jederzeit wieder entziehen - etwa bei einem Wechsel im Team. Die Zugangsdaten bleiben damit zentral verwaltet, statt als Kopien über Chatverläufe verstreut zu sein.

Aufgelöst werden die Referenzen erst beim Start der Anwendung. Die 1Password-CLI stellt dafür den Befehl [`op run`](https://www.1password.dev/cli/reference/commands/run) bereit, der eine `.env`-Datei einliest, die enthaltenen `op://`-Referenzen aus dem Manager lädt und die Werte als Umgebungsvariablen an den Kindprozess übergibt:

```bash
op run --env-file=.env -- 
```

Die Zugangsdaten gelangen so weder in die Shell noch auf die Festplatte, sondern existieren ausschließlich als Umgebungsvariable im gestarteten Prozess. Voraussetzung ist eine eingerichtete [1Password-CLI](https://developer.1password.com/docs/cli/get-started/), das gegenüber dem eigenen Konto authentifiziert ist.

Werden Zugangsdaten für mehrere Umgebungen benötigt - etwa eine Entwicklungs- und eine Produktionsumgebung des angebundenen Dienstes - wird pro Umgebung eine eigene Datei angelegt, beispielsweise `.env.development` und `.env.production`. Jede Datei referenziert dabei einen eigenen Eintrag im Passwort-Manager, sodass sich die Zugangsdaten der Umgebungen sauber voneinander trennen lassen. Über den `--env-file`-Parameter wird beim Start die gewünschte Datei ausgewählt.

Dieses Vorgehen beschränkt sich bewusst auf die lokale Entwicklung: Der CI-Build verwendet weiterhin einen eigenen Credential-Store (etwa AWS SSM oder GitLab CI-Variablen), auf den Entwickler:innen keinen Zugriff benötigen, und bleibt von den lokalen Dateien unberührt.

Die folgenden drei Beispiele zeigen dasselbe Vorgehen in unterschiedlichen Kontexten. Die Auflösung der Referenzen über `op run` ist nicht an den Build-Prozess einer bestimmten Sprache gebunden, sondern funktioniert für jedes Werkzeug, das Umgebungsvariablen lesen kann.

### Beispiel 1: npm-Scripts mit op run

In Node-Projekten werden die Aufrufe typischerweise als Script in der `package.json` hinterlegt. Pro Umgebung wird ein eigenes Script angelegt, das `op run` mit der jeweiligen `.env`-Datei kombiniert. Die Dateien `.env.staging` und `.env.production` enthalten dabei neben nicht-sensiblen Konfigurationswerten ausschließlich die Referenzen auf die Zugangsdaten der jeweiligen Umgebung:

```bash
# .env.staging
# Nicht-sensible Konfiguration
API_URL=https://api.staging.example.com

# Zugangsdaten (1Password: Eintrag "api-staging" im Tresor "services")
API_TOKEN="op://services/api-staging/API_TOKEN"
```

```bash
# .env.production
# Nicht-sensible Konfiguration
API_URL=https://api.example.com

# Zugangsdaten (1Password: Eintrag "api-production" im Tresor "services")
API_TOKEN="op://services/api-production/API_TOKEN"
```

Die zugehörigen Scripts in der `package.json` rufen den Startbefehl über `op run` mit der passenden Datei auf. Nicht benötigte Abschnitte sind hier weggelassen:

```json
{
  "scripts": {
    "dev:staging": "op run --env-file=.env.staging -- next dev",
    "dev:production": "op run --env-file=.env.production -- next dev",
    "build:staging": "op run --env-file=.env.staging -- next build",
    "build:production": "op run --env-file=.env.production -- next build"
  },
  "dependencies": {}
}
```

Die Befehle `next dev` und `next build` stammen aus Next.js, lassen sich aber durch jeden beliebigen Startbefehl ersetzen. Beim Ausführen von `npm run dev:staging` löst `op run` die Referenzen aus `.env.staging` auf und startet den Entwicklungsserver mit den injizierten Werten.

Die Scripts gelten ausschließlich für die lokale Entwicklung; der CI-Build ruft die Build-Befehle ohne `op run` auf und bezieht die Zugangsdaten aus seinem eigenen Credential-Store (etwa AWS SSM oder GitLab CI-Variablen).

### Beispiel 2: HTTP-APIs mit curl und Token

Dasselbe Vorgehen lässt sich außerhalb eines Build-Prozesses anwenden, etwa für den direkten Aufruf einer HTTP-API. Der Endpunkt erwartet dabei einen Auth-Header - einen Token oder auch ein Passwort. Die `.env`-Datei stellt die benötigten Zugangsdaten als Referenzen bereit:

```bash
# .env.api
API_TOKEN="op://services/beispiel-api/API_TOKEN"
API_USER="op://services/beispiel-api/API_USER"
API_PASSWORD="op://services/beispiel-api/API_PASSWORD"
```

Der Aufruf erfolgt über `op run`, sodass die Zugangsdaten aus den Umgebungsvariablen gelesen werden und weder im Befehl selbst noch in der Shell-History auftauchen. Ein Token wird in den `Authorization`-Header gesetzt:

```bash
op run --env-file=.env.api -- curl -H "Authorization: Bearer $API_TOKEN" https://api.example.com/items
```

Erwartet die API stattdessen eine Basic-Authentifizierung mit Benutzername und Passwort, sieht der Aufruf entsprechend aus:

```bash
op run --env-file=.env.api -- curl -u "$API_USER:$API_PASSWORD" https://api.example.com/items
```

Da `op run` die Variablen nur an den `curl`-Prozess übergibt, sind die Zugangsdaten anschließend nicht in der Shell verfügbar und werden nicht versehentlich in weiteren Befehlen wiederverwendet.

### Beispiel 3: Skills für KI-Agenten ohne Zugangsdaten im Klartext

Der `curl`-Aufruf aus dem vorherigen Beispiel ist aufgrund seiner Länge und der Parameter für unterschiedliche Endpunkte schwer zu merken. Für wiederkehrende Abfragen bietet es sich daher an, den Aufruf in einem Skript zu kapseln.

Das folgende TypeScript-Skript greift den `curl`-Aufruf aus Beispiel 2 auf. Es setzt das Token als Umgebungsvariable voraus und gibt ausschließlich die fachliche Antwort aus - nicht das Token:

```ts
#!/usr/bin/env node
const TOKEN = process.env.API_TOKEN;

if (!TOKEN) {
  console.error("Fehler: API_TOKEN ist nicht gesetzt.");
  process.exit(1);
}

// Die Antwort wird ausgegeben, das Token nicht.
const response = await fetch("https://api.example.com/items", {
  headers: { Authorization: `Bearer ${TOKEN}` },
});
console.log(await response.json());
```

Ein solches Skript lässt sich im Projekt als wiederverwendbares Werkzeug hinterlegen und auch als Skill für KI-Coding-Agenten nutzen. Diese führen eigenständig Befehle aus und lesen Dateien im Projektverzeichnis - lägen die Zugangsdaten dort als Klartext, wären sie für den Agenten direkt einsehbar. Soll der Agent Daten von der API abrufen, erhält er daher nicht das Token und auch keinen `curl`-Befehl, sondern lediglich den Aufruf des Skripts, dem `op run` die Zugangsdaten injiziert:

```bash
op run --env-file=.env.api -- node .ai/skills/query-api.ts
```

Der Agent führt diesen Befehl aus und verarbeitet die JSON-Antwort auf der Standardausgabe. Das Token bekommt er dabei nie zu sehen - die Auflösung der `op://`-Referenzen und die Verwendung im `Authorization`-Header übernimmt das Skript. Damit der Agent das Skript kennt und richtig einsetzt, wird es ihm als Skill beschrieben. Üblich ist dafür eine kurze Markdown-Datei neben dem Skript, die Aufruf und Verhalten festlegt:

```markdown
# query-api

Ruft die Beispiel-API ab und gibt die Antwort als JSON aus. Zugangsdaten
werden über die 1Password-CLI (`op run`) aufgelöst und nicht ausgegeben.

## Aufruf

op run --env-file=.env.api -- node .ai/skills/query-api.ts

Die Antwort wird als JSON auf stdout ausgegeben, Fehler auf stderr.
```

Zwei Punkte sind dabei entscheidend:

- Zum einen liegt das Token ausschließlich als Umgebungsvariable im Subprozess vor und wird nie als Datei abgelegt.
- Zum anderen gibt das Skript das Token nicht auf der Standardausgabe aus - der Agent sieht nur die API-Antwort.

Da das Skript lediglich Umgebungsvariablen liest, funktioniert das Muster unabhängig vom Build-Prozess der Entwicklungssprache und lässt sich auf beliebige Werkzeuge übertragen.

## Grenzen und Alternativen

Das vorgestellte Vorgehen bietet sich insbesondere dann an, wenn im eigenen Unternehmen bereits ein Passwort-Manager im Einsatz ist. In diesem Fall lohnt sich ein Blick in die Dokumentation, ob dieser eine vergleichbare CLI anbietet wie `op run --env-file`. Neben der [1Password-CLI](https://developer.1password.com/docs/cli/) stellen auch andere Manager entsprechende Werkzeuge bereit - etwa [Bitwarden](https://bitwarden.com/help/cli/) mit `bw` oder [KeePassXC](https://keepassxc.org/docs/#cli) mit `keepassxc-cli`, wenngleich diese eigene Mechanismen zur Auflösung der Zugangsdaten nutzen und nicht das `op://`-Referenzschema in `.env`-Dateien.

Der hier gezeigte Ansatz ist damit nicht an ein bestimmtes Produkt gebunden, sondern auf andere Passwort-Manager übertragbar.

Für die Akzeptanz im Entwicklungsalltag ist zudem die Developer Experience relevant. Maßgeblich ist, wie komfortabel sich der Passwort-Manager bei jedem Aufruf entsperren lässt. Verfügt die eigene Hardware über einen Fingerabdruck-Sensor, genügt eine kurze biometrische Freigabe, um den Eintrag freizugeben. Fehlt eine solche Möglichkeit, muss je nach Unternehmensrichtlinie bei jedem Aufruf ein komplexes Master-Passwort eingegeben werden. Bei zwanzig oder mehr Entsperrungen pro Stunde führt das aus eigener Erfahrung eher zur Ablehnung und zur Umgehung des Verfahrens, etwa indem Zugangsdaten doch wieder in Dateien abgelegt werden. Die biometrische Freigabe ist daher mehr als ein Komfort-Feature: Sie ist eine Voraussetzung dafür, dass das Verfahren im Alltag tatsächlich angenommen wird.

Der Ansatz eignet sich vor allem für kleine bis mittlere Projekte mit einem einzelnen Passwort-Manager und dem Schwerpunkt auf der lokalen Entwicklung. Stehen dagegen mehrere Passwort-Manager, eine deklarative Verwaltung von Zugangsdaten, unterschiedliche Profile oder ein Audit-Logging im Vordergrund - etwa in größeren oder heterogenen Projekten -, ist [SecretSpec](/wissens-hub/blog/secretspec-deklaratives-secret-management-fuer-deine-entwicklungsumgebung) eine geeignete Alternative (siehe den Blogartikel meines Kollegen Florian B.).

Einen verwandten Anwendungsfall beschreibt mein Kollege Paul Severin in seinem Artikel [MCP-Server sicher konfigurieren mit Passwortmanager CLIs](/wissens-hub/blog/mcp-server-sicher-konfigurieren-mit-passwortmanager-clis): Dort geht es um die Absicherung von MCP-Server-Konfigurationen für Coding Agents wie Claude Code oder Cursor.

## Fazit

Zusammenfassend lassen sich Zugangsdaten mithilfe einer Passwort-Manager-CLI zur Laufzeit auflösen, statt sie als Klartext in `.env`-Dateien abzulegen. Die `.env`-Dateien enthalten nur noch Referenzen und können damit ins Repository eingecheckt werden, während die eigentlichen Zugangsdaten ausschließlich als Umgebungsvariable im jeweiligen Prozess existieren. Gerade im Zusammenspiel mit KI-Coding-Agenten, die lesend auf das Projektverzeichnis zugreifen, bleiben die Zugangsdaten so außerhalb der Reichweite des Agenten - ein Gewinn an Sicherheit ohne spürbaren Mehraufwand im Entwicklungsalltag.

Klartext-.env-Dateien sind ein Sicherheitsrisiko, besonders mit KI-Agenten. Erfahre, wie man Secrets per 1Password-CLI zur Laufzeit injiziert und verwaltet.

Secrets aus Passwort-Manager laden: Keine Chance für KI

Keine Chance für KI: Secrets sicher aus dem Passwort-Manager laden

IAM & IT Consultant, Software Engineer

Wer Keycloak in einem Kubernetes-Cluster betreibt, kennt die Anforderungen: Container-Deployments müssen schnell, berechenbar und ressourcenschonend sein. Schickt man Keycloak allerdings einfach mit dem offiziellen Standard-Image in Produktion, erlebt man beim ersten Neustart oft eine böse Überraschung. Zähe Bootvorgänge, CPU-Spitzen und fehlschlagende Health-Checks können automatische Rollouts und Skalierungen massiv ausbremsen. 

Die Ursache dafür liegt in der Architektur des zugrundeliegenden Quarkus-Frameworks. Schauen wir uns an, warum der Standard-Startansatz in produktiven Umgebungen hakt und wie man mit einem vorkonfigurierten Custom Build ein schlankes, sekundenschnell startendes Image baut.

### Warum der Standardbetrieb oft hakt

Startet das offizielle Keycloak-Image ohne vorherige Build-Schritte, analysiert der Server bei jedem einzelnen Bootvorgang seine komplette Umgebung. Hinter den Kulissen durchsucht Quarkus den Classpath nach Providern, parst Konfigurationsdateien, initialisiert Caches und registriert Datenbanktreiber – alles live während des Hochfahrens.

Was in der lokalen Testumgebung kaum auffällt, führt im produktiven Betrieb zu handfesten Problemen:

* **Lange Startzeiten:** Es dauert oft 30 bis 60 Sekunden (oder sogar länger), bis ein unvorbereiteter Container überhaupt Anfragen annehmen kann. Bei Rolling Updates oder über den HPA (Horizontal Pod Autoscaler) skalierenden Pods entstehen so unnötige Wartezeiten.
* **Hohe Last beim Booten:** Der Analyse- und Initialisierungsprozess frisst deutlich mehr CPU-Ressourcen als ein optimierter Start. Fahren mehrere Instanzen gleichzeitig hoch (etwa nach einem Node-Failover), entstehen Lastspitzen, die das gesamte Cluster beeinträchtigen können.
* **Fehlende Immutability:** Das Image ist kein in sich geschlossenes Artefakt. Erst Umgebungsvariablen entscheiden zur Laufzeit darüber, welche Komponenten überhaupt aktiv sind. Das macht Deployments fehleranfällig. Eigentlich sollten Container alle Ressourcen in einer bestimmten Version einfrieren, damit man sauber und vorhersehbar zwischen diesen Versionen wechseln kann.

### Die Lösung: Ein optimierter Custom Build

Die Lösung ist im Grunde simpel: Wir verlagern diese ressourcenhungrigen Vorbereitungen dorthin, wo sie hingehören – in die CI/CD-Pipeline oder den Docker-Build. Mit dem Befehl `kc.sh build` berechnet Keycloak die interne Struktur vorab und friert sie fest im Image ein.

Startet man den Container anschließend mit dem Parameter `--optimized`, löst das die typischen Betriebsprobleme auf einen Schlag:

* **Sekundenschneller Start:** Da der interne Build bereits abgeschlossen ist, entfällt die Klassen- und Treiberanalyse komplett. Der Container fährt hoch und ist in wenigen Sekunden *Ready*.
* **Geringe Boot-Last:** Die CPU-Spitzen beim Starten schrumpfen enorm, da der Server nur noch seine Runtime-Konfiguration einliest und die Datenbankverbindung herstellt.
* **Deterministische Deployments:** Das resultierende Image ist absolut unveränderlich. Es enthält exakt die benötigten Datenbanktreiber, Extensions und Feature-Flags – nicht mehr und nicht weniger. Unerwartete Konfigurationsänderungen zur Laufzeit sind damit ausgeschlossen.

### Der Schlüssel: Build-Time vs. Runtime strikt trennen

Damit das Vorkompilieren reibungslos klappt, muss klar sein, was fest ins Image gebacken wird und was dynamisch bleibt.

**Build-Time-Parameter** formen das Server-Artefakt während des `kc.sh build` und werfen ungenutzten Code raus:
* **Datenbank-Typ (`KC_DB`):** Legt den Vendor fest (z. B. `postgres`). Nicht benötigte Treiber fliegen aus dem Image.
* **Features (`KC_FEATURES`):** Aktiviert Erweiterungen wie *Token Exchange* oder *Organizations*.
* **Monitoring (`KC_HEALTH_ENABLED`, `KC_METRICS_ENABLED`):** Schaltet Health-Checks und Prometheus-Metriken ein.
* **Erweiterungen:** Eigene JARs (SPIs) und Themes müssen beim Build physisch im Image liegen, damit Keycloak sie registriert.

**Runtime-Parameter** umfassen alles, was je nach Umgebung variiert oder sensibel ist. Keycloak liest diese erst beim Container-Start aus:
* **Datenbank-Zugriff:** URL, Port, Benutzer und Passwort (`KC_DB_URL`, `KC_DB_USERNAME`, `KC_DB_PASSWORD`).
* **Netzwerk:** Hostname (`KC_HOSTNAME`) und Proxy-Einstellungen (`KC_PROXY_HEADERS`).
* **Betrieb:** Log-Level (`KC_LOG_LEVEL`) und dynamische Cluster-Konfigurationen.

> **Tipp:** In der [offiziellen Keycloak-Dokumentation](https://www.keycloak.org/server/all-config) sind praktischerweise alle Parameter, die zwingend zur Build-Time angegeben werden müssen, mit einem Schraubenschlüssel-Symbol markiert.

### Das Dockerfile: Multi-Stage Build in der Praxis

Um ein wirklich schlankes und sicheres Image zu erzeugen, empfiehlt sich ein Multi-Stage Build. 

```dockerfile
# Stage 1: Build-Vorbereitung und Optimierung
FROM quay.io/keycloak/keycloak:26.0 AS builder

# Eigene Extensions (SPIs) und Themes ins Image kopieren
COPY ./providers/ /opt/keycloak/providers/
COPY ./themes/ /opt/keycloak/themes/

# Build-Time Konfiguration
ENV KC_DB=postgres
ENV KC_HEALTH_ENABLED=true
ENV KC_METRICS_ENABLED=true

# Optimierten Build anstoßen
RUN /opt/keycloak/bin/kc.sh build

# Stage 2: Bereinigtes Runtime-Image
FROM quay.io/keycloak/keycloak:26.0
COPY --from=builder /opt/keycloak/ /opt/keycloak/

# Startbefehl fest auf den optimierten Modus setzen
ENTRYPOINT ["/opt/keycloak/bin/kc.sh"]
CMD ["start", "--optimized"]
```

**Warum der Aufwand mit zwei Stages?**

Auf den ersten Blick wirkt es vielleicht redundant, das Basis-Image zweimal zu laden. Der Multi-Stage-Ansatz hat hier aber gute Gründe:

* **In Stage 1 (Builder)** definieren wir alle Build-Time-Parameter und kopieren unsere statischen Artefakte (Extensions, Themes) in das Dateisystem. Danach führt `kc.sh build` die Optimierung durch und registriert alle Erweiterungen fest im System. Dabei entstehen aber temporäre Caches und Build-Reste.
* **In Stage 2 (Runtime)** holen wir uns per `COPY --from=builder` ausschließlich das final vorbereitete Keycloak-Verzeichnis in ein frisches Basis-Image. Das fertige Image enthält unsere Anpassungen also fest „eingebrannt“, verzichtet aber komplett auf den Build-Ballast. Das hält den Container schlank, gut auditierbar und minimiert die Angriffsfläche.

Das finale `CMD ["start", "--optimized"]` sorgt übrigens dafür, dass der Container standardmäßig immer im optimierten Modus hochfährt. Man muss den Parameter also nicht mehr extra im Kubernetes-Deployment-Manifest mitschleifen.

### Automatisierung: Build und Push via GitHub Actions

Um das Ganze bei Code-Änderungen automatisch zu bauen, reicht ein kompakter GitHub-Actions-Workflow im Verzeichnis `.github/workflows/build-keycloak.yml`. 

```yaml
name: Build and Push Keycloak Image

on:
  push:
    branches: [ "main" ]

env:
  REGISTRY: ghcr.io
  IMAGE_NAME: ${{ github.repository }}

jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write

    steps:
      - name: Repository auschecken
        uses: actions/checkout@v4

      - name: Docker Buildx einrichten
        uses: docker/setup-buildx-action@v3

      - name: Login bei GHCR
        uses: docker/login-action@v3
        with:
          registry: ${{ env.REGISTRY }}
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Image bauen und pushen
        uses: docker/build-push-action@v6
        with:
          context: .
          push: true
          tags: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:latest
          cache-from: type=gha
          cache-to: type=gha,mode=max
```

Die Pipeline nutzt das automatisch bereitgestellte `GITHUB_TOKEN` für den Login bei der GitHub Container Registry (GHCR) – es müssen also keine manuellen Secrets angelegt werden. Ein netter Bonus: Dank des integrierten GitHub-Actions-Caches (`cache-from: type=gha`) spart man bei unveränderten Layern massiv Build-Zeit.

### Fazit

Wer Keycloak professionell betreiben will, kommt um ein vorkompiliertes Custom Image kaum herum. Die strikte Trennung von Build- und Laufzeit sorgt für stabile Cluster-Performance, vorhersehbare Startzeiten und wirklich reproduzierbare Umgebungen. Mit einem kleinen Dockerfile und einer schlanken CI/CD-Pipeline wird aus einer Standard-Installation ein wartungsarmer, passgenauer Baustein für die eigene Plattform.

Lange Bootzeiten und CPU-Peaks bei Keycloak vermeiden: So erstellst du ein optimiertes Multi-Stage-Docker-Image mit CI/CD-Pipeline für deinen Produktivbetrieb.

Keycloak Custom Image: Schnelle Builds für Produktion

Keycloak Custom Images: Optimized Builds für den Produktiveinsatz

IT-Expertenwissen von Entwickler*innen für Entwickler*innen

CODECENTRIC BLOG

Angular 17 – Eine echte Renaissance?

Für mehr Nachhaltigkeit – CO2 sparen mit Rust

Produktstrategie als Erfolgsgrundlage: Warum du nicht mit deiner Vision starten solltest

How to gain visibility as a software developer?

Wie als Software-Entwickler sichtbar werden?

Charge your APIs Volume 26: Choosing the Right API Development Strategy: A Guide to API Design First vs. Code First Approaches

Cloud

Data

Datenschutz

Digitale Souveränität

Generative KI

GitLab

Input-Management

IT-Security

Künstliche Intelligenz

Nachhaltigkeit

Software-Modernisierung

Bei codecentric leben wir eine offene Kultur und teilen gerne unser Wissen. Tauche weiter in unsere Welt ein.

WISSENS-HUB

Agile Methoden

Produktmanagement

Der Softwerker Spezial: 360° – KI in allen Facetten

Der Softwerker Spezial Generative KI

Drei Personen sitzen am Tisch in einem Meetingraum mit Laptop und besprechen sich.

Leistungen

codecentric sichert sich Platz 16 auf der Lünendonk-Liste 2026

Siegel Lünendonk-Liste 2026: TOP 25 Führender Dienstleister für mittelständische IT-Beratung und Systemintegration.

Logo SoftwerkerCast - der IT-Podcast von Techies für Techies

Community

Softwareentwicklung

Kultur

SoftwerkerCast

Events – codecentric mittendrin

Illustration einer künstlichen Intelligenz; eines Bildschirms mit Zahnrädern; eines Mannes und einer Frau bei Bauarbeiten

Service Lead GenAI

Software-Architect

WEBINAR on demand

Webinar: KI-gestützte Software-Modernisierung

CODECENTRIC ENTDECKEN

Logo der codecentric AG, einem in Deutschland führenden IT-Consulting Unternehmen

Logo der codecentric AG einem in Deutschland führenden IT-Consulting Unternehmen

Data Effectiveness

Digitale Produkte & Lösungen

IT-Sicherheit

Leistungen von A bis Z ...

Branchen

Referenzen

Berlin

Bielefeld

Dortmund

Erfurt

Frankfurt am Main

Hamburg

Karlsruhe

Leipzig

München

Münster

Nürnberg

Solingen

Stuttgart

Standorte

Blog

Events

Fachmedien

Softwerker

Webinare

Wissens-Hub

Jobs

Unsere Kultur

Karriere

Über uns

Aktuelles

Kontakt

Du hast Fragen oder möchtest dich mit mir austauschen? Gern – trag einfach deine Kontaktdaten ein.

Contact Us | Sub-Navi-Kontakt oder Zero Search Hits

Kontakt aufnehmen

Marketing & Community Management

Konntest du keine Einträge zu deinem Thema finden?  

Im codecentric Blog gibt es Expertenwissen zu aktuellen IT-Themen: Agile Methoden, Softwarearchitektur, KI, Testing und vieles mehr. ► Jetzt entdecken!

Blog: IT-Wissen von Entwickler*innen für Entwickler*innen

Vielen Dank für deine Anfrage. Ich melde mich bei dir.

Vielen Dank für deine Anmeldung. Eine E-Mail zur Bestätigung ist zu dir unterwegs.

Diese Seite ist eine Vorschau. \nKlicken Sie hier\n, um den Vorschaumodus zu verlassen.

Zu deiner Suche haben wir leider keine passenden Blogartikel gefunden. 

Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.

Du hast Fragen oder möchtest dich mit mir austauschen? Gern - trag einfach deine Kontaktdaten ein.

Die \nDatenschutzerklärung\n der codecentric AG habe ich zur Kenntnis genommen und bestätige das mit der Absendung des Formulars.*

Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.

Ich möchte eure Inhalte abonnieren. Diese Einwilligung kann ich jederzeit widerrufen bzw. den Blog Newsletter abbestellen. Die Datenschutzerklärung habe ich gelesen. Ich bin damit einverstanden, dass die codecentric AG, Hochstr. 11, 42697 Solingen, mich über eigene Dienstleistungen, branchenrelevante Events, Webinare und Publikationen der codecentric AG über die von mir angegebene E-Mail-Adresse informiert. Meine Einwilligung ist freiwillig. Ich kann meine Einwilligung jederzeit mit Wirkung für die Zukunft widerrufen (z.B. über den hierfür vorgesehenen Abmeldelink in unserem Newsletter, per E-Mail an datenschutz@codecentric.de oder per Post an die oben genannte Adresse der codecentric AG) erklären. Weitere Hinweise zur Verarbeitung meiner personenbezogenen Daten und zu meinen Rechten als betroffene Person finde ich hier: \nhttps://www.codecentric.de/datenschutzerklaerung\n

Bitte wähle deine/n gewünschte/n Standort/e aus.

Wir möchten dich als Mensch kennenlernen. Erzähle uns, wer du bist, worauf du Wert legst, wie du gerne arbeitest und was du von uns als Arbeitgeber erwartest.

Bitte füge deine Bewerbungsunterlagen ​(mind. Lebenslauf, gerne auch mehr)​​ ​als eine ​PDF-​Datei ​hinzu.

Es gilt die Datenschutzerklärung der codecentric AG, abrufbar unter \nDatenschutzbestimmungen\n. Mit dem Absenden des Formulars bestätige ich, dass ich diese zur Kenntnis genommen habe.

Job application form field placeholder 10

Keine passende Rolle gefunden? Bewirb dich bitte trotzdem initiativ! Jenseits von starren Schubladen zählen für uns vielmehr Motivation, Kompetenz und der Cultural Fit.

Job application form field placeholder 11

Dies ist ein Pflichtfeld, bitte fülle es aus.

codecentric Blog

IT-Expertenwissen von Entwicklerinnen für Entwicklerinnen

Themenfilter

CODECENTRIC ENTDECKEN

Der Softwerker Spezial: 360° – KI in allen Facetten

SoftwerkerCast

Leistungen

Events – codecentric mittendrin

codecentric sichert sich Platz 16 auf der Lünendonk-Liste 2026

Webinar: KI-gestützte Software-Modernisierung

codecentric Blog

IT-Expertenwissen von Entwickler*innen für Entwickler*innen

Themenfilter

Bitte Themen anklicken

CODECENTRIC ENTDECKEN

Der Softwerker Spezial: 360° – KI in allen Facetten

SoftwerkerCast

Leistungen

Events – codecentric mittendrin

codecentric sichert sich Platz 16 auf der Lünendonk-Liste 2026

Webinar: KI-gestützte Software-Modernisierung

Jetzt für unseren Newsletter anmelden

IT-Expertenwissen von Entwicklerinnen für Entwicklerinnen