Glossar

Begriffsdefinitionen für geneigte Leser:innen, die nicht aus dem Coding-Alltag kommen. Korrekturen und bessere Erklärungen jederzeit willkommen.

LLM (Large Language Model)

"Large Language Model" — das technische Wort für das, was umgangssprachlich "AI" oder "KI" heißt. Ein Sprachmodell, trainiert auf großen Mengen Text, das auf hohem Niveau das wahrscheinlichste nächste Wort (genauer: Token) vorhersagt. Beispiele: Claude (Anthropic), GPT (OpenAI), Mistral, Llama. Es gibt einen immer größer werdenden Zoo an LLM's für verschiedenste Aufgaben wie Sprachverstehen, Inhalte zusammenfassen, Code generieren, übersetzen und Schlussfolgern in vielen Domänen. Die Entwicklung ist rasant.

Pattern-Completion

Der Mechanismus, mit dem ein LLM "denkt": Als Reaktion auf eine Eingabe sagt es das wahrscheinlichste nächste Token vorher, dann das nächste, dann das nächste. Keine Reflexion, kein Wissen, keine Wahrheitsprüfung — nur statistische Mustervervollständigung auf Basis der Trainingsdaten. Dies Erklärt, warum LLMs flüssige, plausible Antworten geben können, ohne ein Thema zu verstehen. Pattern-Completion ist auch der Grund für Halluzinationen — wenn das wahrscheinlichste nächste Token nicht das richtige ist, sondern das passendste.

Halluzination

Der Standardbegriff für eine falsche, aber selbstbewusst formulierte Aussage eines LLM. Selbstbewusst ist hier der Knackpunkt: das Modell hat keine eingebaute Möglichkeit, "ich weiß es nicht" zu erkennen — es sagt das wahrscheinlichste Token, auch wenn die Antwort frei erfunden ist. Halluzinationen eines LLM's zu erkennen wird vermutlich eine der Schlüsselkompetenzen für Anwender.

Token

Die kleinste Einheit, in der ein LLM Text verarbeitet — meist ein Wortbestandteil, manchmal ein ganzes Wort, manchmal nur ein Zeichen. Modelle haben Kosten pro Token und ein maximales Token-Budget pro Anfrage.

Kontext-Fenster (Context Window)

Die maximale Menge an Tokens, die ein LLM in einer Anfrage berücksichtigen kann — Eingabe und Antwort zusammen. Aktuelle Modelle haben Fenster zwischen ca. 8.000 und 1.000.000 Tokens. Was über das Fenster hinausgeht, wird nicht gesehen — oder das Tool muss älteres Material zusammenfassen (siehe Compaction). Es Definiert die effektive Aufmerksamkeit eines Agenten in einer Sitzung. Wichtig: Größere Fenster lösen Sicherheitsprobleme nicht — sie skalieren sie. Mehr Material im Fenster heißt mehr ungeprüfter Input.

Slop

Umgangssprachlich für minderwertigen, generierten Output von LLMs — plausibel klingender, aber inhaltlich leerer oder fehlerhafter Text. Verwandt mit "Bullshit" im philosophischen Sinn DAs hilft bei der mentalen Sortierung: ein Teil dessen, was ein LLM produziert, ist Slop. Nicht vom Modell böswillig, sondern strukturell — Pattern-Completion erzeugt manchmal eben nichts Substanzielles.

Repository (Repo)

Ein Ordner, in dem ein Projekt lebt — plus eine vollständige Geschichte aller Änderungen an diesem Ordner. Verwaltet von einem Versionsverwaltungs-Werkzeug (in der Praxis fast immer Git). Ein Repo erlaubt es, jederzeit zu sehen wer was wann warum geändert hat, und jeden früheren Stand wiederherzustellen. Volle und elegante Nachvollziehbarkeit. Es schützt nicht davor, dass etwas Schlechtes hineingeschrieben wird ABER danach kann man zurückrollen.

Branch

Ein paralleler Arbeits-Strang im Repository. Statt direkt am Hauptzweig (main) zu arbeiten, legt man pro Aufgabe einen eigenen Branch an, baut dort, und führt ihn erst zusammen ("merge"), wenn die Änderung fertig und geprüft ist.

Wofür gut. Risiko-Isolation. Wenn ein Branch sich als schlecht herausstellt, wird er einfach verworfen — der Hauptzweig bleibt unberührt. Ein Agent darf in seinem Branch experimentieren, ohne dass die Hauptlinie kaputt geht.

Commit

Eine einzelne, namensgegebene Änderung am Repository — vergleichbar mit einem Speicherpunkt mit Notiz dran ("Das wurde geändert"). Ein gutes Commit ist klein, fokussiert, und in einem Satz beschreibbar. Macht die Geschichte deines Werks lesbar, ermöglicht einfaches Rollback einzelner Schritte, klare Zurechenbarkeit.

Diff

Die Differenz zwischen zwei Ständen einer Datei oder eines Repositories — typischerweise dargestellt als zeilenweise Anzeige: rot weggenommen, grün hinzugefügt. Der Diff ist das, was man liest, wenn man eine Änderung bewerten will. Gut für die Konzentration der Aufmerksamkeit auf das, was sich tatsächlich verändert hat — nicht auf die ganze Datei.

Linter

Ein Werkzeug, das Code automatisch nach bekannten schlechten Mustern absucht — Stilfehler, riskante Konstrukte, häufige Bug-Quellen. Der Linter führt den Code nicht aus, sondern liest ihn und meldet Treffer.

Wofür gut. Schneller, billiger Filter gegen die häufigsten Patzer. Läuft in Sekunden, oft direkt im Editor. Was er nicht leistet. Er findet, was vorher als Muster definiert wurde. Logikfehler, schlecht durchdachte Architektur oder subtile Sicherheitslücken sind außerhalb seiner Reichweite. Beispiele. Für Python: ruff, flake8, pylint. Für JavaScript/TypeScript: eslint. Eine spezielle Variante für Sicherheit: bandit (Python).

Type-Checker

Ein Werkzeug, das prüft, ob die Daten-Typen in einem Programm zueinanderpassen — z.B. ob eine Funktion, die eine Zahl erwartet, nicht versehentlich mit einem Text aufgerufen wird. Der Type-Checker führt den Code ebenfalls nicht aus, er analysiert ihn statisch.

Wofür gut. Fängt eine ganze Klasse von Fehlern, die sonst erst zur Laufzeit auftauchen würden — oft genau dann, wenn ein Nutzer das Problem auslöst. Macht Refactorings (große Umbauten) deutlich sicherer. Was er nicht leistet. Er sagt nichts darüber aus, was der Code macht — nur darüber, dass die Bauteile zueinanderpassen. Beispiele. Für Python: mypy, pyright. In Sprachen mit Typen "ab Werk" (Rust, Go, TypeScript) ist die Prüfung Teil des Übersetzers selbst.

Tests

Code, der anderen Code prüft. Eine Test-Suite ist eine Sammlung kleiner Programme, die jeweils eine konkrete Erwartung formulieren ("wenn ich Funktion X mit Y aufrufe, soll Z herauskommen") und automatisch melden, ob die Erwartung erfüllt ist.

Warum überhaupt — und warum so oft. Drei Gründe, die unabhängig voneinander tragen:

1. Baseline schaffen.
2. Selbstkontrolle für den Agenten. Wenn ein Agent behauptet, Feature X gebaut zu haben, und der Test für X immer noch rot ist, dann hat dein Agent sie Situation nicht richtig erfasst.
3. Schutz vor blinder Zuversicht. LLMs sind oft zuversichtlich, wo sie es nicht sein sollten. Ein laufender Test ist ein Stück Wirklichkeit, das nicht verhandelt wird.

Test-Arten, die im Sicherheitskontext relevant sind:

• Fragt mal euren Coding Agenten spezifisch auf euer projekt...

Was Tests nicht leisten. Sie prüfen nur, was jemand zu prüfen vorgesehen hat. Beispiele. Für Python: pytest (Standard), hypothesis (Property-based), atheris (Fuzz).

Pre-Commit-Hooks

Kleine Programme, die automatisch laufen, bevor ein Commit überhaupt zustande kommen darf. Wenn einer der Hooks rot ist, wird der Commit abgelehnt — der Code muss erst korrigiert werden.

Wofür gut. Verhindert, dass schlechter, riskanter oder verbotener Code überhaupt in die Geschichte des Repos gelangt. Linter, Type-Checker, Secret-Scanner werden typischerweise als Pre-Commit-Hooks eingehängt.

Pre-Push-Hook

Ein lokaler Git-Hook, der beim Push läuft, also kurz bevor Änderungen das eigene Gerät verlassen und an ein entferntes Repository geschickt werden. Er ist der Ort für teurere Prüfungen, die man nicht bei jedem Commit ausführen will: volle Test-Suite, breitere Sicherheitschecks, Integrationsprüfungen.

Secret-Scanner

Ein Spezial-Linter mit einem einzigen Job: den Code (und den Diff) nach Mustern absuchen, die wie Geheimnisse aussehen — API-Schlüssel, Passwörter, Tokens, private Schlüssel.

Wofür gut. Verhindert die häufigste Art von Datenleck — versehentlich committete Schlüssel, die dann für immer in der Git-Geschichte stehen. Was er nicht leistet. Er erkennt, was wie ein Geheimnis aussieht (Form, Länge, Präfix). Obfuskierte oder ungewöhnlich kodierte Geheimnisse rutschen durch. Das Werkzeug arbeitet mit einer Baseline — bereits bekannte, harmlose Treffer (z.B. Beispiele in der Dokumentation) werden auf eine Whitelist gesetzt, damit die Prüfung nicht jedes Mal rot leuchtet. Beispiele. detect-secrets, gitleaks, trufflehog.

CI (Continuous Integration)

Eine Pipeline, die automatisch bei jedem Push (jeder Übertragung von Code an einen gemeinsamen Server) eine festgelegte Reihe von Prüfungen ausführt: Tests, Linter, Type-Check, Secret-Scan, Dependency-Audit. Erst wenn alle Prüfungen grün sind, gilt eine Änderung als bereit für den Hauptzweig.

Wofür gut. Das Gegenstück zu lokalen Pre-Commit-Hooks — nicht umgehbar, weil die Pipeline auf einem Server läuft, den der Entwickler nicht kontrolliert. Macht den Test- und Sicherheits-Stand für jede Änderung sichtbar und vergleichbar. Beispiele. GitHub Actions, GitLab CI, CircleCI, Jenkins. Für ein Solo-Projekt reicht meist GitHub Actions mit einer kurzen YAML-Konfiguration.

Dependency-Audit

Eine Prüfung der installierten Pakete gegen Datenbanken bekannter Sicherheitslücken. Das Werkzeug schaut also nicht auf deinen Code, sondern auf die Bibliotheken, die dein Projekt mitbringt.

Wofür gut. Macht sichtbar, wenn eine Abhängigkeit bereits öffentlich bekannte Schwachstellen enthält. Gerade bei agentisch entstandenen Projekten ist das wichtig, weil schnell neue Pakete dazukommen, deren Pflegezustand niemand bewusst geprüft hat. Was es nicht leistet. Es findet nur bekannte Schwachstellen. Ein sauberes Audit ist kein Beweis dafür, dass eine Abhängigkeit sicher oder gut gewartet ist. Beispiele. pip-audit für Python, npm audit für Node-Projekte, cargo audit für Rust.

Trust Boundary

Eine gedankliche Linie zwischen "innen, dem ich vertraue" und "außen, dem ich nicht vertraue". Konkrete Beispiele: zwischen meinem Programm und dem Nutzer, der etwas eintippt. Zwischen meinem Programm und einer Datei, die es liest. Zwischen meinem Programm und einer Antwort, die ein LLM liefert. Jede Trust Boundary ist ein Punkt, an dem Eingaben geprüft, validiert oder bereinigt werden müssen, bevor sie weiterverarbeitet werden.

Wofür gut. Klares Denken über wo Sicherheitsprüfungen sitzen müssen. "Validierung am Eingang" statt "irgendwo im Code, hoffentlich". Was es nicht leistet. Trust Boundaries müssen bewusst gezogen und respektiert werden. Eine Boundary, die niemand benannt hat, wird auch nicht bewacht.

Nicht-destruktive Defaults

Ein Arbeitsprinzip: Der sichere Standardfall eines Werkzeugs oder eines Agenten ist konservativ — nichts löschen, nichts überschreiben, nichts großflächig still umbauen. Wer destruktiv handeln will, muss das ausdrücklich tun (Flag setzen, Bestätigung geben, Approval einholen).

YOLO-Mode

"You Only Live Once" — die saloppe Bezeichnung für ungebremste Vollautonomie eines Agenten: alles ist erlaubt, nichts wird abgefragt, jede Aktion läuft sofort durch. In den meisten Coding-Agenten gibt es eine entsprechende Einstellung (oft "auto-edit", "yolo", "accept-all" oder ähnlich genannt).

Wofür gut. für Spielwiesen und für Wegwerf-Experimente in einer Sandbox, wo nichts kaputtgehen kann. Was er nicht leistet. Er ist das Gegenteil von Sicherheit.

Steering Files

Konfigurations-Dateien, die einem Coding-Agenten Regeln, Prioritäten und Verhaltensvorgaben mitgeben — vor und während jeder Sitzung. Je nach Anbieter heißen sie unterschiedlich: bei Claude Code ~/.claude/CLAUDE.md (global) und CLAUDE.md (im Projekt-Repo), bei Codex AGENTS.md, bei Cursor .cursorrules. Funktional sind sie identisch: der Versuch, einem LLM so etwas wie berufliche Vorsicht einzuprägen.

Wofür gut. Setzen den Default-Modus des Agenten — was er tun soll, was nicht, wie er sich bei Unsicherheit verhalten soll. Was sie nicht leisten. Steering Files sind Vorschläge mit hoher Wahrscheinlichkeit der Befolgung, keine harten Sperren. Ein manipulierter, abgelenkter oder überforderter Agent kann sie ignorieren.

Session-Anker

Ein kurzer Start-Prompt für eine konkrete Arbeitssitzung. Er sagt dem Agenten, was heute das Ziel ist, welcher Scope gilt, welche Quellen wichtig sind und welche Regeln oder Gates heute besonders zählen.

Wofür gut. Verhindert, dass Aufgaben, Rollen und Kontexte ineinanderlaufen. Ein guter Session-Anker macht aus einer diffusen Unterhaltung einen klaren Arbeitsauftrag. Was er nicht leistet. Er ersetzt weder globale Regeln noch Projektregeln. Wenn der restliche Kontext schlecht ist oder später driftet, kann auch ein guter Start-Anker an Wirkung verlieren.

Cross-Agent-Audit

Eine Review-Methode für Garage-Projekte ohne menschliche Code-Reviewer: Ein zweiter, unabhängiger Coding-Agent (anderes Modell, anderer Anbieter, andere Trainingsdaten) bekommt den expliziten Auftrag, eine Änderung zu zerlegen, nicht zu erweitern — Schwachstellen suchen, Annahmen prüfen, blinde Flecken aufdecken.

Wofür gut. Zwei verschiedene Modelle haben statistisch unterschiedliche blinde Flecken. Was der erste Agent für korrekt hält, sieht der zweite oft als problematisch — und umgekehrt. Was nicht hilft. Auch der Auditor-Agent kann und wird irren.

Blast Radius

Aus dem Sicherheits-Jargon: die Reichweite des Schadens, den eine einzelne fehlerhafte Aktion anrichten kann. Eine Aktion mit kleinem Blast Radius betrifft eine Datei; eine mit großem betrifft das ganze System, mehrere Nutzer, externe Services.

Rollback

Der Weg zurück zu einem früheren, funktionierenden Stand. Im Git-Alltag meint das meist: einen Commit rückgängig machen, einen Branch verwerfen oder einen bekannten guten Zustand wiederherstellen.

Wofür gut. Dein Projekt überlebt diesen letzten Fehler. Wer klein arbeitet und saubere Zwischenstände hat, kann im Zweifel schnell zurück auf einen stabilen Punkt. Was es nicht leistet. Ein Rollback heilt keinen bereits entstandenen externen Schaden. Wenn ein Geheimnis veröffentlicht oder ein System verändert wurde, ist „zurück im Git“ nur ein Teil der Schadensbegrenzung.

Mutation Testing

Eine Test-Qualitäts-Prüfung: man ändert absichtlich eine Stelle im Code (eine Zeile entfernen, eine Bedingung umdrehen, einen Operator ersetzen) und schaut, ob die Test-Suite das bemerkt. Wenn die Tests trotz der "Mutation" grün bleiben, sind sie für diese Stelle blind.

Wofür gut. Belastbarstes Maß für Test-Effektivität, das ein Nicht-Coder punktuell selbst anwenden kann.

Coverage (Test-Abdeckung)

Ein Maß dafür, welcher Anteil des Codes von der Test-Suite überhaupt berührt wird — meist als Prozentzahl angegeben (z.B. 85%). Werkzeuge wie pytest-cov (Python) berichten das pro Datei, pro Funktion, pro Zeile.

Wofür gut. Grobe Untergrenze: was nicht berührt wird, ist sicher nicht getestet. Was sie nicht leistet. Hohe Coverage ≠ gute Tests. Eine Funktion, die aufgerufen wird, ist nicht automatisch geprüft. Coverage misst Berührung, nicht Bedeutung.

Compaction

Wenn ein Coding-Tool bei langen Sessions die älteren Teile der Unterhaltung zusammenfasst, statt sie wörtlich zu behalten — meist um im Kontext-Fenster Platz und Kosten zu sparen. Claude Code macht das ab gewisser Tiefe, einige Cursor-Flows und Aider auch, bei openclaw kann man das manuell auslösen.

Wofür gut. Erlaubt sehr lange Sessions, ohne dass das Fenster überquillt. ACHTUNG. Compaction verformt — eine Zusammenfassung verliert immer Detail, manchmal genau das Detail, das später wichtig wird. Bedeutungen können driften. Vor wichtigen Entscheidungen: lieber neue Session starten, als sich auf compactete Erinnerung zu verlassen.

Lost in the middle

Ein dokumentierter Effekt bei langen Eingaben: LLMs gewichten die Mitte einer langen Eingabe schwächer als Anfang und Ende. Eine wichtige Information, die in der Mitte eines 100k-Token-Kontexts steht, wird statistisch weniger berücksichtigt.

Wofür gut, das zu kennen. Erklärt, warum große Kontexte nicht automatisch besser sind. Wichtige Anweisungen gehören nach vorn (System-Prompt) oder nach hinten (am Ende der Anfrage).

Trust-Zonen

Die bewusste Einteilung von Material, das in den Kontext eines Agenten fließt, in unterschiedliche Vertrauensstufen. Eine intern geprüfte Architektur-Doku ist eine andere Trust-Zone als ein zufälliges Markdown aus dem Netz.

Wofür gut. Macht die Frage "darf das hier den Agenten beeinflussen?" zu einer expliziten Entscheidung statt einer impliziten.

Provenance (Herkunftsnachweis)

Die Frage "woher kommt diese Information?" — explizit beantwortet, am besten mitgeliefert: Quelle, Datum der letzten Prüfung, prüfende Person. Eine Behauptung ohne Provenance ist im LLM-Kontext oft so problematisch wie im journalistischen — nur ohne Redaktion, die sie zurückweist.

Wofür gut. Macht stille Vergiftung sichtbarer. "Behauptung X — gesehen wo?" ist eine Frage, deren Nicht-Beantwortbarkeit ein Warnsignal ist.

Kontext-Minimierung

Das Prinzip: Nur die Information in den Kontext geben, die der Agent für die aktuelle Aufgabe wirklich braucht — nicht "alles, was nützlich sein könnte". Mehr Kontext klingt sicherer, ist aber meist das Gegenteil: mehr ungeprüftes Material, mehr Aufmerksamkeits-Verdünnung, mehr Angriffsfläche.

Wofür gut. Senkt sowohl Halluzinationsrisiko als auch Kosten.

Lethal Trifecta

Eine Schlüssel-Diagnose (vermutlich von Simon Willison) für die gefährliche Konfiguration in agentischen Systemen: (1) untrusted Input trifft auf (2) Zugriff auf sensible Daten trifft auf (3) Werkzeuge, die handeln können (Code-Ausführung, Datei-Schreiben, Netzwerk-Calls). Sind alle drei Fähigkeiten zugleich da, ist das Schadenpotential von Prompt-Injection hoch — eine eingeschleuste Anweisung kann destruktives tun oder Daten auslesen und sie über ein Tool exfiltrieren.

Wofür gut, das zu kennen. Macht klar, warum ein advisory-only-Agent (ohne Aktions-Tools) ein viel kleineres Problem hat als ein voll-aktiver. Wenn nur ein Bein fehlt, schrumpft die Bedrohungslage erheblich.

Prompt-Injection

Eine Klasse von Angriffen, bei denen ein Angreifer Anweisungen im Daten-Kanal eines LLM platziert (z.B. in einer Datei, einer E-Mail, einer Webseite, die der Agent liest), die das Modell als Befehle interpretiert und befolgt. Direkt-Injection: der Angreifer schreibt direkt in den Prompt. Indirekt-Injection: der Angreifer schreibt in etwas, das der Agent später konsumiert.

Wofür gut, das zu kennen. Erklärt, warum jede Quelle, die in den Kontext fließt, als potenziell feindlich behandelt werden muss — selbst die eigene Datei, in die jemand etwas geschmuggelt haben könnte.

Kein Anspruch auf Korrektheit. Ihr seht hier meinen Lernprozess. Korrekturen, Widerspruch, Erfahrungsberichte willkommen (email im Impressum). Dieser Beitrag wird sich ändern. Erstellt mit LLM Unterstützung. Was heute gilt, kann morgen schon ganz anders sein.