Modul 1
Grundlagen von LLMs & AI Agents
Tag 1 · ca. 90 Minuten
Lernziel Modul 1
Der Teilnehmer versteht, warum LLMs stateless sind,
nicht-deterministisch antworten und in einer
Agent-Schleife arbeiten — und kann daraus die
typischen Einstiegsfehler ableiten.
Drei Eigenschaften, eine Konsequenz. Das ist der ganze Bauplan dieses Moduls.
Inhalt
Tokens & Tokenizer
Womit das Modell tatsächlich rechnet
Thinking & Reasoning
Nachdenken als eigener Arbeitsschritt
Stateless AI
Warum das Modell nichts behält
Unterschiedliche Antworten
Nicht-Determinismus als Feature
Agents & Agent Mindset
Vom Textgenerator zum Werkzeugnutzer
Grenzen & Einstiegsfehler
Was schiefgeht und warum
Modellwahl
Opus, Sonnet, Haiku
Benchmarks vs. Realität
Was Ranglisten nicht sagen
RL & Cut-off Dates
Warum das Modell 2026 nicht kennt
Das Modell sieht keine Wörter
Text wird vor der Verarbeitung in Tokens zerlegt —
Bausteine zwischen Zeichen und Wort.
Der Seminarteilnehmer
storniert die Buchung.
Faustregel Deutsch: 1 Token ≈ 3–4 Zeichen.
Deutsche Komposita zerfallen in mehr Tokens als englische Wörter —
derselbe Inhalt kostet auf Deutsch spürbar mehr.
Warum euch das interessieren muss
Kosten
Abgerechnet wird pro Token — Ein- und Ausgabe getrennt.
Kontextfenster
Die Obergrenze ist in Tokens definiert, nicht in Dateien.
Geschwindigkeit
Mehr Tokens = längere Antwortzeit, linear spürbar.
Qualität
Ein volles Fenster ist nicht nur teuer — es wird auch schlechter (Modul 3).
Alles, was in die Session gerät — jede gelesene Datei,
jede Testausgabe, jeder Fehler-Stacktrace — kostet Tokens und bleibt kosten.
Thinking Models & Reasoning
Nachdenken kostet Tokens — und lohnt sich
Moderne Modelle können vor der eigentlichen Antwort einen
Denkschritt ausführen: sichtbares oder internes Reasoning,
das ebenfalls aus Tokens besteht.
Ohne Reasoning
Schnell, billig, gut bei klaren, lokalen Aufgaben:
Umbenennen, Formatieren, offensichtliche Fixes.
Mit Reasoning
Langsamer, teurer, deutlich besser bei Analyse, Architektur,
Fehlersuche mit mehreren Verdächtigen.
Mehr Nachdenken ist nicht immer besser — es ist besser
bei Problemen, die man nicht auf einen Blick löst.
Understanding Stateless AI
Das Modell hat kein Gedächtnis
Ein LLM ist eine Funktion: Text rein, Text raus.
Zwischen zwei Aufrufen bleibt nichts zurück.
Wenn das Modell nichts behält — warum kann es sich dann im Chat
an die vorige Nachricht erinnern?
Die Antwort: alles wird neu geschickt
| Runde | Was tatsächlich an das Modell geht |
|---|
| 1 | Systemprompt + Frage 1 |
| 2 | Systemprompt + Frage 1 + Antwort 1 + Frage 2 |
| 3 | Systemprompt + Frage 1 + Antwort 1 + Frage 2 + Antwort 2 + Frage 3 |
| … | … und so weiter, bis das Fenster voll ist |
„Gedächtnis" ist eine Illusion, die der Client erzeugt,
indem er die gesamte Historie bei jedem Aufruf mitsendet.
Drei Konsequenzen, sofort
1Sessions wachsen nur. Nichts fällt von selbst raus. Was einmal drin ist, wird bei jedem weiteren Schritt mitbezahlt.
2Wissen muss anfassbar sein. Was der Agent wissen soll, gehört ins Repo — nicht in eine Chatnachricht von gestern.
3Neu anfangen ist ein Werkzeug. Eine frische Session ist oft schneller und besser als eine lange, in der man „nur noch schnell" weitermacht.
Warum AI unterschiedliche Antworten gibt
Gewürfelt wird bei jedem Token
Das Modell berechnet keine Antwort. Es berechnet eine
Wahrscheinlichkeitsverteilung über das nächste Token —
und zieht daraus.
- Gleiche Eingabe → gleiche Verteilung
- Gleiche Verteilung → nicht zwingend gleiche Ziehung
- Ein anderes Token am Anfang → ab da läuft alles anders
Zweimal dieselbe Aufgabe heißt zweimal ein anderer Weg —
und manchmal ein anderes Ergebnis.
Konsequenz für die Arbeitsweise
Funktioniert nicht
„Es hat gestern geklappt, also klappt es heute."
„Ich schreibe den perfekten Prompt und bekomme immer dasselbe."
„Der Kollege hat denselben Prompt — also dasselbe Ergebnis."
Funktioniert
Verifizierbare Ergebnisse statt reproduzierbarer Wege.
Tests, Build, Diff, laufende Anwendung — etwas, das objektiv grün oder rot ist.
Der Weg darf variieren, das Abnahmekriterium nicht.
Das ist der Grund, warum sich der ganze Kurs um Gates und Artefakte
dreht (Modul 5) und nicht um Zauberformeln.
AI Agents & Agent Mindset
Vom Textgenerator zum Agenten
Ein Agent ist ein LLM in einer Schleife, das
Werkzeuge benutzen darf und seine eigenen Ergebnisse liest.
Auftrag
Denken
Werkzeug
benutzen
Ergebnis
lesen
Fertig?
Die Werkzeuge sind das Entscheidende: Dateien lesen und schreiben, Befehle
ausführen, suchen. Damit verlässt das Modell den Chat und betritt euer Projekt.
Agent Mindset
Die produktivste Haltung ist weder „mächtiges Orakel" noch „dummer Autovervollständiger",
sondern:
Ein sehr schneller, sehr fleißiger neuer Kollege, der eure
Codebasis nicht kennt, eure Konventionen nicht kennt, nie nachfragt, wenn er
sich sicher fühlt — und alles vergisst, sobald er den Raum verlässt.
Aufgaben zuschneiden
So groß wie ein Ticket, nicht wie ein Projekt.
Kontext liefern
Was ein neuer Kollege bräuchte, braucht der Agent auch.
Ergebnisse prüfen
Vertrauen entsteht durch Nachsehen, nicht durch Hoffnung.
Eingreifen
Früh abbrechen ist billiger als spät reparieren.
Möglichkeiten, Grenzen & typische Einstiegsfehler
Wo Agents wirklich stark sind
Erschließen
Unbekannte Codebasis, unbekannter Stack — Fragen beantworten mit Belegstelle.
Tests nachrüsten
Ungetesteten Code absichern, bevor man ihn anfasst.
Mechanische Änderungen
Umbenennen, Migrieren, Muster über viele Dateien ziehen.
Erste Fassungen
Gerüst, Doku, Boilerplate — alles, was man leichter korrigiert als schreibt.
Fehlersuche mit Reproduktion
Wenn ein Test rot ist, hat der Agent ein objektives Ziel.
Übersetzen
Zwischen Sprachen, Frameworks, Formaten — sofern verifizierbar.
Wo es zuverlässig scheitert
Ungeschriebenes Wissen
„Das machen wir hier immer so" steht nirgends — also weiß er es nicht.
Große Umbauten am Stück
Je größer der Schritt, desto wahrscheinlicher der Irrweg.
Unklare Ziele
Ohne Abnahmekriterium produziert er etwas Plausibles statt etwas Richtiges.
Sehr Neues
Frische Library-Versionen liegen jenseits des Trainingsstands.
Echte Abwägungen
Fachliche Priorisierung, Risikoentscheidungen, Kundenversprechen.
Was er nicht sehen kann
Laufende Prod-Umgebung, Log-Verhalten, echtes Nutzerverhalten.
Die typischen Einstiegsfehler
| Fehler | Kommt her von… | Gegenmittel |
|---|
| „Bau mir die App" — Auftrag zu groß | Agent-Bild als Orakel | Zerlegen, Modul 5 |
| Ewige Session, wird immer schlechter | Stateless nicht verstanden | Session-Hygiene, Modul 4 |
| Konventionen im Chat statt im Repo | Illusion von Gedächtnis | CLAUDE.md, Modul 7 |
| Diff ungelesen übernommen | Vertrauen statt Verifikation | Review-Loops, Modul 4/9 |
| Alles blind bestätigen | Approval Fatigue | Permissions bewusst setzen, Modul 4 |
| Kein Abnahmekriterium genannt | Nicht-Determinismus ignoriert | Verifiable Outputs, Modul 4 |
| Halluzinierte API geglaubt | Cut-off nicht bedacht | Verifizieren lassen, Modul 3 |
Jeder dieser Fehler ist eine direkte Folge aus stateless,
nicht-deterministisch oder Agent-Schleife. Kein Fehler ist Zufall.
Modellwahl in Claude Code
Opus, Sonnet, Haiku
Opus
Das stärkste Modell. Für schwierige Analyse, Architektur, verzwickte Fehlersuche. Teuerster Token.
Sonnet
Der Ausgleich zwischen Stärke, Tempo und Preis — der Alltagsarbeiter.
Haiku
Klein und schnell. Für mechanische, klar umrissene Aufgaben und Hilfsläufe.
Die Namen sind die Familien, nicht die Versionen. Innerhalb
jeder Familie gibt es Generationen — die konkreten Versionsnamen ändern
sich mehrmals pro Jahr.
Konkrete Modellversionen sind bewusst nicht auf dieser Folie. Aktuellen Stand
vor dem Kurs prüfen (/model in Claude Code bzw. die offizielle
Dokumentation) und mündlich ergänzen. — geprüft am 2026-07-21
Faustregeln zur Modellwahl
Im Zweifel das mittlere Modell. Die meiste Alltagsarbeit braucht keine Spitzenleistung.
Hochschalten bei Ratlosigkeit. Wenn zwei Anläufe scheitern, ist selten der Prompt schuld — sondern die Aufgabenhärte.
Runterschalten bei Fleißarbeit. Mechanisches Umschreiben braucht kein Spitzenmodell.
Nicht am falschen Ende sparen. Ein billiger Fehllauf, den ihr eine Stunde debuggt, war nicht billig.
Benchmarks vs. Realität
Was Benchmarks messen
Abgeschlossene, saubere Aufgaben mit eindeutiger Lösung, ohne Altlasten,
ohne Firmenkonventionen, ohne 200 Dateien Kontext.
Was euer Alltag ist
Gewachsener Code, halbdokumentierte Entscheidungen, Sonderfälle vom
letzten Kunden, ein Build, der nur auf einem Rechner grün ist.
Benchmarks vergleichen Modelle untereinander. Sie sagen
nichts darüber, wie viel Nutzen ihr in eurem Repo habt.
Der einzige belastbare Benchmark ist ein Pilotprojekt bei euch.
Wie das Verhalten entsteht
1Vortraining — sehr viel Text. Ergebnis: Sprache, Weltwissen, Code-Muster.
2Nachtraining mit Feedback (Reinforcement Learning) — das Modell lernt, welche Antworten Menschen als hilfreich und korrekt bewerten.
3Konsequenz: Das Modell ist darauf optimiert, hilfreich zu wirken. Eine flüssige, selbstsichere Antwort ist deshalb kein Qualitätssignal.
Es gibt keinen Tonfall-Unterschied zwischen „das weiß ich sicher" und
„das klingt plausibel". Beides klingt gleich gut.
Cut-off Dates
Das Trainingswissen endet an einem Stichtag. Alles danach
— neue Library-Versionen, geänderte APIs, eure letzten sechs Monate
Projektgeschichte — ist dem Modell unbekannt.
Gefährlich
Es sagt nicht „kenne ich nicht". Es rät eine plausible API —
Methodenname, Signatur und Beispiel sehen perfekt aus und existieren nicht.
Gegenmittel
Nachschlagen lassen statt erinnern lassen: Doku holen, im Projekt suchen,
kompilieren. Der Compiler ist der beste Halluzinationsdetektor.
Modul 1 in vier Sätzen
1Das Modell rechnet in Tokens — alles, was in die Session kommt, kostet dauerhaft.
2Es ist stateless — Gedächtnis wird durch Wiederholen erzeugt, nicht durch Erinnern.
3Es ist nicht-deterministisch — verlasst euch auf Abnahmekriterien, nicht auf Wiederholbarkeit.
4Als Agent benutzt es Werkzeuge und liest die Ergebnisse — damit wird es nützlich und gleichzeitig gefährlich.
Alles, was in den nächsten drei Tagen kommt, ist eine Antwort auf
eine dieser vier Eigenschaften.
Übung 1 — Nicht-Determinismus messen
Aufgabe
Stellt Claude Code dreimal in einer frischen Session dieselbe
Frage zum Beispielprojekt seminar-api — zum Beispiel:
„Wie kommt eine Buchung von der REST-Schnittstelle bis in die Datenbank?"
Verifizierbares Ergebnis: Ihr habt drei Antworten
nebeneinander und könnt drei konkrete Unterschiede benennen
— und beurteilen, ob alle drei fachlich richtig sind.
Dauer ca. 20 Minuten · Einzelarbeit
© 2026 CGS IT Solutions GmbH
Alle Rechte vorbehalten
Diese Schulungsunterlagen sind urheberrechtlich geschützt. Vervielfältigung,
Weitergabe oder kommerzielle Nutzung — auch in Auszügen — nur mit
ausdrücklicher schriftlicher Genehmigung der CGS IT Solutions GmbH.
cgsit-claude-training · Modul 1 · v0.1.0
