# Agentic School - Voller Korpus > Der vollständige, maschinenlesbare Korpus aller veröffentlichten Seiten der Agentic School in beiden Sprachen, als ein einziges Markdown-Dokument. Für immer kostenlos. Abschnitte sind durch Trennlinien getrennt; jeder Eintrag trägt seine kanonische URL und Sprache. --- ## Kurse ### Grundlagen - Von null zur ersten veröffentlichten App - Kanonische URL: https://agenticschool.dev/de/kurse/foundations - Level: einsteiger - Lektionen: 7 Der komplette Einstieg. Verstehe, wie LLMs und Coding Agents wirklich funktionieren, installiere Claude Code und Codex, brieffe sie wie ein Profi und baue dann eine echte Website, die du ins öffentliche Internet bringst. ### Claude Code Mastery - Vom Nutzer zum Power User - Kanonische URL: https://agenticschool.dev/de/kurse/claude-code-mastery - Level: einsteiger - Lektionen: 7 Geh in die Tiefe mit Claude Code. Bring ihm deine Regeln mit CLAUDE.md bei, baue wiederverwendbare Skills und Commands, automatisiere Quality Gates mit Hooks, verbinde Tools mit MCP und nutze Multi-Agent-Workflows, ohne Kontext oder Geld zu verbrennen. ### Der moderne App-Stack - Auth, Daten und Payments - Kanonische URL: https://agenticschool.dev/de/kurse/modern-app-stack - Level: fortgeschritten - Lektionen: 7 Setze ein echtes Produkt zusammen. Lerne, wie moderne Apps aufgebaut sind, ergänze Clerk-Authentifizierung und Google OAuth, modelliere reaktive Daten in Convex, verwalte Secrets sicher, nimm mit Stripe Zahlungen entgegen und migriere von Dev zu Produktion. ### Automation und agentische Systeme - Kanonische URL: https://agenticschool.dev/de/kurse/automation-agentic-systems - Level: fortgeschritten - Lektionen: 7 Baue Automationen und agentisches Tooling. Vergleiche n8n, Zapier und Trigger.dev, automatisiere den Browser mit Playwright, führe Code sicher in Sandboxes aus, baue eigene KI-Tools auf APIs und gestalte Human-in-the-Loop-Systeme. ### Qualität, Sicherheit und das agent-first Business - Kanonische URL: https://agenticschool.dev/de/kurse/quality-security-agent-first - Level: technik - Lektionen: 7 Mach es produktionsreif. Setze Tests und CI/CD auf, sichere Security und Datenschutz, werde von Google und von KI gefunden mit SEO und GEO, gestalte agent-first Produkte und baue und veröffentliche dein eigenes agentisches Produkt von Anfang bis Ende. --- ## Lektionen ### 1.1 Wie LLMs wirklich funktionieren: Tokens, Kontextfenster und der Performance-Cliff - Kanonische URL: https://agenticschool.dev/de/kurse/foundations/how-llms-actually-work-tokens-context-windows-and-the-performance-cliff - Dauer: 22 min Zusammenfassung: Bevor du ein einziges Tool anfässt, brauchst du ein funktionierendes mentales Modell davon, was ein grosses Sprachmodell tut. Diese Lektion erklärt Tokens, Kontextfenster und den Performance-Cliff, der lange Gespräche trifft, damit jede spätere Entscheidung zu Modellen, Prompts und Agents Sinn ergibt. #### Überblick Ein grosses Sprachmodell macht eine Sache erstaunlich gut: Es sagt das nächste Token voraus, basierend auf allem, was es bisher gesehen hat. Sobald du Tokens, das Kontextfenster und den Performance-Cliff bei langen Eingaben verstehst, fühlt sich jede spätere Entscheidung - welches Modell du nimmst, wie du es promptest und wie du Agents laufen lässt - nicht mehr wie Raten an. Diese Lektion gibt dir dieses mentale Modell in klarer Sprache, mit den wenigen Zahlen, die 2026 wirklich zählen. #### Was du lernst Du lernst, was ein Token ist, warum du pro Token und nicht pro Wort bezahlst und limitiert wirst, wie das Kontextfenster das ganze Gespräch hält und warum mehr Text in ein Modell zu kippen die Antworten oft schlechter statt besser macht. Am Ende kannst du das Datenblatt eines Modells lesen und vorhersagen, wie es sich verhält, bevor du einen Cent dafür ausgibst. #### Voraussetzungen Keine. Du musst nicht programmieren können und auch noch nie ein KI-Tool benutzt haben. Wenn du je eine Nachricht in ChatGPT, Claude oder Gemini getippt hast, hast du schon alles an Hintergrund, das du brauchst. Die tieferen Grundlagen zu Terminal und Git verlinken wir später, wenn du sie wirklich brauchst. #### Das Problem Die meisten behandeln ein LLM wie eine Suchmaschine oder einen Menschen. Sie fügen ein riesiges Dokument ein, stellen eine vage Frage und sind überrascht, wenn die Antwort flach, falsch oder an der Hälfte des Eingefügten vorbei ist. Das Modell ist nicht faul geworden. Es ist an Grenzen gestossen, die in seiner Funktionsweise stecken. Ohne ein mentales Modell von Tokens und Kontext wirst du dem Tool immer wieder ein Verhalten vorwerfen, das völlig vorhersehbar ist. #### Tokens, nicht Wörter Ein Modell sieht nie Buchstaben oder Wörter so, wie du es tust. Bevor irgendetwas passiert, wird dein Text in Tokens zerlegt - häufige Zeichenblöcke. Ein Token sind grob vier Zeichen oder etwa drei Viertel eines englischen Wortes. Häufige Wörter sind ein einzelnes Token; seltene Wörter, Code-Symbole und andere Sprachen kosten mehr. Zwei Dinge werden in Tokens gemessen: der Preis, den du zahlst, und die Menge, die ein Modell auf einmal halten kann. Darum kann ein "günstiges" Modell bei langen Dokumenten teuer werden, und darum kosten deutsche oder Code-Prompts mehr Tokens als dieselbe Idee in schlichtem Englisch. - 1 Token sind etwa 4 Zeichen oder 0,75 englische Wörter. - 1.000 Tokens sind grob 750 Wörter, also rund anderthalb Seiten Text. - Der Preis wird pro Million Tokens angegeben, aufgeteilt in Input (was du sendest) und Output (was das Modell zurückschreibt). Output kostet meist ein Vielfaches des Inputs. - Dir wird in jeder Runde das GANZE Gespräch berechnet, weil das Modell jedes Mal alles neu liest, bevor es antwortet. #### Das Kontextfenster Das Kontextfenster ist die maximale Anzahl Tokens, die ein Modell auf einmal berücksichtigen kann: deine Anweisungen, die eingefügten Dateien, der Gesprächsverlauf und die Antwort, die es gerade schreibt, alles zusammengezählt. 2026 hat ein typisch starkes Modell ein Kontextfenster von rund 200.000 Tokens, manche werben mit 1.000.000 oder mehr. Stell es dir als den Schreibtisch des Modells vor. Alles Relevante muss gleichzeitig auf den Tisch passen. Ist der Tisch voll, muss etwas runter, und das Modell vergisst es praktisch. Darum verliert ein langer Chat den Faden zu Anweisungen, die du am Anfang gegeben hast: Diese Tokens sind vom Tisch gefallen. #### Der Performance-Cliff Jetzt der Teil, den fast niemand Einsteigern erzählt: Mehr Kontext ist nicht dasselbe wie bessere Antworten. Während du ein Kontextfenster füllst, sinkt die Modellqualität lange bevor du die harte Grenze erreichst. Modelle achten am besten auf Anfang und Ende einer langen Eingabe und werden in der Mitte unscharf - ein Muster, das oft "lost in the middle" heisst. Ein Fenster mit 1.000.000 Tokens klingt grossartig, aber in der Praxis kann die Antwortqualität bei einem vollgepackten Fenster spürbar schlechter sein als bei einem knappen, gut gewählten Prompt mit 20.000 Tokens. Das ist der Performance-Cliff. Die Lehre ist deutlich: Relevanz schlägt Menge. Ein kurzer Prompt mit genau dem richtigen Kontext schlägt einen riesigen Prompt jedes Mal. - Die Qualität ist am höchsten, wenn das Fenster fast leer ist und jedes Token seinen Platz verdient. - Die Qualität fällt, je voller das Fenster wird, besonders für Informationen, die in der Mitte vergraben sind. - Riesige beworbene Fenster (1M+) liefern ihre volle Qualität am oberen Ende selten - behandle sie als Sicherheitsmarge, nicht als Arbeitsfläche. - Im Zweifel starte ein frisches Gespräch, statt auf ein langes draufzupacken. #### Schritt für Schritt: sieh es selbst Du kannst in zehn Minuten ein Gespür dafür aufbauen, ohne Code zu schreiben. Öffne irgendein Chat-Modell und mach dieses kleine Experiment. Es geht darum zu spüren, wie Tokens, das Fenster und der Cliff in echten Antworten auftauchen. - Frag das Modell: "Aus wie vielen Tokens besteht das Wort internationalization, und warum?" Beachte, dass es in mehrere Tokens zerfällt, weil es lang und selten ist. - Füge einen langen Artikel ein (ein paar tausend Wörter) und stell eine Frage zu einem Satz in der genauen Mitte. Stell dann dieselbe Frage zum ersten Satz. Die Antwort zur Mitte ist meist schwächer. - Bitte das Modell in einem sehr langen Chat, eine Anweisung zu wiederholen, die du ganz oben gegeben hast. Sieh zu, wie es sich abmüht oder erfindet - diese frühen Tokens sind vom Tisch. - Starte einen brandneuen Chat, füge nur den relevanten Absatz ein und frag erneut. Die Antwort ist schärfer. Das ist Relevanz, die Menge schlägt. #### Typische Fehler Der klassische Einsteigerfehler ist der "alles reinkippen"-Prompt: ein 50-seitiges PDF einfügen und eine enge Frage stellen. Das Modell ertrinkt. Der zweite Fehler ist der nie endende Chat, bei dem du ein Gespräch tagelang offen hältst und dich wunderst, warum es dümmer wird. Der dritte ist die Annahme, ein grösseres Kontextfenster erlaube dir, bei der Relevanz nachlässig zu sein. Alle drei kommen daher, den Cliff nicht zu respektieren. Die Lösung ist immer dieselbe: sende weniger, aber das richtige Weniger, und setze oft zurück. #### Business-ROI Das ist nicht akademisch. Tokens sind Geld und Kontextdisziplin ist Qualität. Ein Team, das das versteht, schreibt knappere Prompts, wählt günstigere Modelle für einfache Aufgaben und bekommt verlässlichere Ergebnisse, was weniger Nacharbeit bedeutet. In einem echten Workflow, der tausende Male läuft, kann das Kürzen eines aufgeblähten Prompts von 30.000 auf 5.000 Tokens deine Rechnung um 80 Prozent senken UND die Antworten verbessern. Den Cliff zu verstehen ist das mit Abstand wirkungsvollste, das eine nicht-technische Gründerin lernen kann, bevor sie KI in grossem Massstab einsetzt. #### Checkliste Bevor du weitergehst, stell sicher, dass du diese Fragen beantworten kannst, ohne zurückzublättern. Wenn eine Antwort wackelig ist, lies den passenden Abschnitt nochmal - dieses Modell liegt unter allem anderen im Kurs. - Kannst du einer Kollegin ein Token in einem Satz erklären? - Weisst du grob, wie viele Wörter in ein Fenster mit 200.000 Tokens passen? - Kannst du den Performance-Cliff beschreiben und warum Relevanz Menge schlägt? - Weisst du, warum dir in jeder Runde das ganze Gespräch berechnet wird? #### Ressourcen Halt die Idee bei der Arbeit parat: Wenn eine Antwort schlecht ist, sind deine ersten beiden Fragen immer "Ist mein Kontext zu gross?" und "Steht die richtige Information tatsächlich nah am Anfang oder Ende?" Die Grundlagen-Seite zu Tokens geht tiefer auf Tokenisierung ein, wenn du das Detail dahinter willst, und der Modellvergleich in der nächsten Lektion baut direkt auf den hier eingeführten Zahlen auf. #### Deine Aufgabe Mach das vierschrittige Experiment oben in einem Chat-Modell deiner Wahl und schreib in eigenen Worten einen Satz auf, der den Moment beschreibt, in dem du das Modell "vergessen" oder unscharf werden gesehen hast. Diese konkrete Erinnerung festzuhalten lässt später jede Prompting-Entscheidung im Kurs einrasten. #### Nächste Lektion Jetzt, wo du weisst, was ein Modell unter der Haube tut, ist die nächste Frage offensichtlich: welches Modell nutzen? Die nächste Lektion vergleicht Haiku, Sonnet und Opus mit GPT und Gemini, erklärt Benchmarks ehrlich und zeigt, wo du starke Modelle günstig oder kostenlos bekommst. ### 1.2 Das richtige Modell wählen: Haiku vs Sonnet vs Opus, GPT, Gemini und Benchmarks - Kanonische URL: https://agenticschool.dev/de/kurse/foundations/choosing-your-model-haiku-vs-sonnet-vs-opus-gpt-gemini-and-benchmarks - Dauer: 24 min Zusammenfassung: Es gibt kein einzelnes bestes Modell, nur das richtige Modell für eine Aufgabe und ein Budget. Diese Lektion kartiert die Modelllandschaft 2026 - Claude Haiku, Sonnet und Opus, OpenAI GPT, Google Gemini -, erklärt, wie du Benchmarks liest, ohne dich täuschen zu lassen, und zeigt, wo du starke Modelle günstig über OpenRouter und kostenlose Gemini-Credits bekommst. #### Überblick Jeder Modellanbieter liefert eine Familie von Modellen, nicht ein Modell. Sie kommen in Stufen: klein und schnell, mittel und ausgewogen, gross und schlau. Sobald du die Stufen statt der Markennamen siehst, wird das Wählen einfach. Diese Lektion gibt dir eine Entscheidungsregel, die du auf jedes neu erscheinende Modell anwenden kannst, plus die praktischen Tricks, um Top-Modelle günstig oder kostenlos zu bekommen. #### Was du lernst Du lernst das Drei-Stufen-Modell, wie sich Claude (Haiku, Sonnet, Opus), OpenAI GPT und Google Gemini darin einordnen, wie du Benchmarks mit gesundem Misstrauen behandelst und wie du an starke Modelle kommst, ohne den vollen Listenpreis zu zahlen - mit OpenRouter und kostenlosen Gemini-Credits. #### Voraussetzungen Die vorige Lektion zu Tokens und Kontext. Du solltest mit der Idee vertraut sein, dass der Preis pro Million Tokens angegeben wird und dass mehr Kontext nicht automatisch besser ist, denn beide Ideen treiben die Modellwahl. #### Das Problem Einsteiger greifen entweder zum einzigen Modell, von dem sie gehört haben, oder sie jagen dem hinterher, was letzte Woche ein Leaderboard angeführt hat. Beides sind teure Fehler. Ein Flaggschiff-Modell zum Umformatieren einer Liste zu nutzen ist, wie eine Chirurgin ein Pflaster aufkleben zu lassen. Ein winziges Modell für harte architektonische Überlegungen zu nutzen produziert selbstbewussten Unsinn. Die Fähigkeit besteht darin, Aufgabenschwierigkeit auf Modellstufe abzustimmen, und diese Fähigkeit überlebt jeden einzelnen Modellnamen. #### Die drei Stufen Vergiss Markentreue und denk in Stufen. Kleine Modelle sind schnell und günstig, super für Klassifikation, Extraktion, einfache Umschreibungen und Jobs mit hohem Volumen. Mittlere Modelle sind das ausgewogene Arbeitspferd für die meiste echte Programmier- und Schreibarbeit. Grosse Modelle sind langsamer und teurer, denken aber bei wirklich harten Problemen weit besser. Fast jeder Anbieter spiegelt diese Struktur, also kannst du, sobald du sie verinnerlicht hast, jedes neue Modell sofort einordnen. - Klein / schnell: Claude Haiku, GPT-Kleinstufe, Gemini Flash. Nutze sie für Volumen, Extraktion, Routing, günstige Entwürfe. - Mittel / ausgewogen: Claude Sonnet, GPT-Mittelstufe, Gemini Pro. Dein täglicher Begleiter fürs Programmieren und ernsthaftes Schreiben. - Gross / schlau: Claude Opus, GPT-grosse Reasoning-Stufe, Gemini Ultra/Pro-Topstufe. Nutze sie für hartes Reasoning, kniffliges Debugging, Architektur. - Faustregel: starte eine Stufe tiefer, als du denkst, und geh nur höher, wenn der Output wirklich nicht gut genug ist. #### Wie du Benchmarks ehrlich liest Benchmarks sind nützlich und zugleich regelmässig irreführend. Ein Modell kann einen Coding-Benchmark anführen und sich in deinem echten Projekt trotzdem schlechter anfühlen, weil Benchmarks enge Aufgaben unter Idealbedingungen messen und Anbieter hart darauf optimieren. Behandle Benchmarks als groben Filter, nicht als Urteil. Der einzige Benchmark, der zählt, ist dein eigener: nimm drei echte Aufgaben aus deiner Arbeit, jage sie durch zwei oder drei Modelle und beurteile den Output selbst. Achte auf Konstanz, nicht nur auf Spitzenleistung, denn ein Modell, mit dem du in Produktion gehst, muss verlässlich gut sein, nicht gelegentlich brillant. #### Preise und das echte Kostenbild Der Preis wird pro Million Input- und Output-Tokens angegeben, und der Abstand zwischen den Stufen ist gross - oft 10x oder mehr zwischen einem kleinen und einem grossen Modell. Weil Output ein Vielfaches des Inputs kostet, sind wortreiche Modelle und geschwätzige Prompts teurer, als du erwartest. Der praktische Zug ist, nach Schwierigkeit zu routen: günstiges Modell für die 80 Prozent leichten Aufrufe, teures Modell nur für die harten 20 Prozent. In einem Workflow im grossen Massstab zählt diese eine Entscheidung oft mehr als die Wahl des Anbieters. #### Starke Modelle günstig oder kostenlos Du musst nicht den vollen Preis zahlen, um zu starten. Es gibt 2026 drei verlässliche Wege, und ein Einsteiger sollte alle kennen, bevor er Budget bindet. - OpenRouter: ein einziger Account und API-Key, der dir Zugang zu fast jedem Modell gibt (Claude, GPT, Gemini, offene Modelle) über einen Endpoint, mit transparenter Preisgestaltung pro Token und einfachem Modellwechsel. Ideal, um Modelle zu vergleichen, ohne fünf Accounts zu jonglieren. - Kostenlose Gemini-Credits: Google bietet über sein AI Studio regelmässig einen grosszügigen Free Tier und Credits, ein wirklich starker, günstiger Weg zu einem fähigen mittleren Modell für Experimente und Tools mit kleinem Volumen. - Free Tiers und Trials der Anbieter: die meisten Anbieter geben dir etwas kostenlose Nutzung zum Evaluieren. Nutze sie gezielt, um deinen eigenen Drei-Aufgaben-Benchmark zu fahren. #### Warum 1M-Kontext-Modelle enttäuschen Du wirst Modelle sehen, die mit Kontextfenstern von 1.000.000 Tokens werben, und annehmen, sie seien strikt besser. In der Praxis enttäuschen sie oft, aus genau dem Grund aus der vorigen Lektion: dem Performance-Cliff. Ein Modell kann technisch eine Million Tokens annehmen und trotzdem schlechter antworten als ein fokussierter Prompt, weil die Qualität sinkt, je voller das Fenster wird. Behandle ein riesiges Kontextfenster als gelegentliche Versicherung für ein wirklich grosses Dokument, nicht als Erlaubnis, mit dem Kuratieren von Kontext aufzuhören. An den meisten Tagen schlägt ein mittleres Modell mit knappem Prompt ein Modell mit riesigem Kontext und schlampigem Prompt. #### Schritt für Schritt: ein Modell für eine echte Aufgabe wählen Mach das konkret mit einer Aufgabe aus deiner eigenen Arbeit. Ziel ist, die Entscheidungsregel zu üben, nicht eine endgültige Antwort zu finden. - Schreib die Aufgabe auf und bewerte ihre Schwierigkeit: einfach, normal oder wirklich hart. - Wähle die passende Stufe: klein, mittel oder gross. - Jage sie durch zwei Modelle dieser Stufe (nutze OpenRouter zum schnellen Wechseln). - Beurteile den Output selbst nach Qualität und Konstanz und notiere, welches du tatsächlich nutzen würdest und warum. #### Typische Fehler Die grossen: immer zum Flaggschiff greifen und bei leichten Aufgaben Geld verbrennen; einem Leaderboard mehr trauen als dem eigenen Drei-Aufgaben-Test; annehmen, ein grösseres Kontextfenster bedeute ein schlaueres Modell; und sich auf einen Anbieter festlegen, sodass du nie merkst, wenn ein Konkurrent etwas Besseres für deinen Anwendungsfall bringt. OpenRouter existiert genau dafür, dass die Wechselkosten niedrig bleiben. #### Business-ROI Die Modellwahl ist einer der klarsten Hebel auf deine KI-Rechnung und deine Output-Qualität. Leichte Arbeit an ein kleines Modell zu leiten und das grosse Modell für hartes Reasoning zu reservieren, kann Kosten um eine Grössenordnung senken und gleichzeitig die Verlässlichkeit erhöhen, weil jede Aufgabe das richtige Werkzeug bekommt. Für eine Gründerin ist die Disziplin "Stufe an Schwierigkeit anpassen, an eigenen Aufgaben benchmarken, Wechseln günstig halten" mehr wert als jede einzelne Modellwahl. #### Checkliste Du bist bereit weiterzugehen, wenn du Folgendes sicher kannst, ohne an den Markennamen zu zweifeln. - Jedes neue Modell anhand von Datenblatt und Preis als klein, mittel oder gross einordnen. - Erklären, warum du für einen einfachen Extraktionsjob kein Flaggschiff nutzen würdest. - Einen persönlichen Drei-Aufgaben-Benchmark fahren, statt einem Leaderboard zu trauen. - Benennen, wo es ein starkes Modell günstig oder kostenlos gibt (OpenRouter, Gemini-Credits). #### Ressourcen Richte jetzt einen OpenRouter-Account ein, damit der Modellwechsel für den Rest des Kurses reibungslos ist, und schnapp dir kostenlose Gemini-Credits aus dem Google AI Studio für günstige Experimente. Du wirst beides immer wieder nutzen. Die nächste Lektion geht vom Modell zum Tool, das es umhüllt. #### Deine Aufgabe Erstelle einen OpenRouter-Account und jage dann eine echte Aufgabe aus deiner Arbeit durch ein kleines, ein mittleres und ein grosses Modell. Schreib eine zweizeilige Notiz, welche Stufe tatsächlich gut genug war. Diese Notiz ist dein erstes echtes, persönliches Benchmark-Datum und sie wird deine Modellwahl über Monate leiten. #### Nächste Lektion Ein Modell für sich redet nur. Damit es Arbeit erledigt - Dateien lesen, Befehle ausführen, Code ändern - hüllst du es in ein Harness. Die nächste Lektion erklärt, was ein Harness ist, und vergleicht Claude Code, Codex, Pi und OpenCode, damit du weisst, zu welchem Tool du greifst. ### 1.3 Was ist ein Harness? Claude Code vs Codex vs Pi vs OpenCode - Kanonische URL: https://agenticschool.dev/de/kurse/foundations/what-is-a-harness-claude-code-vs-codex-vs-pi-vs-opencode - Dauer: 22 min Zusammenfassung: Ein Modell sagt Text voraus. Ein Harness macht daraus Handlung: Dateien lesen, Befehle ausführen, Code ändern, in Schleifen arbeiten, bis eine Aufgabe erledigt ist. Diese Lektion definiert das Harness klar und vergleicht die vier, die 2026 zählen - Claude Code, Codex, Pi und OpenCode -, inklusive der Fälle, in denen das minimale Pi-Harness das schwere Werkzeug echt schlägt. #### Überblick Das Modell ist der Motor. Das Harness ist das Auto darum herum: die Lenkung, die Pedale und die Werkzeuge, die den Motor tatsächlich irgendwohin fahren lassen. Ein Harness gibt dem Modell die Fähigkeit, Dateien zu lesen und zu schreiben, Terminal-Befehle auszuführen, die Ergebnisse zu sehen und in Schleifen zu arbeiten, bis der Job erledigt ist. Diese Lektion definiert das Harness und vergleicht die vier, die man 2026 kennen sollte, damit du aufhörst, das Modell mit dem Tool drumherum zu verwechseln. #### Was du lernst Du lernst, was ein Harness tut, warum sich dasselbe Modell in verschiedenen Harnesses sehr unterschiedlich verhält und wie sich Claude Code, Codex, Pi und OpenCode in Philosophie, Kontrolle und Integration vergleichen. Du gehst mit einer Entscheidungsregel raus, inklusive des nicht offensichtlichen Falls, in dem das winzige Pi-Harness das mächtige Claude Code schlägt. #### Voraussetzungen Die beiden vorigen Lektionen. Du solltest damit vertraut sein, dass ein Modell nur Tokens vorhersagt und dass Kontextdisziplin zählt, denn ein Harness ist weitgehend eine Maschine, um dem Modell den richtigen Kontext zu füttern und auf seinen Output zu reagieren. #### Das Problem Leute sagen "Claude ist besser als GPT" oder "Codex kann X nicht", meinen aber eigentlich das Harness, nicht das Modell. Dasselbe Claude-Modell wirkt in einem Tool brillant und in einem anderen plump, weil das Harness entscheidet, welche Dateien es sieht, welche Befehle es ausführen darf und wie es in Schleifen läuft. Wenn du Modell und Harness im Kopf nicht trennst, ziehst du die falschen Schlüsse und wählst das falsche Tool. #### Was ein Harness tatsächlich tut Ein Harness ist das Programm, das zwischen dir und dem Modell sitzt und dem Modell Hände gibt. In jedem Schritt sammelt es Kontext (deine Anweisung plus relevante Dateien und Befehlsausgaben), schickt ihn ans Modell, liest die vorgeschlagene Aktion zurück, führt diese Aktion in deiner Umgebung aus und füttert das Ergebnis zurück, damit das Modell den nächsten Schritt entscheiden kann. Diese Schleife - Kontext, Modell, Aktion, Ergebnis, wiederholen - ist das ganze Spiel. Alles, was ein Harness besser macht als ein anderes, ist eine Variation davon, wie gut es diese Schleife managt. - Liest und bearbeitet Dateien in deinem Projekt. - Führt Terminal-Befehle aus und liest ihre Ausgabe (Tests, Builds, Git). - Managt das Kontextfenster: entscheidet, was rein soll und wann komprimiert wird. - Läuft autonom in Schleifen, bis die Aufgabe erledigt ist oder es dich braucht. #### Claude Code Claude Code ist Anthropics offizielles Kommandozeilen-Harness, gebaut um Claude-Modelle. Es ist das Schwergewicht: tiefe Projektintegration, ein reichhaltiges Berechtigungssystem, Unterstützung für Projektregeln in einer CLAUDE.md-Datei, wiederverwendbare Skills, Hooks und Sub-Agents. Es ist das Tool, mit dem genau dieser Kurs gebaut und gepflegt wird. Wenn du einen Agent willst, der in einem echten Repository lebt, deine Tests laufen lässt, deine Konventionen respektiert und mehrschrittige Arbeit erledigt, ist Claude Code die Standardempfehlung. Der Haken ist, dass es meinungsstark und mächtig genug ist, um sich für winzige Einmal-Jobs schwer anzufühlen. #### Codex Codex ist OpenAIs Kommandozeilen-Coding-Agent, der GPT-Modelle umhüllt. Es ist pragmatisch und stark darin, unbekannten Code zu lesen, ihn zu erklären und fokussierte, gut abgegrenzte Änderungen zu machen. Wenn du im OpenAI-Ökosystem lebst oder zu einer kniffligen Änderung eine zweite Meinung von einem Modell der GPT-Familie willst, ist Codex ein natürlicher Griff. Behandle es als fähigen Kollegen von Claude Code statt als Rivalen, den man fürchten muss: viele ernsthafte Builder haben beide installiert und wählen je Aufgabe. #### Pi und OpenCode Pi ist der Minimalist. Es ist ein bewusst winziges, transparentes, erweiterbares Harness: du siehst genau, was es tut, und du biegst es zu deinem Workflow statt umgekehrt. OpenCode ist ein Open-Source-Harness im ähnlichen Geist, modellagnostisch und community-getrieben, oft mit Modellen genutzt, die über OpenRouter geroutet werden. Beide tauschen Handführung gegen Kontrolle und Transparenz. Die überraschende Wahrheit ist, dass für bestimmte Jobs - eine schnelle geskriptete Aufgabe, eine eigene Schleife, ein Setup, in dem du volle Sicht und null Magie willst - das minimale Harness das Schwergewicht schlägt, weil weniger zwischen dir und dem Modell steht und nichts versteckt ist. - Pi: minimal, transparent, hoch erweiterbar. Du besitzt das Verhalten. - OpenCode: Open Source, modellagnostisch, passt gut zu OpenRouter. - Wann minimal gewinnt: geskriptete oder wiederholbare Aufgaben, Setups mit voller Sicht, eigene Schleifen, oder wenn ein schweres Harness gegen deinen Workflow kämpft. #### Schritt für Schritt: eine Entscheidungsregel Du musst dich nicht abquälen. Jage deine Aufgabe durch diese Regel und wähle in Sekunden. Es geht darum, die Wahl nicht mehr als Loyalitätsfrage zu behandeln, sondern als Passungsfrage. - Tiefe Arbeit in einem echten Repo mit Tests, Konventionen und mehrschrittigen Änderungen: Claude Code. - Unbekannten Code lesen oder erklären, oder eine zweite Meinung von GPT: Codex. - Eine geskriptete, wiederholbare oder voll transparente eigene Schleife: Pi. - Open-Source-, modellagnostisches, über OpenRouter geroutetes Setup: OpenCode. - Unsicher: starte mit Claude Code, denn der Rest dieses Kurses setzt es voraus. #### Typische Fehler Der grosse Fehler ist, dem Modell die Schuld fürs Harness zu geben. Der zweite ist Tool-Stammesdenken - darauf zu beharren, ein Harness sei universell das beste, wenn die ehrliche Antwort "kommt auf die Aufgabe an" lautet. Der dritte ist, zum schwersten Werkzeug für triviale Jobs zu greifen, wo ein winziges Harness oder sogar ein schlichter Chat schneller wäre. Halt zwei Harnesses installiert und lass die Aufgabe entscheiden. #### Business-ROI Das richtige Harness zu wählen heisst zu wählen, wie viel von der Arbeit deines Teams du sicher an einen Agent delegieren kannst. Ein schweres Harness mit guten Projektregeln lässt dich echte Engineering-Aufgaben von Anfang bis Ende abgeben, und genau da summieren sich die Zeitersparnisse. Ein minimales Harness lässt dich günstige, transparente, wiederholbare Automationen bauen. Beide zu kennen heisst, dass du für einen einfachen Job nie zu viel an Komplexität zahlst und einen harten nie unterversorgst. #### Checkliste Vergewissere dich, dass du Folgendes kannst, bevor du weitergehst, denn die nächste Lektion wird bei der Installation praktisch. - Den Unterschied zwischen einem Modell und einem Harness in einem Satz erklären. - Die Schleife Kontext-Modell-Aktion-Ergebnis beschreiben. - Eine Aufgabe Claude Code, Codex, Pi oder OpenCode zuordnen. - Ein Beispiel nennen, wo ein minimales Harness Claude Code schlägt. #### Ressourcen Du musst noch nichts installieren - die nächste Lektion geht die Installation Schritt für Schritt durch. Halt für jetzt nur das mentale Modell fest: Das Modell ist der Motor, das Harness ist das Auto. Die Grundlagen-Seite zum Terminal hilft, wenn die Kommandozeile sich noch fremd anfühlt. #### Deine Aufgabe Schreib die eine Aufgabe auf, die du dir diese Woche am meisten von einem Agent erledigt wünschst, wende dann die Entscheidungsregel an und benenne das Harness, das du nutzen würdest. Du installierst es in der nächsten Lektion, also wähle etwas Echtes. #### Nächste Lektion Zeit, mit dem Lesen aufzuhören und mit dem Installieren anzufangen. Die nächste Lektion bringt Claude Code und Codex auf deinem Rechner zum Laufen, erklärt die Subscription-Pläne und macht den Fall, warum der 200-Dollar-pro-Monat-Plan für einen ernsthaften Builder eigentlich günstig ist. ### 1.4 Claude Code und Codex installieren und starten - Kanonische URL: https://agenticschool.dev/de/kurse/foundations/installing-and-running-claude-code-and-codex - Dauer: 26 min Zusammenfassung: Das ist die praktische Setup-Lektion. Du installierst Claude Code und Codex, führst deine erste echte Agent-Session aus, verstehst die 20-, 100- und 200-Dollar-Pläne (und warum 200 für einen ernsthaften Builder günstig ist) und richtest die grundlegenden Schutzmassnahmen ein, die dein Business und dein geistiges Eigentum von Tag eins an absichern. #### Überblick Genug Theorie. In dieser Lektion installierst du die beiden Coding Agents, führst deine erste Session aus und richtest die Schutzmassnahmen ein, die deine Arbeit sicher halten. Wir entmystifizieren auch die Subscription-Pläne, denn die Preisgestaltung verwirrt Leute echt und die falsche Wahl verschwendet entweder Geld oder drosselt dich mitten in der Aufgabe. #### Was du lernst Du installierst Claude Code und Codex, authentifizierst sie, führst eine erste Agent-Aufgabe aus, verstehst die 20-, 100- und 200-Dollar-Planstufen und richtest drei grundlegende Schutzmassnahmen ein, damit ein Agent nie ein Secret leakt oder Code anfasst, den er nicht anfassen sollte. #### Voraussetzungen Du brauchst Node.js installiert und etwas Vertrautheit damit, ein Terminal zu öffnen. Falls dir eines davon neu ist, behandeln die Grundlagen-Seiten zu Node.js und Terminal-Basics es von Grund auf - installiere zuerst Node.js und komm dann hierher zurück. Du willst ausserdem einen Code-Editor wie VS Code, der eine eigene Grundlagen-Seite hat. #### Das Problem Der Setup-Schritt ist der Punkt, an dem die meisten Einsteiger hängen bleiben. Sie sind unsicher, welchen Plan sie kaufen sollen, nervös, einem Agent Zugriff auf ihren Rechner zu geben, und besorgt um Sicherheit und Kosten. Also führen sie das Tool nie wirklich aus. Diese Lektion räumt jeden dieser Blocker der Reihe nach weg, damit du mit einem funktionierenden, sicheren Setup fertig wirst. #### Schritt für Schritt: Claude Code installieren Claude Code installiert sich über npm, den Paketmanager, der mit Node.js kommt. Öffne dein Terminal und führe den Installationsbefehl aus, starte es dann in einem Projektordner. Beim ersten Lauf wirst du gebeten, dich über deinen Browser einzuloggen, um deinen Anthropic-Account zu verbinden. ```bash # Die Claude Code CLI global installieren npm install -g @anthropic-ai/claude-code # In einen Projektordner wechseln (lege bei Bedarf einen an) mkdir my-first-app && cd my-first-app # Claude Code starten - beim ersten Lauf öffnet sich ein Browser zum Einloggen claude ``` Claude Code installieren und starten Sobald es startet, red einfach mit ihm. Probier: "Erstelle eine README.md, die erklärt, dass dies mein erstes mit KI gebautes Projekt ist." Sieh zu, wie es die Änderung vorschlägt, um Erlaubnis fragt und die Datei schreibt. Diese Schleife - vorschlagen, Erlaubnis, handeln - ist das Sicherheitsmodell, auf das du dich verlässt. #### Schritt für Schritt: Codex installieren Codex ist OpenAIs CLI und installiert sich genauso. Beide zu haben gibt dir eine zweite Meinung und einen Rückfall, wenn ein Anbieter ausgelastet ist oder ein bestimmtes Modell besser zur Aufgabe passt. ```bash # Die Codex CLI global installieren npm install -g @openai/codex # Sie in deinem Projekt starten codex ``` Codex installieren und starten Authentifiziere dich mit deinem OpenAI-Account, wenn du dazu aufgefordert wirst. Führe eine kleine Aufgabe aus, um zu bestätigen, dass es funktioniert, etwa indem du es bittest, die gerade erstellte README zu erklären. Du hast jetzt zwei Coding Agents installiert. #### Die Pläne verstehen: 20, 100 und 200 Dollar Anthropic bietet Claude in gestaffelten Plänen an, und dieselbe Logik gilt für OpenAI. Der 20-Dollar-Plan ist für leichte, gelegentliche Nutzung. Der 100-Dollar-Plan passt zu regelmässigen täglichen Nutzern. Der 200-Dollar-Plan ist für schwere Ganztags-Builder und gibt dir die grosszügigste Nutzung der stärksten Modelle. Die ehrliche Einordnung: Wenn du fürs Bauen lebst, sind 200 Dollar im Monat günstig. Eine Stunde der Zeit einer Entwicklerin kostet mehr als das, und ein ernsthafter Plan spart dir jede einzelne Woche viele Stunden. Die teure Option ist der günstige Plan, der dich mitten in echter Arbeit drosselt. - 20 Dollar/Monat: leichte Nutzung, Abende und Wochenenden, Lernen. - 100 Dollar/Monat: täglicher Begleiter für die meisten Profis. - 200 Dollar/Monat: schweres Ganztags-Bauen, maximaler Zugang zu Top-Modellen. - Umdeuten: vergleiche den Plan mit einer abrechenbaren Stunde, nicht mit einem Streaming-Abo. Er rechnet sich binnen Tagen durch gesparte Zeit. #### Dein Business und IP schützen Ein Agent führt Befehle aus und bearbeitet Dateien, also sind grundlegende Schutzmassnahmen von Tag eins an nicht verhandelbar. Nichts davon ist schwer, und es zu überspringen ist, wie Einsteiger API-Keys leaken oder privaten Code ins öffentliche Internet pushen. Richte diese drei Schutzmassnahmen ein, bevor du echte Arbeit machst. - Nutze private Repositories. Wenn du dich mit GitHub verbindest, stell jedes Business-Projekt standardmässig auf privat, damit dein Code und IP nicht öffentlich sichtbar sind. - Committe nie Secrets. API-Keys, Passwörter und Tokens leben in einer .env-Datei, die in .gitignore steht, damit sie nie zu GitHub geschickt wird. Der Agent darf nie ein Secret in committeten Code schreiben. - Lauf mit sinnvollen Berechtigungen. Lass den Agent anfangs fragen, bevor er Befehle ausführt, damit du siehst, was er tun will. Lockere das erst, wenn du dem Workflow vertraust. Beide Tools respektieren auch eine Projektregel-Datei (CLAUDE.md für Claude Code, AGENTS.md für Codex), in der du diese Schutzmassnahmen in klarer Sprache festhältst, damit der Agent ihnen automatisch folgt. Die bauen wir in Kurs 2 richtig auf. #### Typische Fehler Die häufigen Fehler hier sind, den falschen Plan zu kaufen und dann zu schliessen "KI ist nicht gut genug", obwohl du eigentlich nur gedrosselt wurdest; pauschale Auto-Run-Berechtigungen zu geben, bevor du das Tool verstehst; und Arbeit ohne .gitignore zu beginnen, sodass ein Secret in deinem ersten Commit landet. Jeder davon ist mit den Schritten oben vermeidbar. #### Business-ROI Ein korrekt eingerichteter Agent ist die wirkungsvollste Einstellung, die du je machst, sofort verfügbar und unermüdlich. Die Plankosten sind nichtig gegen die gesparten Stunden, aber nur, wenn du eine Stufe wählst, die zu deiner Nutzung passt, und Schutzmassnahmen einrichtest, damit du selbstbewusst delegieren kannst. Gründer, die den 200-Dollar-Plan als teuer ansehen, optimieren meist den falschen Posten um den Faktor zehn. #### Checkliste Du bist fertig, wenn alles Folgende stimmt. Geh nicht weiter, bis jedes Kästchen wirklich abgehakt ist, denn der Rest des Kurses setzt einen funktionierenden Agent voraus. - Claude Code installiert, authentifiziert, und es hat eine Datei für dich geschrieben. - Codex installiert und authentifiziert. - Du hast einen Plan gewählt, der zu deiner echten Nutzung passt. - Eine .gitignore existiert, Secrets leben in .env, und dein Projekt steht standardmässig auf einem privaten Repo. #### Ressourcen Wenn Installationsbefehle fehlschlagen, ist die übliche Ursache ein fehlendes oder veraltetes Node.js - schau nochmal in die Node.js-Grundlagen-Seite. Halt die offiziellen Claude-Code- und Codex-Docs für Flags und Updates als Lesezeichen. Die nächste Lektion bringt dir bei, wie du tatsächlich mit diesen Agents redest, damit sie liefern. #### Deine Aufgabe Installiere beide Agents, erstelle einen frischen Projektordner mit einer .gitignore und einer leeren .env und lass Claude Code eine einfache HTML-Seite generieren, die hallo sagt. Bestätige, dass der Agent vor dem Schreiben um Erlaubnis gefragt hat. Du hast jetzt ein sicheres, funktionierendes Setup und deine erste vom Agent gebaute Datei. #### Nächste Lektion Du hast die Tools. Jetzt musst du sie fahren. Die nächste Lektion ist Prompt Engineering, das wirklich funktioniert: Axiome, das Unlimited-Budget-Framing, den Agent um Widerspruch bitten und Spec Sheets schreiben, die beim ersten Versuch grossartige Ergebnisse bringen. ### 1.5 Mit Agents reden: Prompt Engineering, das wirklich funktioniert - Kanonische URL: https://agenticschool.dev/de/kurse/foundations/talking-to-agents-prompt-engineering-that-actually-works - Dauer: 24 min Zusammenfassung: Einen Agent zu prompten ist keine Zauberei, sondern klare Führung. Diese Lektion vermittelt die Techniken, die Qualität wirklich bewegen: Axiome und Projektverträge schreiben, das Unlimited-Budget-Framing, gezielt um Widerspruch bitten und aus einer vagen Idee ein Spec Sheet machen, das der Agent ohne Raten ausführen kann. #### Überblick Der mit Abstand grösste Sprung bei den Ergebnissen kommt nicht von einem besseren Modell, sondern von einem besseren Briefing. Gut mit einem Agent zu reden ist eine Führungskompetenz: du setzt klare Regeln, framest die Arbeit auf Qualität statt Abkürzungen, lädst Widerspruch ein und übergibst eine Spezifikation statt eines Bauchgefühls. Diese Lektion gibt dir die konkreten Muster, die frustrierende Sessions von Agents trennen, die es beim ersten Mal treffen. #### Was du lernst Du lernst, Axiome zu schreiben (nicht verhandelbare Regeln), das Unlimited-Budget-Framing zu nutzen, das den Agent vom Ecken-Abschneiden abhält, explizit um Widerspruch zu bitten, damit der Agent deine Fehler fängt, und eine vage Anfrage in ein Spec Sheet mit Ziel, Kontext, Constraints und Akzeptanzkriterien zu verwandeln. #### Voraussetzungen Ein funktionierendes Claude-Code- oder Codex-Setup aus der vorigen Lektion. Du solltest dich auch an die Kontext-Lektionen erinnern: ein grossartiger Prompt besteht teils darin, den richtigen Kontext zu geben, nicht nur die richtigen Worte. #### Das Problem Das klassische Scheitern ist der einzeilige Wunsch: "bau mir eine Website". Der Agent muss die Zielgruppe, den Stack, das Design, den Umfang und die Definition von "fertig" raten, und er rät falsch. Dann gibst du der KI die Schuld. Das eigentliche Problem ist, dass du einen Dienstleister mit fünf Worten gebrieft und ein fertiges Haus erwartet hast. Gutes Prompten nimmt das Raten weg. #### Axiome: die Regeln einmal festlegen Axiome sind nicht verhandelbare Regeln, die du vorab festlegst, damit der Agent aufhört, sie bei jeder Aufgabe neu zu entscheiden. Statt dasselbe zehnmal zu korrigieren, schreibst du es als Regel. "Nutze immer TypeScript. Verwende nie Em-Dashes. Jedes neue Feature braucht einen Test. Committe nie Secrets." Die lesen sich wie ein Vertrag, und der Agent behandelt sie als Constraints statt als Vorschläge. In Kurs 2 verschiebst du diese in eine dauerhafte CLAUDE.md, aber selbst oben in eine Session eingefügt heben sie die Konstanz deutlich. - Formuliere Regeln als Absolute: "Immer...", "Nie...", "Jedes... muss...". - Deck Stil, Stack, Tests, Sicherheit und Ton ab - die Dinge, die du immer wieder korrigierst. - Halt sie kurz und eindeutig; ein Agent folgt einer knackigen Regel besser als einem Absatz voller Nuancen. #### Das Unlimited-Budget-Framing Agents tendieren wie Junior-Mitarbeitende zur schnellsten akzeptablen Antwort. Wenn du Weltklasse-Arbeit willst, musst du das sagen. Die Aufgabe so zu framen, als wären Budget und Zeit unbegrenzt - "tu das Richtige für die langfristige Gesundheit dieses Projekts, nicht das Einfache; schneide keine Ecken ab" -, hebt die Qualität messbar, weil es dem Agent erlaubt, Tests zu ergänzen, Randfälle zu behandeln und zu refaktorieren, statt den schnellsten Fix draufzuschrauben. Es klingt weich, aber es verschiebt den Output verlässlich von "funktioniert technisch" zu "ist tatsächlich gut". #### Um Widerspruch bitten Standardmässig ist ein Agent zustimmend und setzt eine schlechte Idee bereitwillig um. Die Lösung ist ein Satz: "Bevor du anfängst, sag mir alles, was an diesem Plan falsch ist, alles, was ich übersehen habe, und einen besseren Ansatz, falls es einen gibt." Das macht aus dem Agent statt eines Befehlsempfängers einen Berater. Er fängt fehlende Anforderungen, weist auf Sicherheitslücken hin und schlägt einfachere Designs vor. Einige der wertvollsten Momente in agentischer Arbeit kommen daher, dass der Agent dir widerspricht - aber nur, wenn du ihm dafür explizit die Erlaubnis gibst. #### Schritt für Schritt: ein Spec Sheet schreiben Ein Spec Sheet ist der Unterschied zwischen einem vagen Wunsch und einem ausführbaren Briefing. Es muss nicht lang sein. Vier Teile reichen, und sie zu schreiben zwingt dich, die Entscheidungen zu treffen, die der Agent sonst raten würde. - Ziel: was existieren soll, wenn das fertig ist, in ein bis zwei Sätzen. - Kontext: der Stack, die relevanten Dateien, Beispiele zum Folgen und alles, was der Agent nicht ableiten kann. - Constraints: deine Axiome plus aufgabenspezifische Grenzen (keine neuen Dependencies, muss auf Mobile funktionieren, und so weiter). - Akzeptanzkriterien: eine konkrete Checkliste, die "fertig" definiert, damit du und der Agent wissen, wann Schluss ist. ```markdown ## Ziel Ein Kontaktformular auf der Landingpage, das mir Eingaben per E-Mail schickt. ## Kontext - Stack: dieses Astro-Projekt, vorhandene Styles in src/styles. - Folge dem Button-Stil, der bereits in der Hero-Section genutzt wird. ## Constraints - Nur TypeScript. Keine neue UI-Library. - Den E-Mail-API-Key nie im Client-Code offenlegen. - Einen Test für die Formularvalidierung ergänzen. ## Akzeptanzkriterien - [ ] Formular validiert Name und E-Mail vor dem Absenden. - [ ] Absenden zeigt eine Erfolgsmeldung. - [ ] Der Validierungstest besteht. ``` Ein minimales, aber vollständiges Spec Sheet, das du in den Agent einfügen kannst #### Typische Fehler Die wiederkehrenden Fehler: der einzeilige Wunsch ohne Spec; nie Axiome festlegen, sodass du dieselben Dinge ewig korrigierst; die erste Antwort akzeptieren, statt um Widerspruch zu bitten; und den Prompt mit irrelevantem Kontext vollstopfen, was den Performance-Cliff aus Lektion eins auslöst. Knappe, strukturierte Briefings schlagen lange, weitschweifige. #### Business-ROI Briefing-Kompetenz ist der Multiplikator auf alles andere. Derselbe Agent und dasselbe Modell liefern mittelmässige oder hervorragende Arbeit, je ganz nach Briefing, und ein gutes Spec Sheet verwandelt oft drei frustrierende Runden in eine saubere Lieferung. Für eine Gründerin ist es der günstigste mögliche Weg, den Wert jedes KI-Abos, das du ohnehin zahlst, zu verdreifachen. #### Checkliste Bevor du weitergehst, stell sicher, dass du jedes davon auf Abruf produzieren kannst, denn jede spätere Lektion setzt voraus, dass du einen Agent gut briefen kannst. - Eine kurze Liste von Axiomen für deine eigenen Projekte. - Eine auf Qualität geframte Aufgabe mit den Zeilen Unlimited-Budget und Pushback. - Ein vierteiliges Spec Sheet für ein echtes Feature. - Ein ehrliches Gespür dafür, wann dein Prompt zu lang ist, nicht zu kurz. #### Ressourcen Speichere deine Axiome irgendwo wiederverwendbar - du fügst sie in Kurs 2 in eine CLAUDE.md ein. Das Agent-Task-Brief-Template in der Ressourcen-Bibliothek ist ein fertiges Spec-Sheet-Gerüst zum Kopieren. Als Nächstes setzt du all das ein, um ein echtes Projekt zu bauen. #### Deine Aufgabe Nimm die Projektidee, die du vor zwei Lektionen gewählt hast, und schreib ein vollständiges Spec Sheet für ihr erstes Feature, inklusive deiner Axiome, dem Unlimited-Budget-Framing und der Pushback-Bitte. Übergib es deinem Agent und beachte, wie viel schärfer das Ergebnis ist, als es ein einzeiliger Prompt wäre. #### Nächste Lektion Du kannst einen Agent briefen. Jetzt baust du etwas Echtes. Die nächste Lektion scaffoldet ein echtes Projekt, startet einen Dev Server, damit du es im Browser siehst, und stellt es unter Versionskontrolle mit Git und einem privaten GitHub-Repo. ### 1.6 Dein erstes Projekt: Scaffolding, Dev Server, Git und GitHub - Kanonische URL: https://agenticschool.dev/de/kurse/foundations/your-first-project-scaffolding-dev-server-git-and-github - Dauer: 26 min Zusammenfassung: Jetzt baust du. Diese Lektion scaffoldet ein echtes Webprojekt mit deinem Agent, startet den Dev Server, sodass du es live im Browser siehst, und bringt alles unter Versionskontrolle mit Git und einem privaten GitHub-Repository - ohne je ein Secret zu committen. Das ist der Moment, in dem deine Idee zu einer laufenden Sache wird. #### Überblick Das ist die Lektion, in der das Abstrakte konkret wird. Du scaffoldest ein echtes Projekt, führst es in deinem Browser aus und stellst es unter Versionskontrolle in einem privaten GitHub-Repo. Am Ende hast du eine lokal laufende App und eine sichere, gesicherte Historie deiner Arbeit - das Fundament, auf dem jedes spätere Projekt aufbaut. #### Was du lernst Du scaffoldest ein Projekt mit deinem Agent, startest einen Dev Server und siehst es unter localhost, verstehst, was Git und Commits tatsächlich tun, und pushst deinen Code in ein privates GitHub-Repository mit sicher ausgeschlossenen Secrets. Das sind die alltäglichen Bewegungen des Bauens, also machen wir sie jetzt zur Muskelerinnerung. #### Voraussetzungen Ein funktionierendes Agent-Setup, Node.js und ein GitHub-Account (kostenlos). Die Grundlagen-Seiten zu Git, GitHub, dem Terminal und dazu, was ein Dev Server ist, helfen, falls dir ein Begriff hier neu ist - überflieg sie und komm dann zurück. Du musst keine Git-Befehle auswendig können; der Agent führt die meisten aus, aber du solltest verstehen, was sie tun. #### Das Problem Einsteiger bleiben zwischen "Ich habe eine Idee" und "es läuft auf meinem Bildschirm" stecken. Sie sind unsicher, wie sie ein Projekt starten, haben Angst vor dem Terminal und sind von Git verwirrt. Das Ergebnis ist ein Ordner voller Dateien ohne Historie und ohne Backup, in dem eine schlechte Änderung Stunden Arbeit verliert. Diese Lektion schliesst diese Lücke richtig. #### Schritt für Schritt: scaffolden und ausführen Statt ein Framework auswendig zu lernen, bitte deinen Agent, einen modernen Starter zu scaffolden und jeden Schritt zu erklären. Eine häufige, einsteigerfreundliche Wahl ist ein Vite-basiertes Projekt, aber der genaue Stack zählt weniger als das Verstehen des Ablaufs: Projekt erstellen, Dependencies installieren, Dev Server starten, Browser öffnen. ```bash # Ein neues Vite-Projekt scaffolden (dein Agent kann das für dich ausführen) npm create vite@latest my-first-app # Reingehen und die benötigten Dependencies installieren cd my-first-app npm install # Den lokalen Dev Server starten npm run dev ``` Ein Projekt scaffolden und den Dev Server starten Der Dev Server gibt eine lokale Adresse aus, meist etwas wie http://localhost:5173. Öffne sie in deinem Browser und du siehst deine App auf deinem eigenen Rechner laufen. "localhost" heisst schlicht "dieser Computer" - noch ist nichts im öffentlichen Internet, was beim Bauen genau richtig ist. Bearbeite eine Datei, speichere, und der Browser aktualisiert sich sofort. Diese Live-Schleife lässt Webbauen sich schnell anfühlen. #### Was Git tatsächlich tut Git ist Versionskontrolle: es macht Schnappschüsse deines Projekts namens Commits, damit du immer zurück kannst. Stell es dir als unbegrenzte Rückgängig-Historie mit Etiketten vor. Jeder Commit hält fest, was sich geändert hat und warum, was bedeutet, dass eine schlechte Änderung nie eine Katastrophe ist - du kehrst einfach zum letzten guten Commit zurück. Diese eine Gewohnheit nimmt die Angst weg, die Einsteiger vom Experimentieren abhält, weil nichts, was du tust, endgültig ist, bis du es entscheidest. ```bash # Dieses Projekt mit Git zu tracken beginnen git init # Alle aktuellen Dateien für den ersten Schnappschuss vormerken git add . # Den Schnappschuss mit einer beschreibenden Nachricht speichern git commit -m "Initial project scaffold" ``` Einen Ordner in ein versionskontrolliertes Projekt verwandeln #### Secrets draussen halten, bevor du committest Bevor du je zu GitHub pushst, stell sicher, dass Secrets nicht entkommen können. Eine .gitignore-Datei listet Dinge auf, die Git ignorieren soll. Deine .env-Datei - in der API-Keys leben - und der node_modules-Ordner gehören beide dorthin. Mach das einmal richtig und du veröffentlichst nie versehentlich einen Key. Dein Agent kann diese Datei erstellen, aber du solltest eine korrekte erkennen können. ```bash # .gitignore - sagt Git, was es nie tracken soll node_modules .env .env.local dist ``` Eine minimale .gitignore, die Secrets und Build-Output schützt Die Regel ist absolut: Secrets gehen in .env, .env geht in .gitignore, und der Agent schreibt nie einen Key in committeten Code. Wenn du dir von der Sicherheit aus diesem Kurs sonst nichts merkst, merk dir das. #### Schritt für Schritt: in ein privates GitHub-Repo pushen GitHub speichert dein Repository in der Cloud: ein Backup, eine Historie und später das, womit sich dein Deployment verbindet. Erstelle das Repository als privat, damit dein Business-Code dir gehört. Der Agent kann das meiste davon, aber hier ist, was unter der Haube passiert. ```bash # Ein PRIVATES Repo erstellen und pushen, mit der GitHub CLI gh repo create my-first-app --private --source=. --push # Oder, falls du das Repo zuerst auf github.com erstellt hast: git remote add origin https://github.com/yourname/my-first-app.git git push -u origin main ``` Deinen Code in ein privates GitHub-Repository veröffentlichen Privat ist der Standard, den du für alles Kommerzielle willst. Öffentliche Repos sind grossartig für Open Source, aber dein Business-IP sollte privat starten und nur bewusst öffentlich gehen, nach einem Security-Review - ein Thema, das Kurs 5 ausführlich behandelt. #### Typische Fehler Die schmerzhaften: eine .env-Datei mit einem aktiven API-Key committen (jetzt für immer in deiner Historie, auch wenn du sie später löschst); nie git commit ausführen, sodass es keine Historie zum Zurücksetzen gibt; ein öffentliches Repo für privaten Business-Code erstellen; und am Terminal in Panik geraten, statt den Agent die Befehle ausführen zu lassen, während du liest, was sie tun. Mach langsam, lies jeden Befehl und committe früh und oft. #### Business-ROI Versionskontrolle ist günstige Versicherung mit enormem Nutzen. Ein einziger behebbarer Fehler - eine kaputte Änderung in Sekunden zurücksetzen statt sie stundenlang neu zu bauen - bezahlt die Gewohnheit vielfach. Ein privates Repo schützt das IP, auf dem dein Business steht. Und eine lokal laufende App heisst, dass du schnell iterieren kannst, was der ganze Sinn des Bauens mit Agents ist. #### Checkliste Du bist bereit zu shippen, sobald jedes davon stimmt. Überspring die Secret-Sicherheitspunkte nicht - sie zählen mehr, als sie aussehen. - Dein Projekt läuft lokal und du kannst es unter localhost öffnen. - Das Projekt ist ein Git-Repo mit mindestens einem Commit. - .env steht in .gitignore und enthält in keiner committeten Datei Secrets. - Der Code ist in ein PRIVATES GitHub-Repository gepusht. #### Ressourcen Die Grundlagen-Seiten zu Git, GitHub und dem Dev Server sind deine Referenz, falls ein Schritt wackelig war. Die Claude-Code-Setup-Checkliste in der Ressourcen-Bibliothek hält diese Schutzmassnahmen als wiederverwendbare Liste fest. Ein Schritt bleibt: das hier von deinem Rechner ins öffentliche Internet zu bringen. #### Deine Aufgabe Scaffolde ein kleines Projekt, führ es lokal aus, mach mindestens zwei Commits, während du etwas änderst, und pushe es in ein privates GitHub-Repo mit einer korrekten .gitignore. Bestätige auf github.com, dass deine .env nirgends zu finden ist. Du hast jetzt ein echtes, versionskontrolliertes, gesichertes Projekt. #### Nächste Lektion Deine App läuft auf deinem Rechner. Die letzte Lektion dieses Kurses bringt sie ins öffentliche Internet: Deploy auf Vercel, eine echte Domain verbinden und DNS und Cloudflare handhaben, damit jeder auf der Welt deine Seite besuchen kann. ### 1.7 Ship it: Deploy auf Vercel, Domain verbinden, DNS und Cloudflare - Kanonische URL: https://agenticschool.dev/de/kurse/foundations/ship-it-deploy-to-vercel-connect-a-domain-dns-and-cloudflare - Dauer: 24 min Zusammenfassung: Die Ziellinie. Du deployst dein Projekt auf Vercel, sodass es live im öffentlichen Internet ist, verbindest eine echte eigene Domain und verstehst DNS und Cloudflare gut genug, um jede Domain auf jede Seite zu zeigen. Wenn diese Lektion endet, hast du eine echte, öffentliche Website mit KI veröffentlicht - genau das, was Kurs 1 versprochen hat. #### Überblick Das ist die Lektion, die aus einem lokalen Projekt eine echte Website macht, die jeder besuchen kann. Du verbindest dein GitHub-Repo mit Vercel, bekommst in Minuten eine Live-URL, zeigst eine eigene Domain darauf und verstehst DNS und Cloudflare gut genug, um nie wieder Angst vor ihnen zu haben. Schliess das ab und du hast getan, was der ganze Kurs versprochen hat: eine echte App mit KI gebaut und veröffentlicht. #### Was du lernst Du deployst aus deinem privaten GitHub-Repo auf Vercel, richtest automatische Deploys bei jedem Push ein, verbindest eine eigene Domain, verstehst, was DNS-Records tun, und nutzt Cloudflare für DNS, kostenloses HTTPS und grundlegenden Schutz. Keine vorherige Hosting-Erfahrung nötig. #### Voraussetzungen Ein Projekt, das aus der vorigen Lektion in ein privates GitHub-Repo gepusht ist, und ein kostenloser Vercel-Account. Die Grundlagen-Seite zu DNS vertieft den Domain-Abschnitt, aber diese Lektion erklärt genug, um dich live zu bringen. Falls du noch keine Domain besitzt, kannst du zuerst auf der kostenlosen Vercel-URL shippen und später eine Domain ergänzen. #### Das Problem Einsteiger bauen oft etwas Gutes und dann stirbt es auf ihrem Laptop, weil Deployment sich wie eine Wand aus unbekannten Worten anfühlt: Hosting, DNS, Nameserver, SSL, CDN. Also geht das Projekt nie live und bekommt nie Feedback. Diese Lektion löst diese Wand auf, indem sie es einmal, der Reihe nach, macht und den Jargon erklärt, sobald er auftaucht. #### Schritt für Schritt: auf Vercel deployen Vercel ist eine Hosting-Plattform, die genau dafür gebaut ist. Der glatteste Weg ist, dein GitHub-Repo zu verbinden: Vercel beobachtet es und deployt jedes Mal automatisch neu, wenn du pushst. Du fasst das Terminal kaum an. - Melde dich bei Vercel mit deinem GitHub-Account an. - Klick auf "Add New Project" und importiere dein privates Repository - Vercel kann private Repos lesen, sobald du es autorisierst. - Vercel erkennt Framework und Build-Einstellungen automatisch; für eine Standard-Vite- oder Next.js-App kannst du die Defaults akzeptieren. - Klick auf Deploy. In ein, zwei Minuten bekommst du eine Live-URL wie my-first-app.vercel.app, die jeder auf der Welt öffnen kann. Von jetzt an löst jeder git push auf deinen main-Branch automatisch ein neues Deploy aus. Das ist der moderne Workflow: du baust lokal, pushst, und deine Live-Seite aktualisiert sich selbst. Wenn du Umgebungsvariablen (deine Secrets) im Vercel-Dashboard statt im Code setzt, bleiben sie sicher und berühren nie dein Repo - dieselbe .env-Disziplin aus der letzten Lektion, in Produktion angewandt. #### Was DNS tatsächlich ist DNS, das Domain Name System, ist das Telefonbuch des Internets. Es übersetzt einen menschlichen Namen wie yoursite.com in die Adresse des Servers, der antworten soll. Wenn du "eine Domain verbindest", fügst du diesem Telefonbuch Einträge hinzu, die sagen "für diesen Namen schick Besucher zu Vercel". Die beiden Records, die dir am häufigsten begegnen, sind ein A-Record (zeigt eine Domain auf eine IP-Adresse) und ein CNAME (zeigt einen Namen auf einen anderen Namen). Das ist ehrlich gesagt das meiste, was du zum Shippen wissen musst. - A-Record: bildet eine Domain oder Subdomain auf eine numerische IP-Adresse ab. - CNAME-Record: bildet einen Namen auf einen anderen Namen ab (zum Beispiel www auf dein Vercel-Ziel). - Nameserver: entscheiden überhaupt erst, welche Firma dein DNS-Telefonbuch hält. - Propagation: DNS-Änderungen können Minuten bis ein paar Stunden brauchen, um sich weltweit zu verbreiten - nicht kaputt, nur langsam. #### Schritt für Schritt: eine eigene Domain verbinden Öffne in Vercel dein Projekt, geh zu den Domain-Einstellungen und füge deine Domain hinzu. Vercel sagt dir dann genau, welche DNS-Records du bei deinem Domain-Anbieter erstellen sollst. Du kopierst diese Records in die DNS-Einstellungen deines Anbieters, speicherst und wartest auf die Propagation. Vercel verifiziert die Verbindung und stellt automatisch ein kostenloses HTTPS-Zertifikat aus, sodass deine Seite sicher mit dem Schloss lädt. - Füge deine Domain in den Vercel-Projekteinstellungen hinzu. - Kopiere die A- und/oder CNAME-Records, die Vercel dir gibt. - Füge sie bei deinem DNS-Anbieter ein und speichere. - Warte auf die Verifizierung, besuche dann deine Domain - sie liefert nun deine Live-Seite über HTTPS aus. #### Wo Cloudflare reinpasst Cloudflare ist ein beliebter Ort, um DNS zu verwalten, und es tut mehr als Records zu halten. Zeig die Nameserver deiner Domain auf Cloudflare und du bekommst ein sauberes DNS-Dashboard, kostenloses HTTPS, ein globales Content Delivery Network, das deine Seite weltweit schneller laden lässt, und grundlegenden Schutz gegen Angriffe und Bots. Für die meisten Builder ist das Muster: Domain irgendwo registriert, DNS bei Cloudflare verwaltet, Seite auf Vercel gehostet, mit Cloudflares Records, die auf das Vercel-Ziel zeigen. Du brauchst nicht jedes Cloudflare-Feature am ersten Tag - kostenloses DNS, HTTPS und CDN sind Grund genug, es zu nutzen. #### Typische Fehler Die häufigen: annehmen, die Seite sei kaputt, wenn DNS einfach noch nicht propagiert ist (warten, dann erneut prüfen); die falschen DNS-Records bearbeiten oder veraltete liegen lassen, die kollidieren; vergessen, Umgebungsvariablen in Vercel zu setzen, sodass der Live-Seite ihre Secrets fehlen; und so durch Cloudflare proxen, dass HTTPS doppelt behandelt wird. Wenn etwas falsch aussieht, prüf Propagation und Umgebungsvariablen, bevor du das Schlimmste annimmst. #### Business-ROI Beim Shippen erscheint endlich Wert. Ein Projekt auf deinem Laptop verdient nichts; eine Live-Seite kann Kunden gezeigt, von Google indexiert, von KI empfohlen und mit echtem Feedback iteriert werden. Automatische Deploys heissen, dass eine Verbesserung zu shippen dich einen einzigen git push kostet, sodass die Schleife von Idee zu Live-Update Minuten dauert, nicht Tage. Diese Geschwindigkeit ist der gesamte Wettbewerbsvorteil dieser Bauweise. #### Checkliste Du hast Kurs 1 abgeschlossen, wenn alles davon stimmt. Nimm dir einen Moment - das ist ein echter Meilenstein. - Dein Projekt ist auf Vercel deployed und live unter einer öffentlichen URL. - Jeder git push deployt die Seite automatisch neu. - Secrets leben in Vercel-Umgebungsvariablen, nicht im Repo. - Eine eigene Domain (oder die Vercel-URL) lädt deine Seite über HTTPS. #### Ressourcen Halt die Vercel- und Cloudflare-Dashboards als Lesezeichen und lehn dich an die DNS-Grundlagen-Seite, wann immer Records dich verwirren. Die Vercel-Deploy-Checkliste in der Ressourcen-Bibliothek hält diese Schritte fürs nächste Mal fest. Du hast jetzt die ganze Schleife durchlaufen: Idee, Bauen, Versionskontrolle, Shippen. #### Deine Aufgabe Deploye dein Projekt auf Vercel und bestätige, dass es unter einer öffentlichen URL lädt. Falls du eine Domain besitzt, verbinde sie über DNS und bestätige, dass HTTPS funktioniert. Mach dann eine kleine Änderung lokal, committe, pushe und sieh zu, wie Vercel automatisch neu deployt. Glückwunsch: du hast eine echte Website mit KI gebaut und veröffentlicht. #### Nächste Lektion Du kannst eine Idee jetzt den ganzen Weg bis zu einer Live-Seite bringen. Kurs 2, Claude Code Mastery, macht aus dem Agent statt eines hilfreichen Tools einen verlässlichen Power-User-Workflow: Projektregeln, wiederverwendbare Skills, automatisierte Quality Gates, MCP und Multi-Agent-Systeme. ### 2.1 CLAUDE.md und AGENTS.md: Deinem Agent die Regeln beibringen - Kanonische URL: https://agenticschool.dev/de/kurse/claude-code-mastery/claude-md-and-agents-md-teaching-your-agent-the-rules - Dauer: 24 min Zusammenfassung: Eine Projektregel-Datei ist das mit Abstand wirkungsvollste Upgrade für deinen Agent. CLAUDE.md (für Claude Code) und AGENTS.md (für Codex und andere Harnesses) sagen dem Agent deine Konventionen, deinen Stack, deine Schutzmassnahmen und deinen Ton ein einziges Mal, damit er aufhört, sie bei jeder Aufgabe neu zu entscheiden. Diese Lektion zeigt dir, wie du eine schreibst und sie als kontinuierlich lernendes Markdown-System betreibst, in dem jede Korrektur, die du machst, für immer festgehalten wird. #### Überblick CLAUDE.md und AGENTS.md sind schlichte Markdown-Dateien, die in deinem Repository liegen und die der Agent zu Beginn jeder Session automatisch liest. Sie halten deine Axiome, deinen Stack, deine Konventionen, deine Sicherheitsregeln und deinen Ton. Eine gute zu schreiben ist der Unterschied zwischen dem ewigen Korrigieren derselben fünf Fehler und einem Agent, der dein Projekt einfach versteht. Die tiefere Idee, die sich aufaddiert, ist, die Datei als lebende Skills-Library zu behandeln: jeder Gotcha, auf den du stösst, wandert einmal in eine Markdown-Datei und kostet dich nie wieder etwas. #### Was du lernst Du lernst genau, was in eine Projektregel-Datei gehört, wie du Regeln als knackige Axiome formulierst, denen der Agent tatsächlich folgt, den Unterschied zwischen einer Root-CLAUDE.md und der AGENTS.md, die Codex und andere Harnesses lesen, und wie du aus der Datei ein kontinuierlich lernendes System machst, in dem jede wiederholte Korrektur zur dauerhaften Regel wird. Am Ende hast du eine echte Datei, die du heute in dein eigenes Projekt einfügen kannst. #### Voraussetzungen Ein funktionierendes Claude-Code-Setup und die Prompt-Engineering-Lektion aus Kurs 1, denn die Axiome, die du dort geschrieben hast, wandern direkt in diese Datei. Du solltest ausserdem ein versionskontrolliertes Projekt aus Kurs 1 haben, denn die Regel-Datei lebt im Repo und wird neben deinem Code committet, damit das ganze Projekt dieselben Standards teilt. #### Das Problem Du korrigierst den Agent. Er nutzt den falschen Paketmanager, du behebst es. Er fügt ein Em-Dash ein, du behebst es. Er überspringt den Test, du behebst es. Nächste Session, frischer Kontext, dieselben drei Fehler. Du zahlst Tokens und Aufmerksamkeit, um dieselben Lektionen immer wieder neu beizubringen, weil nichts von dem, was du gesagt hast, überdauert hat. Der Agent ist nicht dumm, er hat nur kein Gedächtnis zwischen Sessions. Eine Regel-Datei ist dieses Gedächtnis. Ohne sie startet dein Agent jeden Tag mit Amnesie und du bist sein Vollzeit-Aufpasser. #### Was eine Regel-Datei tatsächlich ist CLAUDE.md ist eine Markdown-Datei, die Claude Code automatisch lädt und als stehende Anweisung für die ganze Session behandelt. Leg sie in die Wurzel deines Repos für projektweite Regeln. Du kannst auch eine persönliche unter ~/.claude/CLAUDE.md halten für Regeln, die dir über jedes Projekt folgen, und Claude Code führt sie zusammen. AGENTS.md ist die gleichwertige Datei, die Codex und eine wachsende Zahl anderer Harnesses lesen, also hält ein tool-übergreifendes Team oft beide, oder die echten Regeln in einer und einen kurzen Verweis in der anderen. Alles, was du sonst in jeden Prompt neu tippen würdest, gehört hierher: Sprache, Framework, Paketmanager, Test-Policy, Sicherheitsregeln, Namenskonventionen und Ton. - Root-CLAUDE.md: Projektregeln, ins Repo committet, geteilt von allen, die darin arbeiten. - Persönliche ~/.claude/CLAUDE.md: deine eigenen projektübergreifenden Vorlieben, nicht committet. - AGENTS.md: dieselbe Rolle für Codex und andere Harnesses, damit Multi-Tool-Setups konstant bleiben. - Sie wird in jeder Runde geladen, also halt sie knapp - eine aufgeblähte Regel-Datei frisst dasselbe Kontextfenster, das deine Aufgabe braucht. #### Regeln als Axiome schreiben Ein Agent folgt einem knackigen Absolutum weit besser als einem Absatz voller Nuancen. Formuliere jede Regel als "Immer...", "Nie..." oder "Jedes... muss...". Gruppiere sie nach Thema, damit die Datei scanbar bleibt. Hier ist eine echte, kompakte CLAUDE.md, die du heute in ein Projekt fallen lassen könntest. Beachte, dass sie die Dinge abdeckt, die du immer wieder korrigierst, nicht alles Erdenkliche. Kurz und befolgt schlägt lang und ignoriert. ```markdown # Project Rules ## Stack - TypeScript only. No plain JavaScript files. - Package manager is bun. Never use npm or yarn. - Framework is Astro for marketing pages, React for the app. ## Conventions - Use rounded-sm for border-radius on everything. - Never use em dashes. Use a normal "-" instead. - Components are PascalCase, files are kebab-case. ## Quality - Every new feature ships with a test. - Before you say a task is done, run: bun run lint && bun run typecheck && bun run test. ## Security - Secrets live in .env, which is gitignored. Never write a key into committed code. - Default new repos to private. ## Tone - Direct and concise. No filler, no apologising, no "as an AI". ``` Eine echte CLAUDE.md, die du an dein eigenes Projekt anpassen kannst #### Die Skills-Library-Philosophie Das ist der Teil, der aus einer Konfigurationsdatei einen Wettbewerbsvorteil macht. Behandle CLAUDE.md als wachsende Bibliothek hart erarbeiteten Wissens, nicht als einmaliges Setup. Jedes Mal, wenn der Agent einen Fehler macht, der wiederkehren wird, behebst du ihn nicht nur im Moment - du schreibst ihn als Regel auf. Der Agent hat das falsche Verzeichnis für Tests gewählt? Ergänze eine Regel. Er hat falsch verstanden, wie dein Auth-Flow funktioniert? Ergänze eine Notiz. Über ein paar Wochen wird die Datei zu einem präzisen Modell davon, wie dein konkretes Projekt wirklich funktioniert, voller Gotchas, die kein generisches Modell kennen könnte. Der Agent braucht dann immer weniger Handführung, weil das institutionelle Wissen im Repo lebt, nicht in deinem Kopf. - Der Auslöser ist Wiederholung: jede Korrektur, die du dir zweimal vorstellen kannst, wird beim ersten Mal zur Regel. - Halt Gotchas fest, nicht nur Stil: "der Convex-Dev-Server muss vor den Tests laufen" ist mehr wert als eine Namensregel. - Du kannst es dem Agent auftragen: "Ergänze eine Regel in der CLAUDE.md, damit du diesen Fehler nie wieder machst" funktioniert und ist eine Gewohnheit, die man pflegen sollte. - Die Datei wird geteilt und committet, also ist ein Gotcha, den du entdeckt hast, jetzt für jede künftige Session und jedes Teammitglied gelöst. #### Sie lebendig halten, nicht abgestanden Eine Regel-Datei verrottet, wenn du immer nur ergänzt. Überprüf sie nach grossen Aufgaben. Streiche Regeln, die nicht mehr gelten, weil sich der Stack geändert hat. Befördere eine nützliche Einmal-Anweisung, die du ständig einfügst, zur dauerhaften Regel. Teile eine riesige Datei in verlinkte Unterdateien, wenn sie unhandlich wird, denn du kannst aus der CLAUDE.md auf andere Markdown-Dateien verweisen und die Wurzel schlank halten. Die Investition zahlt sich auf die befriedigendste Art aus: jede künftige Aufgabe startet von einer schlaueren Basis, und der Abstand zwischen dir und jemandem, der einen nackten Agent fährt, wird jede Woche grösser. Das ist dieselbe Schleife kontinuierlichen Lernens, die sich durch den restlichen Kurs zieht - die Lektion einmal festhalten, für immer profitieren. #### Typische Fehler Die häufigen Fehler: eine 500-zeilige Regel-Datei schreiben, die die wichtigen Regeln vergräbt und dein Kontextfenster frisst; Regeln als sanfte Vorschläge formulieren ("es wäre schön, wenn..."), die der Agent als optional behandelt; sie einmal einrichten und nie aktualisieren, sodass sie langsam aus dem Takt mit dem echten Projekt gerät; und Regeln über CLAUDE.md und AGENTS.md duplizieren, bis sie sich widersprechen. Halt sie knapp, halt sie absolut, halt sie aktuell und halt eine einzige Quelle der Wahrheit. #### Business-ROI Eine gute Regel-Datei ist das günstigste Qualitäts- und Konstanz-Upgrade, das du je kaufen wirst. Sie verwandelt dein persönliches Wissen in einen Vermögenswert, der im Repo lebt, sodass eine neue Agent-Session - oder eine neue Einstellung, oder ein Freelancer - sofort produktiv und auf Standard ist, statt erst nach einer Woche Korrekturen. Für eine Gründerin ist das der Weg, aufzuhören, der Flaschenhals zu sein. Das institutionelle Wissen, das früher nur in deinem Kopf lebte und mit jedem Session-Ende zur Tür hinausging, addiert sich jetzt in einer Datei, die dein ganzes Business teilt. Das ist Hebelwirkung, die du für immer behältst. #### Checkliste Du bist bereit weiterzugehen, wenn jedes davon stimmt. Überspring die Punkte zur lebenden Datei nicht - dort steckt der echte Wert. - Du hast eine Root-CLAUDE.md in deinem Projekt committet, mit Regeln zu Stack, Konventionen, Qualität und Sicherheit. - Deine Regeln sind als Absolute formuliert, nicht als Vorschläge. - Du hast mindestens einen echten Gotcha festgehalten, den du vorher von Hand korrigiert hast. - Du weisst, wie du den Agent bittest, eine neue Regel zu ergänzen, wenn er ausrutscht. #### Ressourcen Halt die offizielle Dokumentation zu Claude-Code-Memory und CLAUDE.md als Lesezeichen für das genaue Lade- und Merge-Verhalten, denn die Details entwickeln sich. Die Axiome, die du in der Prompting-Lektion aus Kurs 1 gespeichert hast, sind der Keim dieser Datei - füge sie als deine ersten Regeln ein. Das Agent-Task-Brief-Template in der Ressourcen-Bibliothek passt gut zu einer Regel-Datei: die Regeln decken die konstanten Standards ab, das Brief die Besonderheiten je Aufgabe. #### Deine Aufgabe Erstelle eine CLAUDE.md in der Wurzel eines echten Projekts. Füll sie mit deinem Stack, drei Konventionen, die du ständig korrigierst, deinem Quality-Gate-Befehl und deiner Secret-Handling-Regel. Das nächste Mal, wenn der Agent einen Fehler macht, behebst du ihn nicht nur, sondern trägst ihm auf, eine Regel zu ergänzen, damit es nie wieder passiert. Sieh zu, wie die Datei zu etwas wächst, das nur dein Projekt haben könnte. #### Nächste Lektion Mit den Regeln an Ort und Stelle kennt der Agent deine Standards. Die nächste Lektion verpackt deine tatsächlichen Workflows: Skills und Slash Commands, die aus einem bewährten mehrschrittigen Prozess einen einzigen wiederverwendbaren Auslöser machen, sodass häufige Arbeit jedes Mal gleich läuft, ohne dass du das Brief neu tippst. ### 2.2 Skills und Commands: Wiederverwendbare Superkräfte - Kanonische URL: https://agenticschool.dev/de/kurse/claude-code-mastery/skills-and-commands-reusable-superpowers - Dauer: 23 min Zusammenfassung: Sobald du dich dabei ertappst, dem Agent dieselben mehrschrittigen Anweisungen zweimal zu geben, solltest du sie verpacken. Slash Commands und Skills machen aus einem bewährten Workflow einen einzigen wiederverwendbaren Auslöser, sodass der Agent komplexe, konstante Arbeit erledigt, ohne dass du das Brief neu tippst. Diese Lektion zeigt, was eine SKILL.md-Datei wirklich ist, wie sie sich von einem Slash Command unterscheidet und wie du eine kleine persönliche Bibliothek baust, die zu deiner tatsächlichen Arbeitsweise passt. #### Überblick Skills und Slash Commands sind wiederverwendbare, benannte Workflows. Statt dieselbe Aufgabe jedes Mal von Grund auf zu beschreiben, rufst du einen auf, und der Agent führt deine bewährten Schritte mit bereits geladenem Kontext aus. Ein Slash Command ist ein schneller Auslöser für einen Prompt, den du wiederverwendest. Ein Skill ist eine reichhaltigere, in sich geschlossene Fähigkeit, die der Agent heranziehen kann, wenn sie relevant ist. Beide sind der Weg, aufzuhören, deine besten Workflows neu zu tippen, und anzufangen, sie als dauerhafte Vermögenswerte im Repo anzulegen. #### Was du lernst Du lernst den konkreten Unterschied zwischen einem Slash Command und einem Skill, was tatsächlich in einer SKILL.md-Datei steht, inklusive ihres Frontmatters, wie du einen Workflow festhältst, den du immer wieder wiederholst, und wie du eine fokussierte Bibliothek aus zwei oder drei Skills baust, die zu deiner eigenen Arbeitsweise passen, statt einer wuchernden Sammlung, die du vergisst. #### Voraussetzungen Ein funktionierendes Claude-Code-Setup und eine CLAUDE.md aus der vorigen Lektion, denn Skills und Commands bauen auf den dort definierten Konventionen auf - ein Skill, der eine Komponente scaffoldet, sollte denselben Namens- und Stilregeln folgen, die deine Projekt-Datei bereits festlegt. #### Das Problem Du hast einen Workflow, dem du vertraust. Vielleicht ist es "eine neue Seite scaffolden, sie zum Router hinzufügen, einen Smoke-Test schreiben, das Quality Gate ausführen". Du tippst jedes Mal denselben Absatz, der ihn beschreibt, etwas anders, und bekommst etwas andere Ergebnisse. Das Wissen steckt in deinem Kopf und deinen Fingern, nirgends Wiederverwendbarem. Wenn du müde bist, vergisst du einen Schritt. Wenn ein Teammitglied es tut, tut es das auf seine eigene Weise. Der Workflow ist echt und bewährt, aber er ist nicht festgehalten, also ist er fragil und inkonsistent. #### Slash Commands: ein wiederverwendbarer Prompt Ein Slash Command ist die einfachste Form der Wiederverwendung: eine Markdown-Datei, die einen Prompt enthält, den du durch Tippen eines Slashs und seines Namens aufrufst. Leg eine Datei in den Commands-Ordner, und Claude Code stellt sie als Command bereit. Er ist perfekt für eine einzelne, klar definierte Aktion, die du oft auslöst - das Quality Gate ausführen, einen Pull Request mit deiner Standardbeschreibung öffnen, zusammenfassen, was sich seit dem letzten Commit geändert hat. Die Datei kann Argumente annehmen, sodass ein Command über Fälle hinweg flexibel ist. Greif zu einem Command, wenn du Tempo und eine einzelne klare Aktion willst. ```markdown --- description: Run the full pre-push quality gate and report failures clearly. --- Run these in order and stop at the first failure: 1. bun run lint 2. bun run typecheck 3. bun run test If anything fails, show me the exact error and the file it points to, then propose the smallest fix. Do not push. ``` Ein Slash Command unter .claude/commands/ship-check.md, aufgerufen als /ship-check #### Skills: eine verpackte Fähigkeit Ein Skill ist mehr als ein Prompt. Es ist ein Ordner mit einer SKILL.md-Datei in seiner Wurzel, die Frontmatter (einen Namen und eine Beschreibung) plus Anweisungen trägt und optional gebündelte Skripte, Templates oder Referenzdateien, die der Agent nutzen kann. Die Beschreibung zählt enorm: der Agent liest sie, um zu entscheiden, wann der Skill relevant ist, und zieht den Skill automatisch heran, also ist eine scharfe Beschreibung das, was einen Skill auffindbar macht. Nutze einen Skill, wenn ein Workflow mehrschrittig ist, eigenen Kontext oder Assets hat und davon profitiert, eine in sich geschlossene Einheit zu sein, die du an einem Ort pflegst. Hier ist ein echtes SKILL.md-Frontmatter und ein Body für einen Skill, der eine Komponente scaffoldet. ```markdown --- name: new-component description: Scaffold a new React component with its test and story. Use when the user asks to create, add or scaffold a component. --- # New Component When creating a component: 1. Create the component in src/components as a PascalCase .tsx file. 2. Use rounded-sm and the existing button/card styles - never invent new tokens. 3. Create a colocated .test.tsx with a render smoke test. 4. Export it from the components barrel file. 5. Run bun run typecheck on just the new files and fix any errors. Follow all rules in the project CLAUDE.md. Never add a new UI dependency. ``` Eine echte SKILL.md: Frontmatter (name, description) plus Anweisungen #### Einen Workflow festhalten und die Form wählen Das Signal, etwas zu verpacken, ist einfach: beim zweiten Mal, wenn du den Agent über dieselbe Abfolge briefst, ist diese Abfolge ein Kandidat. Schreib die Schritte einmal auf. Wähl dann die Form, indem du fragst, wie reichhaltig sie ist. Eine einzelne klare Aktion ohne Assets ist ein Slash Command. Ein mehrschrittiger Prozess mit eigenem Kontext, Templates oder gebündelten Skripten ist ein Skill. Denk nicht zu viel nach - du kannst mit einem Command starten und ihn später zum Skill befördern, wenn er wächst. Der Gewinn ist, den Workflow überhaupt festzuhalten, dieselbe Gewohnheit kontinuierlichen Lernens aus der letzten Lektion, auf Prozesse statt Regeln angewandt. - Zweimal wiederholt = Kandidat zum Verpacken. Warte nicht aufs zehnte Mal. - Einzelne Aktion, keine Assets, Tempo gewünscht: Slash Command. - Mehrschrittig, eigener Kontext oder gebündelte Dateien, in sich geschlossene Einheit gewünscht: Skill. - Eine grossartige Skill-Beschreibung ist die halbe Arbeit - sie ist, woran der Agent erkennt, wann er ihn nutzt. #### Eine fokussierte persönliche Bibliothek Starte klein und bewusst. Zwei oder drei Skills und Commands für die Workflows, die du am häufigsten machst - dein Quality Gate, eine Komponente scaffolden, einen Standard-Pull-Request öffnen - schlagen eine wuchernde Sammlung aus zwanzig, an die du dich halb erinnerst. Eine fokussierte Bibliothek ist eine, zu der du tatsächlich greifst, und jeder Eintrag verdient seinen Platz, indem er dir ein echtes, wiederholtes Brief erspart. Wie bei der Regel-Datei streiche, was du nicht mehr nutzt, und befördere, was du von Hand einfügst. Das Ziel ist nicht maximale Anzahl Skills, es ist maximale Hebelwirkung pro Skill. #### Typische Fehler Die üblichen Fallen: einen Skill bauen, bevor du den Workflow oft genug gefahren bist, um die richtigen Schritte zu kennen, sodass du einen schlechten Prozess festbackst; eine vage Skill-Beschreibung schreiben, sodass der Agent nie herausfindet, wann er ihn aufrufen soll; Dutzende Skills horten, deren Existenz du vergisst; und Logik duplizieren, die längst in die CLAUDE.md gehört. Skills sind für Workflows, die Regel-Datei ist für Standards - halt sie in ihren Spuren. #### Business-ROI Ein verpackter Workflow ist ein Prozess, der nicht mehr von der Person abhängt, die ihn erfunden hat. Dein bester Weg, zu scaffolden, zu testen oder zu shippen, wird zu einem Ein-Wort-Auslöser, der für dich, für ein Teammitglied und für einen Freelancer am ersten Tag gleich läuft. So schlägt ein kleines Team über seinem Gewicht: die Gründerin codiert den richtigen Weg, etwas zu tun, einmal, und alle führen ihn für immer konstant aus. Inkonsistente Prozesse sind eine stille Steuer auf die Qualität, und eine kleine Skills-Bibliothek entfernt sie zum Preis weniger Markdown-Dateien. #### Checkliste Du bist bereit weiterzugehen, wenn jedes davon stimmt. Die nächste Lektion automatisiert die Checks, mit denen diese Workflows oft enden. - Du kannst erklären, wann ein Slash Command einen Skill schlägt und umgekehrt. - Du hast mindestens einen Slash Command für einen Workflow geschrieben, den du wiederholst. - Du kannst beschreiben, was in einer SKILL.md steht, inklusive warum die Beschreibung zählt. - Deine Bibliothek ist klein und fokussiert, kein Haufen ungenutzter Einträge. #### Ressourcen Halt die offiziellen Claude-Code-Docs zu Skills und Slash Commands als Lesezeichen für die genauen Ordner-Speicherorte und Frontmatter-Felder, die sich mit der Zeit entwickeln. Die Ressourcen-Bibliothek hat ein Starter-Pack aus Command- und Skill-Templates, die du kopieren kannst. Paare jeden Skill mit deiner CLAUDE.md, damit verpackte Workflows automatisch deine Projektstandards erben. #### Deine Aufgabe Wähle den einen Workflow, über den du den Agent am häufigsten briefst. Schreib ihn zuerst als Slash Command - nur den Prompt in einer Markdown-Datei in deinem Commands-Ordner. Ruf ihn zweimal bei echter Arbeit auf. Wenn er Schritte gewinnt oder eigene Assets braucht, befördere ihn mit einer scharfen Beschreibung zum Skill. Du hast jetzt deine erste wiederverwendbare Superkraft im Repo angelegt. #### Nächste Lektion Skills und Commands laufen, wenn du sie auslöst. Die nächste Lektion geht eine Stufe weiter: Hooks und Skripte, die automatisch zu Schlüsselmomenten laufen, sodass deine Quality Gates feuern, ohne dass du je daran denkst, sie aufzurufen. ### 2.3 Hooks und Skripte: Deinen Workflow automatisieren - Kanonische URL: https://agenticschool.dev/de/kurse/claude-code-mastery/hooks-and-scripts-automating-your-workflow - Dauer: 24 min Zusammenfassung: Hooks lassen dich deine eigenen Skripte automatisch zu Schlüsselmomenten im Agent-Lifecycle ausführen - bevor ein Tool läuft, nachdem eine Datei bearbeitet wurde, wenn der Agent fertig ist, vor einem Push. So erzwingst du Quality Gates wie Tests, Linting und Typprüfungen, sodass nie etwas Kaputtes deinen Rechner verlässt, ohne dich auf Gedächtnis oder Disziplin zu verlassen. Diese Lektion zeigt die echte settings.json, die das verdrahtet. #### Überblick Hooks führen Skripte automatisch zu definierten Momenten aus, sodass das Richtige passiert, ob sich jemand daran erinnert oder nicht. Claude Code hat eigene Lifecycle-Hooks, die rund um die Aktionen des Agents feuern, und Git hat Hooks, die rund um Commits und Pushes feuern. Der klassische, wertvollste Einsatz ist ein Quality Gate, das deinen Linter, deinen Typechecker und deine Tests ausführt, bevor Code deinen Rechner verlassen kann, sodass eine Regression physisch nicht in dein Repo oder die Produktion gelangen kann. Diese Lektion verdrahtet beide mit echter, lauffähiger Konfiguration. #### Was du lernst Du lernst, was ein Hook ist, die Lifecycle-Events, in die Claude Code dich hooken lässt, wie du einen Hook in settings.json konfigurierst, wie sich das von einem Git-Pre-Push-Hook unterscheidet und wie du ein Quality Gate zusammenstellst, das dein Projekt automatisch schützt. Du gehst mit einem funktionierenden settings.json-Snippet und einem funktionierenden Git-Hook raus, die du anpassen kannst. #### Voraussetzungen Ein versionskontrolliertes Projekt aus Kurs 1 und mindestens ein Check, den du von der Kommandozeile aus ausführen kannst, etwa ein Lint- oder Test-Skript. Die CLAUDE.md aus Lektion eins hilft auch, denn deine Regel-Datei sollte bereits den Quality-Gate-Befehl benennen, den deine Hooks erzwingen werden. Der Tiefgang dazu, was in das Gate gehört, ist Kurs 5. #### Das Problem Du weisst, dass du die Tests vor dem Pushen laufen lassen solltest. Meistens tust du das. Aber es ist Freitag, die Änderung ist klein, du bist sicher, dass alles in Ordnung ist, und du überspringst es. Das ist der Push, der die Produktion kaputt macht. Sich für Routine-Checks auf menschliche Disziplin zu verlassen scheitert irgendwann, für jeden, weil Aufmerksamkeit endlich ist und der langweilige Check das Erste ist, was wegfällt, wenn du müde oder gehetzt bist. Die Lösung ist nicht mehr Disziplin. Es ist, den Menschen ganz aus der Schleife zu nehmen, damit der Check jedes einzelne Mal automatisch läuft, ohne dass eine Entscheidung beteiligt ist. #### Was ein Hook ist Ein Hook ist ein Befehl, der automatisch läuft, wenn ein bestimmtes Event feuert. Du entscheidest das Event und den Befehl, und wenn der Befehl mit einem Fehler endet, kann die Aktion blockiert werden. Claude Code stellt Lifecycle-Hooks rund um die Arbeit des Agents bereit: bevor ein Tool läuft (PreToolUse), nachdem ein Tool gelaufen ist (PostToolUse), wenn der Agent mit dem Antworten fertig ist (Stop) und andere. Du kannst PostToolUse nutzen, um eine Datei in dem Moment automatisch zu formatieren, in dem der Agent sie bearbeitet, oder PreToolUse, um einen gefährlichen Befehl zu blockieren. Diese Hooks sind deterministisch - es ist das Harness, das dein Skript ausführt, nicht das Modell, das sich dazu entscheidet. - PreToolUse: läuft vor einem Tool-Aufruf. Nutze ihn, um eine Aktion zu validieren oder zu blockieren, bevor sie passiert. - PostToolUse: läuft nach einem Tool-Aufruf. Nutze ihn, um eine Datei direkt nach einer Bearbeitung automatisch zu formatieren oder zu linten. - Stop: läuft, wenn der Agent mit dem Antworten fertig ist. Nutze ihn, um einen finalen Check auszuführen oder dich zu benachrichtigen. - Hooks sind deterministisches Harness-Verhalten, also feuern sie verlässlich - anders als das Modell höflich zu bitten, sich zu erinnern. #### Einen Hook in settings.json verdrahten Claude-Code-Hooks werden in settings.json konfiguriert, in deinem Projekt unter .claude/settings.json oder in deiner User-Konfiguration. Jeder Hook passt zu einem Event und einem Tool-Muster und führt einen Shell-Befehl aus. Hier ist ein echter PostToolUse-Hook, der jede TypeScript-Datei formatiert und lintet, sobald der Agent sie bearbeitet oder schreibt, sodass die Codebasis zwischen den Runden nie in einem unordentlichen Zustand zurückbleibt. ```json { "hooks": { "PostToolUse": [ { "matcher": "Edit|Write", "hooks": [ { "type": "command", "command": "bun run prettier --write \"$CLAUDE_FILE_PATHS\" && bun run eslint --fix \"$CLAUDE_FILE_PATHS\"" } ] } ] } } ``` .claude/settings.json - nach jeder Bearbeitung automatisch formatieren und linten Der Matcher zielt auf die Tools Edit und Write, und der Befehl läuft gegen die Dateien, die der Agent gerade angefasst hat. Jetzt ist Formatieren nie etwas, woran du oder der Agent denken müssen, weil das Harness es nach jeder Änderung erledigt. Schau in die offiziellen Hooks-Docs für die genauen Umgebungsvariablen und die Matcher-Syntax, da diese mit der Zeit verfeinert werden. #### Das Pre-Push-Quality-Gate Die mit Abstand wertvollste Automation ist ein Gate, das deine volle Check-Suite ausführt, bevor Code deinen Rechner verlassen kann. Der robusteste Ort dafür ist ein Git-Pre-Push-Hook, denn er schützt das Repo unabhängig davon, welcher Agent oder Mensch pusht. Ein Git-Hook ist einfach ein ausführbares Skript im Ordner .git/hooks, oder besser, gemanagt von einem Tool wie Husky, damit es committet und geteilt wird. Wenn ein Check fehlschlägt, endet das Skript mit ungleich null und der Push wird verweigert. Kaputter Code kann dein Repo nicht erreichen, Punkt. ```bash #!/usr/bin/env bash # .husky/pre-push - blockiert den Push, wenn ein Check fehlschlägt set -e # beim ersten fehlschlagenden Befehl stoppen echo "Running quality gate before push..." bun run lint bun run typecheck bun run test echo "All checks passed. Pushing." ``` Ein Pre-Push-Git-Hook, der das volle Quality Gate ausführt Mit set -e bricht der erste fehlschlagende Check das Skript ab und der Push passiert nie. Dieses eine Gate verhindert den häufigsten Weg, auf dem Teams Regressionen shippen: jemand überspringt die Tests bei einer "kleinen" Änderung. Es kostet dich eine Minute bei jedem Push und erspart dir den Nachmittag, den ein kaputtes Deploy gekostet hätte. #### Agent-Hooks versus Git-Hooks Diese beiden Systeme ergänzen sich, und zu wissen, welches du nutzt, zählt. Claude-Code-Hooks feuern rund um die Aktionen des Agents und sind grossartig, um jede Bearbeitung sauber zu halten - formatieren beim Schreiben, einen verbotenen Befehl blockieren, dich benachrichtigen, wenn eine lange Aufgabe endet. Git-Hooks feuern rund um Versionskontroll-Events und sind der richtige Ort für das harte Quality Gate, denn sie bewachen das Repo, egal wer oder was den Push anstösst. Das Muster, das die meisten ernsthaften Builder nutzen: Agent-Hooks fürs Aufräumen unterwegs, Git-Hooks für das finale Gate, an dem nichts vorbeikommt. Doppelt hält besser. #### Typische Fehler Die häufigen: dein einziges Quality Gate in einen Agent-Hook stecken, sodass ein manueller Push vom Terminal direkt daran vorbeisegelt; einen Hook schreiben, der so langsam ist, dass jeder Push zur Qual wird und du anfängst, ihn zu umgehen; set -e vergessen, sodass ein fehlschlagender Check ignoriert wird und der Push trotzdem weiterläuft; und deine Git-Hooks nicht committen (nutze Husky), sodass sie nur deinen Rechner schützen und nicht deine Teammitglieder. Ein Gate funktioniert nur, wenn es schnell, geteilt und echt blockierend ist. #### Business-ROI Automation schlägt Disziplin jedes Mal, und die Rechnung ist brutal zu ihren Gunsten. Ein Pre-Push-Gate, das eine Minute dauert, verhindert das kaputte Deploy, das einen Nachmittag Feuerlöschen plus den Vertrauensverlust eines kundensichtbaren Bugs kostet. Den Check als Hook zu codieren heisst, er läuft für jeden, jedes Mal, mit null laufender Aufmerksamkeit. Für eine Gründerin verwandelt das "Ich hoffe, alle denken daran zu testen" in "Kaputter Code kann nicht shippen" - eine Garantie statt eines Wunsches. Gute Automation macht das Richtige zur Voreinstellung, und die Voreinstellung ist das, was Freitag um 18 Uhr tatsächlich passiert. #### Checkliste Du bist bereit weiterzugehen, wenn jedes davon stimmt. Das Gate, das du hier baust, ist das Rückgrat der Qualitätsarbeit in Kurs 5. - Du kannst drei Claude-Code-Lifecycle-Events benennen und wofür jedes gut ist. - Du hast einen PostToolUse-Hook, der nach Bearbeitungen formatiert oder lintet. - Du hast einen Pre-Push-Git-Hook, der Lint, Typecheck und Test ausführt und bei Fehlschlag blockiert. - Deine Git-Hooks sind committet und geteilt, nicht nur auf deinem Rechner. #### Ressourcen Halt die offizielle Claude-Code-Hooks-Dokumentation als Lesezeichen für die aktuellen Event-Namen, Matcher und Umgebungsvariablen. Husky ist das Standard-Tool für committete, geteilte Git-Hooks - seine Docs führen dich in ein paar Befehlen durch das Setup. Die Test-Lektion in Kurs 5 behandelt genau, was du in das Gate steckst, damit es echte Bugs fängt, ohne langsam zu sein. #### Deine Aufgabe Ergänze einen Pre-Push-Git-Hook in einem echten Projekt, der deine Lint-, Typecheck- und Test-Befehle ausführt und den Push blockiert, wenn einer fehlschlägt. Mach absichtlich einen Test kaputt, versuch zu pushen und sieh zu, wie er verweigert wird. Ergänze dann einen Claude-Code-PostToolUse-Hook, der Dateien nach Bearbeitungen formatiert. Du hast jetzt Automation, die deine Standards erzwingt, statt deines Gedächtnisses. #### Nächste Lektion Dein Agent folgt jetzt Regeln, fährt verpackte Workflows und erzwingt Gates automatisch. Die nächste Lektion verbindet ihn mit der Welt jenseits deiner Dateien: MCP, das Model Context Protocol, das deinem Agent über einen Standard-Stecker Zugang zu Datenbanken, Design-Tools, Diensten und Datenquellen gibt. ### 2.4 MCP erklärt: Deinen Agent mit allem verbinden - Kanonische URL: https://agenticschool.dev/de/kurse/claude-code-mastery/mcp-explained-connecting-your-agent-to-everything - Dauer: 23 min Zusammenfassung: MCP, das Model Context Protocol, ist der Standardweg, einem Agent neue Fähigkeiten zu geben: eine Verbindung zu einer Datenbank, einem Design-Tool, einem Browser, einem Suchdienst. Diese Lektion erklärt MCP in klaren Worten, zeigt eine echte .mcp.json, die einen Server anbindet, und gibt dir das Urteilsvermögen, zu erkennen, wann ein MCP-Server der richtige Zug ist und wann ein einfacher CLI-Befehl in deiner Regel-Datei besser ist. #### Überblick MCP ist ein universeller Stecker für Agents. Statt dass jedes Tool seine eigene massgeschneiderte Integration erfindet, stellt ein MCP-Server seine Fähigkeiten auf eine Standardweise bereit, die jeder kompatible Agent nutzen kann. Verbinde einen, und dein Agent kann plötzlich eine Datenbank abfragen, eine Design-Datei lesen, einen Browser steuern oder deine Docs durchsuchen - und nutzt diese Aktionen wie jedes andere Tool. Das Protokoll ist der Grund, warum die Agent-Fähigkeiten explodiert sind: einen Server einmal bauen, und jeder MCP-fähige Agent kann ihn nutzen. #### Was du lernst Du lernst, was MCP ist und warum ein gemeinsames Protokoll zählt, den Unterschied zwischen einem Server und einem Client, wie du einen Server mit einer echten .mcp.json-Konfiguration zu Claude Code hinzufügst, und das wichtigste und am meisten übersehene Urteil in diesem ganzen Bereich: wann ein MCP-Server wirklich das richtige Tool ist gegenüber wann ein schlichtes Kommandozeilen-Tool, das in deiner CLAUDE.md beschrieben ist, die Arbeit mit weniger Overhead erledigt. #### Voraussetzungen Ein funktionierendes Agent-Setup und die Kontext-Lektionen aus Kurs 1, denn jeder verbundene Server verbraucht Kontext - seine Tool-Definitionen sitzen im Fenster - und der Performance-Cliff gilt weiterhin. Die Lektionen zu CLAUDE.md und Hooks helfen auch, denn die Entscheidung CLI gegen MCP läuft oft auf eine Regel oder ein Skript hinaus, das du schon schreiben kannst. #### Das Problem Dein Agent ist brillant innerhalb deiner Dateien und blind überall sonst. Er kann deine Produktionsdatenbank, deine Design-Dateien, den Live-Zustand einer Webseite oder den Inhalt eines externen Dienstes nicht sehen. Also wirst du zur menschlichen Zwischenablage: du kopierst Daten aus einem Tool, fügst sie in den Agent ein, kopierst den Output des Agents zurück. Diese manuelle Staffel ist langsam, fehleranfällig und deckelt, wie viel echte Arbeit du delegieren kannst. Vor MCP war der einzige Weg, das zu beheben, eine eigene Integration pro Tool, die fast niemand gebaut hat. #### Das Problem, das MCP löst MCP definiert einen Standard-Stecker. Ein Server spricht MCP, um eine Fähigkeit bereitzustellen - eine Datenbank, einen Dateispeicher, einen Browser, eine API. Ein Client (dein Agent-Harness) spricht MCP, um jeden Server zu nutzen. Weil das Protokoll geteilt wird, wird die Integration einmal pro Tool geschrieben und funktioniert über jeden Agent, der MCP unterstützt, genauso wie USB bedeutete, dass du nicht mehr ein anderes Kabel für jedes Gerät brauchtest. Diese eine Entscheidung ist der Grund, warum sich die Unterstützung so schnell verbreitet hat und warum es jetzt für fast alles, was du verbinden möchtest, einen MCP-Server gibt. - Server: stellt eine Fähigkeit über MCP bereit (eine Datenbank, ein Design-Tool, einen Browser, einen Suchindex). - Client: dein Agent-Harness, das jeden MCP-Server nutzen kann, den du anbindest. - Standard-Stecker: eine Integration pro Tool funktioniert über jeden MCP-fähigen Agent, statt N massgeschneiderter Integrationen. - Ein Server kann Tools anbieten (Aktionen, die der Agent ausführt) und Resources (Daten, die der Agent liest). #### Einen Server hinzufügen In Claude Code registrierst du MCP-Server in einer .mcp.json-Datei in der Wurzel deines Projekts (committet, damit das Team dieselben Verbindungen teilt) oder in deiner User-Konfiguration für persönliche. Jeder Eintrag benennt einen Server und wie er gestartet wird. Hier ist eine echte .mcp.json, die zwei häufige Server anbindet: einen Filesystem-Server, der auf einen Ordner beschränkt ist, und einen Playwright-Server, der den Agent einen echten Browser steuern lässt. Binde sie einmal an, und diese Aktionen werden dem Agent wie jedes andere Tool verfügbar. ```json { "mcpServers": { "filesystem": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-filesystem", "./data"] }, "playwright": { "command": "npx", "args": ["-y", "@playwright/mcp@latest"] } } } ``` .mcp.json - einen Filesystem-Server und einen Browser-Server anbinden Server, die Credentials brauchen (eine Datenbank, eine gehostete API), nehmen sie über Umgebungsvariablen statt fest eingebauter Keys, also gilt dieselbe .env-Disziplin aus Kurs 1: Secrets bleiben aus committeter Konfiguration heraus. Nachdem du einen Server hinzugefügt hast, kann dein Agent seine Tools direkt auflisten und aufrufen. Schau in die eigenen Docs jedes Servers für seinen genauen Startbefehl und die benötigten Umgebungsvariablen. #### MCP versus ein schlichtes CLI-Tool Das ist das Urteil, das Leute, die Agents verstehen, von Leuten trennt, die Integrationen sammeln. Ein MCP-Server ist nicht automatisch besser als ein Kommandozeilen-Tool. Claude Code kann bereits jedes CLI ausführen, das du installiert hast, und eine einzeilige Anweisung in deiner CLAUDE.md - "nutze die gh CLI für GitHub, die stripe CLI für Stripe" - ist oft einfacher, leichter und transparenter als ein dedizierter MCP-Server. CLI-Tools glänzen, wenn bereits eine ausgereifte Kommandozeilen-Schnittstelle existiert, wenn du genau sehen willst, welcher Befehl gelaufen ist, und wenn du null zusätzlichen Kontext-Overhead willst. MCP verdient seinen Platz, wenn es kein gutes CLI gibt, wenn du strukturierte Daten und Resources statt Textausgabe brauchst, oder wenn die Interaktion wirklich interaktiv ist, wie einen Browser steuern oder eine Live-Datenbank über eine typisierte Schnittstelle abfragen. Greif zuerst zum CLI; greif zu MCP, wenn das CLI die Arbeit wirklich nicht gut erledigen kann. - Bevorzuge ein CLI, wenn: ein gutes Kommandozeilen-Tool bereits existiert, du volle Transparenz willst und du minimale Kontextkosten willst. - Bevorzuge MCP, wenn: es kein anständiges CLI gibt, du strukturierte Tools und Resources brauchst, oder die Aufgabe interaktiv ist (Browser, Live-DB). - Jeder verbundene Server fügt deinem Kontextfenster Tool-Definitionen hinzu, also hat jeder echte, laufende Kosten. - Verbinde bewusst. Drei Server, die du nutzt, schlagen fünfzehn, die deinen Kontext aufblähen. #### Typische Fehler Die häufigen Fehler: jeden MCP-Server anbinden, den du findest, und dein Kontextfenster in Tool-Definitionen ertränken, die du nie nutzt; zu einem MCP-Server greifen, wenn ein CLI-Tool, das du schon hast, die Arbeit einfacher erledigen würde; Credentials in .mcp.json fest einbauen, statt Umgebungsvariablen zu nutzen; und vergessen, dass ein MCP-Server fremder Code mit Zugriff auf deine Sachen ist, also solltest du prüfen, was du anbindest, genauso wie du eine Dependency prüfen würdest. Verbinde wenige, verbinde bewusst, verbinde Dinge, denen du vertraust. #### Business-ROI MCP ist das, was aus einem Code-Agent einen Allzweck-Operator für dein Business macht. Verbinde die richtigen Server, und der Agent braucht dich nicht mehr als Zwischenablage: er kann deine Datenbank lesen, eine Live-Seite prüfen, aus einem Dienst ziehen und auf echte Daten von Anfang bis Ende reagieren. Das ist der Unterschied zwischen einem Agent, der Code entwirft, und einem Agent, der einen Workflow fährt. Die Disziplin, bewusst zu verbinden - und ein CLI zu wählen, wenn ein CLI reicht - hält diese Macht günstig und deinen Kontext scharf, sodass du die Reichweite bekommst, ohne die Cliff-Steuer zu zahlen. #### Checkliste Du bist bereit weiterzugehen, wenn jedes davon stimmt. Die nächste Lektion skaliert von einem gut ausgestatteten Agent auf mehrere. - Du kannst MCP als Standard-Stecker erklären und die Rollen Server und Client benennen. - Du hast mindestens einen MCP-Server über .mcp.json zu einem echten Projekt hinzugefügt. - Du kannst einen klaren Fall benennen, in dem ein CLI-Tool einen MCP-Server schlägt, und umgekehrt. - Du verstehst, dass jeder verbundene Server Kontext und Angriffsfläche kostet. #### Ressourcen Halt die offizielle Model-Context-Protocol-Seite und die Claude-Code-MCP-Dokumentation als Lesezeichen für das aktuelle Konfigurationsformat und das Verzeichnis verfügbarer Server. Die Filesystem-, Playwright- und Datenbank-Server sind gute erste Verbindungen. Paare MCP mit einer Regel in deiner CLAUDE.md, die dem Agent sagt, welches CLI er für welchen Job bevorzugen soll, damit er nur zu einem Server greift, wenn das CLI wirklich nicht helfen kann. #### Deine Aufgabe Binde einen MCP-Server über .mcp.json an ein echtes Projekt an - der Filesystem- oder Playwright-Server ist ein leichter Start. Tu dann bewusst das Gegenteil: wähle eine Aufgabe, für die du vielleicht zu einem Server gegriffen hättest, und ergänze stattdessen eine einzeilige Regel in deiner CLAUDE.md, die dem Agent sagt, ein bestehendes CLI-Tool zu nutzen. Beachte, welches sich leichter anfühlte. Dieser Instinkt ist hier die eigentliche Kompetenz. #### Nächste Lektion Ein einzelner gut ausgestatteter Agent ist mächtig, aber er kann nur so viel im Kontext halten. Die nächste Lektion skaliert auf mehrere Agents: Sub-Agents, Agent-Teams, die Context-Cliff-Motivation dahinter und wie du ein Team davon abhältst, deine Kosten still zu vervielfachen. ### 2.5 Sub-Agents, Agent-Teams und Workflows - Kanonische URL: https://agenticschool.dev/de/kurse/claude-code-mastery/sub-agents-agent-teams-and-workflows - Dauer: 25 min Zusammenfassung: Ein Agent kann nur so viel im Kontext halten, bevor die Qualität über den Cliff fällt. Sub-Agents lassen dich eine in sich geschlossene Aufgabe an einen frischen Agent mit sauberem Kontext delegieren, was den Haupt-Agent scharf hält. Diese Lektion behandelt die Context-Cliff-Motivation, die Labyrinth-Analogie für Delegation, wann du Sub-Agents sequentiell versus parallel laufen lässt und wie du ein Team von Agents davon abhältst, deine Rechnung still zu vervielfachen. #### Überblick Ein Sub-Agent ist ein frischer Agent, den du für eine abgegrenzte Aufgabe startest. Er erledigt die Arbeit in seinem eigenen sauberen Kontextfenster und bringt nur das Ergebnis zurück, sodass dein Haupt-Agent fokussiert bleibt und nie den Performance-Cliff erreicht, weil er alles auf einmal trägt. Diese Lektion erklärt, warum das zählt, gibt dir die Labyrinth-Analogie, die gute Delegation offensichtlich macht, und behandelt die praktischen Entscheidungen - sequentiell versus parallel, welches Modell, wie du die Aufgabe abgrenzt -, die darüber entscheiden, ob ein Team hilft oder nur Geld verbrennt. #### Was du lernst Du lernst, warum es Sub-Agents gibt und welches Context-Cliff-Problem sie lösen, die Labyrinth-Analogie zum Abgrenzen delegierter Arbeit, wie du ein sauberes Brief für einen Sub-Agent schreibst, damit er eine knappe Schlussfolgerung statt eines Durcheinanders zurückbringt, wann du Agents sequentiell versus parallel laufen lässt und wie du Kosten im Blick behältst, damit ein Team von Agents deine Rechnung nicht still um ein Vielfaches steigert. #### Voraussetzungen Die Lektion zu Tokens, Kontext und Performance-Cliff aus Kurs 1 und ein bequemer Single-Agent-Workflow. Multi-Agent zahlt sich erst aus, wenn du einen Agent wirklich gemeistert hast, denn hier geht es durchweg darum, die Grenzen zu managen, die du zuerst in Kurs 1 getroffen hast - jetzt über mehrere Agents statt einen. #### Das Problem Du gibst deinem Agent eine grosse Aufgabe. Auf halbem Weg ist sein Kontextfenster vollgestopft mit Dateiinhalten, Befehlsausgaben, Sackgassen, die er erkundet hat, und Gesprächsverlauf. Der Performance-Cliff schlägt zu: er beginnt, das ursprüngliche Ziel zu vergessen, frühere Entscheidungen zu widersprechen und bei Details unscharf zu werden, die vor einer Stunde glasklar waren. Die Arbeit in der zweiten Hälfte ist schlechter als in der ersten, nicht weil das Modell schlechter wurde, sondern weil sein Schreibtisch zugeschüttet ist. Das kannst du nicht beheben, indem du besser promptest. Das Fenster ist schlicht voller Rauschen, das die Aufgabe unterwegs erzeugt hat. #### Warum es Sub-Agents gibt Ein Sub-Agent löst das Problem des zugeschütteten Schreibtischs, indem er die unordentliche Erkundung anderswo erledigt. Du startest einen frischen Agent mit leerem Kontext, gibst ihm eine in sich geschlossene Aufgabe, und er arbeitet sich durch all das Dateilesen, Befehlsausführen und die Sackgassen in seinem eigenen Fenster. Wenn er fertig ist, bringt er nur die Schlussfolgerung zu deinem Haupt-Agent zurück. All das Rauschen - die zwölf Dateien, die er gelesen hat, die gescheiterten Ansätze, die rohe Befehlsausgabe - bleibt im Kontext des Sub-Agents und berührt deinen nie. Der Schreibtisch deines Haupt-Agents bleibt sauber, also bleibt er für die ganze Aufgabe scharf. Das ist der ganze Sinn: Sub-Agents sind zuerst ein Kontext-Management-Tool, ein Parallelismus-Tool erst danach. #### Die Labyrinth-Analogie Stell dir deinen Haupt-Agent vor, wie er durch ein Labyrinth auf ein Ziel zugeht und den Faden hält, der den Weg zurück markiert. Jeder Seitengang, den er selbst erkundet, riskiert, dass er seinen Platz verliert und die Route vergisst. Jetzt stell dir vor, er kann stattdessen einen Späher in einen Seitengang schicken. Der Späher erkundet den ganzen Ast - liest alles, trifft auf die Sackgassen, findet die Antwort - und kommt zurück, um nur einen Satz zu berichten: "dieser Gang führt zur Schatzkammer, nimm die zweite links". Der Haupt-Agent hat nie den Hauptweg verlassen, nie den Faden verloren und genau das Wissen gewonnen, das er brauchte. Das ist ein Sub-Agent. Du delegierst einen Ast der Arbeit, der Sub-Agent absorbiert all das Durcheinander des Erkundens, und dein Haupt-Kontext empfängt nur die saubere Schlussfolgerung. - Gute Sub-Agent-Aufgaben sind in sich geschlossen: "finde, welche Datei die Auth-Middleware definiert, und fasse zusammen, wie sie funktioniert". - Der Sub-Agent erledigt all die laute Arbeit: viele Dateien lesen, Suchen ausführen, Ansätze probieren. - Er bringt eine Schlussfolgerung zurück, kein Transkript: eine knappe Zusammenfassung, auf die der Haupt-Agent reagieren kann. - Dein Haupt-Kontext wächst nur um diese Schlussfolgerung, nicht um alles, was der Sub-Agent angefasst hat. #### Sequentiell versus parallel Sobald du Sub-Agents hast, kannst du sie auf zwei Arten laufen lassen, und richtig zu wählen zählt für Korrektheit und Kosten. Lass sie sequentiell laufen, wenn jeder Schritt vom letzten abhängt - erkunden, dann auf Basis des Gefundenen bauen, dann auf Basis des Builds testen. Die Reihenfolge ist die Logik. Lass sie parallel laufen, wenn die Aufgaben wirklich unabhängig sind: fünf getrennte Dateien zusammenfassen, oder drei nicht verwandte Subsysteme prüfen. Parallel ist schneller, aber nur sicher, wenn es keinen geteilten Zustand gibt, über den die Agents stolpern würden. Die ehrliche Voreinstellung ist sequentiell: es ist leichter zu durchdenken, leichter zu debuggen, und die meiste echte Arbeit hat Abhängigkeiten zwischen Schritten. Greif nur zu parallel, wenn die Unabhängigkeit offensichtlich ist. - Sequentiell: jeder Schritt braucht das Ergebnis des vorigen Schritts. Leichter zu durchdenken und zu debuggen. Die sichere Voreinstellung. - Parallel: Aufgaben sind völlig unabhängig ohne geteilten Zustand. Schneller, aber nur korrekt, wenn wirklich unabhängig. - Im Zweifel sequentiell - eine falsche parallele Aufteilung verursacht subtile, schwer aufspürbare Bugs. - Beachte, dass die CLAUDE.md-Axiome in genau diesem Projekt aus exakt diesem Grund auf sequentieller Sub-Agent-Arbeit bestehen. #### Kostenkontrolle Jeder Agent kostet Tokens, und ein Team vervielfacht das schnell. Drei Sub-Agents plus ein Haupt-Agent sind vier Kontextfenster, die gefüllt und berechnet werden, und wenn du sie sorglos startest, klettert die Rechnung still. Drei Gewohnheiten halten es vernünftig. Erstens, starte einen Sub-Agent nur, wenn der Fokus, den er einkauft, die Ausgabe wert ist - ein einzelner Agent erledigt viel Arbeit gut, und nicht alles muss delegiert werden. Zweitens, passe das Modell an die Aufgabe an: eine enge Extraktions- oder Zusammenfassungs-Teilaufgabe kann auf einem kleinen, günstigen Modell laufen, während der Haupt-Agent ein starkes fürs Reasoning nutzt. Drittens, grenze Sub-Agent-Aufgaben eng ab, damit sie schnell fertig werden und nicht abschweifen, denn ein vages Brief macht aus einem günstigen Späher einen teuren Erkunder. Das Ziel ist, Fokus zu kaufen, wo Fokus es wert ist, nicht ein stehendes Heer von Agents zu führen. #### Typische Fehler Die teuren: Sub-Agents für Arbeit starten, die ein einzelner Agent gut erledigen würde, sodass du für nicht benötigte Koordination zahlst; Aufgaben parallel laufen lassen, die heimlich Zustand teilen und sich gegenseitig korrumpieren; einem Sub-Agent ein vages Brief geben, sodass er ein ausuferndes Transkript zurückbringt, das deinen Haupt-Kontext neu verschmutzt statt einer sauberen Schlussfolgerung; und ein Flaggschiff-Modell für jede Teilaufgabe nutzen, wenn ein günstiges reichen würde. Delegiere bewusst, grenze eng ab und wähle das Modell je Job. #### Business-ROI Sub-Agents sind der Weg, die Menge echter Arbeit zu skalieren, die ein agentischer Workflow erledigen kann, ohne dass die Qualität am Cliff zusammenbricht. Ein Team, das gut delegiert, kann Aufgaben übernehmen, die weit grösser sind, als ein einzelnes Kontextfenster je halten könnte, und hält dabei den finalen Output scharf, weil der Haupt-Agent nie in Details ertrinkt. Mit Disziplin gemacht - nur delegieren, wenn es sich lohnt, günstige Modelle für enge Jobs, enge Abgrenzungen - bekommst du den Durchsatz eines Teams für einen Bruchteil dessen, was sorgloses Multi-Agent-Ausgeben kosten würde. Für eine Gründerin ist das der Unterschied zwischen einem Agent, der bei Aufgaben hilft, und einem agentischen System, das ganze Projekte fährt. #### Checkliste Du bist bereit weiterzugehen, wenn jedes davon stimmt. Die nächste Lektion geht tief ins Managen von Kontext über einen oder viele Agents. - Du kannst erklären, warum ein Sub-Agent das Haupt-Kontextfenster schützt. - Du kannst die Labyrinth-Analogie nutzen, um zu entscheiden, was eine gute delegierte Aufgabe ausmacht. - Du weisst, wann du Sub-Agents sequentiell versus parallel laufen lässt und warum sequentiell die Voreinstellung ist. - Du hast drei konkrete Gewohnheiten, um die Multi-Agent-Kosten unter Kontrolle zu halten. #### Ressourcen Halt die Claude-Code-Dokumentation zu Sub-Agents als Lesezeichen für die aktuelle Art, sie zu definieren und aufzurufen, inklusive eigener Sub-Agent-Konfigurationen. Die Modellauswahl-Lektion aus Kurs 1 ist deine Referenz, um ein günstiges Modell an eine enge Teilaufgabe anzupassen. Deine CLAUDE.md ist der richtige Ort, um Team-Regeln festzulegen - sequentiell als Voreinstellung, wann delegiert wird -, damit der Agent sie automatisch anwendet. #### Deine Aufgabe Nimm eine Aufgabe, die normalerweise deinen Kontext aufbläht - etwas, das mehrere Dateien erkunden muss, bevor es handelt. Fahr sie zweimal: einmal mit einem einzelnen Agent, der alles erledigt, und einmal so, dass du den Agent einen Sub-Agent starten lässt, der erkundet und eine Schlussfolgerung zurückmeldet, bevor er handelt. Beachte, wie viel sauberer die Haupt-Session beim zweiten Mal bleibt. Das ist der Cliff, der gemanagt statt getroffen wird. #### Nächste Lektion Kontext über einen oder viele Agents zu managen ist ein eigenes Handwerk. Die nächste Lektion geht tief auf die Hebel: warum Auto-Compaction still schadet, wie du deine Ziele danach neu einspielst, Übergabe-Dokumente schreiben, wann du einen Chat ganz zurücksetzt und den Thinking Effort an die Aufgabe anpassen. ### 2.6 Context Engineering: Compaction, Übergaben, Resets und Thinking Effort - Kanonische URL: https://agenticschool.dev/de/kurse/claude-code-mastery/context-engineering-compaction-handovers-resets-and-thinking-effort - Dauer: 25 min Zusammenfassung: Lange agentische Arbeit lebt und stirbt mit dem Kontext-Management. Diese Lektion behandelt die praktischen Hebel: warum Auto-Compaction still schadet und wie du dein Ziel danach neu einspielst, ein Übergabe-Dokument schreiben, damit eine frische Session sauber anknüpft, wissen, wann ein Reset das Weitermachen schlägt, und den Thinking Effort hoch- oder runterdrehen, um ihn an die Schwierigkeit der Aufgabe anzupassen. Das sind die Techniken, die lange Aufgaben scharf halten, statt sie verrotten zu lassen. #### Überblick Context Engineering ist das aktive Managen dessen, was der Agent gerade hält. Vier Hebel erledigen die meiste Arbeit. Compaction fasst ein langes Gespräch zusammen, um das Fenster freizumachen, aber die automatische Version lässt still Dinge fallen, die dir wichtig waren, also steuerst du sie. Eine Übergabe gibt eine saubere Zusammenfassung an eine frische Session weiter. Ein Reset wirft einen verwirrten Kontext weg und beginnt mit einem knappen Prompt neu. Und der Thinking Effort tauscht Kosten gegen Tiefe bei wirklich harten Problemen. Meistere diese vier, und lange Aufgaben bleiben scharf, statt in Verwirrung abzudriften. #### Was du lernst Du lernst, warum Auto-Compaction eine Falle ist und wie du zu deinen eigenen Bedingungen komprimierst, wie du dein Ziel neu einspielst, damit der Agent nach einer Zusammenfassung nicht abdriftet, wie du ein Übergabe-Dokument schreibst, das eine frische Session ohne Fadenverlust fortsetzen lässt, wie du erkennst, wann ein Reset eine weitere Runde Flicken schlägt, und wie du den Thinking Effort setzt, damit du für tiefes Reasoning nur zahlst, wenn die Aufgabe es verdient. #### Voraussetzungen Die Lektion zu Tokens, Kontext und Performance-Cliff aus Kurs 1 und echte Erfahrung mit mehrschrittigen Aufgaben, lange genug, dass du eine Session unscharf werden gespürt hast. Diese Techniken zählen erst, wenn Sessions lang werden, also ist die Sub-Agent-Lektion davor eine natürliche Hinführung - Sub-Agents managen Kontext über Agents hinweg, diese Lektion managt ihn innerhalb eines. #### Das Problem Du steckst tief in einer langen Aufgabe. Das Kontextfenster füllt sich, und irgendwann komprimiert das Harness automatisch - es fasst das bisherige Gespräch zusammen, um Platz zu machen. Plötzlich fühlt sich der Agent anders an. Er hat eine Entscheidung vergessen, die du früh getroffen hast, oder er optimiert jetzt auf das falsche Ziel, oder er widerspricht selbstbewusst etwas, dem er vor einer Stunde zugestimmt hat. Auto-Compaction hat ihren Job mechanisch erledigt: sie hat Platz geschaffen. Aber sie hat nach ihren eigenen Prioritäten zusammengefasst, nicht deinen, und still das Constraint fallen gelassen, das dir am wichtigsten war. Du hast nicht gewählt, was bleibt, also hast du den Faden verloren, ohne es zu merken. #### Warum Auto-Compaction schadet, und sie steuern Auto-Compaction ist nicht bösartig, sie ist nur verlustbehaftet und ungetimt. Sie feuert, wenn das Fenster fast voll ist, was meist der schlechteste Moment ist, mitten im Gedanken, und sie komprimiert alles nach einer generischen Heuristik herunter, die dein echtes Ziel nicht kennt. Das Ergebnis ist ein subtiler Qualitätsverlust, den du oft erst bemerkst, nachdem der Agent abgedriftet ist. Die Lösung ist, die Kontrolle über den Moment und den Inhalt zu übernehmen. Komprimiere bewusst, an einem sauberen Bruchpunkt zwischen Teilaufgaben statt mitten im Schritt. Und spiel direkt nach jeder Compaction dein Ziel neu ein: formuliere das Ziel, die zentralen Constraints und den aktuellen Stand in ein paar Zeilen neu. Dieser eine Absatz verankert den Agent neu und macht das meiste rückgängig, was die Compaction verwischt hat. - Komprimiere an einem sauberen Bruchpunkt, den du wählst, nicht wenn das Fenster es mitten in der Aufgabe erzwingt. - Spiel nach der Compaction das Ziel neu ein: formuliere das Ziel, die nicht verhandelbaren Constraints und wo du jetzt stehst neu. - Achte nach einer Zusammenfassung auf Abdriften - wenn sich die Antworten des Agents falsch anfühlen, ist ein verlorenes Constraint die übliche Ursache. - Eine CLAUDE.md hilft auch hier: Regeln in der Datei überleben, weil sie neu geladen werden, anders als Punkte, die im Chat vergraben sind. #### Übergabe-Dokumente Manchmal ist der sauberste Zug nicht zu komprimieren, sondern an eine frische Session mit sauberem Fenster zu übergeben. Das Werkzeug dafür ist ein Übergabe-Dokument: eine kurze Markdown-Datei, die du den Agent schreiben lässt und die alles festhält, was die nächste Session braucht. Gut gemacht liest ein neuer Agent die Übergabe und ist sofort so informiert wie der alte, aber mit einem leeren, scharfen Kontext. Das ist der mit Abstand verlässlichste Weg, Arbeit zu fahren, die für ein Fenster viel zu lang ist, ohne den Qualitätsverfall, und es ist zugleich ein Protokoll, das du einem Teammitglied geben kannst. ```markdown # Handover: Checkout flow refactor ## Goal Move checkout from the old form to Stripe embedded checkout. Must keep the existing success page and not change the cart. ## Done so far - Added the Stripe SDK and the new checkout component. - Wired the create-session endpoint (see src/api/checkout.ts). ## Current state / next step - The embedded form renders but the redirect after payment 404s. - Next: fix the return_url in checkout.ts to point at /order/success. ## Constraints (do not forget) - TypeScript only, run the quality gate before pushing. - Never log the Stripe secret key. ``` Ein Übergabe-Dokument, das eine frische Session sauber fortsetzen lässt Bitte den Agent, das zu schreiben, bevor du eine lange Session beendest, und füg es dann in einen frischen Chat ein, um fortzufahren. Die neue Session startet mit einem sauberen Fenster und einem präzisen Brief, was fast immer schärfer ist, als eine aufgeblähte Session eine weitere Runde zu schieben. #### Wann zurücksetzen Ein Reset ist, mit einem frischen, fokussierten Prompt neu zu beginnen und den aktuellen Kontext aufzugeben. Es klingt, als würfe man Arbeit weg, aber es ist oft der schnellste Weg nach vorn. Wenn ein Agent auf demselben gescheiterten Fix in einer Schleife hängt, sich selbst widerspricht oder einen so aufgeblähten Kontext trägt, dass jede Antwort mittelmässig ist, hilft mehr Flicken selten - du streitest mit einem verwirrten Fenster. Setz stattdessen zurück. Nimm, was du gelernt hast, schreib einen knappen Prompt oder eine Übergabe und beginn sauber. Das Signal ist einfach: wenn du dasselbe zweimal erklärt hast und es immer noch nicht ankommt, ist der Kontext das Problem, nicht die Anweisung. Ein Reset räumt ihn auf. #### Thinking Effort Thinking Effort ist, wie viel bewusstes Reasoning das Modell vor dem Antworten betreibt. Mehr Effort heisst, es arbeitet das Problem sorgfältiger durch, was mehr Tokens und Zeit kostet, aber die Qualität bei wirklich harten Aufgaben hebt - kniffliges Debugging, Architekturentscheidungen, subtile Logik. Weniger Effort ist richtig für Routinearbeit, bei der tiefes Reasoning verschwendetes Geld ist. Die praktische Regel spiegelt die Modellauswahl aus Kurs 1: dreh den Effort für die harten 20 Prozent hoch, die ihn wirklich brauchen, und halt ihn niedrig für die leichten 80 Prozent. Du kannst eine Voreinstellung setzen und sie je Aufgabe anheben. Für maximales Reasoning bei einem Rename oder einem Formatierungsdurchlauf zu zahlen ist derselbe Fehler, wie eine Chirurgin ein Pflaster aufkleben zu lassen. - Hoher Effort: hartes Debugging, Architektur, subtile Logik - die Fälle, in denen sorgfältiges Reasoning die Antwort verändert. - Niedriger Effort: Routine-Bearbeitungen, Formatieren, einfache Refactors - Tiefe ist hier verschwendetes Geld. - Passe den Effort an die Schwierigkeit an, genauso wie du die Modellstufe an die Schwierigkeit anpasst. - Effort und ein starkes Modell addieren sich: spar beides für die wirklich harten Probleme. #### Typische Fehler Die wiederkehrenden: Auto-Compaction feuern lassen und nie das Ziel neu einspielen, sodass der Agent still abdriftet; eine verwirrte, aufgeblähte Session Runde um Runde schieben, wenn ein Reset schneller gewesen wäre; nie eine Übergabe schreiben, sodass jede lange Aufgabe verfällt, statt sauber fortzufahren; und maximalen Thinking Effort bei trivialer Arbeit verbrennen, während du dich wunderst, warum die Rechnung hoch ist. Der Meta-Fehler ist, Kontext als etwas zu behandeln, das dir einfach passiert, statt als etwas, das du aktiv engineerst. #### Business-ROI Context Engineering ist das, was grosse, mehrstündige agentische Arbeit wirklich verlässlich macht statt eines langsamen Abgleitens in Verwirrung. Zu deinen Bedingungen zu komprimieren, sauber zu übergeben und im richtigen Moment zurückzusetzen halten die Output-Qualität über Aufgaben hinweg hoch, die weit grösser sind als ein Fenster - was weniger Nacharbeit und weniger subtile Bugs durch einen abdriftenden Agent bedeutet. Den Thinking Effort an die Schwierigkeit anzupassen steuert die Kosten direkt. Für eine Gründerin, die echte Workflows fährt, sind diese Gewohnheiten der Unterschied zwischen agentischer Arbeit, die skaliert, und agentischer Arbeit, die still verfällt, je länger sie läuft. #### Checkliste Du bist bereit weiterzugehen, wenn jedes davon stimmt. Die letzte Lektion stellt das Pro-Setup zusammen, das all das im Alltag glatt macht. - Du kannst erklären, warum Auto-Compaction schadet und was das Neu-Einspielen des Ziels bewirkt. - Du kannst den Agent ein Übergabe-Dokument schreiben lassen und in einer frischen Session fortfahren. - Du kennst die Signale, die Reset statt Flicken bedeuten. - Du passt den Thinking Effort an die Aufgabenschwierigkeit an, statt ihn immer zu maximieren. #### Ressourcen Halt die Claude-Code-Dokumentation zum Kontext-Management und den Befehlen compact und clear als Lesezeichen für das aktuelle Verhalten und die Flags. Halt ein Übergabe-Template in deiner Ressourcen-Bibliothek, damit eines zu schreiben eine Zwei-Minuten-Gewohnheit ist. Deine CLAUDE.md ist deine Versicherung gegen Compaction-Verlust, denn Regeln in der Datei werden neu geladen, während Punkte im Chat vergraben es nicht werden. #### Deine Aufgabe Bei deiner nächsten langen Aufgabe tu zwei Dinge bewusst. Wenn das Fenster voll wird, komprimiere selbst an einem sauberen Bruchpunkt und spiel dann dein Ziel in einem kurzen Absatz neu ein. Lass später den Agent ein Übergabe-Dokument schreiben, öffne eine frische Session, füg es ein und fahr fort. Beachte, wie viel schärfer sich die frische Session anfühlt. Du hast gerade deinen Kontext engineert, statt ihn dich engineern zu lassen. #### Nächste Lektion Du kannst Regeln, Skills, Hooks, MCP, Multi-Agent-Arbeit und Kontext managen. Die letzte Lektion dieses Kurses stellt das Pro-Setup zusammen, das alles verbindet: eine eigene Status Line, die Handvoll CLI-Flags, die du täglich nutzt, und Sessions von deinem Handy oder der Cloud aus laufen lassen, damit Bauen nicht an einen Schreibtisch gebunden ist. ### 2.7 Pro-Setup: Status Line, zentrale Flags, Handy- und Cloud-Sessions - Kanonische URL: https://agenticschool.dev/de/kurse/claude-code-mastery/pro-setup-status-line-key-flags-phone-and-cloud-sessions - Dauer: 23 min Zusammenfassung: Diese Lektion stellt das Power-User-Setup zusammen. Eine eigene Status Line, die dein Modell, deine Kontextgrösse, deinen Branch und deine Kosten sichtbar macht. Die Handvoll Flags, die jeden Tag zählen - Sessions mit --resume fortsetzen, mit -c weitermachen und der gefährliche-aber-nützliche Permissions-Skip. Und wie du Sessions zwischen deinem lokalen Rechner und der Cloud bewegst, inklusive eine Session vom Handy über einen Browser steuern. Das ist das Setup, das ernsthafte Builder fahren. #### Überblick Ein Pro-Setup entfernt Reibung, sodass das Tool dir aus dem Weg geht. Die richtigen Flags lassen dich Arbeit sofort fortsetzen und weitermachen und, wenn du es wirklich brauchst, ohne den Permission-Prompt laufen. Eine gute Status Line hält die Zahlen, die zählen - Modell, Kontextfüllung, Branch, Kosten - ständig im Blick, sodass du den Performance-Cliff oder eine ausufernde Rechnung kommen siehst. Und Cloud- und Handy-Sessions bedeuten, dass eine lange Aufgabe weiterläuft, während du wegtrittst, und du Arbeit von überall starten oder prüfen kannst. Diese Lektion verdrahtet alle drei. #### Was du lernst Du lernst die Alltags-Flags, die es zu merken lohnt, und genau, was jedes tut, wie du eine eigene Status Line konfigurierst, die die Informationen sichtbar macht, die du tatsächlich beobachtest, und die Optionen, Sessions remote zu fahren - Arbeit zwischen lokal und Cloud bewegen und eine Session vom Handy über einen Browser steuern. Am Ende fühlt sich dein Setup wie ein Cockpit an statt einer Blackbox. #### Voraussetzungen Ein sicherer Single-Agent-Workflow und die Installations-Lektion aus Kurs 1, denn das baut auf einem funktionierenden Claude-Code-Setup auf. Die Kontext-Lektion direkt davor passt besonders gut, denn eine Status Line ist weitgehend ein Werkzeug, um die Kontextfüllung zu beobachten, die du dort zu managen gelernt hast. #### Das Problem Ab Werk fliegst du blind und tippst dich selbst neu. Du kannst nicht sehen, wie voll dein Kontext ist, also überrascht dich der Cliff. Du kannst die laufenden Kosten nicht sehen, also überrascht dich die Rechnung. Du schliesst dein Terminal und verlierst den Faden einer Session, die du fortsetzen wolltest. Du bestätigst denselben sicheren Befehl zum hundertsten Mal. Und sobald du deinen Schreibtisch verlässt, hört alle Arbeit auf. Nichts davon ist schwer zu beheben, und es zu beheben ist der Unterschied zwischen dem Kampf mit dem Tool und dem Fluss mit ihm. #### Die zentralen Flags Ein paar Flags tragen den meisten Alltagswert. Lern diese vier, und die Reibung fällt weg. --resume lässt dich eine vergangene Session aus einer Liste wählen und genau dort fortsetzen, wo sie aufgehört hat. -c (continue) springt direkt zurück in deine jüngste Session in diesem Verzeichnis, die du ständig greifst. -p führt einen Prompt nicht-interaktiv aus und gibt das Ergebnis aus, perfekt, um den Agent in andere Tools zu skripten. Und --dangerously-skip-permissions umgeht die Pro-Aktion-Bestätigungsprompts. Letzteres ist so benannt, dass es dir Angst macht, zu Recht: es ist wirklich nützlich für einen vertrauenswürdigen, gesandboxten, wiederholbaren Workflow und wirklich gefährlich überall dort, wo der Agent etwas Zerstörerisches mit Daten ausführen könnte, die dir wichtig sind. ```bash # Deine jüngste Session in diesem Ordner fortsetzen claude -c # Eine vergangene Session aus einer Liste wählen und fortsetzen claude --resume # Einen Prompt nicht-interaktiv ausführen (super für Skripte) claude -p "Summarise what changed since the last commit" # Permission-Prompts überspringen - nur in einem vertrauenswürdigen, gesandboxten Setup claude --dangerously-skip-permissions ``` Die vier Flags, zu denen du am häufigsten greifst Behandle --dangerously-skip-permissions als Power-Tool mit entfernter Sicherung. Nutze es für eine abgegrenzte, wiederholbare Aufgabe, der du voll vertraust, idealerweise in einer Sandbox oder einer Wegwerf-Umgebung. Nutze es nie bei einer Session, die Produktion, Secrets oder Daten berühren kann, die du dir nicht zu verlieren leisten kannst. Der Permission-Prompt ist Reibung mit Absicht, und die meiste Zeit willst du ihn. #### Eine eigene Status Line Eine Status Line ist ein Streifen lebender Informationen, den Claude Code dir durchgehend zeigt. Du konfigurierst sie mit einem kleinen Skript, das das Harness aufruft und mit Session-Daten als JSON füttert, und du gibst zurück, was du willst. Der Sinn ist, die Zahlen, die du tatsächlich beobachtest, jederzeit im Blick zu halten: welches Modell du fährst, wie voll das Kontextfenster ist (deine Frühwarnung für den Cliff), dein aktueller Git-Branch und die laufenden Kosten. Sobald du Kontextfüllung und Kosten ohne Nachfragen sehen kannst, beginnst du, beide instinktiv zu managen - du komprimierst vor dem Cliff und bemerkst eine ausufernde Rechnung in Sekunden statt am Monatsende. ```json // .claude/settings.json - auf dein Status-Line-Skript zeigen { "statusLine": { "type": "command", "command": "~/.claude/statusline.sh" } } ``` Eine eigene Status Line in settings.json registrieren ```bash #!/usr/bin/env bash # ~/.claude/statusline.sh - liest Session-JSON von stdin, gibt eine Status Line aus input=$(cat) model=$(echo "$input" | jq -r ".model.display_name") dir=$(echo "$input" | jq -r ".workspace.current_dir" | xargs basename) branch=$(git -C "$(echo "$input" | jq -r ".workspace.current_dir")" branch --show-current 2>/dev/null) echo "[$model] $dir @ ${branch:-no-git}" ``` Ein minimales Status-Line-Skript, das Modell, Ordner und Branch zeigt Das ist ein Ausgangspunkt - erweitere das Skript, um Kontextgrösse und Kosten aus dem Session-JSON zu zeigen, sobald du dich wohlfühlst. Schau in die offiziellen Status-Line-Docs für die genauen verfügbaren JSON-Felder, da sie mit der Zeit wachsen. Die Gewohnheit, die es aufbaut - einen Blick auf Kontext und Kosten zu werfen, wie ein Fahrer auf das Armaturenbrett -, ist mehr wert als jedes einzelne Feld. #### Handy- und Cloud-Sessions Das letzte Upgrade löst das Bauen vom Schreibtisch. Cloud-Sessions fahren den Agent auf einem entfernten Rechner statt auf deinem Laptop, was bedeutet, dass eine lange Aufgabe weiterläuft, nachdem du den Deckel zuklappst, und du sie später von überall aufnehmen kannst. Weil eine Cloud-Session auf einem Server mit eigener Web-Oberfläche lebt, kannst du sie in einem Browser öffnen - inklusive dem Browser auf deinem Handy - und lesen, was der Agent tut, eine Frage beantworten, die er hat, oder eine neue Aufgabe anstossen, während du weg von deinem Computer bist. Das Muster, das entsteht, ist fliessend: starte eine schwere Aufgabe auf deinem Rechner oder in der Cloud, tritt weg, prüf sie vom Handy, und die Arbeit stockt nie, weil du weggegangen bist. Bauen wird zu einer Always-on-Tätigkeit statt etwas, das an einen Bildschirm gekettet ist. - Cloud-Session: der Agent läuft auf einem entfernten Rechner, sodass lange Aufgaben weiterlaufen, nachdem du deinen Laptop schliesst. - Browser-Zugriff: öffne die Session in jedem Browser, inklusive auf deinem Handy, um sie zu beobachten oder zu steuern. - Vom Handy kannst du Fortschritt lesen, die Fragen des Agents beantworten und neue Aufgaben ohne deinen Computer starten. - Der Ablauf: Arbeit anstossen, wegtreten, vom Handy prüfen und anstupsen, zu einem fertigen Job zurückkommen. #### Typische Fehler Die, die wehtun: --dangerously-skip-permissions bei einer Session nutzen, die Produktion oder Secrets erreichen kann, was genau der Weg ist, auf dem ein Agent echten Schaden anrichtet; nie eine Status Line einrichten und dann vom Cliff oder einer überraschenden Rechnung kalt erwischt werden; vergessen, dass -c existiert, und mühsam Kontext neu erklären, den du in einem Tastendruck hättest fortsetzen können; und Cloud- und Handy-Zugriff als Spielereien behandeln statt als das, was lange Aufgaben in Bewegung hält, während du dein Leben lebst. Richte das Armaturenbrett ein, respektiere das gefährliche Flag und nutze die Remote-Optionen wirklich. #### Business-ROI Ein Pro-Setup multipliziert jede andere Kompetenz in diesem Kurs, indem es die Reibung entfernt, die sie alle still besteuert. Eine Status Line, die Kontext und Kosten sichtbar macht, verhindert die zwei häufigsten Arten, wie agentische Arbeit schiefgeht - der Qualitäts-Cliff und die ausufernde Rechnung -, bevor sie dich etwas kosten. Die Resume- und Continue-Flags gewinnen jede einzelne Session Minuten zurück, die sich schnell summieren. Und Cloud- und Handy-Zugriff bedeuten, dass teure, lange laufende Arbeit im Hintergrund deines Tages passiert, statt deinen Bildschirm zu blockieren, sodass du in denselben Stunden mehr schaffst. Für eine Gründerin ist das das Setup, das aus dem Agent statt eines Tools, vor dem du sitzt, eine Belegschaft macht, die du von überall beaufsichtigst. #### Checkliste Du hast Kurs 2 abgeschlossen, wenn jedes davon stimmt. Nimm dir einen Moment - du fährst jetzt wirklich ein Power-User-Setup. - Du weisst, was --resume, -c, -p und --dangerously-skip-permissions jeweils tun und wann das gefährliche angebracht ist und wann nicht. - Du hast eine eigene Status Line, die mindestens dein Modell und deinen Branch zeigt, mit Kontext und Kosten als nächstem Schritt. - Du kannst eine Session in der Cloud fahren und sie aus einem Browser prüfen. - Du verstehst, wie du Arbeit von deinem Handy aus startest, beobachtest und steuerst. #### Ressourcen Halt die offiziellen Claude-Code-Docs zu CLI-Flags, der Status Line und Cloud-Sessions als Lesezeichen für die aktuellen Befehle und JSON-Felder, die sich entwickeln. Das im Status-Line-Skript genutzte Tool jq lohnt sich zu installieren, falls du es nicht hast. Deine settings.json ist jetzt das Zuhause für deine Status Line, deine Hooks aus Lektion drei und deine Berechtigungen - halt sie aufgeräumt und committet, wo sie geteilt werden soll. #### Deine Aufgabe Tu drei Dinge. Richte eine grundlegende eigene Status Line ein, die dein Modell und deinen Branch zeigt. Nutze claude -c, um deine letzte Session fortzusetzen, und beachte die Reibung, die es entfernt. Starte dann eine Session in der Cloud, öffne sie im Browser deines Handys und schick ihr von dort eine Anweisung. Du fährst jetzt das Setup, das ernsthafte Builder nutzen - und du hast Kurs 2 abgeschlossen. #### Nächste Lektion Du bist jetzt ein Claude-Code-Power-User: Regeln, Skills, Hooks, MCP, Multi-Agent-Arbeit, Context Engineering und ein Pro-Setup. Kurs 3 geht zum modernen App-Stack über - Architektur, Authentifizierung mit Clerk, eine reaktive Datenbank mit Convex und Payments mit Stripe -, um deine Projekte in echte Produkte zu verwandeln, für die Leute zahlen. ### 3.1 Architektur 101: Frameworks, Monorepos und wie moderne Apps zusammenpassen - Kanonische URL: https://agenticschool.dev/de/kurse/modern-app-stack/architecture-101-frameworks-monorepos-and-how-modern-apps-fit-together - Dauer: 24 min Zusammenfassung: Bevor du Auth, Daten und Payments dranschraubst, brauchst du eine mentale Karte davon, wie eine moderne App zusammenpasst. Diese Lektion erklärt Frameworks wie Next.js, Astro, TanStack Start und Vue, die Aufteilung zwischen Frontend, Backend und Datenbank, warum Teams wie Clerk und Convex ihre schnelle Marketing-Seite von der App selbst trennen und wann ein Monorepo hilft, statt im Weg zu stehen. #### Überblick Du hast Kurs 1 mit dem Shippen einer echten Seite abgeschlossen und Kurs 2 damit, deinen Agent in ein Power-Tool zu verwandeln. Jetzt steigst du von einer einzelnen statischen Seite zu einer echten Anwendung mit Nutzern, Daten und Payments auf. Vor all dem brauchst du die Karte. Diese Lektion ist diese Karte: was ein Framework tatsächlich für dich tut, die drei Schichten, aus denen jede App gebaut ist, warum ernsthafte Teams eine schnelle Marketing-Seite von der schwereren App trennen und wann ein Monorepo ein Geschenk ist gegenüber einer Steuer. Mach das klar, und jede spätere Entscheidung in diesem Kurs fühlt sich nicht mehr willkürlich an. #### Was du lernst Du lernst den Unterschied zwischen Frontend, Backend und Datenbank in klarer Sprache, wie die wichtigsten 2026er Frameworks im Vergleich stehen und wann jedes passt, warum Firmen wie Clerk und Convex eine separate Marketing-Seite von ihrer App betreiben und die ehrliche Regel, wann sich ein Monorepo auszahlt. Am Ende kannst du die Architektur jedes SaaS auf einer Serviette skizzieren und erklären, warum sie so geformt ist. #### Voraussetzungen Kurs 1, besonders die Lektionen zum Projekt-Setup und Deploy, denn Architekturentscheidungen bauen auf einer funktionierenden Bauen-und-Shippen-Schleife auf. Du solltest dich beim Ausführen von Terminal-Befehlen wohlfühlen und mindestens eine Seite deployed haben. Wenn die Wörter "Framework" oder "TypeScript" noch unscharf sind, überflieg zuerst die Grundlagen-Seiten dazu, was ein Framework ist und was TypeScript ist, und komm dann zurück. #### Das Problem Die meisten Einsteiger kleben eine App zusammen, indem sie kopieren, was ein Tutorial getan hat, ohne ein Modell davon, wie die Teile zusammenhängen. Dann stossen sie an eine Wand: die Marketing-Seite ist langsam, weil sie mit der ganzen App gebündelt ist, Auth und Daten sind in die UI verstrickt, und niemand kann sagen, wo eine bestimmte Verantwortung lebt. Das Ergebnis ist eine App, die schwer zu ändern und unmöglich zu durchdenken ist. Nichts davon ist ein Problem der Coding-Kompetenz. Es ist ein fehlendes mentales Modell. Diese Lektion installiert das Modell, damit dein Agent auf festem Boden baut statt auf einem Haufen kopierter Snippets. #### Die drei Schichten: Frontend, Backend, Datenbank Jede Web-App, egal wie schick, sind drei Schichten, die sich die Arbeit zureichen. Das Frontend ist das, was im Browser läuft: das HTML, CSS und JavaScript, das den Bildschirm zeichnet und auf Klicks reagiert. Das Backend ist der Code, der auf einem Server läuft, fern vom Nutzer, wo du Logik und Secrets ablegst, die der Browser nicht sehen soll. Die Datenbank ist, wo Daten dauerhaft leben, sodass sie einen Seiten-Refresh überleben und zwischen Nutzern geteilt werden. Ein Request fliesst einen Weg und zurück: der Browser bittet das Backend um etwas, das Backend liest oder schreibt die Datenbank und schickt eine Antwort, die der Browser rendert. Die meiste Verwirrung darüber, "wohin gehört dieser Code", löst sich in dem Moment auf, in dem du benennen kannst, welcher dieser drei Schichten ein Stück Arbeit gehört. - Frontend: läuft im Browser, zeichnet die UI, hält nie Secrets, jeder kann es lesen. - Backend: läuft auf einem Server, hält Geschäftslogik und API-Keys, redet mit der Datenbank. - Datenbank: speichert Daten dauerhaft und teilt sie über Nutzer und Sessions hinweg. - Goldene Regel: ein Secret (API-Key, Passwort) gehört ins Backend, nie in Frontend-Code, denn der Browser liefert seinen Code an jeden Besucher aus. #### Was ein Framework dir gibt Ein Framework gibt dir Struktur, Routing und Konventionen, sodass du keine App aus rohen Dateien zusammenbaust. Es entscheidet, wie URLs auf Seiten abgebildet werden, wie Seiten Daten holen, wie die App gebündelt und ausgeliefert wird, und hundert kleine Dinge, die du sonst neu erfinden würdest. Die 2026er Optionen neigen jeweils in eine andere Richtung, und die richtige Wahl hängt davon ab, wie viel deines Produkts Content versus App ist. - Astro: gebaut für schnelle, content-lastige Seiten - Blogs, Docs, Marketing-Seiten. Liefert standardmässig fast kein JavaScript aus, sodass Seiten schnell laden und gut ranken. Greif dazu, wenn der Grossteil deines Produkts Content ist. - Next.js: das Schwergewicht-React-Framework für reichhaltige, interaktive Apps. Riesiges Ökosystem, Server-Rendering und die Voreinstellung, die viele Teams für eine vollwertige Produkt-App wählen. - TanStack Start: ein neueres Full-Stack-React-Framework, gebaut auf TanStack Router, mit ausgezeichneter Typsicherheit und einem leichteren, transparenteren Gefühl. Genau diese Plattform läuft auf TanStack Start. - Vue (mit Nuxt): die wichtigste Alternative zu React. Gleicher Job, andere Syntax und Philosophie. Wähl es, wenn du oder dein Team schon in Vue denken. Du musst nicht alle vier meistern. Wähl ein App-Framework und ein Content-Framework und bleib dabei. Eine häufige, vernünftige Kombination ist Astro für die Marketing-Seite und ein React-Framework (Next.js oder TanStack Start) für die App. Die genauen Namen zählen weniger als das Verstehen der Achse: content-schnell versus app-reich. #### Der Marketing-Seite-versus-App-Split Hier ist das Muster, das Einsteiger verwirrt, bis es jemand benennt: ernsthafte Produkte betreiben ihre öffentliche Marketing-Seite und ihre eingeloggte App als zwei separate Dinge, oft auf zwei Subdomains. Schau dir Clerk und Convex selbst an - die Homepage auf der nackten Domain ist eine schnelle Marketing-Seite, und das Dashboard lebt unter einer separaten Adresse. Es ist nicht dieselbe Codebasis, die beide bedient. Der Grund ist, dass die beiden Oberflächen entgegengesetzte Bedürfnisse haben. Öffentliche Marketing-Seiten müssen blitzschnell und voll indexierbar von Google und KI-Crawlern sein, denn so wirst du gefunden. Die eingeloggte App darf schwerer und reich interaktiv sein, denn dann ist der Nutzer schon angekommen und eingeloggt, und SEO zählt nicht mehr. Sie zusammenzubündeln erzwingt einen schlechten Kompromiss: entweder zieht deine Marketing-Seite die ganze App mit und lädt langsam, oder deine App wird von Marketing-Seiten-Constraints ausgebremst. Sie zu trennen lässt jede für ihren echten Job optimieren. - Marketing-Seite: nackte Domain (yoursite.com), schnell, SEO- und GEO-optimiert, oft Astro. Ihr Job ist, gefunden zu werden und Besucher zu konvertieren. - App: eine Subdomain (app.yoursite.com), schwerer, interaktiv, hinter Auth. Ihr Job ist, das Produkt zu liefern. SEO zählt hier nicht. - Auth und Dashboards (Clerk) und deine Datenbank (Convex) leben auf der App-Seite, nie in die Marketing-Seiten gebündelt. - Dieser Split ist der Grund, warum deine Homepage 100 auf Lighthouse erreichen kann, während deine App eine reiche, zustandsbehaftete React-Erfahrung ist. #### Was ein Monorepo ist und wann es hilft Ein Monorepo ist ein einzelnes Git-Repository, das mehrere verwandte Projekte hält - sagen wir deine Marketing-Seite, deine App und ein geteiltes Paket an Komponenten - statt eines Repos pro Projekt. Der Reiz ist echt: du teilst Code (Typen, UI-Komponenten, Utilities) über Oberflächen hinweg, ohne Pakete zu veröffentlichen, und ein Pull Request kann alles ändern, was zusammen geändert werden muss. Die Kosten sind ebenfalls echt: Monorepos fügen Tooling-Overhead hinzu (Workspace-Manager, komplexere Builds, langsamere CI, wenn du nachlässig bist), den ein Solo-Einsteiger am ersten Tag nicht braucht. Die ehrliche Regel: greif zu einem Monorepo, wenn du wirklich bedeutsamen Code über zwei oder mehr Oberflächen teilst und die Duplizierung dir wehtut. Bis dahin sind separate Repos einfacher und völlig in Ordnung. Übernimm kein Monorepo, weil eine grosse Firma es tut - die haben Hunderte Engineers und du hast einen Agent und einen Laptop. - Monorepo: ein Repo, viele Projekte, geteilter Code, koordinierte Änderungen. - Lohnt sich, wenn: Marketing-Seite und App Typen oder Komponenten teilen und du sie oft zusammen änderst. - Überspring es, wenn: du eine einzelne App hast oder zwei Oberflächen, die kaum Code teilen. Der Overhead ist nicht gratis. - Du kannst immer mit separaten Repos starten und später in ein Monorepo zusammenführen, wenn der Schmerz echt ist. #### Typische Fehler Die wiederkehrenden Fehler in dieser Phase: Marketing-Seite und App in ein Projekt bündeln und sich dann wundern, warum die Homepage langsam ist und SEO leidet; einen geheimen API-Key in Frontend-Code legen, wo jeder Besucher ihn lesen kann; am ersten Tag ein Monorepo übernehmen, weil es professionell aussieht, und in Build-Konfiguration ertrinken; und ein Framework nach Hype wählen statt danach, ob dein Produkt content-lastig oder app-lastig ist. Jeder davon kommt daher, das mentale Modell zu überspringen. Benenne die Schicht, benenne die Oberfläche, und die richtige Struktur folgt. #### Business-ROI Architektur, die am Anfang gut entschieden wird, ist nahezu gratis; schlecht entschieden besteuert sie jede künftige Änderung. Ein sauberer Marketing-versus-App-Split heisst, deine Homepage bleibt schnell und wird gefunden, was die Spitze deines ganzen Funnels ist - langsame Marketing-Seiten kosten dich für immer still Kunden und Suchranking. Zu wissen, welche Schicht welche Verantwortung besitzt, heisst, dass du (und dein Agent) Features shippst, ohne Verstrickungen zu schaffen, die später teure Umschreibungen brauchen. Die Gründer, die sich am schnellsten bewegen, sind nicht die, die das trendigste Framework gewählt haben; es sind die, deren Architektur ihnen erlaubt, eine Sache zu ändern, ohne drei andere zu brechen. #### Checkliste Bevor du weitergehst, stell sicher, dass du diese ohne Zurückblättern beantworten kannst. Diese Karte liegt unter jeder anderen Lektion im Kurs. - Kannst du Frontend, Backend und Datenbank erklären und welche davon Secrets hält? - Kannst du sagen, wann du Astro versus Next.js oder TanStack Start wählst? - Kannst du erklären, warum Teams die Marketing-Seite von der App trennen? - Kannst du die ehrliche Regel nennen, wann sich ein Monorepo lohnt? #### Ressourcen Halt die offiziellen Docs für deine gewählten Frameworks als Lesezeichen - Astro, Next.js, TanStack Start und Nuxt haben alle ausgezeichnete Getting-Started-Guides. Die Grundlagen-Seiten dazu, was ein Framework ist und was TypeScript ist, untermauern diese Lektion, falls ein Konzept unscharf blieb. Die nächsten drei Lektionen füllen die drei Schichten eine nach der anderen: Auth, dann Daten, dann die Secrets, die sie verbinden. #### Deine Aufgabe Skizziere dein eigenes Produkt (oder ein Produkt, das du bewunderst) als Diagramm mit drei Boxen - Frontend, Backend, Datenbank - und einem Pfeil, der einen Request durch sie hindurch fliessen zeigt. Markiere dann, welche Teile die Marketing-Seite und welche die App sind. Fünf Minuten mit einem Stift machen den Rest dieses Kurses konkret, denn du hast jetzt eine echte Form, an die du jedes neue Teil hängst. #### Nächste Lektion Mit klarer Architektur fügt die nächste Lektion den ersten echten Baustein hinzu: Authentifizierung mit Clerk, inklusive was OAuth tatsächlich ist, warum du Auth nie selbst bauen darfst und ein vollständiger Google-OAuth-Durchgang von einer Development-Instanz zur Produktion. ### 3.2 Clerk: Authentifizierung und OAuth von Dev zu Produktion - Kanonische URL: https://agenticschool.dev/de/kurse/modern-app-stack/clerk-authentication-and-oauth-from-dev-to-production - Dauer: 30 min Zusammenfassung: Authentifizierung ist eines der Dinge, die am leichtesten gefährlich falsch laufen, also baust du sie nie selbst - du nutzt einen dedizierten Dienst. Diese Lektion erklärt, was OAuth tatsächlich ist, warum selbstgebaute Auth eine Falle ist, wie du Clerk hinzufügst und wie du sauber von einer Development-Instanz zu einer Produktions-Instanz wechselst, inklusive des vollständigen Google-OAuth-Durchgangs: Consent Screen, Credentials und die Custom-Domain-DNS-Records, die du am Ende ergänzt. #### Überblick Deine App braucht jetzt Nutzer: Leute, die sich registrieren, einloggen und ihre eigenen Daten haben. Das ist Authentifizierung, und es ist eine Stelle, an der ein kleiner Fehler jedes Kundenpasswort leakt, das du hältst. Der richtige Zug 2026 ist eindeutig: bau sie nicht selbst, nutze einen Dienst. Clerk ist dieser Dienst für die meisten Builder, für die dieser Kurs gedacht ist. Diese Lektion erklärt das eine Konzept, das du verstehen musst (OAuth), bringt Clerk in deine App und führt dich dann durch den Teil, den alle fummelig finden - von Development-Keys zu einer echten Produktions-Instanz mit Google-Login auf deiner eigenen Domain. #### Was du lernst Du lernst, was OAuth in klarer Sprache ist, warum selbstgebaute Auth eine Falle ist, in die selbst grosse Firmen tappen, wie Clerk zu deiner App passt, den entscheidenden Unterschied zwischen einer Development-Instanz und einer Produktions-Instanz und die genauen Schritte, um Google OAuth in Produktion zu aktivieren, inklusive Google-Consent-Screen, Credentials und der DNS-Records, die es auf deiner Domain laufen lassen. #### Voraussetzungen Eine funktionierende App aus Kurs 1 und die Architektur-Karte aus der vorigen Lektion, denn Auth lebt auf der App-Seite, nicht der Marketing-Seite. Du brauchst auch die Secrets-Disziplin aus Kurs 1: Auth-Keys sind hochsensibel und dürfen nie committet werden. Die nächste Lektion zu Secrets geht tiefer, aber die Grundregel (Keys in .env, .env in .gitignore) muss bereits in Fleisch und Blut sein. #### Das Problem Auth selbst zu bauen klingt wie eine Mutprobe. Es ist eigentlich ein Minenfeld. Du musst Passwörter korrekt hashen und salten, Sessions und Tokens managen, Passwort-Resets behandeln, dich gegen Credential Stuffing und Brute Force wehren, alles sicher speichern und ewig mit neuen Angriffstechniken Schritt halten. Mach ein Detail falsch und du leakst Kundendaten, was eine juristische und reputative Katastrophe ist. Derweil haben deine Konkurrenten mit Clerk den Login an einem Nachmittag geshippt und sind weitergezogen, ihr eigentliches Produkt zu bauen. Es gibt keinen Preis für die selbstgebaute Version. Das ist ein gelöstes Problem, und dein Job ist, die Lösung zu nutzen, nicht sie neu zu erfinden. #### Was OAuth tatsächlich ist OAuth ist das Protokoll hinter jedem "Sign in with Google"- oder "Sign in with GitHub"-Button. Die Kernidee ist Delegation, ohne dein Passwort zu teilen. Wenn ein Nutzer "Sign in with Google" klickt, sieht deine App nie sein Google-Passwort. Stattdessen reicht deine App ihn an Google weiter, Google bestätigt, wer er ist, und bittet ihn, das Teilen seiner E-Mail und seines Namens mit deiner App zu genehmigen, und Google schickt einen Token zurück, der beweist "ja, das ist wirklich er". Deine App vertraut Googles Wort. Das ist das ganze Konzept: ein vertrauenswürdiger Dritter bürgt für den Nutzer, sodass du sein Passwort nie speichern oder prüfen musst. Es ist sicherer (du hältst keine Passwörter), bequemer (ein Klick, kein neuer Account) und es ist, was Nutzer erwarten. Clerk wickelt den gesamten OAuth-Tanz für dich ab - du aktivierst einfach die Provider, die du willst. - OAuth = einen vertrauenswürdigen Provider (Google, GitHub, Apple) für den Nutzer bürgen lassen, sodass du sein Passwort nie anfässt. - Deine App bekommt einen Token, der die Identität beweist, plus grundlegende Profil-Infos, deren Teilen der Nutzer genehmigt hat. - Sicherer für dich (keine Passwörter gespeichert), bequemer für sie (ein Klick). - Clerk fährt den OAuth-Flow; du aktivierst einen Provider und fügst seine Credentials hinzu. #### Clerk zu deiner App hinzufügen Clerk gibt dir Drop-in-Komponenten für Registrierung, Login, Nutzerprofil und Session-Management plus die Backend-Teile, um deine Routen zu schützen. Du installierst sein Paket, fügst deine Keys in deine Umgebung ein, umhüllst deine App mit seinem Provider und lässt die vorgefertigten Komponenten fallen. Die Keys kommen in zwei Geschmacksrichtungen: ein Publishable Key (sicher in Frontend-Code, er identifiziert nur deine App) und ein Secret Key (nur Backend). Die genauen Import-Pfade hängen von deinem Framework ab, also folge Clerks Docs für die präzisen Zeilen. ```bash # .env.local - dev keys, never committed (.env* is gitignored) VITE_CLERK_PUBLISHABLE_KEY=pk_test_xxxxxxxxxxxxxxxxxxxx CLERK_SECRET_KEY=sk_test_xxxxxxxxxxxxxxxxxxxx ``` Clerk-Keys leben in deiner env-Datei. Beachte die pk_test / sk_test Präfixe - die bedeuten Development. Beachte die Test-Präfixe. Eine Development-Instanz gibt Keys aus, die mit pk_test und sk_test beginnen; eine Produktions-Instanz gibt pk_live und sk_live aus. Dieses Präfix ist dein Auf-einen-Blick-Check, zu welcher Umgebung ein Key gehört, und es ist das mit Abstand häufigste, das Leute verwechseln. Sobald deine Keys gesetzt sind, umhüllst du deine App mit Clerks Provider und nutzt seine Komponenten. ```tsx // A protected page: only signed-in users see the content. import { SignedIn, SignedOut, SignInButton, UserButton } from '@clerk/clerk-react' export function AppShell() { return (
) } ``` Clerk-Komponenten erledigen die gesamte Eingeloggt- / Ausgeloggt-UI für dich. #### Development-Instanz versus Produktions-Instanz Clerk trennt dein Projekt in zwei völlig unabhängige Instanzen. Die Development-Instanz ist fürs Bauen: sie nutzt Test-Keys, läuft auf einer von Clerk bereitgestellten geteilten Domain und kommt mit gelockerten Einstellungen, damit du schnell iterieren kannst. Sie ist nicht für echte Nutzer gedacht. Die Produktions-Instanz ist das echte Ding: Live-Keys, deine eigene Domain, strengere Sicherheit und der Ort, an dem echte Kunden sich einloggen. Die beiden teilen keine Nutzer oder Einstellungen - sie sind separate Welten. Der Fehler, den Einsteiger machen, ist, die Development-Instanz als gut genug zu behandeln und echte Nutzer darauf zu zeigen, oder mit pk_test-Keys noch in ihrer Produktionsumgebung zu shippen. Der saubere Ablauf ist: alles auf der Development-Instanz bauen und testen, dann die Produktions-Instanz erstellen, sie konfigurieren (inklusive einer Custom Domain und OAuth) und deine deployten Umgebungsvariablen auf die pk_live- und sk_live-Keys umstellen. - Development-Instanz: pk_test / sk_test Keys, geteilte Clerk-Domain, gelockerte Einstellungen, nur fürs Bauen. - Produktions-Instanz: pk_live / sk_live Keys, deine eigene Domain, strenge Einstellungen, für echte Nutzer. - Sie sind separate Welten - Nutzer und Konfiguration übertragen sich nicht automatisch. - Live gehen = die Produktions-Instanz erstellen, sie konfigurieren, die deployten env vars auf die Live-Keys umstellen. #### Google-OAuth-Produktionsdurchgang Auf der Development-Instanz lässt Clerk dich Google-Login mit geteilten Dev-Credentials aktivieren, sodass du sofort testen kannst. Für Produktion verlangt Google, dass du deine eigenen Google-Credentials und einen verifizierten Consent Screen nutzt, sodass deine Nutzer deinen App-Namen (nicht Clerks) sehen, wenn sie sich einloggen. Das ist der Teil, der Leute stolpern lässt, also hier die Reihenfolge, die funktioniert. Die genauen Button-Beschriftungen in der Google Cloud Console verschieben sich mit der Zeit, also vertrau dem Ablauf und folge Clerks und Googles aktuellen Docs für die präzisen Klicks. - Erstelle (oder wähle) in der Google Cloud Console ein Projekt für deine App. - Konfiguriere den OAuth-Consent-Screen: setze den App-Namen, die Support-E-Mail und deine Domain. Füge die Scopes für E-Mail und Profil hinzu. Veröffentliche ihn, damit er nicht im Testmodus festhängt. - Erstelle OAuth-Credentials vom Typ "OAuth client ID" für eine Web-Anwendung. Google gibt dir eine Client ID und ein Client Secret. - Füge die autorisierte Redirect-URI hinzu, die Clerk dir in seinen Google-Provider-Einstellungen zeigt - dorthin schickt Google den Nutzer zurück, nachdem er genehmigt hat. - Füg die Google Client ID und das Client Secret in Clerks Google-Provider-Einstellungen auf deiner Produktions-Instanz ein und aktiviere es. - Test: logge dich mit Google auf deiner Produktions-Domain ein. Nutzer sollten deinen App-Namen auf dem Google-Consent-Screen sehen, nicht einen generischen. Ein subtiler Gotcha: die Redirect-URI muss exakt übereinstimmen, inklusive https und keiner Unterschiede beim abschliessenden Slash. Wenn der Login mit einem redirect_uri_mismatch-Fehler scheitert, ist diese Exakt-Übereinstimmung fast immer die Ursache. Kopiere die URI wortwörtlich aus Clerk. #### Custom Domain und DNS-Records Eine Produktions-Clerk-Instanz läuft auf deiner eigenen Domain, sodass Auth zum Beispiel bei accounts.yoursite.com oder clerk.yoursite.com passiert statt unter einer generischen Clerk-URL. Damit das funktioniert, fügst du DNS-Records, die Clerk dir gibt, bei deinem Domain-Anbieter (oder Cloudflare, aus Kurs 1) hinzu. Das sind meist CNAME-Records, die eine Subdomain auf Clerks Server zeigen, sodass Clerk diese Subdomain ausliefern und absichern kann. Du fügst sie hinzu, wartest auf die DNS-Propagation, und Clerk verifiziert sie und stellt die Zertifikate aus. Hier ist die Form dessen, was du hinzufügst - deine echten Werte kommen aus dem Clerk-Dashboard. ```text ; DNS records you add at your provider (example shape - copy real values from Clerk) ; Type Name (host) Value (target) CNAME clerk frontend-api.clerk.services CNAME accounts accounts.clerk.services CNAME clkmail mail.xxxxx.clerk.services CNAME clk._domainkey dkim1.xxxxx.clerk.services CNAME clk2._domainkey dkim2.xxxxx.clerk.services ``` Produktions-Clerk nutzt CNAME-Records auf Subdomains. Die mail/domainkey-Records lassen Clerk Verifizierungs-E-Mails von deiner Domain senden. Wenn du DNS über Cloudflare verwaltest, füge diese als DNS-only (graue Wolke, nicht proxied) hinzu, sofern Clerk nichts anderes sagt - das Proxen von Auth-Subdomains kann den TLS-Handshake brechen. Nachdem du die Records gespeichert hast, kann die Verifizierung von ein paar Minuten bis zu ein paar Stunden dauern. Es ist nicht kaputt, DNS ist nur langsam, genau wie du es beim Verbinden einer Domain in Kurs 1 gelernt hast. #### Typische Fehler Die Klassiker: mit pk_test-Keys noch gesetzt in Produktion shippen, sodass echte Nutzer auf deiner Development-Instanz landen; vergessen, den Google-Consent-Screen zu veröffentlichen, sodass er im Testmodus bleibt, in dem sich nur freigeschaltete Accounts einloggen können; ein redirect_uri_mismatch durch eine Redirect-URI, die um einen Slash oder http versus https danebenliegt; die Clerk-DNS-Records durch Cloudflare proxen und Zertifikate brechen; und der tiefste von allen, Auth von Grund auf bauen zu wollen "um zu lernen" und ein Sicherheitsloch zu shippen. Nutze den Dienst, prüf deine Key-Präfixe, kopiere Redirect-URIs wortwörtlich. #### Business-ROI Auth ist reines Abwärtsrisiko, wenn du sie baust, und reine Hebelwirkung, wenn du sie kaufst. Eine geleakte Passwort-Tabelle ist ein juristischer Albtraum unter der DSGVO und den US-Datenschutzgesetzen, plus eine Vertrauenskatastrophe, die ein junges Produkt beenden kann. Clerk entfernt diese ganze Risikokategorie für moderate monatliche Kosten und gibt dir Social Login, das die Registrierungs-Conversion messbar hebt, weil Nutzer es hassen, noch ein Passwort anzulegen. Du shippst den Login an einem Nachmittag statt in zwei Wochen, du schläfst nachts, und dein Registrierungs-Funnel konvertiert besser. Es gibt keine Version der Rechnung, in der selbstgebaute Auth für eine Gründerin gewinnt, die mit Agents baut. #### Checkliste Du bist bereit weiterzugehen, wenn all das in einer echten App stimmt, nicht nur in der Theorie. - Du kannst OAuth in einem Satz erklären: ein vertrauenswürdiger Provider bürgt für den Nutzer, sodass du sein Passwort nie hältst. - Clerk ist installiert, Keys sind in .env (gitignored), und die Eingeloggt- / Ausgeloggt-UI funktioniert. - Du kennst den Unterschied zwischen pk_test und pk_live und zu welcher Umgebung jeder gehört. - Google OAuth funktioniert auf deiner Produktions-Domain mit deinem eigenen Consent Screen und den richtigen DNS-Records. #### Ressourcen Halt die Clerk-Docs und den Google-Cloud-Console-OAuth-Guide offen, während du das Produktions-Setup machst - beide ändern ihre genaue UI mit der Zeit, und die Docs sind immer aktuell. Die Grundlagen-Seiten dazu, was OAuth ist und was DNS ist, untermauern die zwei kniffligsten Konzepte hier. Als Nächstes gibst du deinen eingeloggten Nutzern etwas zu tun: echte Daten mit Convex. #### Deine Aufgabe Füge Clerk zu einer Test-App auf der Development-Instanz hinzu und bring den Login zum Laufen, aktiviere dann Google-Login. Wenn du eine Domain besitzt, geh einen Schritt weiter: erstelle eine Produktions-Instanz, richte den Google-Consent-Screen und die Credentials ein, füge die DNS-Records hinzu und bestätige, dass ein echter Google-Login auf deiner Domain mit deinem App-Namen auf dem Consent Screen funktioniert. Den Produktionspfad einmal zu gehen nimmt die Angst für jede App, die du danach baust. #### Nächste Lektion Nutzer können sich einloggen. Die nächste Lektion gibt ihnen Daten mit Convex, einer reaktiven, typsicheren Datenbank, in der deine Backend-Logik und deine UI automatisch synchron bleiben, und in der du auch das Soft-Delete-Muster lernst, das dich einen Nutzerfehler rückgängig machen lässt, statt Daten für immer zu verlieren. ### 3.3 Convex: Deine reaktive Datenbank - Kanonische URL: https://agenticschool.dev/de/kurse/modern-app-stack/convex-your-reactive-database - Dauer: 30 min Zusammenfassung: Convex ist ein reaktives Backend: du definierst ein Schema, schreibst Queries und Mutations als TypeScript-Funktionen, und deine UI aktualisiert sich live, wann immer sich Daten ändern. Diese Lektion erklärt, was eine Datenbank wirklich ist versus eine Excel-Tabelle, warum Reaktivität zählt, das Schema-Queries-Mutations-Actions-Modell, die durchgängige Typsicherheit, die ganze Bug-Klassen tötet, wann du einen Index hinzufügst und das Soft-Delete-Muster, das dich gelöschte Daten wiederherstellen lässt, statt sie für immer zu verlieren. #### Überblick Deine Nutzer können sich einloggen. Jetzt brauchen sie Daten, die bestehen bleiben: ihr Profil, ihre Projekte, ihre gespeicherte Arbeit. Das ist die Datenbank-Schicht, und Convex passt besonders gut zu den Buildern, für die dieser Kurs gedacht ist, weil es etwas tut, das die meisten Datenbanken nicht tun - es ist reaktiv. Wenn sich Daten ändern, aktualisiert sich jeder Teil deiner UI, der von diesen Daten abhängt, von selbst, ohne manuellen Refresh-Code. Obendrein fliessen deine Typen durchgängig, von der Datenbank in deine React-Komponenten, sodass eine ganze Kategorie von Bugs schlicht nicht passieren kann. Diese Lektion lehrt das Modell: was eine Datenbank ist, die vier Arten von Funktion, die du schreibst, Indexes und die Delete-Muster, die ein Spielzeug von einem echten Produkt trennen. #### Was du lernst Du lernst, was eine Datenbank tatsächlich ist und warum sie für eine App eine Tabelle schlägt, was dir Reaktivität bringt, wie du ein Schema definierst und Queries, Mutations und Actions schreibst, wie durchgängige Typsicherheit Bugs verhindert, bevor sie passieren, wann und warum du einen Index hinzufügst und den Unterschied zwischen Hard und Soft Deletes mit einem Wiederherstellungsmuster, das du kopieren kannst. #### Voraussetzungen Eine funktionierende App mit Clerk-Auth aus der vorigen Lektion, denn du willst Daten an eingeloggte Nutzer binden. Die Architektur-Lektion, damit du dich erinnerst, dass die Datenbank die dritte Schicht ist. Und die Grundlagen-Seite dazu, was eine Datenbank ist, falls die Idee eines Schemas oder einer Tabelle brandneu ist. Vertrautheit mit einfachem TypeScript hilft, denn in Convex ist deine Datenbank-Logik einfach TypeScript-Funktionen. #### Das Problem Einsteiger greifen zu dem, was sie kennen: einer Tabelle, einer CSV-Datei oder einem Haufen JSON, der auf die Festplatte gespeichert wird. Das funktioniert, bis zwei Nutzer dieselben Daten anfassen, oder du einen Datensatz unter zehntausend schnell finden musst, oder du die Form deiner Daten änderst und alles still bricht. Dann schrauben sie eine traditionelle Datenbank an die Seite und verbringen Tage mit Glue-Code: beim Laden holen, nach jeder Änderung neu holen, Ladezustände behandeln, die UI synchron halten und Stale-Data-Bugs jagen, bei denen der Bildschirm alte Zahlen zeigt. Das meiste dieses Glues ist reine Verschwendung. Eine reaktive, typisierte Datenbank löscht den Glue und die Bug-Klasse gleich mit. #### Eine Datenbank ist keine Tabelle Eine Excel-Tabelle oder eine CSV ist in Ordnung für eine Liste, die du mit dem Auge liest. Eine Datenbank ist für einen anderen Job gebaut: viele Nutzer, die gleichzeitig lesen und schreiben, bestimmte Datensätze schnell finden, selbst unter Millionen, die Form deiner Daten erzwingen, sodass keine schlechte Zeile sich einschleichen kann, und nie Daten verlieren oder korrumpieren, wenn zwei Dinge gleichzeitig passieren. Eine Tabelle hat keine Ahnung, wer sie sonst noch bearbeitet, und keine Möglichkeit zu garantieren, dass eine "Preis"-Spalte immer eine Zahl ist. Eine Datenbank kann beides. Das mentale Upgrade ist dieses: eine Tabelle ist ein Dokument, das du ansiehst; eine Datenbank ist ein Dienst, mit dem deine App redet und der garantiert, dass die Daten korrekt und konsistent bleiben, egal wie viele Nutzer oder wie viel Last. In dem Moment, in dem deine Daten zwischen Nutzern geteilt werden oder schnell abgefragt werden müssen, bist du der Tabelle entwachsen. - Tabelle/CSV: ein Editor zur Zeit, keine Garantien zur Datenform, langsam zu durchsuchen im grossen Massstab, leicht zu korrumpieren. - Datenbank: viele gleichzeitige Nutzer, erzwungene Datenform (das Schema), schnelle Lookups via Indexes, sicher unter Last. - Convex fügt Reaktivität obendrauf: Änderungen werden automatisch an jeden verbundenen Client gepusht. #### Warum Reaktivität zählt In einem normalen Setup schreibst du viel Code, um den Bildschirm mit der Datenbank synchron zu halten: holen, wenn die Seite lädt, neu holen, nachdem du etwas geändert hast, nach Updates von anderen Nutzern pollen, Lade- und Fehlerzustände von Hand managen. Jeder davon ist eine Chance für einen Bug, bei dem die UI veraltete Daten zeigt. Convex dreht das um. Eine Query ist ein Live-Abonnement: du schreibst sie einmal, und wann immer sich Daten ändern, die sie liest - ob du sie geändert hast oder ein anderer Nutzer -, pusht Convex das neue Ergebnis an deine Komponente und sie rendert neu. Du löschst die Refetch-Logik, das Polling und die ganze Stale-Data-Bug-Klasse. Für ein kollaboratives oder Echtzeit-Produkt (ein Dashboard, ein Chat, eine geteilte Liste) ist das transformativ, und selbst für eine einfache App entfernt es einen Haufen mühsamer, fehleranfälliger Verkabelung. #### Schema, Queries, Mutations und Actions Convex gibt dir vier Bausteine. Das Schema deklariert die Form deiner Daten - deine Tabellen und ihre Felder und Typen - sodass die Datenbank sie erzwingen kann. Queries lesen Daten und sind reaktiv. Mutations ändern Daten (insert, update, delete) und laufen in einer Transaktion, sodass sie entweder voll gelingen oder voll scheitern. Actions sind dafür, mit der Aussenwelt zu reden (eine externe API aufrufen, eine E-Mail senden), wo du etwas tun musst, das kein reines Datenbank-Lesen oder -Schreiben ist. Hier ist ein echtes Schema plus eine Query und eine Mutation, die alltäglichen Bewegungen, die du ständig schreiben wirst. ```typescript // convex/schema.ts - die Form deiner Daten, von der Datenbank erzwungen import { defineSchema, defineTable } from 'convex/server' import { v } from 'convex/values' export default defineSchema({ projects: defineTable({ ownerId: v.string(), // die Clerk-User-ID, der dieses Projekt gehört name: v.string(), archivedAt: v.optional(v.number()), // null/abwesend = aktiv; ein Timestamp = soft-deleted }) // Index, damit 'finde die Projekte dieses Nutzers' ein schneller Lookup ist, kein Full Scan .index('by_owner', ['ownerId']), }) ``` Ein Schema mit einer typisierten Tabelle und einem Index. archivedAt ist das Feld, das Soft Delete antreibt. ```typescript // convex/projects.ts - eine Query (Read, reaktiv) und eine Mutation (Write, transaktional) import { query, mutation } from './_generated/server' import { v } from 'convex/values' // Reaktiv: jeder Client, der das abonniert hat, rendert neu, wenn sich die Daten ändern. export const listActive = query({ args: { ownerId: v.string() }, handler: async (ctx, { ownerId }) => { const rows = await ctx.db .query('projects') .withIndex('by_owner', (q) => q.eq('ownerId', ownerId)) .collect() // Soft-deleted Zeilen haben archivedAt gesetzt - verbirg sie aus der aktiven Liste. return rows.filter((row) => row.archivedAt === undefined) }, }) export const create = mutation({ args: { ownerId: v.string(), name: v.string() }, handler: async (ctx, { ownerId, name }) => { return await ctx.db.insert('projects', { ownerId, name }) }, }) ``` Queries lesen und sind live; Mutations schreiben in einer Transaktion. Beide sind schlichtes TypeScript. #### Durchgängige Typsicherheit Das ist die stille Superkraft. Weil dein Schema TypeScript ist und Convex Typen daraus generiert, fliesst der Typ deiner Daten den ganzen Weg von der Datenbank in deine React-Komponenten. Wenn du ein Feld im Schema umbenennst, wird jede Query, Mutation und Komponente, die den alten Namen genutzt hat, in deinem Editor rot, bevor du die App je ausführst. Du kannst nicht versehentlich ein Feld lesen, das nicht existiert, einer Mutation das falsche Argument übergeben oder annehmen, dass ein String eine Zahl ist. Ganze Klassen von "es ist in Produktion abgestürzt, weil die Daten nicht die Form hatten, die ich annahm"-Bugs werden unmöglich, weil dein Editor und der Typechecker sie fangen, während du tippst. Für jemanden, der mit einem Agent baut, ist das riesig: der Agent bekommt dieselben Typsignale und schreibt weit öfter korrekten Code, und dein Typecheck-Quality-Gate fängt den Rest, bevor er shippt. #### Indexes: Reads schnell machen Wenn du die Datenbank fragst "gib mir alle Projekte, die diesem Nutzer gehören", hat sie zwei Wege zu antworten. Ohne Index scannt sie jede Zeile und prüft jede - in Ordnung für zehn Zeilen, schmerzhaft langsam für eine Million. Mit einem Index auf ownerId springt sie direkt zu den passenden Zeilen, wie das Register am Ende eines Buchs zu nutzen, statt jede Seite zu lesen. Die Regel ist einfach: jedes Feld, nach dem du regelmässig filterst oder sortierst, verdient einen Index. Du hast es im Schema oben gesehen - der by_owner-Index ist, was listActive schnell macht, egal wie viele Projekte insgesamt existieren. Indexes früh hinzuzufügen kostet fast nichts; zu entdecken, dass du sie brauchtest, wenn deine App unter echten Daten zum Kriechen kommt, kostet eine stressige Debugging-Session. - Kein Index: die Datenbank prüft jede Zeile (ein Full Scan). In Ordnung für winzige Tabellen, langsam im grossen Massstab. - Mit einem Index: sie springt direkt zu den passenden Zeilen. Schnell selbst mit Millionen Zeilen. - Indexiere die Felder, nach denen du oft filterst oder sortierst - ownerId, status, createdAt sind häufig. - Definiere den Index im Schema; nutze ihn in Queries mit .withIndex(...). #### Soft Delete versus Hard Delete, mit Wiederherstellung Ein Hard Delete entfernt eine Zeile dauerhaft - sie ist weg, und jede Chance, sie zurückzubekommen, auch. Ein Soft Delete behält die Zeile, markiert sie aber als gelöscht, meist mit einem Timestamp wie dem archivedAt-Feld im Schema oben. Echte Produkte bevorzugen für nutzerseitige Daten fast immer Soft Deletes, denn Nutzer löschen ständig Dinge aus Versehen, und "tut mir leid, das ist für immer weg" ist eine schreckliche Erfahrung und manchmal ein Compliance-Problem. Mit einem Soft Delete kannst du einen Papierkorb oder ein Undo anbieten, die Daten wiederherstellen und Historie und Audit-Trails intakt halten. Du machst erst später einen Hard Delete, nach Zeitplan, für Daten, die lange genug soft-deleted waren und die du rechtlich löschen darfst. Hier ist das Muster: Löschen setzt den Timestamp, Wiederherstellen leert ihn, und ein Hintergrund-Job kann wirklich alte Zeilen hart löschen. ```typescript // Soft Delete: markiere es, zerstöre es nicht. Wiederherstellen ist dann trivial. export const softDelete = mutation({ args: { id: v.id('projects') }, handler: async (ctx, { id }) => { await ctx.db.patch(id, { archivedAt: Date.now() }) }, }) export const restore = mutation({ args: { id: v.id('projects') }, handler: async (ctx, { id }) => { await ctx.db.patch(id, { archivedAt: undefined }) }, }) // Hard Delete: nur für lang soft-deleted Daten, meist von einem geplanten Job ausgeführt. export const purge = mutation({ args: { id: v.id('projects') }, handler: async (ctx, { id }) => { await ctx.db.delete(id) }, }) ``` Soft Delete setzt ein Flag und bleibt wiederherstellbar; Hard Delete ist endgültig und für alte, löschbare Daten reserviert. #### Typische Fehler Die häufigen: manuellen Refetch- und Polling-Code schreiben, wenn Convex-Queries schon reaktiv sind, sodass du gegen das Tool kämpfst; Indexes vergessen und zusehen, wie die App kriecht, sobald echte Daten ankommen; Nutzerdaten ohne Wiederherstellung hart löschen und dann das Support-Ticket bekommen, das du nicht beheben kannst; versuchen, eine externe API in einer Query oder Mutation aufzurufen statt in einer Action; und dein Schema lockern (alles optional, alles ein String), bis die Typsicherheit, die dich schützte, verdunstet. Lehn dich ins Schema und die Reaktivität, statt um sie herum zu arbeiten. #### Business-ROI Eine reaktive, typisierte Datenbank ist Produktivitäts-Multiplikator und Qualitäts-Multiplikator zugleich. Du schreibst dramatisch weniger Verkabelung, also shippen Features schneller. Durchgängige Typen fangen Bugs, bevor sie einen Kunden erreichen, also shippst du mit weniger Bränden. Indexes halten die App schnell, während du wächst, was sowohl Conversion als auch deinen Ruf schützt. Und das Soft-Delete-Muster verwandelt eine Kategorie katastrophaler Support-Vorfälle - "ich habe aus Versehen alles gelöscht" - in ein Ein-Klick-Restore. Für eine Gründerin sind die bei der Verkabelung gesparte Zeit und die Bugs, die nie passieren, weit mehr wert als die moderaten Kosten des Dienstes. #### Checkliste Du bist bereit weiterzugehen, wenn jedes davon in einer echten App stimmt, die du gebaut hast, nicht nur in der Theorie verstanden. - Du kannst erklären, warum eine Datenbank eine Tabelle schlägt, sobald Daten geteilt oder gross sind. - Du hast ein Schema mit mindestens einer Tabelle, einem Index und funktionierenden Query- und Mutation-Funktionen. - Du kannst Typen vom Schema in deine Komponenten fliessen sehen und einen Rename-Fehler im Editor fangen. - Du hast Soft Delete mit einem funktionierenden Restore implementiert und weisst, wann ein Hard Delete angebracht ist. #### Ressourcen Die Convex-Docs sind ausgezeichnet und aktuell - halt die Seiten zu Schema, Queries, Mutations und Indexes als Lesezeichen. Die Grundlagen-Seite dazu, was eine Datenbank ist, erdet die Konzepte, falls eines wackelig war. Du hast jetzt Auth und Daten; die nächste Lektion sichert die Secrets ab, die jeden Dienst verbinden, den du hinzugefügt hast, inklusive wie du API-Keys verschlüsselst, die deine Nutzer dir anvertrauen. #### Deine Aufgabe Füge eine Convex-Tabelle für etwas hinzu, das deine App braucht (eine Liste von Items, Projekten oder Notizen, an den eingeloggten Nutzer gebunden), mit einem Index auf den Owner. Schreib eine reaktive Query und eine Create-Mutation, implementiere dann Soft Delete und Restore. Lösche ein Item, bestätige, dass es aus der Liste verschwindet, stell es dann wieder her und sieh zu, wie es ohne Seiten-Refresh wieder erscheint. Diese eine Übung beweist, dass du Reaktivität, Indexes und wiederherstellbare Deletes alle auf einmal verstehst. #### Nächste Lektion Deine App hat jetzt Nutzer und Daten, was heisst, sie hat einen wachsenden Haufen geheimer Keys, die sie verbinden. Die nächste Lektion ist die disziplinierte Version des Secret-Handlings: env-Dateien, .gitignore, was zu tun ist, wenn du je ein Secret gepusht hast, Convex-Deploy-Keys und das Verschlüsseln von Nutzer-API-Keys statt sie als Klartext zu speichern. ### 3.4 Secrets und Umgebung: .env, .gitignore, Deploy Keys und Verschlüsselung - Kanonische URL: https://agenticschool.dev/de/kurse/modern-app-stack/secrets-and-environment-env-gitignore-deploy-keys-and-encryption - Dauer: 26 min Zusammenfassung: Jeder Dienst, den du hinzufügst, kommt mit geheimen Keys, und einen zu leaken kann katastrophal sein. Diese Lektion ist die disziplinierte Version des Secret-Handlings: was eine .env-Datei ist, warum .gitignore nicht verhandelbar ist, was genau zu tun ist, wenn du ein Secret GEPUSHT hast (rotieren, nicht nur löschen), wie Convex-Deploy-Keys funktionieren und warum du von Nutzern gelieferte API-Keys im Ruhezustand verschlüsseln musst, statt sie als Klartext zu speichern. #### Überblick Du jonglierst jetzt Keys für Clerk, Convex, bald Stripe und wahrscheinlich einen KI-Provider. Jeder ist ein Schlüssel zu etwas Wertvollem - deinen Diensten, deinem Geld, den Daten deiner Kunden. Sie gut zu handhaben ist nicht optional, sobald echtes Geld und echte Nutzer im Spiel sind. Diese Lektion ist die rigorose Version der Secrets-Gewohnheit, die du in Kurs 1 begonnen hast: wo Secrets leben, wie du sie für immer aus Git heraushältst, die Notfallprozedur, wenn eines entkommt, wie Deploy Keys deinem Hosting Zugang geben, ohne deine Master-Credentials offenzulegen, und warum jeder Key, den deine Nutzer dir geben, verschlüsselt werden muss, nicht als lesbarer Text gespeichert. #### Was du lernst Du lernst, was eine env-Datei ist und warum es sie gibt, wie du .gitignore nutzt, sodass ein Secret nie committet werden kann, warum jede Umgebung ihre eigenen Keys bekommt, die genauen Wiederherstellungsschritte, wenn du ein Secret bereits gepusht hast, wie Convex-Deploy-Keys funktionieren und wohin sie gehören und wie du von Nutzern gelieferte API-Keys im Ruhezustand verschlüsselst, sodass ein Datenbank-Leak Angreifern nicht die Credentials deiner Kunden in die Hand gibt. #### Voraussetzungen Die Secrets-Basics aus Kurs 1 (Keys in .env, .env in .gitignore) und eine Multi-Service-App aus dem früheren Teil dieses Kurses, denn das Risiko wächst mit jeder Integration, die du hinzufügst. Die Grundlagen-Seite dazu, was eine env-Datei ist, deckt die absoluten Grundlagen ab, falls du sie ausbuchstabiert haben willst, bevor du tiefer gehst. #### Das Problem Geleakte Secrets sind eine der häufigsten und teuersten Einsteiger-Katastrophen, und sie passieren leise. Du fügst einen Key in eine Datei ein, um etwas zu testen, committest ihn gedankenlos, pushst zu GitHub, und jetzt ist dieser Key für immer in deiner Repository-Historie - lesbar für jeden, der das Repo sehen kann, und binnen Minuten von Bots gescrapt, die öffentliches GitHub genau danach durchsuchen. Leute mit einem geleakten Stripe- oder Cloud-Key sind zu Tausenden Dollar betrügerischer Abbuchungen aufgewacht. Und die API-Keys deiner Nutzer als Klartext zu speichern heisst, dass ein einziger Datenbank-Breach alle Kunden-Credentials auf einmal offenlegt. Nichts davon braucht Pech. Es braucht einen unachtsamen Commit. Diese Lektion macht Unachtsamkeit strukturell schwer. #### Was eine .env-Datei ist und gitignore richtig gemacht Eine .env-Datei ist eine schlichte Textdatei, die deine Secrets als KEY=value-Paare hält, getrennt von deinem Code, sodass der Code sie zur Laufzeit lesen kann, ohne dass die Werte in committeten Dateien fest eingebaut sind. Der ganze Sinn ist Trennung: der Code sagt "lies den Stripe-Key aus der Umgebung", und der eigentliche Key sitzt in .env, das nie deinen Rechner verlässt. Was das sicher macht, ist .gitignore - eine Datei, die auflistet, was Git nie tracken darf. Deine .env und all ihre Varianten gehören dorthin, immer, in jedes Projekt, ohne Ausnahme. Mach das einmal pro Projekt richtig, und ein Secret kann physisch nicht committet werden. ```bash # .env.local - deine echten Secrets. NIE committen. CLERK_SECRET_KEY=sk_live_xxxxxxxxxxxxxxxxxxxx STRIPE_SECRET_KEY=sk_live_xxxxxxxxxxxxxxxxxxxx CONVEX_DEPLOY_KEY=prod:your-deployment|xxxxxxxxxxxxxxxxxxxx ENCRYPTION_KEY=base64-32-byte-random-value-here ``` Eine echte .env-Datei: ein Secret pro Zeile, nie committet. ```bash # .gitignore - die nicht verhandelbaren Zeilen für jedes Projekt node_modules .env .env.local .env.*.local .DS_Store dist ``` Diese .gitignore-Zeilen verhindern, dass je eine .env-Datei in Git gelangt. Eine nützliche Gewohnheit: committe eine .env.example-Datei (mit den Keys, aber leeren oder Fake-Werten), damit jeder, der das Projekt einrichtet, weiss, welche Variablen nötig sind, ohne je ein echtes Secret zu committen. Die Beispiel-Datei ist genau deshalb sicher zu committen, weil sie keine echten Werte enthält. #### Separate Keys pro Umgebung Development und Produktion müssen verschiedene Keys nutzen. Du hast das bei Clerk gesehen (pk_test versus pk_live), und Stripe macht dasselbe (Test- versus Live-Keys). Der Grund ist der Wirkungsradius: wenn ein Development-Key leakt, kann er nur Test-Daten und den Testmodus berühren, also ist der Schaden begrenzt. Ein geleakter Produktions-Key berührt echte Kunden und echtes Geld. Sie strikt getrennt zu halten heisst, dass ein Fehler beim Bauen nie Live-Daten erreichen kann, und du kannst einem Teammitglied oder einem Agent deine Development-Keys geben, ohne das Business zu riskieren. Verwende nie einen Produktions-Key in Development "um Zeit zu sparen" - genau so belastet ein Test-Skript versehentlich eine echte Karte oder löscht einen echten Nutzer. - Development-Keys (Testmodus): sicher beim Bauen zu nutzen, berühren nur Test-Daten. - Produktions-Keys (Live-Modus): echtes Geld, echte Nutzer - bewache sie und nutze sie nur in deiner deployten Umgebung. - Setze Produktions-Secrets in deinem Host (Vercel) und deinem Backend (Convex) Dashboard, nicht in einer committeten Datei. - Ein geleakter Dev-Key ist eine Unannehmlichkeit; ein geleakter Prod-Key kann eine Katastrophe sein. Halt sie auseinander. #### Was zu tun ist, wenn du ein Secret GEPUSHT hast Das ist der wichtigste Abschnitt der Lektion, denn es wird dir oder jemandem, mit dem du arbeitest, irgendwann passieren. Der Instinkt ist, die Zeile zu löschen und erneut zu committen, oder den Commit zu löschen. Das reicht nicht und ist gefährlich, denn das Secret lebt weiter in deiner Git-Historie und ist, falls das Repo je öffentlich war oder irgendwohin gepusht wurde, vielleicht schon gescrapt. Die einzige sichere Annahme ist, dass ein gepushtes Secret kompromittiert ist. Also ist der echte Fix, es zu rotieren: geh zum Dienst, widerrufe den geleakten Key und generiere einen neuen. Die Git-Historie zu säubern ist sekundär und optional, sobald der Key tot ist. Behandle Rotation als ersten und dringendsten Schritt, jedes einzelne Mal. - Nimm an, das Secret ist kompromittiert in dem Moment, in dem es gepusht wurde. Bots scannen öffentliches GitHub binnen Minuten. - ZUERST ROTIEREN: geh zum Dienst (Stripe, Clerk, Convex, dein KI-Provider), widerrufe den alten Key, erstelle einen neuen. - Aktualisiere den neuen Key in deiner .env und in deinen Host-/Backend-Umgebungsvariablen. - Erst dann, optional, säubere die Historie (Tools wie git filter-repo oder BFG) - aber ein toter Key kann dir ohnehin nicht schaden. - Prüf den Dienst auf unbefugte Aktivität (Abbuchungen, neue Nutzer, API-Aufrufe), während der Key offengelegt war. Sag es deutlich: den Commit zu löschen macht das Leak des Secrets nicht rückgängig. Den Key zu rotieren schon. Wenn du dir eine Sache aus dieser Lektion merkst, merk dir, zuerst zu rotieren und danach aufzuräumen. #### Convex-Deploy-Keys Wenn dein Hosting (Vercel) deine App baut und deployt, braucht es die Erlaubnis, deine Backend-Funktionen und dein Schema zu Convex zu pushen. Es wäre falsch, deiner Build-Umgebung deinen persönlichen Login zu geben. Stattdessen gibt Convex einen Deploy Key aus: eine eingegrenzte Credential, die eine automatisierte Umgebung zu einem bestimmten Convex-Deployment deployen lässt und nichts weiter. Du generierst ihn im Convex-Dashboard für dein Produktions-Deployment und speicherst ihn dann als Umgebungsvariable in Vercel (nie im Code). Das Prinzip verallgemeinert sich: automatisierte Umgebungen bekommen enge, eingegrenzte Credentials, nicht deinen Master-Account, sodass ein geleakter Deploy Key einen begrenzten Wirkungsradius hat und rotiert werden kann, ohne etwas anderes zu berühren, das dir gehört. ```bash # In Vercel als Umgebungsvariable setzen (NICHT in einer committeten Datei). # Im Convex-Dashboard für dein PRODUKTIONS-Deployment generiert. CONVEX_DEPLOY_KEY=prod:your-deployment-name|xxxxxxxxxxxxxxxxxxxxxxxx # Dein Build-Befehl nutzt ihn dann, um das Backend während des Vercel-Builds zu deployen: # bunx convex deploy --cmd "bun run build" ``` Ein Convex-Deploy-Key ist eine eingegrenzte Credential für automatisierte Deploys, in deinem Host gespeichert, nie committet. #### Von Nutzern gelieferte Keys im Ruhezustand verschlüsseln Hier ist ein Szenario, zu dem dieser Kurs direkt führt: dein Produkt lässt Nutzer ihren eigenen API-Key mitbringen (ihren OpenAI-Key, ihren Stripe-Key, ihren Key für einen Dienst, den du integrierst). Du speicherst ihn, damit du in ihrem Namen handeln kannst. Wenn du diesen Key als Klartext in deiner Datenbank speicherst, dann gibt ein einziger Breach einem Angreifer die Credentials jedes Kunden auf einen Schlag - eine Katastrophe, die aus einem Vorfall Hunderte macht. Der Fix ist, sensible Werte zu verschlüsseln, bevor sie in die Datenbank gehen, und sie nur in dem Moment zu entschlüsseln, in dem du sie nutzt. Selbst wenn jemand deine Datenbank stiehlt, sind die verschlüsselten Blobs ohne den Verschlüsselungs-Key nutzlos, der getrennt in deiner Umgebung lebt, nicht in der Datenbank. Das ist der Unterschied zwischen "wir hatten einen Breach" und "wir hatten einen Breach und haben die Keys jedes Kunden geleakt". ```typescript // Vor dem Speichern verschlüsseln, nur beim Nutzen entschlüsseln. Der ENCRYPTION_KEY lebt in // deiner Umgebung, NICHT in der Datenbank, sodass eine gestohlene Datenbank allein nutzlos ist. import { createCipheriv, createDecipheriv, randomBytes } from 'node:crypto' const key = Buffer.from(process.env.ENCRYPTION_KEY!, 'base64') // 32 bytes export function encryptSecret(plain: string) { const iv = randomBytes(12) const cipher = createCipheriv('aes-256-gcm', key, iv) const enc = Buffer.concat([cipher.update(plain, 'utf8'), cipher.final()]) const tag = cipher.getAuthTag() // iv + tag + ciphertext zusammen speichern; nichts davon ist für sich geheim. return Buffer.concat([iv, tag, enc]).toString('base64') } export function decryptSecret(stored: string) { const raw = Buffer.from(stored, 'base64') const iv = raw.subarray(0, 12) const tag = raw.subarray(12, 28) const enc = raw.subarray(28) const decipher = createDecipheriv('aes-256-gcm', key, iv) decipher.setAuthTag(tag) return Buffer.concat([decipher.update(enc), decipher.final()]).toString('utf8') } ``` AES-256-GCM: Nutzer-Keys vor dem Speichern verschlüsseln, nur am Einsatzpunkt entschlüsseln. Der Key bleibt in der Umgebung. Du musst keine Kryptografin sein, um einen gut getesteten Algorithmus wie AES-256-GCM über die Standard-Krypto-Library deiner Plattform zu nutzen, wie oben. Die Faustregel: erfinde nie deine eigene Verschlüsselung, nutze immer die Standard-Library und halt den Verschlüsselungs-Key in deiner Umgebung, völlig getrennt von den Daten, die er schützt. #### Typische Fehler Die schmerzhaften: eine .env committen, weil .gitignore fehlte oder falsch war; ein geleaktes Secret aus einer Datei löschen und glauben, es sei sicher, obwohl es noch in der Historie lebt und schon gescrapt ist; einen Produktions-Key in Development wiederverwenden und versehentlich Live-Daten berühren; einen Deploy Key oder eine Master-Credential in committeten Code legen; und Nutzer-API-Keys als Klartext speichern, sodass ein Breach sie alle leakt. Jeder davon wird durch dieselbe Disziplin verhindert: Secrets aus Git heraus, separate Keys pro Umgebung, beim Leak rotieren, sensible Daten im Ruhezustand verschlüsseln. #### Business-ROI Secret-Disziplin ist günstige Versicherung gegen eine Kategorie von Katastrophen, die kleine Produkte in den Ruin getrieben hat: eine ausufernde Cloud-Rechnung durch einen geleakten Key, einen Betrugsvorfall durch einen geleakten Payment-Key oder einen Breach, der Kunden-Credentials offenlegt und rechtliche Haftung unter der DSGVO und den US-Datenschutzgesetzen auslöst. Die Kosten, das richtig zu machen, sind ein paar Minuten Setup pro Projekt und eine Standard-Verschlüsselungsfunktion, die du einmal schreibst. Die Kosten, es falsch zu machen, werden in Tausenden Dollar, rechtlicher Exposition und verlorenem Vertrauen gemessen, das du vielleicht nie zurückgewinnst. Für eine Gründerin ist das eine der Gewohnheiten mit der höchsten Rendite pro Aufwand im ganzen Stack. #### Checkliste Du bist sicher genug, um Payments hinzuzufügen, wenn all das über jedes Projekt stimmt, das du shippst. - Jedes Projekt hat eine korrekte .gitignore und keine .env wurde je committet. - Development und Produktion nutzen separate Keys, mit Prod-Secrets in deinen Host- und Backend-Dashboards gesetzt. - Du kennst die Regel: ein gepushtes Secret wird zuerst rotiert, die Historie danach gesäubert. - Jeder von Nutzern gelieferte API-Key ist im Ruhezustand verschlüsselt, mit dem Verschlüsselungs-Key aus der Datenbank herausgehalten. #### Ressourcen Halt die API-Key- und Rotations-Seiten deiner Dienste als Lesezeichen, damit du einen geleakten Key in Sekunden widerrufen kannst, wenn der Moment kommt. GitHub bietet auch Secret Scanning an, das dich auf geleakte Keys aufmerksam machen kann - schalt es ein. Die Grundlagen-Seite dazu, was eine env-Datei ist, deckt die Basics ab. Mit deinem abgesicherten Stack fügen die nächsten zwei Lektionen das Geld hinzu: Stripe Checkout und Subscriptions, dann die kniffligeren Billing-Details. #### Deine Aufgabe Auditiere eines deiner echten Projekte jetzt sofort. Bestätige, dass .gitignore jede .env-Variante ausschliesst, durchsuche die Repo-Historie nach einem versehentlich committeten Key, und falls du einen findest, rotier ihn sofort. Füge dann eine .env.example mit leeren Werten hinzu, damit das Projekt seine benötigten Secrets sicher dokumentiert. Wenn deine App einen von Nutzern gelieferten Key speichert, umhülle ihn mit den encrypt/decrypt-Funktionen oben. Dieses Audit ist die Art Sache, die Gründer aufschieben, bis es zu spät ist - mach es heute. #### Nächste Lektion Dein Stack ist sicher. Jetzt lass ihn verdienen. Die nächste Lektion fügt Stripe hinzu: Hosted versus Embedded Checkout, Produkte und Preise, Subscriptions mit monatlicher und jährlicher Abrechnung und die strikte Test-versus-Produktion-Disziplin, die dich Payments bauen lässt, ohne je eine echte Abbuchung zu riskieren. ### 3.5 Stripe Teil 1: Checkout, Subscriptions, Test vs Produktion - Kanonische URL: https://agenticschool.dev/de/kurse/modern-app-stack/stripe-part-1-checkout-subscriptions-test-vs-production - Dauer: 30 min Zusammenfassung: Hier kann dein Produkt verdienen. Stripe wickelt Zahlungen ab, sodass du nie rohe Kartendaten anfässt. Diese Lektion behandelt Embedded versus Hosted Checkout, das Produkte-und-Preise-Modell, Subscriptions mit monatlicher und jährlicher Abrechnung, die Testkarten, gegen die du baust (4242 4242 4242 4242), und die strikte Trennung von Test und Produktion, die dich Kunden selbstbewusst belasten lässt, ohne in Development echtes Geld zu riskieren. #### Überblick Auth, Daten und Secrets sind an Ort und Stelle. Jetzt kann dein Produkt Geld verdienen. Stripe ist der Standard, um Zahlungen entgegenzunehmen, und der Hauptnutzen ist, dass du nie eine rohe Kreditkartennummer anfässt - Stripe sammelt sie ein, sodass deine Compliance-Last von beängstigend auf handhabbar schrumpft. Diese Lektion bringt dich zu einer funktionierenden Subscription: die zwei Geschmacksrichtungen von Checkout, wie Produkte und Preise deine Preisgestaltung modellieren, wie Subscriptions wiederkehrende Abrechnung handhaben inklusive des Monatlich-versus-Jährlich-Toggles, den deine Pricing-Seite braucht, und die Testmodus-Disziplin, die dich das Ganze bauen und prüfen lässt, ohne einen Cent echtes Geld zu bewegen. #### Was du lernst Du lernst den Unterschied zwischen Hosted und Embedded Checkout und wann du jedes nutzt, wie Stripes Produkte-und-Preise-Modell auf deine Preisstufen abbildet, wie Subscriptions wiederkehrende monatliche und jährliche Abrechnung handhaben, wie du komplett im Testmodus mit Stripes Testkarten baust und die saubere Checkliste, um auf Produktion umzustellen, sobald alles funktioniert. #### Voraussetzungen Eine funktionierende App mit Auth und Daten und die Secrets-Disziplin aus der vorigen Lektion, denn Stripe-Keys gehören zu den sensibelsten, die du je halten wirst - ein geleakter Live-Key ist eine direkte Leitung zu deinem Geld. Du solltest auch damit vertraut sein, dass Test und Produktion separate Welten sind, genau wie bei Clerk. #### Das Problem Einsteiger nehmen an, Zahlungen entgegenzunehmen heisse, ein Kreditkartenformular zu bauen und Kartennummern zu speichern. Dieser Weg ist ein Albtraum: rohe Karten zu handhaben stellt dich unter das volle Gewicht der PCI-Compliance, und ein Fehler setzt dich Betrug und rechtlicher Haftung aus, die du nicht zu tragen ausgerüstet bist. Also vermeiden Leute entweder das Belasten ganz und lassen Geld auf dem Tisch, oder sie bauen etwas Unsicheres. Stripe existiert genau dafür, dass du nie eine Kartennummer speicherst. Du reichst den Zahlungsschritt an Stripe weiter, es sammelt die Karte auf seiner eigenen sicheren Infrastruktur ein und teilt dir das Ergebnis mit. Dein Job schrumpft auf "Produkte einrichten und auf das reagieren, was Stripe dir sagt", was völlig machbar ist. #### Hosted versus Embedded Checkout Stripe Checkout ist eine vorgefertigte, sichere Zahlungsseite, die Stripe pflegt, sodass du einen polierten, PCI-konformen Zahlungs-Flow ohne ein Formular zu bauen bekommst. Es kommt in zwei Geschmacksrichtungen. Hosted Checkout leitet den Kunden auf eine von Stripe gehostete Seite um (checkout.stripe.com), er zahlt, und Stripe leitet ihn zurück zu deiner Erfolgs-URL - am einfachsten einzurichten, voll von Stripe gepflegt. Embedded Checkout rendert dieselbe sichere Zahlungserfahrung innerhalb deiner eigenen Seite, sodass der Kunde deine App nie verlässt, was die Conversion verbessern kann und sich nativer anfühlt. Beide sind gleich sicher, weil Stripe so oder so die Kartendaten handhabt; der Unterschied ist rein, ob die Zahlung auf Stripes Seite oder eingebettet in deiner passiert. Starte mit Hosted, um am schnellsten funktionsfähig zu sein, wechsle dann zu Embedded für eine reibungslosere Erfahrung (Teil 2 behandelt Embedded ausführlich). - Hosted Checkout: zu einer Stripe-Seite umleiten, zahlen, zurück umleiten. Am schnellsten zu shippen, null Kartenhandhabung. - Embedded Checkout: derselbe sichere Flow, gerendert innerhalb deiner eigenen App. Bessere Conversion, mehr Politur. - Beide sind gleich sicher - Stripe handhabt die Karte in beiden Fällen. Die Wahl betrifft die Nutzererfahrung. - Du siehst oder speicherst mit keiner der beiden Optionen eine Kartennummer. #### Produkte und Preise Stripe modelliert deine Preisgestaltung mit zwei verknüpften Objekten: einem Produkt und einem oder mehreren Preisen. Ein Produkt ist die Sache, die du verkaufst ("Pro-Plan"). Ein Preis ist eine bestimmte Art, dafür zu zahlen ("20 USD pro Monat" oder "200 USD pro Jahr"). Ein Produkt kann mehrere Preise haben - das ist genau, wie du eine Pricing-Seite mit einem Monatlich/Jährlich-Toggle baust: dasselbe Pro-Produkt hat einen monatlichen Preis und einen jährlichen Preis, und dein Toggle schaltet um, welchen Preis der Checkout nutzt. Du erstellst Produkte und Preise im Stripe-Dashboard (oder via API), und jeder Preis bekommt eine ID wie price_xxx, auf die du verweist, wenn du einen Checkout startest. Preise als separate Objekte zu halten, statt Beträge in deinem Code fest einzubauen, heisst, dass du die Preisgestaltung im Dashboard ändern kannst, ohne neu zu deployen. - Produkt: was du verkaufst (der "Pro-Plan"). - Preis: eine Art, dafür zu zahlen (monatlich vs jährlich sind zwei Preise am selben Produkt). - Ein Monatlich/Jährlich-Toggle ist einfach die Wahl zwischen zwei Preis-IDs zum Checkout-Zeitpunkt. - Verweise auf Preise per ihrer price_xxx-ID; ändere Beträge im Dashboard, ohne Code anzufassen. #### Subscriptions: monatlich und jährlich Eine Subscription ist ein Preis, der nach einem wiederkehrenden Zeitplan abgerechnet wird. Wenn ein Kunde mit einem wiederkehrenden Preis auscheckt, erstellt Stripe eine Subscription und belastet seine Karte automatisch in jedem Zyklus - monatlich oder jährlich - und handhabt Verlängerungen, Wiederholungen bei fehlgeschlagenen Zahlungen und Kündigungen für dich. Das ist der Motor der SaaS-Umsätze, und Stripe fährt den Abrechnungszyklus, sodass du es nicht musst. Für die Pricing-Seite, die der Hausstil dieses Kurses verlangt, modellierst du zwei wiederkehrende Preise pro Stufe (einen monatlichen Preis und einen jährlichen Preis), stellst die Seite standardmässig auf den jährlichen Preis pro Monat und lässt den Toggle auf monatlich umschalten. Hier ist die Form, einen Subscription-Checkout zu starten - die genaue API-Oberfläche entwickelt sich, also folge Stripes aktuellen Docs, aber die Struktur bleibt stabil. ```typescript // Nur Backend (nutzt den SECRET key). Erstellt eine Checkout-Session für einen // wiederkehrenden Preis. Die Preis-ID entscheidet monatlich vs jährlich. import Stripe from 'stripe' const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!) export async function createSubscriptionCheckout(opts: { priceId: string // price_xxx für den gewählten monatlichen ODER jährlichen Plan customerEmail: string }) { return stripe.checkout.sessions.create({ mode: 'subscription', // wiederkehrende Abrechnung, keine Einmalzahlung line_items: [{ price: opts.priceId, quantity: 1 }], customer_email: opts.customerEmail, success_url: 'https://app.yoursite.com/welcome?session_id={CHECKOUT_SESSION_ID}', cancel_url: 'https://app.yoursite.com/pricing', }) } ``` Eine Subscription-Checkout-Session. mode: subscription bedeutet wiederkehrend; die Preis-ID wählt monatlich oder jährlich. Das läuft auf dem Backend mit deinem Secret Key, nie im Browser. Die Session, die es zurückgibt, ist das, wohin du den Kunden umleitest (Hosted) oder was du in deiner Seite renderst (Embedded). So oder so wird die Karte von Stripe eingesammelt. #### Testmodus und Testkarten Stripe gibt dir zwei völlig separate Modi - Test und Live - jeden mit eigenen Keys und eigenen Daten. Im Testmodus baust und prüfst du den gesamten Zahlungs-Flow, ohne echtes Geld zu bewegen, mit speziellen Testkartennummern, die Stripe erkennt. Die berühmte ist 4242 4242 4242 4242: eine Visa, die immer gelingt. Stripe bietet auch Karten, die Fehlschläge, Ablehnungen und Authentifizierungs-Herausforderungen simulieren, sodass du auch die unglücklichen Pfade testen kannst. Nutze ein beliebiges zukünftiges Ablaufdatum, eine beliebige dreistellige CVC und eine beliebige Postleitzahl. Mach deine ganze Entwicklung hier. Deine Test-Keys beginnen mit sk_test und pk_test und spiegeln dieselbe Präfix-Konvention, die du bei Clerk gesehen hast. - 4242 4242 4242 4242 - gelingt jedes Mal. Deine Voreinstellung fürs Happy-Path-Testen. - 4000 0000 0000 0002 - immer abgelehnt, sodass du die Fehlerbehandlung testen kannst. - 4000 0025 0000 3155 - erfordert Authentifizierung (3D Secure), sodass du diesen Flow testen kannst. - Nutze ein beliebiges zukünftiges Ablaufdatum, eine beliebige CVC, eine beliebige Postleitzahl. Echte Karten tun im Testmodus nichts. Testmodus-Daten (Kunden, Subscriptions, Zahlungen) sind völlig getrennt von Live-Daten und übertragen sich nie. Wenn du live gehst, startest du mit einem sauberen Live-Dashboard. Diese Trennung ist ein Feature: du kannst frei experimentieren, ohne je eine echte Abbuchung zu fürchten. #### Auf Produktion gehen Sobald alles im Testmodus funktioniert, ist Live-Gehen eine kurze, sorgfältige Checkliste statt eines Neuaufbaus. Du aktivierst deinen Stripe-Account (Stripe braucht deine Geschäfts- und Bankdaten, um dich auszuzahlen), erstellst deine Produkte und Preise im Live-Modus neu, falls du sie nur im Test gemacht hast, tauschst deine Test-Keys gegen Live-Keys in deiner deployten Umgebung und aktualisierst alle Preis-IDs, auf die dein Code verweist, auf die Live-IDs. Dann fährst du selbst eine echte, kleine Transaktion, um zu bestätigen, dass die ganze Schleife von Anfang bis Ende mit Live-Keys funktioniert. Entscheidend ist, dass du Test und Live strikt getrennt hältst - füg nie einen Live-Key in eine Development-env-Datei ein. Teil 2 fügt das Webhook-Setup hinzu, das Produktions-Billing wirklich braucht, also behandle Live-Gehen als "bereit, Zahlungen entgegenzunehmen" statt "voll produktionsgehärtet", bis du Teil 2 gemacht hast. - Aktiviere deinen Stripe-Account mit echten Geschäfts- und Bankdaten, damit Auszahlungen funktionieren. - Erstelle Produkte und Preise im Live-Modus neu; notiere die neuen Live-price_xxx-IDs. - Tausche sk_test / pk_test gegen sk_live / pk_live nur in deiner deployten Umgebung. - Mach selbst eine kleine echte Transaktion, um die Live-Schleife zu bestätigen, dann erstatte sie zurück. - Nenn es nicht fertig, bis Teil 2 die Webhooks verdrahtet - sie sind, wie deine App erfährt, was wirklich passiert ist. #### Typische Fehler Die häufigen: den Stripe Secret Key in Frontend-Code legen, wo jeder Besucher ihn lesen kann (er gehört nur ins Backend); Preisbeträge im Code fest einbauen, statt auf Preis-IDs zu verweisen, sodass eine Preisänderung ein Neu-Deploy bedeutet; vergessen, dass Test- und Live-Daten sich nie verbinden, und dann in Panik geraten, dass die Produktion leer aussieht; und der grosse, vor dem dieser Kurs immer wieder warnt - denken, Checkout allein reiche. Ohne Webhooks (Teil 2) rät deine App, ob eine Zahlung wirklich gelungen ist. Bau im Testmodus, halt den Secret Key im Backend und behandle Teil 2 als verpflichtend, nicht optional. #### Business-ROI Payments sind der Moment, in dem dein Produkt aufhört, eine Kostenstelle zu sein, und ein Business wird. Stripe lässt eine Solo-Gründerin Geld von überall auf der Welt entgegennehmen, nach einem wiederkehrenden Zeitplan, ohne ein Payments-Team oder PCI-Auditoren, an einem Nachmittag. Subscriptions verwandeln speziell einmaligen Aufwand in wiederkehrenden Umsatz, was der gesamte finanzielle Reiz von SaaS ist - du baust einmal und verdienst monatlich. Und der Monatlich-versus-Jährlich-Toggle ist nicht kosmetisch: jährliche Pläne verbessern den Cashflow und senken die Abwanderung, weshalb der Hausstil dieses Kurses die Pricing-Seite standardmässig auf den jährlichen Preis stellt. Gut bezahlt zu werden ist genauso eine Produktentscheidung wie eine technische. #### Checkliste Du bist bereit für Teil 2, wenn all das im Testmodus stimmt. - Du kannst erklären, warum du nie rohe Kartendaten handhabst und was Checkout für dich tut. - Du hast ein Produkt mit sowohl einem monatlichen als auch einem jährlichen Preis erstellt. - Ein Subscription-Checkout funktioniert im Testmodus mit Karte 4242 4242 4242 4242. - Der Stripe Secret Key lebt nur im Backend, in einer gitignored env-Datei. #### Ressourcen Die Stripe-Docs und die Testkarten-Referenz sind essentiell und immer aktuell - halt sie offen, während du baust. Die Stripe CLI (in Teil 2 stark genutzt) lohnt sich jetzt zu installieren. Deine Pricing-Seite sollte dem Hausstil dieses Kurses folgen: jährlicher Preis standardmässig pro Monat gezeigt, mit einem Monatlich/Jährlich-Toggle. Als Nächstes macht Teil 2 das Billing mit Webhooks wirklich verlässlich. #### Deine Aufgabe Erstelle im Testmodus ein Pro-Produkt mit einem monatlichen und einem jährlichen Preis, baue dann einen Subscription-Checkout, den ein eingeloggter Nutzer mit der 4242-Testkarte abschliessen kann. Bestätige, dass die Subscription in deinem Stripe-Test-Dashboard erscheint. Probier dann die abgelehnte Karte (4000 0000 0000 0002) und beachte, wie deine App den Fehlschlag handhabt - dieses Bewusstsein für den unglücklichen Pfad trennt einen echten Billing-Flow von einer Demo. #### Nächste Lektion Checkout ist nur die halbe Geschichte. Die nächste Lektion handhabt die Teile, die Billing vertrauenswürdig machen: Webhooks (und warum Polling der falsche Instinkt ist), Signaturverifizierung, Idempotenz, Proration, wenn ein Kunde mitten im Zyklus upgradet, Coupons und Promotion Codes und Embedded Checkout. Das sind die Details, die ein Spielzeug von einem echten Billing-System trennen. ### 3.6 Stripe Teil 2: Webhooks, Proration, Coupons und Embedded Checkout - Kanonische URL: https://agenticschool.dev/de/kurse/modern-app-stack/stripe-part-2-webhooks-proration-coupons-and-embedded-checkout - Dauer: 32 min Zusammenfassung: Verlässliches Billing hängt von Webhooks ab: Stripe sagt deiner App, was tatsächlich passiert ist, statt dass deine App rät. Diese Lektion behandelt, was Webhooks sind und warum Polling falsch ist, Webhook-Secrets und Signaturverifizierung, Idempotenz, damit du nie ein Event doppelt verarbeitest, Proration, wenn ein Kunde mitten im Zyklus upgradet, Coupons und Promotion Codes, Embedded Checkout und die häufigen Webhook-Gotchas, über die alle stolpern. #### Überblick In Teil 1 hast du eine Zahlung entgegengenommen. Aber hier ist die unbequeme Wahrheit: nachdem du einen Kunden zum Checkout umgeleitet hast, weiss deine App eigentlich nicht, was mit ihm passiert ist. Hat er gezahlt? Ist die Karte später fehlgeschlagen? Hat er nächsten Monat gekündigt? Zu raten ist, wie Leute das Produkt versehentlich gratis verschenken oder gekündigte Kunden weiter belasten. Die Antwort sind Webhooks: Stripe ruft deine App, wann immer etwas passiert, sodass deine App auf die Realität reagiert statt zu raten. Diese Lektion macht dein Billing vertrauenswürdig: verifizierte Webhooks, Idempotenz, Proration, Coupons, Embedded Checkout und die Gotchas, die jeden beim ersten Mal beissen. #### Was du lernst Du lernst, was ein Webhook ist und warum es der falsche Instinkt ist, Stripe zu pollen, wie du eine Webhook-Signatur verifizierst, sodass Angreifer keine Events fälschen können, wie Idempotenz dich davon abhält, ein dupliziertes Event doppelt zu verarbeiten, wie Proration eine Planänderung mitten im Zyklus fair handhabt, den Unterschied zwischen Coupons und Promotion Codes, wie Embedded Checkout funktioniert und die Webhook-Gotchas, die den klassischen "es funktionierte im Test, aber brach in Produktion"-Fehlschlag verursachen. #### Voraussetzungen Stripe Teil 1 und ein funktionierender Subscription-Checkout, plus ein Backend, das HTTP-Requests empfangen kann (deine Convex-Actions oder die Server-Routen deines Frameworks), denn ein Webhook ist einfach Stripe, das einen Request an dein Backend schickt. Die Secrets-Lektion auch, denn das Webhook-Signing-Secret ist ein weiterer Key, den es zu bewachen gilt. #### Das Problem Der naive Instinkt nach dem Checkout ist zu pollen: alle paar Sekunden Stripe fragen "haben sie schon gezahlt?". Das ist auf jeder Achse falsch. Es verschwendet Requests, es ist langsam, es verpasst Events, die später passieren (eine Verlängerung nächsten Monat, eine Karte, die in 30 Tagen fehlschlägt, eine Kündigung), und es skaliert nicht. Schlimmer, sich allein auf die Erfolgs-URL-Umleitung zu verlassen ist unzuverlässig - ein Kunde kann zahlen und dann den Tab schliessen, bevor die Umleitung feuert, und jetzt hat er gezahlt, aber deine App hat es nie aufgezeichnet. Das richtige Modell ist umgekehrt: frag nicht, lass dir sagen. Stripe pusht ein Event an dein Backend in dem Moment, in dem etwas passiert, und deine App reagiert. Das ist ein Webhook, und ihn richtig hinzubekommen ist, was Billing vertrauenswürdig macht. #### Was Webhooks sind und Signaturen verifizieren Ein Webhook ist Stripe, das einen HTTP-Request an eine URL macht, die dir gehört, wann immer ein Event auftritt: eine Zahlung ist gelungen, eine Subscription wurde verlängert, eine Karte ist fehlgeschlagen, eine Subscription wurde gekündigt. Dein Backend lauscht an dieser URL und aktualisiert deine Datenbank als Reaktion. Aber es gibt einen Haken: jeder im Internet könnte einen gefälschten Request an diese URL schicken und vorgeben, Stripe zu sein, und versuchen, deine App zu täuschen, kostenlosen Zugang zu gewähren. Also musst du verifizieren, dass jeder Request wirklich von Stripe kam. Stripe signiert jeden Webhook mit einem Secret (dem Webhook-Signing-Secret, das mit whsec_ beginnt), und du verifizierst diese Signatur bei jedem Request. Wenn die Verifizierung fehlschlägt, lehnst du den Request ab. Vertrau nie einem unverifizierten Webhook. Hier ist die Verifizierung, die nicht verhandelbar ist. ```typescript // Webhook-Handler (Backend). Verifiziere die Signatur, BEVOR du irgendetwas vertraust. import Stripe from 'stripe' const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!) const webhookSecret = process.env.STRIPE_WEBHOOK_SECRET! // whsec_xxx export async function handleStripeWebhook(req: Request) { const signature = req.headers.get('stripe-signature')! const rawBody = await req.text() // MUSS der rohe Body sein, kein geparstes JSON let event: Stripe.Event try { // Wirft, wenn die Signatur ungültig oder der Body verändert wurde. event = await stripe.webhooks.constructEventAsync(rawBody, signature, webhookSecret) } catch { return new Response('Invalid signature', { status: 400 }) } switch (event.type) { case 'checkout.session.completed': // Zugang gewähren / den Nutzer in deiner Datenbank als abonniert markieren. break case 'customer.subscription.deleted': // Zugang entziehen - sie haben gekündigt. break case 'invoice.payment_failed': // Den Nutzer warnen / einen Dunning-Flow starten. break } return new Response('ok', { status: 200 }) } ``` Verifiziere immer die Signatur mit dem rohen Body, bevor du einem Webhook vertraust. Ein unverifizierter Webhook ist eine offene Tür. Ein Detail, das Leute bricht: du musst gegen den rohen Request-Body verifizieren, genau wie Stripe ihn gesendet hat. Wenn dein Framework den Body in JSON parst, bevor du verifizierst, passt die Signatur nicht und jeder Webhook schlägt fehl. Lies zuerst den rohen Body, verifiziere, dann parse. #### Idempotenz: Duplikate sicher handhaben Stripe garantiert, dass es jedes Event mindestens einmal zustellt, was heisst, es könnte dasselbe Event mehr als einmal zustellen - bei einem Retry nach einem Timeout oder einem Netzwerk-Schluckauf. Wenn dein Handler einen Monat Gratis-Credits gewährt oder eine Willkommens-E-Mail sendet, jedes Mal wenn er checkout.session.completed sieht, gewährt oder mailt eine doppelte Zustellung doppelt. Der Fix ist Idempotenz: gestalte deinen Handler so, dass das Verarbeiten desselben Events zweimal denselben Effekt hat wie das Verarbeiten einmal. Der einfachste verlässliche Ansatz ist, jede Event-ID aufzuzeichnen, die du verarbeitet hast, und sie zu überspringen, wenn du sie erneut siehst. Stripe empfiehlt auch, schnell mit einer 200 zu antworten und langsame Arbeit danach zu erledigen, damit Stripe nicht in einen Timeout läuft und unnötig erneut zustellt. - Stripe stellt jedes Event mindestens einmal zu, also passieren Duplikate - gestalte dafür. - Speichere verarbeitete Event-IDs; wenn du eine schon gesehen hast, quittiere sie und überspring die Arbeit. - Mach Aktionen sicher zu wiederholen: "setze subscribed = true" ist natürlich idempotent; "füge einen Monat hinzu" ist es nicht. - Antworte schnell mit 200; wenn du langsam bist oder einen Fehler hast, retryt Stripe, was mehr Duplikate verursacht. #### Proration bei Upgrades mitten im Zyklus Ein Kunde im monatlichen Plan upgradet zum jährlichen Plan, oder wechselt von einer günstigeren Stufe zu einer teureren, mitten in seinem Abrechnungszeitraum. Was soll er zahlen? Proration ist Stripe, das den fairen Betrag berechnet: es schreibt den ungenutzten Teil dessen gut, was er schon gezahlt hat, und berechnet die Differenz für den neuen Plan für den Rest des Zeitraums. Du berechnest das nicht selbst - du sagst Stripe, die Subscription auf den neuen Preis zu aktualisieren, und Stripe ermittelt die anteilige Abbuchung oder Gutschrift. Dein Job ist, das Verhalten zu entscheiden (die Differenz sofort berechnen oder auf die nächste Rechnung anwenden) und den Zugang in deiner App zu aktualisieren, wenn der Webhook die Änderung bestätigt. Der zu vermeidende Fehler ist, anteilige Beträge von Hand zu berechnen; lass Stripe die Arithmetik machen und reagiere auf die resultierenden Events. - Upgrade mitten im Zyklus: Stripe schreibt die ungenutzte Zeit gut und berechnet die anteilige Differenz. - Du aktualisierst die Subscription auf die neue Preis-ID; Stripe berechnet das Geld. - Wähle, ob die Proration jetzt berechnet oder auf die nächste Rechnung addiert wird. - Reagiere auf den Webhook (Subscription aktualisiert, Rechnung bezahlt), um den Zugang in deiner App zu synchronisieren. #### Coupons und Promotion Codes Diese zwei sind verwandt, aber nicht dasselbe, und die Unterscheidung zählt. Ein Coupon ist die zugrunde liegende Rabattregel: "20 Prozent Rabatt" oder "10 USD Rabatt, einmalig". Ein Promotion Code ist ein kundenseitiger Code (wie LAUNCH20), der einen Coupon anwendet. Du erstellst einen Coupon, dann erstellst du einen oder mehrere Promotion Codes, die auf ihn zeigen. Der Grund für zwei Schichten ist Flexibilität: ein Coupon ("20 Prozent Rabatt") kann mehrere Codes mit verschiedenen Einschränkungen tragen (Ablauf, Nutzungslimit, nur Erstkunden). Im Checkout kannst du ein Promotion-Code-Feld aktivieren, sodass Kunden selbst einen Code tippen, oder du kannst einen Coupon direkt auf eine Session im Code anwenden für einen automatischen Rabatt. Nutze Promotion Codes für Marketing-Kampagnen, bei denen Kunden eingeben sollen, und direkte Coupon-Anwendung für Rabatte, die du programmatisch gewährst. - Coupon: die Rabattregel selbst (Prozent Rabatt, fester Betrag, Dauer). - Promotion Code: ein kundenseitiger Code (LAUNCH20), der einen Coupon anwendet. - Ein Coupon kann viele Promotion Codes mit verschiedenen Limits und Abläufen tragen. - Aktiviere das Promotion-Code-Feld im Checkout für kundeneingegebene Codes, oder wende einen Coupon im Code an für automatische Rabatte. #### Embedded Checkout Teil 1 erwähnte Embedded Checkout; hier verdient es seinen Platz. Embedded Checkout rendert Stripes sicheren Zahlungs-Flow innerhalb deiner eigenen Seite, statt zu einer von Stripe gehosteten URL umzuleiten, sodass der Kunde die ganze Zeit auf deiner Domain bleibt. Das hebt meist die Conversion (jede Umleitung ist eine Chance, jemanden zu verlieren) und fühlt sich mehr wie Teil deines Produkts an. Die Mechanik: dein Backend erstellt eine Checkout-Session im embedded ui_mode und gibt ein Client Secret zurück, und dein Frontend mountet Stripes Embedded-Komponente mit diesem Secret. Die Karte wird weiterhin vollständig von Stripe eingesammelt, sodass du alle Sicherheits- und Compliance-Vorteile behältst, während du die Erfahrung besitzt. Greif zu Embedded, sobald dein Hosted-Flow funktioniert und du die Conversion straffen willst. ```typescript // Backend: erstelle eine EMBEDDED Checkout-Session und gib ihr Client Secret zurück. const session = await stripe.checkout.sessions.create({ ui_mode: 'embedded', // embedded, keine Umleitung mode: 'subscription', line_items: [{ price: priceId, quantity: 1 }], return_url: 'https://app.yoursite.com/welcome?session_id={CHECKOUT_SESSION_ID}', }) // Sende session.client_secret an das Frontend, das Stripes Embedded-UI mountet. ``` Embedded Checkout hält den Kunden auf deiner Domain, während Stripe weiterhin die Karte handhabt. #### Häufige Webhook-Gotchas Das sind die konkreten Dinge, die Webhooks "im Test funktionieren, aber in Produktion brechen" lassen, gesammelt, damit du jedem ausweichen kannst. Die meisten Produktions-Billing-Bugs lassen sich auf einen davon zurückführen. - Den Body vor dem Verifizieren parsen: die Signaturprüfung braucht den rohen Body. Lies zuerst roh, verifiziere, dann parse. - Das falsche Webhook-Secret nutzen: Test und Live haben jeweils ein anderes whsec_, und die Stripe CLI gibt ein drittes fürs lokale Weiterleiten. Passe das Secret an die Umgebung an. - Duplikate nicht handhaben: ohne Idempotenz verarbeitet ein erneut zugestelltes Event doppelt. Speichere verarbeitete Event-IDs. - Der Erfolgs-Umleitung statt dem Webhook vertrauen: der Nutzer kann den Tab schliessen, bevor die Umleitung feuert, also gewähre Zugang aus dem Webhook, nicht der Umleitung. - Langsame oder fehlschlagende Handler: gib schnell 200 zurück. Wenn du zu lange brauchst oder einen Fehler hast, retryt Stripe, was Duplikate vervielfacht. - Vergessen, den Produktions-Webhook-Endpoint zu registrieren: der Test-Endpoint überträgt sich nicht in den Live-Modus. Füg die Live-URL und ihr Secret hinzu, wenn du live gehst. ```bash # Webhooks lokal mit der Stripe CLI testen - sie leitet Live-Events an deinen Rechner weiter # und gibt ein whsec_-Secret zur lokalen Verifizierung aus. stripe login stripe listen --forward-to localhost:5296/api/stripe/webhook # In einem anderen Terminal ein Fake-Event auslösen, um deinen Handler zu testen: stripe trigger checkout.session.completed ``` Die Stripe CLI leitet echte Events an localhost weiter und lässt dich Test-Events auslösen - der Standardweg, um Webhooks zu entwickeln. #### Typische Fehler Über die Gotcha-Liste hinaus: Stripe pollen, statt Webhooks zu nutzen; einem unverifizierten Webhook vertrauen und einen Angreifer ein "Zahlung gelungen"-Event fälschen lassen, um kostenlosen Zugang zu bekommen; Proration von Hand berechnen, statt Stripe es machen zu lassen; Coupons und Promotion Codes verwechseln; und Embedded Checkout shippen, ohne zuerst den Hosted-Flow und die Webhooks solide zu bekommen. Der rote Faden: lass dir sagen, frag nicht; verifiziere alles; lass Stripe die Geld-Mathematik machen; und behandle Duplikate als unvermeidlich. #### Business-ROI Diese Lektion ist der Unterschied zwischen Billing, das dir still Geld verliert, und Billing, dem du vertrauen kannst. Ohne verifizierte Webhooks verschenkst du entweder Zugang, für den du nie bezahlt wurdest, oder belastest weiter Leute, die gekündigt haben - beides ist direkter Umsatz- und Reputationsschaden. Idempotenz verhindert die peinliche Doppelabbuchung oder Doppelgewährung. Von Stripe gemachte Proration hält Upgrades fair, was Reibung aus der wertvollsten Aktion nimmt, die ein Kunde tun kann: mehr ausgeben. Und Embedded Checkout plus Promotion Codes sind direkte Conversion-Hebel. Einen Tag aufzuwenden, um Webhooks richtig zu bekommen, schützt jeden Dollar, der von hier an durch dein Produkt fliesst. #### Checkliste Dein Billing ist produktionsreif, wenn all das gilt. - Du verifizierst jede Webhook-Signatur gegen den rohen Body, bevor du darauf reagierst. - Dein Handler ist idempotent - ein dupliziertes Event verursacht keine Doppelverarbeitung. - Du gewährst und entziehst Zugang aus Webhooks, nicht aus der Erfolgs-Umleitung. - Upgrades nutzen Stripe-Proration, und du hast einen funktionierenden Promotion Code und einen Embedded- oder Hosted-Flow live. #### Ressourcen Die Stripe-Webhooks-Docs, die Events-Referenz und die Stripe CLI sind hier deine Kernwerkzeuge - die CLI macht besonders die lokale Webhook-Entwicklung schmerzlos. Halt deine Test- und Live-Webhook-Signing-Secrets klar beschriftet, damit du sie nie kreuzt. Als Nächstes nimmt die letzte Lektion den ganzen Stack live: Dev-zu-Prod-Migration für Clerk und Convex, DNS, Cloudflare, Search Console und Performance. #### Deine Aufgabe Installiere die Stripe CLI, führe stripe listen aus, um Events an dein lokales Backend weiterzuleiten, und baue einen Webhook-Handler, der die Signatur verifiziert und bei checkout.session.completed Zugang gewährt. Löse ein Duplikat desselben Events aus und bestätige, dass dein Handler es nicht doppelt verarbeitet. Aktiviere dann ein Promotion-Code-Feld in deinem Checkout und teste einen Coupon. Du hast jetzt Billing, das auf die Realität reagiert, statt zu raten. #### Nächste Lektion Dein Produkt nimmt Zahlungen verlässlich entgegen. Die letzte Lektion des Kurses nimmt alles live: Clerk und Convex von Dev zu Prod migrieren, DNS und Cloudflare verdrahten, deine Seite in der Google Search Console verifizieren und deine Sitemap einreichen und deine Lighthouse-Scores ins Grüne bringen, damit das Live-Produkt schnell und auffindbar ist. ### 3.7 Live gehen: Dev-zu-Prod-Migration, Search Console und Performance - Kanonische URL: https://agenticschool.dev/de/kurse/modern-app-stack/going-live-dev-to-prod-migration-search-console-and-performance - Dauer: 30 min Zusammenfassung: Die Launch-Lektion für den modernen Stack. Du migrierst Clerk und Convex von Development zu Produktion, ohne Logins oder Daten zu brechen, verdrahtest deine Domain und DNS mit Cloudflare davor, verifizierst deine Seite in der Google Search Console und reichst deine Sitemap ein, damit du indexiert wirst, und stimmst Lighthouse und die Page-Speed-Grundlagen ab, die wirklich zählen, damit das Live-Produkt schnell und auffindbar ist. #### Überblick Du hast den ganzen Stack gebaut: Architektur, Auth, Daten, Secrets und Payments. Jetzt nimmst du ihn live und sorgst dafür, dass die Welt ihn finden kann. Live-Gehen ist kein einzelner Knopf - es ist, jeden Dienst von seiner Development-Instanz zur Produktion in einer sorgfältigen Reihenfolge zu migrieren, deine Domain über Cloudflare auf die richtigen Stellen zu zeigen, Google zu sagen, dass deine Seite existiert, und sie schnell zu machen. Mach es in der richtigen Reihenfolge, und der Launch-Tag ist ruhig. Mach es ad hoc, und du bekommst den klassischen Launch-Tag-Fehlschlag, bei dem ein verpasster Key Logins oder Billing lahmlegt, während Kunden zusehen. Diese Lektion gibt dir die ruhige Version. #### Was du lernst Du lernst eine sichere Reihenfolge, um Clerk und Convex von Development zu Produktion zu migrieren, wie du deine Domain und DNS mit Cloudflare vor deiner App verdrahtest, wie du deine Seite in der Google Search Console verifizierst und deine Sitemap einreichst, damit du indexiert wirst, und welche Lighthouse- und Core-Web-Vitals-Grundlagen wirklich für Tempo, SEO und Conversion zählen. #### Voraussetzungen Ein kompletter Stack aus diesem Kurs - Auth, Daten und Payments, alle in Development funktionierend - denn Live-Gehen verbindet alle drei. Die Deploy-Lektion aus Kurs 1, denn Vercel, DNS und Cloudflare tauchten dort auf und diese Lektion baut darauf auf. Und die Produktions-Setup-Teile aus den Lektionen zu Clerk, Stripe und Secrets, die du jetzt zusammenbringst. #### Das Problem Migration ist, wo selbstbewusste Builder gedemütigt werden. Jeder Dienst hat seine eigenen Dev- und Prod-Welten (Clerk-Instanzen, Convex-Deployments, Stripe-Modi), und sie in der falschen Reihenfolge umzuschalten oder einen Key zu vergessen hinterlässt eine halb-live App, in der sich Nutzer registrieren können, aber ihre Daten verschwinden, oder sie zahlen können, aber nie Zugang bekommen. Derweil ist selbst ein perfekter Launch unsichtbar, wenn Google nicht weiss, dass deine Seite existiert, und deine Seiten langsam sind. Gründer giessen Wochen ins Bauen und vermasseln dann die letzte Meile, sodass das Produkt kaputt oder unauffindbar startet. Diese Lektion ist diese letzte Meile, in einer bewussten Reihenfolge gemacht. #### Eine sichere Migrationsreihenfolge Migriere einen Dienst nach dem anderen und verifiziere jeden vor dem nächsten, sodass du, wenn etwas bricht, genau weisst, welcher Schritt es verursacht hat. Die sichere Reihenfolge ist: Domain und DNS zuerst (damit die Adresse existiert), dann Convex (damit Daten ein Zuhause haben), dann Clerk (damit Auth auf die Live-Domain und die Live-Datenbank zeigt), dann Stripe (damit Payments Zugang zum nun-live System gewähren), dann mit allen Live-Keys an Ort und Stelle deployen. Nach jeder Umstellung teste den echten Flow, bevor du weitergehst. Der mit Abstand häufigste Fehlschlag ist, einen Test-Key in der deployten Umgebung zu lassen, also mach einen finalen Durchlauf über jede Umgebungsvariable und bestätige, dass kein einziges sk_test, pk_test oder Test-Webhook-Secret in Produktion überlebt. - Domain und DNS zuerst: die Domain registrieren, sie über Cloudflare auf deine App und Marketing-Seite zeigen. - Convex als Nächstes: das Produktions-Deployment erstellen, seine env vars setzen, dein Schema und deine Funktionen darauf deployen. - Clerk als Nächstes: die Produktions-Instanz erstellen, ihre DNS-Records hinzufügen, Google OAuth konfigurieren, auf pk_live / sk_live umstellen. - Stripe zuletzt: den Account aktivieren, Produkte und Preise im Live-Modus neu erstellen, den Live-Webhook-Endpoint registrieren, auf Live-Keys umstellen. - Finaler Durchlauf: bestätige, dass null Test-Keys in den Produktions-env-vars verbleiben, dann deploye und teste den vollen Signup-zu-Payment-Flow live. #### Domain, DNS und Cloudflare davor Deine Marketing-Seite und deine App leben an verschiedenen Adressen, meist der nackten Domain (yoursite.com) fürs Marketing und einer Subdomain (app.yoursite.com) für die App, genau wie die Architektur-Lektion beschrieb. Du zeigst beide über DNS, und ein häufiges, starkes Muster ist, Cloudflare davorzusetzen: DNS bei Cloudflare verwalten, sein kostenloses HTTPS und globales CDN bekommen und jeden Namen an die richtige Stelle routen (typischerweise Vercel für beide Oberflächen). Erinnere dich an die Clerk-Subdomains aus Lektion 2 - diese CNAME-Records wollen meist DNS-only (graue Wolke) sein statt proxied, damit sie den Auth-TLS-Handshake nicht brechen. Cloudflare davor gibt dir Tempo und grundlegenden Schutz gratis, weshalb die meisten Builder es nutzen. Pass auf, dass du nicht doppelt proxst oder HTTPS doppelt handhabst, der Gotcha aus Kurs 1. ```text ; Example DNS layout (real targets come from Vercel / Clerk) ; Type Name Value / target Proxy CNAME @ cname.vercel-dns.com proxied ; marketing site CNAME app cname.vercel-dns.com proxied ; the app CNAME clerk frontend-api.clerk.services DNS only ; auth - do NOT proxy CNAME accounts accounts.clerk.services DNS only ; auth - do NOT proxy ``` Marketing und App können durch Cloudflare proxied werden; Clerk-Auth-Subdomains bleiben DNS-only, damit TLS funktioniert. #### Google Search Console und deine Sitemap Eine Live-Seite, von der Google nichts weiss, bekommt keinen Suchtraffic. Die Google Search Console ist das kostenlose Tool, das Google sagt, dass deine Seite existiert, zeigt, wie es dich indexiert, und Probleme früh sichtbar macht. Der Ablauf: füg deine Seite als Property hinzu, verifiziere, dass sie dir gehört (die einfachste Methode ist meist ein DNS-TXT-Record, den die Search Console dir gibt und den du bei Cloudflare hinzufügst), reich dann deine Sitemap-URL ein. Deine Sitemap ist die maschinenlesbare Liste deiner Seiten - dieses Projekt generiert bereits eine mit dem generate:sitemaps-Skript - und sie einzureichen sagt Google genau, was zu crawlen ist. Danach wird die Search Console dein Frühwarnsystem: sie zeigt die Indexierungs-Abdeckung, für welche Queries du erscheinst, und alle Crawl-Fehler, sodass du SEO-Probleme fängst, bevor sie dich Traffic kosten. ```text ; Eigentum in der Search Console mit einem TXT-Record verifizieren (Wert kommt von Google) ; Type Name Value TXT @ google-site-verification=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ; Dann deine Sitemap-URL in der Search-Console-UI einreichen: ; https://yoursite.com/sitemap.xml ``` Mit einem DNS-TXT-Record verifizieren, dann deine Sitemap einreichen, damit Google weiss, was zu crawlen ist. Indexierung ist nicht sofort. Nach dem Einreichen braucht Google Tage bis Wochen, um eine neue Seite zu crawlen und zu indexieren, und die Search Console zeigt den Fortschritt. Die Sitemap einzureichen und alle Fehler zu beheben, die sie meldet, ist die wirkungsvollste SEO-Aktion, die du beim Launch unternehmen kannst. #### Lighthouse und die Page-Speed-Grundlagen, die zählen Lighthouse ist das kostenlose Audit, das in Chrome eingebaut ist (und in CI lauffähig), das deine Seiten auf Performance, Barrierefreiheit, Best Practices und SEO bewertet. Schnelle Seiten konvertieren besser und ranken besser - Google nutzt Core Web Vitals als Ranking-Signal, und KI-Crawler bevorzugen ebenfalls schnelle, saubere Seiten -, also zahlt es sich doppelt aus, Tempo als Teil des Launches zu behandeln. Du musst keine perfekte 100 bei jeder Metrik jagen, aber du solltest die Handvoll Dinge verstehen, die wirklich etwas bewegen, denn die meisten langsamen Seiten sind aus denselben wenigen Gründen langsam. Fahr Lighthouse besonders auf deinen Marketing-Seiten, denn die sind die Eingangstür deines Funnels und wo Tempo am meisten zählt. - Bilder: der Hauptschuldige Nummer eins. Liefere moderne Formate (WebP/AVIF), dimensioniere sie korrekt und lazy-loade Bilder unterhalb der Falz. - JavaScript: liefere weniger davon. Genau darum nutzt die Marketing-Seite ein content-first Framework - weniger Skripte, schnellere Seiten. - Largest Contentful Paint (LCP): wie schnell der Hauptinhalt erscheint. Optimiere dein Hero-Bild und deine Fonts, um es zu verbessern. - Cumulative Layout Shift (CLS): Dinge, die beim Laden der Seite herumspringen. Reserviere Platz für Bilder und Anzeigen, damit nichts verrutscht. - Fonts: lade sie effizient und vermeide Blitze unsichtbaren Texts. Selbst-Hosting und Preloading helfen. - Caching und das CDN: Cloudflare davor liefert statische Assets bereits weltweit schnell aus - lehn dich darauf. #### Typische Fehler Die Launch-Tag-Klassiker: einen Test-Key in Produktion lassen, sodass Logins oder Payments still fehlschlagen; Dienste in einer verworrenen Reihenfolge migrieren, sodass du nicht sagen kannst, was gebrochen ist; Clerks Auth-Subdomains durch Cloudflare proxen und den TLS-Handshake brechen; vergessen, den Live-Stripe-Webhook-Endpoint zu registrieren, sodass Produktionszahlungen nie Zugang gewähren; die Seite nie in der Search Console verifizieren oder die Sitemap einreichen, sodass der Launch für Google unsichtbar ist; und schwere, unoptimierte Bilder shippen, die Lighthouse und Conversion abstürzen lassen. Jeder davon wird durch die geordnete Checkliste und einen finalen Umgebungsvariablen-Durchlauf verhindert. #### Business-ROI Die letzte Meile ist, wo all dein Bauen sich entweder auszahlt oder still scheitert. Eine saubere Migration heisst, der Launch-Tag ist langweilig statt ein Ausfall vor deinen ersten Kunden. Search Console und die Sitemap sind der Unterschied zwischen einem Produkt, das über Monate Traffic aufaddiert, und einem, das nie jemand findet. Und Page-Speed ist ein direkter Hebel auf sowohl Conversion als auch Ranking - schnellere Seiten verdienen buchstäblich mehr Geld und ranken höher, jeden einzelnen Tag, den sie live sind. Für eine Gründerin schützt es die gesamte Investition des Produktbaus überhaupt, die letzte Meile richtig hinzubekommen. #### Checkliste Du hast Kurs 3 abgeschlossen, wenn all das am Live-Produkt stimmt. - Clerk, Convex und Stripe sind alle in Produktion, und null Test-Keys verbleiben in den Produktions-env-vars. - Deine Domain liefert die Marketing-Seite und App über HTTPS aus, mit Cloudflare davor und Clerk-Subdomains DNS-only. - Deine Seite ist in der Google Search Console verifiziert und deine Sitemap ist eingereicht. - Lighthouse auf deinen Marketing-Seiten ist gesund, mit optimierten Bildern und JavaScript. #### Ressourcen Halt die Clerk- und Convex-Produktions-Deployment-Guides, die Stripe-Go-Live-Checkliste und die Google Search Console während des Launches offen - jeder ist aktuell, wo dieser Kurs auf Docs verweist. Fahr Lighthouse aus den Chrome DevTools oder deiner CI auf jeder Marketing-Seite. Die Deploy-Lektion aus Kurs 1 ist deine Referenz für Vercel-, DNS- und Cloudflare-Grundlagen. Du kannst jetzt ein komplettes, bezahltes Produkt von Anfang bis Ende bauen und launchen. #### Deine Aufgabe Nimm ein Projekt aus diesem Kurs live, auch ein kleines. Migriere Clerk und Convex in der sicheren Reihenfolge zu Produktion, zeig deine Domain über Cloudflare, mach den finalen env-var-Durchlauf, um jeden Test-Key zu töten, verifiziere die Seite in der Search Console und reich die Sitemap ein, fahr dann Lighthouse auf deiner Homepage und behebe die zwei grössten Probleme, die es meldet. Die volle letzte Meile einmal zu machen verwandelt den Launch von einer beängstigenden Unbekannten in eine Routine-Checkliste für jedes Produkt, das du danach baust. #### Nächste Lektion Du kannst jetzt ein echtes, bezahltes Produkt von Anfang bis Ende bauen und launchen: Architektur, Auth, Daten, Secrets, Payments und ein sauberes Live-Gehen. Kurs 4 geht über eine einzelne App hinaus in Automation und agentische Systeme - n8n und Workflow-Tools, Browser-Automation, Sandboxes und das Bauen eigener KI-Tools, die Arbeit für dich erledigen, während du schläfst. ### 4.1 Workflow-Automation: n8n, Zapier und Trigger.dev - was du wann nimmst - Kanonische URL: https://agenticschool.dev/de/kurse/automation-agentic-systems/workflow-automation-n8n-zapier-and-trigger-dev-what-to-use-when - Dauer: 26 min Zusammenfassung: Nicht alles muss eine eigene App sein. Automations-Plattformen verbinden Dienste und führen Workflows auf Trigger aus. Diese Lektion vergleicht n8n, Zapier und Trigger.dev, behandelt das Self-Hosting von n8n auf einem günstigen VPS für Kontrolle und Kosten und zeigt, wie du Workflow-JSON mit Claude Code generierst, statt dich durch einen Builder zu klicken. #### Überblick Bevor du eine eigene App baust, frag dich, ob ein Workflow-Tool den Job an einem Nachmittag erledigen kann. Automations-Plattformen sitzen zwischen deinen Diensten und feuern eine Kette von Schritten ab, wann immer etwas passiert: ein Formular wird abgeschickt, eine Zeile ändert sich, ein Timer läuft ab. Die drei, die 2026 zählen, sind Zapier (am einfachsten, gehostet, Bezahlung pro Task), n8n (flexibel, selbst hostbar, der Builder-Liebling) und Trigger.dev (code-first Jobs, die neben deiner App leben). Diese Lektion gibt dir eine Entscheidungsregel, das echte Kostenbild und den Trick, der alle schneller macht: lass deinen Agent das Workflow-JSON schreiben, statt Nodes hin- und herzuziehen. #### Was du lernst Du lernst, wie sich die drei Plattformen in Philosophie und Kosten unterscheiden, warum das Self-Hosting von n8n auf einem VPS für 5 bis 10 Dollar oft die Pro-Task-Abrechnung schlägt, sobald das Volumen wächst, wann Trigger.dev die richtige Wahl ist und wie du einen Workflow für Claude Code beschreibst und importierbares JSON zurückbekommst. Am Ende wählst du in Sekunden eine Plattform und stellst sie am selben Tag auf. #### Voraussetzungen Kurse 1 bis 3. Du brauchst die API- und Webhook-Grundlagen, Vertrautheit mit Umgebungsvariablen und Secrets und idealerweise ein deploytes Projekt aus Kurs 3, damit eine Automation etwas Echtes zum Reden hat. Wenn dir die Wörter Trigger, Webhook und Cron noch nicht in Fleisch und Blut übergegangen sind, überflieg zuerst die Fundamentals-Seite dazu, was eine API ist. #### Das Problem Einsteiger greifen zu einem von zwei Extremen. Entweder verdrahten sie alles in Zapier, sehen die Pro-Task-Rechnung mit dem Volumen klettern und fühlen sich gefangen. Oder sie entscheiden, ein eigenes Backend für einen Job zu bauen, der eigentlich nur "wenn ein Typeform reinkommt, füge eine Zeile hinzu und sende eine Slack-Nachricht" ist - drei Wochen Arbeit für etwas, das ein Workflow-Tool in zwanzig Minuten erledigt. Die Fähigkeit besteht darin zu wissen, welche Jobs workflow-förmig sind und welche Plattform zu der Kontrolle, den Kosten und dem Code passt, die du wirklich willst. #### Eine Plattform wählen Denk in drei Fragen: Wie sehr kümmern dich die Kosten bei Volumen, wie viel Kontrolle brauchst du und wie viel Code bist du bereit zu schreiben. Zapier optimiert darauf, in fünf Minuten live zu sein, mit tausenden vorgebauten Integrationen. n8n optimiert auf Flexibilität und Kostenkontrolle, weil du es selbst hosten kannst. Trigger.dev optimiert für Entwickler, die ihre Hintergrund-Jobs versioniert in ihrem eigenen Repo wollen. Pass die Plattform zur Antwort an, nicht zur Markenvertrautheit. - Zapier: gehostet, am einfachsten, der breiteste Integrationskatalog. Die Abrechnung läuft pro Task (jeder Schritt, der läuft, zählt), was bei geringem Volumen passt und bei hohem Volumen schmerzt. Nimm es für schnellen Klebstoff zwischen SaaS-Tools, wo du hunderte Tasks im Monat fährst, nicht Millionen. - n8n: Open Source und selbst hostbar, ein visueller Node-Editor wie Zapier, aber du besitzt die Instanz. Eine gehostete Cloud-Option existiert, aber der Gewinn liegt darin, es selbst zu fahren, zu einem flachen VPS-Preis. Nimm es, wenn das Volumen echt ist, du volle Kontrolle willst oder eigenen Code in Schritten brauchst. - Trigger.dev: code-first. Du schreibst Hintergrund-Jobs in TypeScript in deinem eigenen Repo, mit Retries, Scheduling und langlaufenden Tasks, die für dich erledigt werden. Nimm es, wenn die Automation wirklich Teil deiner App ist und neben ihr in die Versionskontrolle gehört, nicht in eine separate Klick-UI. - Faustregel: prototype in Zapier, lass hochvolumigen Klebstoff zu selbst gehostetem n8n aufsteigen und leg app-gekoppelte Jobs in Trigger.dev. #### Die Kostenfalle und das Self-Hosting von n8n Die Pro-Task-Abrechnung ist das, was dich beisst. Ein Workflow mit sechs Schritten, der 5.000 Mal im Monat läuft, sind 30.000 Tasks, und auf einem gehosteten Plan summiert sich das schnell. n8n selbst zu hosten dreht das zu einem flachen Preis um: ein kleiner VPS bei einem Anbieter wie Hostinger, Hetzner oder ein einfacher DigitalOcean-Droplet kostet grob 5 bis 10 Dollar im Monat und führt fröhlich zehntausende Workflow-Läufe aus. Du tauschst etwas Setup gegen vorhersehbare Kosten und volle Kontrolle, inklusive eigener Code-Nodes und Zugriff auf deine eigene Datenbank auf derselben Box. Hier ist eine minimale Docker-Compose-Skizze, um n8n mit einem persistenten Volume aufzustellen, damit deine Workflows einen Neustart überleben. ```yaml # docker-compose.yml - minimales selbst gehostetes n8n auf einem kleinen VPS services: n8n: image: docker.n8n.io/n8nio/n8n restart: always ports: - '5678:5678' environment: - N8N_HOST=your-domain.com - N8N_PORT=5678 - N8N_PROTOCOL=https - WEBHOOK_URL=https://your-domain.com/ # Setze immer Basic Auth oder pack es hinter einen Reverse Proxy - N8N_BASIC_AUTH_ACTIVE=true - N8N_BASIC_AUTH_USER=admin - N8N_BASIC_AUTH_PASSWORD=${N8N_PASSWORD} volumes: # Credentials und Workflows über Neustarts hinweg persistieren - n8n_data:/home/node/.n8n volumes: n8n_data: ``` Eine docker-compose.yml zum Start für selbst gehostetes n8n. Pack es hinter einen Reverse Proxy mit HTTPS und exponiere es nie ohne Auth. Fahre es mit docker compose up -d, zeig mit einer Subdomain auf die Box und pack es hinter einen Reverse Proxy (Caddy oder Nginx) für HTTPS. Die Security-Denkweise aus Kurs 3 gilt: eine offene n8n-Instanz ohne Auth ist eine Remote-Code-Execution-Maschine für jeden, der sie findet. Sperr sie ab, bevor du einen einzigen Credential hineinlegst. #### Workflow-JSON mit deinem Agent generieren Hier ist der Teil, der dich schneller macht als Leute, die in diesen Buildern leben. n8n und Zapier speichern Workflows unter der Haube beide als JSON. Das heisst, du musst gar keine Nodes herumziehen - du kannst den Workflow für Claude Code beschreiben, das JSON erzeugen lassen und importieren. Für alles jenseits von drei Schritten ist das drastisch schneller, und es legt deine Automation in eine Datei, die du versionieren, diffen und wiederverwenden kannst. Der Trick ist, dem Agent das Node-Schema zum Folgen zu geben, das du bekommst, indem du zuerst einen Beispiel-Workflow aus der UI exportierst. ```markdown ## Goal An n8n workflow JSON I can import directly. ## Trigger Webhook node. It receives a POST with { email, name, plan }. ## Steps 1. Validate that email contains "@"; if not, respond 400. 2. Insert a row into Postgres (table: leads) with the three fields plus a created_at timestamp. 3. Send a Slack message to #new-leads: "New lead: {name} on {plan}". 4. Respond 200 with { ok: true }. ## Constraints - Match the exact node JSON structure of the example I pasted below. - Use n8n expression syntax ={{ $json.email }} for field references. - Do not invent credential IDs; leave them as placeholders I will fill in. ## Example node structure ``` Ein Spec, das du Claude Code geben kannst, um importierbares n8n-Workflow-JSON zu bekommen. Füge immer ein echtes exportiertes Beispiel ein, damit es zum aktuellen Schema passt. Dasselbe Muster funktioniert für Trigger.dev, nur ist der Output TypeScript in deinem Repo statt JSON in einer UI, was für einen Agent sogar natürlicher ist. Importiere das generierte JSON immer zuerst in einen Test-Workflow und lass es einmal laufen, bevor du ihm in Produktion traust, denn Node-Schemata driften zwischen n8n-Versionen und der Agent arbeitet mit dem Beispiel, das du ihm gegeben hast. #### Typische Fehler Die wiederkehrenden Fehler: standardmässig für alles auf Zapier setzen und die Pro-Task-Rechnung erst bei Skalierung entdecken; n8n ohne Auth und ohne HTTPS selbst hosten, was ein Security-Loch ist, keine Ersparnis; eine eigene App für einen Job bauen, der immer workflow-förmig war; und agent-generiertem JSON trauen, ohne es einmal zu importieren und laufen zu lassen. Achte auch darauf, Secrets nicht direkt in Workflow-Nodes zu legen statt in den Credential-Store der Plattform - das leakt sie bei jedem Export. #### Business-ROI Workflow-Tools sind die hebelstärkste Automation, die du ohne ein Backend ausliefern kannst. Ein einziger n8n-Flow kann einen Teilzeitjob ersetzen: Leads empfangen, anreichern, routen, einen Menschen benachrichtigen, alles loggen. Hochvolumigen Klebstoff von der Pro-Task-Abrechnung von Zapier auf eine selbst gehostete n8n-Box zu verschieben, kann eine wiederkehrende Rechnung von hunderten Dollar im Monat auf unter zehn senken, ohne Funktionsverlust. Und das JSON mit deinem Agent zu generieren komprimiert einen halben Tag Klicken in ein zehnminütiges Spec, sodass du fünf Automationen in der Zeit baust, in der andere eine bauen. #### Checkliste Du bist bereit weiterzugehen, wenn du diese ohne Zögern beantworten kannst, denn der Rest dieses Kurses setzt voraus, dass du eine Automation aufstellen kannst. - Kannst du die richtige Plattform für einen schnellen SaaS-Klebstoff-Job, einen hochvolumigen Flow und einen app-gekoppelten Hintergrund-Job nennen? - Weisst du, warum die Pro-Task-Abrechnung bei Skalierung schmerzt und ungefähr, was ein selbst gehosteter n8n-VPS kostet? - Kannst du n8n mit Docker Compose aufstellen, hinter Auth und HTTPS? - Kannst du ein Spec schreiben, das importierbares Workflow-JSON aus deinem Agent holt? #### Ressourcen Setz die offiziellen Docs von n8n, Zapier und Trigger.dev als Lesezeichen, denn Node-Namen und Preise ändern sich und du willst die aktuelle Quelle, nicht eine Erinnerung. Die n8n-Docs zu Self-Hosting und Docker sind die kanonische Referenz für das Compose-Setup oben. Wenn ein agent-generierter Workflow sich danebenbenimmt, ist dein erster Zug immer, ein frisches Beispiel aus der laufenden Instanz zu exportieren und dagegen neu zu prompten. #### Deine Aufgabe Wähle eine echte, sich wiederholende Aufgabe in deiner Arbeit, die in die Form "wenn X passiert, tu Y und Z" passt. Bau sie zweimal: einmal von Hand in einem kostenlosen Zapier- oder n8n-Account, um den Builder zu fühlen, dann nochmal, indem du deinen Agent das JSON aus einem Spec generieren lässt. Notiere, was schneller war und was du tatsächlich pflegen würdest. Dieser Vergleich sagt dir, wie du ab hier jede Automation baust. #### Nächste Lektion Automationen müssen ständig auf Websites agieren, die keine API haben. Die nächste Lektion behandelt Browser-Automation und Scraping mit Playwright, den Non-Headless-Trick mit manuellem Login und den .har-Trick, um die echte API zu finden, die sich hinter einer Seite versteckt. ### 4.2 Browser-Automation und Scraping: Playwright, Browser Use und der .har-Trick - Kanonische URL: https://agenticschool.dev/de/kurse/automation-agentic-systems/browser-automation-and-scraping-playwright-browser-use-and-the-har-trick - Dauer: 28 min Zusammenfassung: Wenn es keine API gibt, ist der Browser deine API. Diese Lektion behandelt das Automatisieren des Webs mit Playwright und agent-getriebenem Browsing, verantwortungsvolles Scraping, den Non-Headless-Trick, einen sichtbaren Browser zu starten und sich von Hand einzuloggen, bevor du automatisierst, und den .har-Trick: Netzwerkverkehr in den DevTools aufzeichnen und einen Agent die echten API-Endpunkte daraus extrahieren lassen. #### Überblick Der grösste Teil des Webs hat keine öffentliche API, aber jede Site ist bereits eine Oberfläche, die ein Mensch bedienen kann, was heisst, dass auch ein Programm sie bedienen kann. Playwright ist das Tool, das das tut: Es steuert einen echten Browser so, wie es eine Nutzerin täte, klickt, tippt und liest die Seite. Darauf sitzen zwei Tricks, die fragiles Scraping in zuverlässige Automation verwandeln. Der Non-Headless-Trick lässt dich dich einmal von Hand einloggen und die Session wiederverwenden. Der .har-Trick lässt dich die gerenderte Seite ganz überspringen und die API aufrufen, die die Site selbst aufruft. Diese Lektion lehrt alle drei, plus wann du zu einem agent-getriebenen Browser greifst und wie du auf der richtigen Seite von Ethik und Gesetz bleibst. #### Was du lernst Du lernst die Playwright-Grundlagen, wie sich agent-getriebenes Browsing (Browser Use und Ähnliches) von skripteter Automation unterscheidet, das Muster mit sichtbarem Browser und manuellem Login, das den härtesten Teil authentifizierter Sites umgeht, und wie du eine .har-Datei aufzeichnest und einen Agent die zugrunde liegenden API-Calls extrahieren lässt. Du lernst auch, wo die rechtlichen und ethischen Grenzen liegen und wann du Skalierung an einen Anbieter wie Brightdata abgibst. #### Voraussetzungen Kurse 1 bis 3 und ein funktionierendes Node-Projekt. Du solltest mit asynchronem Code vertraut sein, damit, wie HTTP-Requests und Header funktionieren, und damit, deine Browser-DevTools zu lesen. Die Fundamentals-Seite dazu, was eine API ist, hilft, wenn Request und Response noch unscharf sind, denn der ganze .har-Trick dreht sich darum, die API zu finden, die eine Seite versteckt. #### Das Problem Du brauchst Daten oder eine Aktion von einer Site, die dir keine API gibt. Der naive Ansatz ist, das gerenderte HTML mit brüchigen Selektoren zu scrapen, die in dem Moment kaputtgehen, in dem die Site einen Klassennamen ändert. Die härteren Fälle sind Sites hinter einem Login, mit Bot-Erkennung, oder die alles über JavaScript laden, sodass das HTML leer ist, bis Scripts laufen. Leute verbrennen Tage damit, gegen Selektoren und Login-Flows zu kämpfen, während die Site die ganze Zeit leise saubere JSON-API-Calls macht, sichtbar in den DevTools, die sie direkt aufrufen könnten. #### Playwright-Grundlagen Playwright startet und steuert Chromium, Firefox oder WebKit. Du sagst ihm, eine URL aufzurufen, auf Elemente zu warten, zu klicken, zu tippen und Text oder Attribute zu lesen. Es wartet automatisch, bis Elemente bereit sind, was den grössten Teil der Flakiness entfernt, die ältere Tools plagte. Dieselbe Library treibt die End-to-End-Tests aus deinen Quality Gates an, also ist der Muskel wiederverwendbar. Hier ist die Form eines Basis-Skripts, das eine Seite lädt und ein paar Daten herauszieht. ```typescript import { chromium } from 'playwright' const browser = await chromium.launch() const page = await browser.newPage() await page.goto('https://example.com/products') // Wartet automatisch auf den Selektor vor dem Lesen await page.waitForSelector('.product-card') const titles = await page.$$eval('.product-card h2', (nodes) => nodes.map((n) => n.textContent?.trim()), ) console.log(titles) await browser.close() ``` Ein minimales Playwright-Scrape: Seite laden, auf Elemente warten, Text lesen. Das Auto-Warten handhabt die meiste Timing-Flakiness. #### Der Non-Headless-Trick mit manuellem Login Der härteste Teil beim Automatisieren einer authentifizierten Site ist der Login: Passwörter, Zwei-Faktor-Codes, Captchas und Bot-Erkennung kämpfen alle gegen dich, und Credentials in ein Skript zu hardcoden ist sowohl fragil als auch ein Security-Risiko. Der Trick ist, das Automatisieren des Logins ganz zu überspringen. Starte den Browser non-headless (sichtbar), navigiere zur Login-Seite und pausiere das Skript, während du dich von Hand einloggst. Sobald du drin bist, speichert Playwright die authentifizierte Session (Cookies und Storage) in eine Datei, und jeder künftige Lauf lädt diese Datei und ist schon eingeloggt. Keine gespeicherten Passwörter, kein Captcha-Lösen, kein brüchiger Login-Flow. ```typescript import { chromium } from 'playwright' // Einmalig: von Hand einloggen, dann die Session speichern. const browser = await chromium.launch({ headless: false }) // sichtbar const context = await browser.newContext() const page = await context.newPage() await page.goto('https://app.example.com/login') console.log('Log in manually in the window, then press Enter here...') // Warte, bis DU den Login beendet hast, bevor es weitergeht await page.waitForURL('**/dashboard', { timeout: 0 }) // Die authentifizierte Session für alle künftigen Läufe speichern await context.storageState({ path: 'auth.json' }) await browser.close() // Jeder spaetere Lauf startet schon eingeloggt: // const context = await browser.newContext({ storageState: 'auth.json' }) ``` Der Non-Headless-Login-Trick: sichtbar starten, einmal von Hand einloggen, die Session speichern, dann für immer headless wiederverwenden. Halt auth.json aus Git heraus (es ist ein lebendiger Session-Token) und behandle es wie ein Secret. Sessions laufen ab, also ist es normal, den einmaligen Login-Schritt gelegentlich neu auszuführen. Dieses Muster ist das mit Abstand grösste Zuverlässigkeits-Upgrade für authentifizierte Automation. #### Agent-getriebenes Browsing Skriptetes Playwright ist präzise, aber brüchig: Ändere die Seite und deine Selektoren brechen. Agent-getriebene Browser-Tools wie Browser Use nehmen den entgegengesetzten Ansatz. Du gibst einem Agent ein Ziel in normaler Sprache ("finde den günstigsten Flug von Zürich nach London nächsten Freitag und leg ihn in den Warenkorb") und es liest die Seite, entscheidet, was zu klicken ist, und passt sich an, wenn das Layout anders ist als erwartet. Es ist langsamer und weniger deterministisch, aber es überlebt Site-Änderungen und handhabt Aufgaben, die du nicht vollständig vorab spezifizieren kannst. Der ehrliche Trade-off: nimm skriptetes Playwright für stabile, hochvolumige, wiederholbare Jobs, bei denen du das Ziel kontrollierst, und einen agent-getriebenen Browser für einmalige oder unscharfe Aufgaben, bei denen Anpassungsfähigkeit Tempo schlägt. Viele echte Systeme kombinieren beide - ein Agent, um den Flow einmal zu entdecken, dann ein generiertes Skript, um ihn günstig in grossem Massstab zu fahren. #### Der .har-Trick Das ist der hebelstärkste Zug der ganzen Lektion. Bevor du irgendein gerendertes HTML scrapst, öffne die DevTools, geh zum Network-Tab, führe die Aktion aus, die du automatisieren willst, dann rechtsklick und "Save all as HAR". Eine .har-Datei ist eine vollständige Aufzeichnung jedes Netzwerk-Requests, den die Seite gemacht hat, inklusive der JSON-API-Calls hinter den Kulissen. Die meisten modernen Sites rendern aus sauberen internen APIs, was heisst, dass die Daten, die du willst, oft in einer aufgeräumten JSON-Response sitzen, die du direkt aufrufen kannst - keine Selektoren, kein Headless-Browser, weit schneller und weit robuster. Die Datei ist gross und verrauscht, was genau die Stelle ist, an der ein Agent glänzt: gib ihm die .har und bitte ihn, die relevanten Endpunkte zu extrahieren. ```markdown ## Task Here is a .har file I recorded while loading the product list page. Extract the underlying API the page uses to fetch products. I want: 1. The exact request URL and method. 2. Which headers actually matter (auth token, content-type) vs noise. 3. Query params or request body, with what each field appears to mean. 4. The shape of the JSON response (the fields I care about: name, price, id). 5. A minimal fetch() call in TypeScript that reproduces just that request. Ignore analytics, fonts, images and tracking pixels. Focus only on the call that returns the product data. ``` Ein Prompt, der einen verrauschten .har-Export in einen sauberen, wiederholbaren API-Call verwandelt. Der Agent erledigt das mühsame Filtern für dich. Sobald der Agent dir den fetch-Call gibt, hast du ein brüchiges Browser-Scrape durch einen direkten API-Call ersetzt, der schneller, günstiger und weit stabiler ist. Wenn die API einen Auth-Token braucht, holst du ihn aus der Non-Headless-Session oben. Diese Kombination - manueller Login für den Token, .har-Trick für den Endpunkt - handhabt einen riesigen Anteil echter "diese Site hat keine API"-Probleme. #### Ethik, Legalität und Skalierung Das Web zu automatisieren ist mächtig und nicht folgenlos, also sei bewusst. Dieser Abschnitt ist Orientierung, keine Rechtsberatung - wenn Geld oder personenbezogene Daten im Spiel sind, sprich mit einer Anwältin. - Lies die Nutzungsbedingungen und robots.txt. Manche Sites verbieten automatisierten Zugriff, und das zu ignorieren kann einen Vertrag brechen oder, in manchen Rechtsräumen, gegen Computer-Missbrauchsrecht verstossen. - Scrape nie personenbezogene Daten ohne Rechtsgrundlage. Die Datenschutzgesetze aus CLAUDE.md (DSGVO, FADP, US-Bundesstaatengesetze) gelten für gescrapte Daten genauso wie für alle anderen. - Rate-limite dich selbst und identifiziere dich ehrlich. Eine Site zu hämmern ist missbräuchlich und bringt dich auf die Blockliste; ein höflicher, langsamer Scraper ist ein besserer Bürger und zuverlässiger. - Für legitime Skalierung nimm einen Anbieter wie Brightdata. Sie handhaben Proxy-Rotation, Geo-Verteilung und Compliance-Tooling, was der verantwortungsvolle Weg ist, grosse Jobs zu fahren, statt eine verdeckte Bot-Armee zu bauen. #### Typische Fehler Die Klassiker: brüchiges HTML scrapen, wenn eine saubere JSON-API die ganze Zeit in der .har sass; Credentials hardcoden statt den Non-Headless-Session-Trick zu nutzen; auth.json oder einen Token nach Git committen; einen agent-getriebenen Browser für einen stabilen, hochvolumigen Job fahren, wo ein günstiges Skript reichen würde; und Nutzungsbedingungen und Rate Limits ignorieren, bis du blockiert wirst oder Schlimmeres. Prüfe den Network-Tab, bevor du einen einzigen Selektor schreibst. #### Business-ROI Browser-Automation schaltet Daten und Aktionen frei, die sonst eine Integration bräuchten, die der Anbieter nie gebaut hat. Der .har-Trick allein kann ein mehrtägiges Scraping-Projekt in einen Nachmittag verwandeln, weil du die gerenderte Seite überspringst und die echte API aufrufst. Der Non-Headless-Trick entfernt den fragilsten Teil jeder authentifizierten Automation. Zusammen lassen sie ein kleines Team Wettbewerbsrecherche automatisieren, interne Dateneingabe quer durch Altsysteme und sich wiederholende Anbieter-Portal-Aufgaben, die keine API haben - Arbeit, die sonst für immer manuell bleibt. #### Checkliste Bestätige, dass du jedes davon kannst, bevor du weitergehst, denn die nächste Lektion setzt voraus, dass du nicht vertrauenswürdigen Code sicher ausführen kannst. - Ein Basis-Playwright-Skript schreiben, das eine Seite lädt und Daten liest. - Den Non-Headless-Trick nutzen, um dich einmal einzuloggen und die Session headless wiederzuverwenden. - Erklären, wann du agent-getriebenes Browsing statt eines festen Skripts nimmst. - Eine .har-Datei aufzeichnen und einen wiederholbaren API-Call mit deinem Agent daraus extrahieren. - Zwei rechtliche oder ethische Grenzen nennen, die du beim Scraping immer respektierst. #### Ressourcen Halt die Playwright-Docs als Lesezeichen für Selektor- und Auto-Wait-Referenz und die Browser-Use-Docs für agent-getriebenes Browsing. Der Network-Tab deiner Browser-DevTools ist das mit Abstand nützlichste Tool dieser Lektion - lern fliessend, ein HAR daraus aufzuzeichnen und zu speichern. Für grosse oder compliance-sensible Jobs sind Brightdata und ähnliche Anbieter der dokumentierte, unterstützte Weg. #### Deine Aufgabe Wähle eine Site, die du nutzt und die keine API hat. Zeichne eine .har der Aktion auf, die dich interessiert, gib sie deinem Agent mit dem Prompt oben und sieh, ob du die Aktion mit einem direkten fetch-Call reproduzieren kannst. Wenn die Site einen Login braucht, speichere zuerst eine Session mit dem Non-Headless-Trick. Schreib auf, welchen Ansatz (Skript, agent-getrieben oder direkte API aus der .har) du ausliefern würdest. #### Nächste Lektion Code, den ein Agent generiert hat - oder den ein Scrape hereingezogen hat - auf deiner eigenen Maschine auszuführen ist riskant. Die nächste Lektion behandelt Sandboxes: isolierte, wegwerfbare Umgebungen von E2B, Daytona und ähnlichen Tools, die einen schlechten Lauf so einsperren, dass er dein System nicht anfassen kann. ### 4.3 Sandboxes: sichere Code-Ausführung mit E2B, Daytona und Co. - Kanonische URL: https://agenticschool.dev/de/kurse/automation-agentic-systems/sandboxes-safe-code-execution-with-e2b-daytona-and-co - Dauer: 24 min Zusammenfassung: Einen Agent beliebigen Code auf deiner Maschine ausführen zu lassen ist ein echtes Risiko, kein hypothetisches. Eine Sandbox gibt dem Code eine isolierte, wegwerfbare Umgebung, damit ein schlechter oder feindlicher Lauf dein System oder deine Daten nicht anfassen kann. Diese Lektion erklärt, warum Sandboxing zählt, was eine Sandbox eigentlich ist, wie E2B und Daytona funktionieren und genau, wann du eine brauchst. #### Überblick Ein Agent, der Code schreiben kann, ist auch ein Agent, der ihn ausführen will, und in dem Moment, in dem du beliebigen Code auf deinem Laptop oder Server ausführen lässt, kann eine schlechte Zeile Dateien löschen, Secrets aus deiner Umgebung leaken oder eine Verbindung öffnen, die du nicht beabsichtigt hast. Eine Sandbox löst das, indem sie dem Code einen frischen, isolierten, wegwerfbaren Computer zum Laufen gibt. Geht der Lauf schief, wirfst du die Sandbox weg und verlierst nichts. Diese Lektion erklärt das Risiko ehrlich, definiert, was eine Sandbox ist, stellt die wichtigsten Dienste vor und gibt dir eine klare Regel dafür, wann du eine nutzt und wann ein lokaler Lauf in Ordnung ist. #### Was du lernst Du lernst, warum es ein Security- und Zuverlässigkeitsrisiko ist, KI-generierten Code auf deiner eigenen Maschine auszuführen, was eine Sandbox tatsächlich bietet (Isolation, Wegwerfbarkeit, Ressourcenlimits), wie verwaltete Dienste wie E2B und Daytona eine auf Abruf für deinen Agent hochfahren, und die drei konkreten Situationen, die immer nach einer Sandbox verlangen. Du gehst hinaus und kannst pro Aufgabe entscheiden, ob Code lokal laufen kann oder eingesperrt werden muss. #### Voraussetzungen Kurse 1 bis 3, besonders das Secrets- und Security-Material aus Kurs 3. Du solltest verstehen, dass deine Maschine Umgebungsvariablen, SSH-Keys und eingeloggte Sessions hält, die jeder lokale Prozess lesen kann, denn genau das schützt eine Sandbox. Die API-Grundlagen zählen auch, da du diese Dienste über ihre SDKs steuerst. #### Das Problem Agentische Workflows generieren Code und müssen ihn dann ausführen, um zu sehen, ob er funktioniert, um Daten zu transformieren oder eine Anfrage zu erfüllen. Die Versuchung ist, ihn einfach laufen zu lassen - und für Code, den du geschrieben und geprüft hast, ist das in Ordnung. Aber Agent-Output ist nicht immer korrekt, und wenn irgendein Input von einem Nutzer oder dem offenen Web kam, ist er nicht immer freundlich. Ein einziges rm-Kommando, eine Endlosschleife, die deine CPU lahmlegt, ein Skript, das process.env liest und nach Hause telefoniert: das sind keine exotischen Fälle, das sind die Standard-Fehlermodi, wenn man nicht vertrauenswürdigen Code mit vollem Zugriff auf dein echtes System ausführt. #### Was eine Sandbox eigentlich ist Eine Sandbox ist eine isolierte, wegwerfbare Ausführungsumgebung - in der Praxis eine leichtgewichtige virtuelle Maschine oder ein gehärteter Container -, die keinen Zugriff auf dein echtes Dateisystem, deine Secrets oder dein Netzwerk hat, ausser dem, was du ausdrücklich erlaubst. Code läuft darin mit seinem eigenen Dateisystem, seinen eigenen Speicher- und CPU-Limits und einem harten Zeitbudget. Wenn der Lauf fertig ist, reisst du die Sandbox ab und nichts bleibt bestehen. Das mentale Modell ist ein Reinraum: Der Code bekommt genau die Inputs, die du ihm gibst, und erzeugt genau die Outputs, die du einsammelst, und er kann nichts ausserhalb des Raums erreichen. - Isolation: der Code kann dein Host-Dateisystem, Umgebungsvariablen oder andere Prozesse nicht sehen. - Wegwerfbarkeit: jeder Lauf ist eine frische Umgebung; eine kompromittierte oder kaputte Sandbox wird einfach zerstört. - Ressourcenlimits: CPU, Speicher und Wanduhrzeit sind gedeckelt, sodass eine ausser Kontrolle geratene Schleife deine Maschine nicht lahmlegen kann. - Kontrolliertes I/O: du entscheidest, welche Dateien hineingehen und was herauskommt; der Netzwerkzugriff kann eingeschränkt oder verweigert werden. #### E2B, Daytona und Freunde Du baust Sandboxes nicht selbst - du rufst einen Dienst auf, der sie über ein SDK in unter einer Sekunde hochfährt. E2B ist speziell dafür gebaut, dass KI-Agents Code ausführen: du erstellst eine Sandbox, führst Code oder Shell-Kommandos darin aus, liest den Output und beendest sie, alles aus ein paar Zeilen in deiner App. Daytona bietet schnelle, ephemere Entwicklungsumgebungen im selben Geist, nützlich, wenn ein Agent einen volleren Workspace statt einer einzelnen Ausführung braucht. Beide abstrahieren die VM- und Container-Klempnerei weg, sodass dein Agent einen sicheren Ort bekommt, um Code auf Abruf auszuführen. Das Muster unten ist, wie fast jede Integration aussieht. ```typescript import { Sandbox } from '@e2b/code-interpreter' // Eine frische, isolierte Sandbox nur für diesen Lauf hochfahren const sandbox = await Sandbox.create() try { // Agent-generierten Code laufen lassen, wo er dir nicht schaden kann const execution = await sandbox.runCode(agentGeneratedPython) console.log(execution.logs.stdout) console.log(execution.error) // eingesperrt: ein Fehler hier ist nicht dein Problem } finally { // Immer abreissen - nichts bleibt bestehen await sandbox.kill() } ``` Das Kern-Sandbox-Muster: erstellen, nicht vertrauenswürdigen Code darin ausführen, Output einsammeln, zerstören. Die genaue SDK-Oberfläche entwickelt sich, also prüfe die aktuellen E2B-Docs. Produktdetails und SDK-Namen ändern sich in diesem Feld schnell, also behandle das Snippet als die Form des Musters und bestätige die aktuellen Methodennamen gegen die offiziellen E2B- und Daytona-Docs, bevor du baust. Das Konzept - erstellen, ausführen, einsammeln, zerstören - ist stabil, auch wenn sich die APIs bewegen. #### Wann du tatsächlich eine Sandbox brauchst Nicht jeder Code-Lauf braucht Isolation, und Über-Sandboxing fügt Latenz und Kosten hinzu. Die Regel ist einfach: sandboxe immer dann, wenn der Code oder seine Inputs nicht voll vertrauenswürdig sind, und lauf lokal, wenn sie es sind. Drei Situationen überschreiten diese Linie immer. - Vom Nutzer eingereichter Code: alles, was ein Produkt Nutzer schreiben und ausführen lässt (ein "führe dieses Snippet aus"-Feature, ein Datentransformations-Feld, eine Formel-Engine), muss gesandboxt werden. Du führst fremden Code auf deiner Infrastruktur aus. - Nicht vertrauenswürdiger Agent-Output: wenn ein Agent Code aus nicht vertrauenswürdigem Input generiert (eine gescrapte Seite, eine Nutzeranfrage, ein Drittanbieter-Dokument) und du ihn ausführst, ohne jede Zeile zu lesen, sperr ihn ein. Der Agent ist nur so sicher wie der schlimmste Input, den er gesehen hat. - Parallele Experimente: wenn du viele Varianten auf einmal laufen lassen willst - ein generiertes Skript gegen zehn Datensätze testen, eine Idee fuzzen, mehrere Agents Lösungen probieren lassen - geben dir Sandboxes saubere, isolierte, parallele Umgebungen, die sich nicht gegenseitig oder deinen Host stören können. - Wann lokal in Ordnung ist: Code, den du geschrieben oder voll geprüft hast, gegen vertrauenswürdige Inputs ausgeführt, auf einer Maschine, deren Secrets du kontrollierst. Zahl dafür nicht die Sandbox-Steuer. #### Typische Fehler Die gefährlichen: agent-generierten Code lokal "nur dieses eine Mal" ausführen und einen API-Key aus deiner Umgebung leaken; ein Produkt-Feature bauen, das Nutzer-Input ohne Isolation ausführt, was eine Lehrbuch-Remote-Code-Execution-Schwachstelle ist; vergessen, CPU-, Speicher- und Zeitlimits zu setzen, sodass ein ausser Kontrolle geratener Lauf dir trotzdem schadet; und Sandboxes am Leben lassen, statt sie abzureissen, was Geld verschwendet und die Wegwerfbarkeit aushebelt. Der entgegengesetzte Fehler existiert auch: trivialen, vertrauenswürdigen Code zu sandboxen und dich ohne Sicherheitsgewinn auszubremsen. #### Business-ROI Sandboxing ist der Unterschied zwischen einem agentischen Feature, das du sicher vor Nutzer stellen kannst, und einer Haftung, die du nicht ausliefern kannst. Ein einziger eingesperrter Vorfall - ein feindlicher Input, der einen Server gelöscht hätte, der jetzt nur eine wegwerfbare Sandbox zerstört - bezahlt die ganze Praxis. Für Produkte, die Nutzer- oder Agent-Code ausführen, sind Sandboxes kein optionaler Feinschliff; sie sind die Kontrolle, die dir erlaubt, das Feature überhaupt anzubieten. Und für internes Experimentieren lassen günstige parallele Sandboxes ein kleines Team zehn Ideen in der Zeit probieren, die es bräuchte, um eine sorgfältig zu fahren. #### Checkliste Du bist bereit weiterzugehen, wenn jedes davon sitzt, denn die nächste Lektion lässt dich Tools bauen, die generierten Code ausführen können. - In einem Satz erklären, warum nicht vertrauenswürdigen Code lokal auszuführen riskant ist. - Die vier Eigenschaften einer Sandbox definieren (Isolation, Wegwerfbarkeit, Limits, kontrolliertes I/O). - Das Erstellen-Ausführen-Einsammeln-Zerstören-Muster mit einem Dienst wie E2B beschreiben. - Die drei Situationen nennen, die immer eine Sandbox verlangen, und eine, die es nicht tut. #### Ressourcen Halt die E2B- und Daytona-Docs als Lesezeichen, da sich ihre SDKs entwickeln und die aktuellen Methodennamen zählen, wenn du baust. Das Security-Material aus Kurs 3 zu Secrets und Umgebungsvariablen ist hier das Fundament - eine Sandbox hilft nur, wenn du auch echte Secrets aus dem Code heraushältst, den du ihr gibst. Im Zweifel, ob du sandboxen sollst, setze auf Ja für alles, was Nutzer- oder Drittanbieter-Input berührt. #### Deine Aufgabe Melde dich bei E2B an (es hat ein kostenloses Kontingent), dann schreib ein winziges Skript, das eine Sandbox hochfährt, ein paar Zeilen generiertes Python darin laufen lässt, den Output ausgibt und sie abreisst. Lass bewusst eine Zeile laufen, die auf deiner echten Maschine destruktiv wäre (etwa eine Mülldatei schreiben), und bestätige, dass sie eingesperrt bleibt. Dieser praktische Beweis ist, was Sandboxing von einer abstrakten Idee in eine Gewohnheit verwandelt. #### Nächste Lektion Mit sicherer Ausführung abgedeckt bist du bereit, echte Tools auf Modell-APIs zu bauen. Die nächste Lektion zeigt wie, anhand zweier Gründer-Fallstudien: ein Rechnungszuordnungs-Tool und ein Schweizer Sammelkarten-Katalogisierer, die ein Foto in einen Datenbank-Datensatz verwandeln. ### 4.4 Eigene KI-Tools mit APIs bauen - Kanonische URL: https://agenticschool.dev/de/kurse/automation-agentic-systems/building-your-own-ai-tools-with-apis - Dauer: 28 min Zusammenfassung: Du musst nicht warten, bis jemand das Tool baut, das du brauchst. Mit Modell-APIs baust du dein eigenes, oft an einem Nachmittag. Diese Lektion zeigt, wie du Gemini und Claude direkt aufrufst, strukturiertes JSON zurückbekommst und Vision nutzt, um ein Foto in einen Datenbank-Datensatz zu verwandeln - illustriert durch zwei echte Gründer-Tools: Rechnungszuordnung und ein Schweizer Sammelkarten-Katalogisierer. #### Überblick Der grösste Wandel im Software-Bauen ist dieser: Wenn das Tool, das du brauchst, nicht existiert, baust du es am selben Nachmittag. Modell-APIs lassen dich ein LLM aus deinem eigenen Code aufrufen, mit deinem eigenen Prompt, und - entscheidend - strukturierte Daten zurückbekommen statt einer Wand aus Prosa. Sobald ein Modell ein Bild oder ein Dokument verlässlich in einen sauberen JSON-Datensatz verwandeln kann, verschwindet eine ganze Klasse manueller Dateneingabe-Arbeit. Diese Lektion lehrt den direkten API-Call, den Trick mit strukturiertem Output, der die Antwort nutzbar macht, und zwei echte Tools, die der Gründer dieser School aus genau diesen Teilen gebaut hat. #### Was du lernst Du lernst, Gemini und Claude direkt mit einem minimalen fetch-Request aufzurufen, das Modell zu zwingen, JSON passend zu einem Schema zurückzugeben, sodass der Output direkt in eine Datenbank fällt, Vision zu nutzen, sodass ein Foto zu strukturierten Daten wird, und zu erkennen, wann der Bau eines kleinen internen Tools das Bezahlen von SaaS schlägt. Die zwei Gründer-Fallstudien machen es konkret: Foto einer Rechnung rein, zugeordneter Datensatz raus; Foto einer Sammelkarte rein, katalogisierter Datensatz raus. #### Voraussetzungen Kurse 1 bis 3. Du brauchst die Modellauswahl-Lektion aus Kurs 1 (die Tool-Kosten hängen ganz davon ab, welches Modell du aufrufst), die Secrets-Disziplin aus Kurs 3 (der API-Key fasst nie Client-Code an) und eine Datenbank zum Hineinschreiben - Convex aus Kurs 3 ist perfekt. Die Fundamentals-Seite dazu, was eine API ist, deckt die Request-Grundlagen ab, falls du sie brauchst. #### Das Problem Unternehmen zahlen monatlich für SaaS-Tools, die eine enge Sache tun - Belege lesen, Bilder taggen, Felder aus PDFs extrahieren -, und die trotzdem nicht ganz zu ihrem Workflow passen. Dabei ist derselbe Job einen einzigen API-Call entfernt. Der Blocker war nie die Fähigkeit; es ist, dass Leute nicht merken, wie wenig Code zwischen "ich habe ein Foto einer Rechnung" und "die Rechnung ist in meinem Buchhaltungssystem, dem richtigen Projekt zugeordnet" steht. Diese Lektion entfernt diesen Blocker, indem sie den ganzen Weg von Anfang bis Ende zeigt. #### APIs als Bausteine Eine Modell-API direkt aufzurufen gibt dir totale Kontrolle: dein Prompt, dein Modell, dein Output-Format, keine UI im Weg. Es ist auch weniger Code, als Leute erwarten. Ein Request ist ein POST mit deinem API-Key in einem Header und einem JSON-Body, der beschreibt, was du willst. Hier ist ein minimaler Call zu Gemini und dieselbe Idee gegen Claude, damit du beide siehst. Google bietet ein wirklich grosszügiges kostenloses Gemini-Kontingent über AI Studio, was es zum natürlichen Ort macht, Vision-Tools zu prototypen, ohne etwas auszugeben. ```typescript // Minimaler Gemini-Call. Der Key lebt in einer Env-Var, nie im Client-Code. const res = await fetch( 'https://generativelanguage.googleapis.com/v1beta/models/gemini-2.5-flash:generateContent', { method: 'POST', headers: { 'Content-Type': 'application/json', 'x-goog-api-key': process.env.GEMINI_API_KEY!, }, body: JSON.stringify({ contents: [{ parts: [{ text: 'Summarise this in one sentence: ...' }] }], }), }, ) const data = await res.json() console.log(data.candidates[0].content.parts[0].text) ``` Ein minimaler Gemini-API-Call. Modellnamen und genaue Pfade ändern sich - bestätige gegen die aktuellen Google-AI-Docs. Claude funktioniert genauso: ein POST zum Anthropic-Messages-Endpunkt mit deinem Key in einem x-api-key-Header und einem messages-Array im Body. Der Anbieter unterscheidet sich, die Form ist dieselbe. Wähle das Modell mit der Modellauswahl-Regel aus Kurs 1 - ein schnelles, günstiges Modell für hochvolumige Extraktion, ein stärkeres nur, wenn das Denken wirklich schwer ist. #### Strukturierter Output: der Trick, der es nützlich macht Ein Modell, das in Prosa antwortet, ist kein Tool - du kannst einen Absatz nicht in eine Datenbankspalte legen. Der Trick ist, strukturierten Output zu verlangen: gib dem Modell ein JSON-Schema und verlange, dass es Daten zurückgibt, die exakt zu diesem Schema passen. Moderne APIs unterstützen das direkt (ein Response-Schema oder Structured-Output-Modus), und das Ergebnis ist ein Objekt mit garantierter Form, das du validieren und einfügen kannst. Das ist es, was "das Modell hat etwas über die Rechnung gesagt" in "die Rechnungszeile hat Lieferant, Betrag, Währung, Datum und project_id" verwandelt. Validiere das zurückgegebene JSON immer gegen dein Schema (Zod aus deinem Stack ist ideal), bevor du ihm traust, denn ein Modell kann gelegentlich noch driften. ```typescript import { z } from 'zod' // Die genaue Form, die du zurückwillst - das IST dein Datenbank-Datensatz. const InvoiceSchema = z.object({ supplier: z.string(), invoiceNumber: z.string(), amount: z.number(), currency: z.string(), issueDate: z.string(), // ISO-Datum projectId: z.string().nullable(), }) // Sag dem Modell, NUR JSON passend zu diesem Schema zurückzugeben, dann validiere. const parsed = InvoiceSchema.parse(JSON.parse(modelJsonString)) // parsed ist jetzt ein typisierter, validierter Datensatz, bereit zum Einfügen. Keine Prosa. ``` Definiere die Datensatzform mit Zod, weise das Modell an, passendes JSON zurückzugeben, und validiere vor dem Einfügen. Die Validierung fängt das seltene Driften. #### Vision: ein Foto rein, ein Datensatz raus Dieselbe API akzeptiert Bilder, nicht nur Text. Vision-Modelle wie Gemini lesen ein Bild und geben, kombiniert mit dem Trick für strukturierten Output, einen sauberen Datensatz zurück, der beschreibt, was sie sehen. Du sendest die Bild-Bytes neben deiner Anweisung und deinem Schema und bekommst strukturierte Daten zurück. Das ist der Zug, der Dateneingabe aus der physischen Welt automatisiert: richte ein Handy auf ein Dokument oder ein Objekt, und eine Datenbankzeile erscheint. Das Modell macht das Lesen; dein Schema macht das Strukturieren; dein Code macht das Einfügen. Drei Schritte, und eine Aufgabe, die früher eine Person war, die stundenlang tippt, wird zu einem Foto und einem Webhook. #### Gründer-Fallstudie: Rechnungszuordnung Hier ist eine echte, die wir gebaut haben. Ein Unternehmen ertrank in Lieferantenrechnungen, die jede gelesen, deren Felder extrahiert und - der mühsame Teil - dem richtigen internen Projekt zugeordnet werden mussten, bevor sie ins Buchhaltungssystem gingen. Wir bauten ein kleines Tool: ein Rechnungsfoto oder PDF reinwerfen, ein Vision-Modell extrahiert Lieferant, Nummer, Betrag, Währung und Datum in das genaue Schema oben, und ein zweiter Schritt ordnet es dem richtigen Projekt zu, anhand der Positionen und der Lieferantenhistorie. Ein Mensch genehmigt weiterhin Grenzfälle (mehr dazu in der Human-in-the-Loop-Lektion), aber das Lesen und Zuordnen, das früher Stunden pro Woche frass, passiert jetzt in Sekunden. Kein SaaS-Abo, keine Gebühr pro Dokument, totale Kontrolle über die Logik, und es passt exakt zum Unternehmen, weil das Unternehmen das Schema definiert hat. #### Gründer-Fallstudie: Schweizer Sammelkarten Das zweite Tool macht mehr Spass und trifft denselben Punkt. Wir hatten eine grosse Sammlung Schweizer Sammelkarten zu katalogisieren - jede braucht ihren Spieler oder ihr Motiv, das Set, das Jahr und den Zustand erfasst, was von Hand zermürbend ist. Das Tool ist fast peinlich einfach: eine Karte fotografieren, ein Vision-Modell gibt einen strukturierten Datensatz zurück (Name, Set, Jahr, geschätzter Zustand) passend zu einem Schema, und es landet in einer Datenbank mit dem angehängten Bild. Was Tage manueller Eingabe gewesen wäre, wurde zu einem Nachmittag Fotos machen. Die Lehre handelt nicht von Sammelkarten; es ist, dass "Bild zu strukturiertem Datenbank-Datensatz" ein universelles Muster ist. Rechnungen, Karten, Inventar, Visitenkarten, Belege, Geräte-Typenschilder - dieselben drei Schritte gelten für alle. #### Bauen, nicht kaufen Beide Fallstudien ersetzten einen SaaS-Kauf durch ein internes Tool, und das ist der strategische Punkt. Wenn ein Job eng und spezifisch für dein Unternehmen ist, schlägt ein kleines, API-gestütztes Tool, das du besitzt, meist ein generisches Produkt, das du mietest. Du bekommst eine exakte Passform, keine Gebühren pro Sitzplatz oder pro Dokument, volle Kontrolle über die Daten und die Fähigkeit, die Logik in dem Moment zu ändern, in dem sich dein Prozess ändert. Das ist nicht "baue alles" - nimm grossartiges SaaS für Standardbedürfnisse. Es ist "für die engen, sich wiederholenden, geschäftsspezifischen Datenjobs gewinnt oft ein fünfzigzeiliges Tool auf einer Modell-API". - Bau, wenn der Job eng, spezifisch für dein Unternehmen und hochvolumig genug ist, dass SaaS-Gebühren pro Einheit sich summieren. - Kauf, wenn der Bedarf generisch ist, die SaaS-Passform gut ist und du ein ausgereiftes Produkt neu erfinden würdest. - Besitze deine Daten und dein Schema. Ein Tool, das du gebaut hast, beugt sich deinem Prozess; ein Tool, das du mietest, lässt deinen Prozess sich ihm beugen. #### Typische Fehler Die häufigen: den API-Key in clientseitigen Code legen, wo ihn jeder stehlen kann (er gehört in eine Server-Env-Var, immer); nach Prosa fragen und sie dann mit brüchigem String-Matching parsen, statt schema-validiertes JSON zu verlangen; die Validierung überspringen und einen fehlerhaften Datensatz in deine Datenbank einfügen; ein teures Flaggschiff-Modell für einfache hochvolumige Extraktion nutzen, wenn ein günstiges schnelles Modell reichlich ist; und SaaS für einen Job kaufen, den ein fünfzigzeiliges internes Tool besser und günstiger erledigen würde. #### Business-ROI Das ist die Lektion, in der KI aufhört, ein Chat-Spielzeug zu sein, und anfängt, Positionen auf deiner Rechnung und Stunden in deinem Kalender zu ersetzen. Ein Bild-zu-Datensatz-Tool kann eine Teilzeit-Dateneingabe-Stelle eliminieren, und weil du es besitzt, sind die Grenzkosten pro Dokument Bruchteile eines Cents Modellnutzung, kein SaaS-Abo. Die Gründer-Tools oben brauchten jeweils einen Nachmittag zum Bauen und sparten jede Woche wiederkehrende Stunden. Für ein kleines Unternehmen ist die Fähigkeit, das exakte Tool, das du brauchst, auf Abruf zu bauen, ein struktureller Vorteil, den Wettbewerber, die nur SaaS kaufen, nicht erreichen können. #### Checkliste Du bist bereit weiterzugehen, wenn jedes davon stimmt, denn die nächsten Lektionen bauen Funnels und Feedback-Schleifen auf Tools wie diesen auf. - Einen minimalen API-Call zu Gemini oder Claude machen, mit dem Key sicher in einer Env-Var. - Strukturierten JSON-Output erzwingen und ihn mit einem Schema validieren, bevor du ihn nutzt. - Ein Foto mit einem Vision-Modell in einen strukturierten Datenbank-Datensatz verwandeln. - Für einen echten Job entscheiden, ob du ein internes Tool baust oder SaaS kaufst. #### Ressourcen Hol dir kostenloses Gemini-Guthaben aus Google AI Studio, um Vision-Tools kostenlos zu prototypen, und halt die Anthropic- und Google-AI-Docs griffbereit, weil sich Modellnamen und die Structured-Output-API-Oberfläche ändern. Zod aus deinem bestehenden Stack ist deine Validierungsschicht. Die /builds-Fallstudien zur Rechnungsautomation und zum Schweizer-Sammelkarten-Tool gehen tiefer auf jede ein, wenn du die ganze Geschichte willst. #### Deine Aufgabe Wähle eine sich wiederholende Dateneingabe-Aufgabe in deiner Arbeit, die mit einem Bild oder Dokument beginnt. Bau ein winziges Tool: nimm das Bild, sende es an Gemini mit einem Zod-Schema, validiere das JSON und logge den Datensatz. Du brauchst keine UI - ein Skript, das den strukturierten Datensatz ausgibt, ist der Beweis. Notiere, wie lange es gedauert hat gegenüber dem, was dich die manuelle Aufgabe jede Woche kostet. #### Nächste Lektion Tools und Automationen brauchen Menschen, die sie finden. Die nächste Lektion behandelt die Marketing-Klempnerei: Lead Magnets, Capture-Formulare, Funnels und die Double-Opt-in-E-Mail-Regeln, die du in der EU und der Schweiz befolgen musst. ### 4.5 E-Mail, Lead Magnets und Funnels: erfassen und pflegen - Kanonische URL: https://agenticschool.dev/de/kurse/automation-agentic-systems/email-lead-magnets-and-funnels-capture-and-nurture - Dauer: 24 min Zusammenfassung: Ein grossartiges Produkt, von dem niemand hört, verdient nichts. Diese Lektion behandelt die Marketing-Klempnerei: das Vokabular (Impressions, CTR, Conversion, Lead, Funnel, Upsell), Lead Magnets, die eine E-Mail-Adresse verdienen, Newsletter- und Kontaktformular-Grundlagen, die rechtliche Double-Opt-in-Pflicht in der EU und der Schweiz und ob du E-Mail von deiner eigenen Domain oder von einem Drittanbieter sendest. #### Überblick Du kannst das beste Tool der Welt bauen und nichts verdienen, wenn niemand es findet und niemand wiederkommt. Marketing ist die Klempnerei, die das behebt: es erfasst interessierte Fremde, verdient die Erlaubnis, sie zu kontaktieren, und pflegt sie hin zu Kunden. Diese Lektion lehrt das Vokabular, damit du Wachstum präzise planen und darüber reden kannst, die Mechanik von Lead Magnets und Capture-Formularen, den Funnel, der einen Kontakt in einen Kunden verwandelt, und die rechtlichen Regeln - besonders Double Opt-in -, die du befolgen musst, wenn du in Europa und der Schweiz Menschen erfasst und ihnen E-Mails sendest. #### Was du lernst Du lernst die Kern-Marketing-Begriffe (Impressions, Click-Through-Rate, Conversion, Lead, Funnel, Upsell), wie du einen Lead Magnet entwirfst, der eine E-Mail-Adresse wert ist, wie Newsletter- und Kontaktformulare tatsächlich einen Kontakt erfassen, warum Double Opt-in in der EU und CH eine rechtliche Pflicht und keine Nettigkeit ist, und die Abwägungen zwischen E-Mail-Versand von deiner eigenen Domain und der Nutzung eines Drittanbieters. #### Voraussetzungen Eine Live-Site aus Kurs 1 oder 3, um ein Formular draufzusetzen, und die Automations-Grundlagen aus früher in diesem Kurs - ein Funnel ist nur eine Automation, ausgelöst durch ein Formular-Absenden. Der rechtliche Kontext aus CLAUDE.md (DSGVO, FADP, US-Bundesstaatengesetze) ist hier direkt relevant, denn E-Mail-Marketing ist eines der am stärksten regulierten Dinge, die ein kleines Unternehmen tut. #### Das Problem Gründer stecken Mühe in ein Produkt und "machen dann Marketing" als vagen Nachgedanken, meist gemeint als ein paar Social Posts, die niemanden erreichen. Sie haben keine Möglichkeit, die Handvoll wirklich interessierter Leute zu erfassen, die doch auftauchen, keine Erlaubnis zur Nachfassung und keine Sprache, um überhaupt zu diagnostizieren, was scheitert. Ist das Problem, dass niemand die Seite sieht (Impressions), dass sie sie sehen und nicht klicken (CTR), oder dass sie klicken und nicht handeln (Conversion)? Ohne das Vokabular und die Klempnerei kannst du es nicht sagen, also kannst du es nicht beheben. #### Das Vokabular, das du brauchst Du kannst nicht verbessern, was du nicht benennen kannst. Diese wenigen Begriffe lassen dich einen Funnel präzise diagnostizieren und mit jeder Marketerin oder jedem Tool reden. Lern sie einmal und das ganze Feld hört auf, ein Nebel zu sein. - Impressions: wie oft dein Ding gezeigt wurde (ein Suchergebnis, eine Anzeige, ein Post). Die Spitze des Funnels - keine Impressions, nichts. - Click-Through-Rate (CTR): von denen, die es sahen, der Anteil, der klickte. Misst, wie überzeugend dein Titel und Angebot sind. - Conversion: der Anteil der Besucher, die die Aktion machen, die du willst (anmelden, kaufen, herunterladen). Die Zahl, die tatsächlich bezahlt. - Lead: eine Person, die dir die Erlaubnis gab, sie zu kontaktieren, meist eine E-Mail-Adresse. Der Vermögenswert, für den ein Funnel existiert. - Funnel: der Weg vom Fremden zum Kunden, der sich bei jedem Schritt verengt (sah es, klickte, wurde ein Lead, kaufte). - Upsell: einem bestehenden Kunden etwas mehr anbieten (eine höhere Stufe, ein Add-on), sobald er dir bereits vertraut. Der günstigste Umsatz, den du je verdienen wirst. #### Lead Magnets und Capture-Formulare Leute geben dir ihre E-Mail nicht umsonst, und das sollten sie auch nicht. Ein Lead Magnet ist etwas wirklich Nützliches, das du im Tausch gegen eine E-Mail verschenkst: eine Checkliste, ein Template, ein kurzer Leitfaden, ein kostenloses Tool, ein Rabatt. Die Messlatte ist echter Wert - wenn der Magnet dünn ist, ist der Lead wertlos. Ein Capture-Formular erfasst die E-Mail, und die besten Formulare fragen nach dem Minimum (oft nur der E-Mail), weil jedes zusätzliche Feld die Conversion senkt. Das Absenden des Formulars ist der Trigger, der alles Nachgelagerte startet, und genau hier kommen die Automations-Fähigkeiten aus früher in diesem Kurs ins Spiel: Formular abgeschickt, Kontakt gespeichert, Willkommens-Sequenz beginnt. - Mach den Magnet spezifisch und sofort nützlich - "die 12-Punkte-Pre-Launch-Security-Checkliste" schlägt "unser Newsletter". - Frag nach so wenig wie möglich. Nur E-Mail, ausser ein späterer Schritt braucht wirklich mehr. - Ein Kontaktformular ist auch ein Lead Magnet: jemand, der sich meldet, ist ein warmer Lead, also erfasse und fass nach, antworte nicht nur einmal. - Sag klar, wofür sie sich anmelden, und verlinke deine Datenschutzerklärung auf dem Formular. Das ist sowohl ehrlich als auch rechtlich erforderlich. #### Double Opt-in: eine rechtliche Pflicht, keine Nettigkeit Das ist der Teil, den zu viele Bauende falsch machen, und er trägt echtes rechtliches Risiko. In der EU (DSGVO) und der Schweiz (revFADP) brauchst du generell eine klare, belegbare Einwilligung, bevor du Marketing-E-Mails sendest, und der robuste Weg, sie zu bekommen und zu beweisen, ist Double Opt-in. Single Opt-in heisst, jemand schickt das Formular ab und du fängst an, E-Mails zu senden. Double Opt-in fügt einen Schritt hinzu: nach dem Absenden sendest du ihnen einen Bestätigungslink per E-Mail, und sie werden erst zum Abonnenten, sobald sie ihn klicken. Das beweist, dass die E-Mail ihnen gehört, beweist, dass sie eingewilligt haben, und schützt dich vor Beschwerden und Bussen. Es verbessert auch die Zustellbarkeit, weil deine Liste sauber ist. Behandle Double Opt-in als verpflichtend für jedes EU- oder Schweizer Publikum und als gute Praxis überall. - Formular absenden, dann eine Bestätigungs-E-Mail mit einem eindeutigen Link senden. Keine Marketing-E-Mails, bis sie ihn klicken. - Logge die Einwilligung: Zeitstempel, IP und was genau sie zugestimmt haben. Du musst es vielleicht später beweisen. - Jede Marketing-E-Mail muss eine funktionierende Ein-Klick-Abmeldung haben, und du musst sie prompt ehren. - Kauf nie E-Mail-Listen und füg nie Leute hinzu, die nicht eingewilligt haben. Es ist in der EU und CH illegal und zerstört deine Absender-Reputation. #### E-Mail-Funnels: hin zum Kauf pflegen Sobald jemand ein bestätigter Lead ist, ist ein Funnel schlicht eine Sequenz von E-Mails, die Vertrauen aufbaut und sie hin zum Kauf bewegt, automatisch in den richtigen Abständen gesendet. Eine typische Form: eine Willkommens-E-Mail, die den Magnet liefert, ein paar E-Mails mit echtem Wert (kein ständiges Verkaufen), eine sanfte Vorstellung deines bezahlten Angebots und ein klarer Call to Action. Die Automations-Tools aus der n8n-Lektion oder eine dedizierte E-Mail-Plattform senden die richtige Nachricht zur richtigen Zeit, ohne dass du sie anfässt. Das Ziel ist nicht zu spammen; es ist, nützlich und präsent zu bleiben, bis zu dem Moment, in dem der Lead bereit ist, dann das Angebot offensichtlich zu machen. Eine gut gestaltete Nurture-Sequenz ist der Unterschied zwischen einer Liste, die konvertiert, und einer Liste, die dich ignoriert. #### Eigene Domain versus Drittanbieter Du stehst vor einer technischen Wahl: E-Mail selbst von deiner eigenen Domain senden oder einen Drittanbieter-E-Mail-Dienst nutzen. Für transaktionale und Marketing-E-Mail bei jedem echten Volumen nimm einen seriösen Anbieter - sie handhaben Zustellbarkeit, die Authentifizierungs-Einträge (SPF, DKIM, DMARC), die deine Mail aus dem Spam halten, Bounce-Handling, Abmelde-Verwaltung und Compliance-Tooling. Massen-E-Mail von einem rohen selbst gehosteten Server zu senden ist ein Zustellbarkeits-Albtraum und eine Security-Exposition. Beachte, dass der SESSION-PLAN die Wahl eines konkreten E-Mail-Anbieters für dieses Projekt vertagt, also lehrt diese Lektion die dauerhaften Prinzipien statt einer Marke: nutze deine eigene Domain für Absenderidentität und Vertrauen, aber sende über einen Anbieter, der Zustellbarkeit und Einwilligung für dich verwaltet. - Nutze deine eigene Domain als Absender (hello@yourbusiness.com) für Vertrauen und Marke - nie eine generische kostenlose Adresse für Geschäfts-E-Mail. - Sende über einen Anbieter, der SPF, DKIM und DMARC handhabt, damit deine Mail sich authentifiziert und den Posteingang erreicht. - Lass den Anbieter Abmeldungen, Bounces und Einwilligungs-Aufzeichnungen verwalten - das selbst korrekt zu tun ist schwerer, als es aussieht. - Halt Marketing- und transaktionalen Versand getrennt, damit eine Marketing-Beschwerde nie deine Passwort-Reset-E-Mails blockiert. #### Typische Fehler Die teuren: Leute anmailen, die nur single-opt-in gemacht haben (oder nie eingewilligt haben) in der EU oder CH, was ein Rechtsverstoss ist; ein schwacher Lead Magnet, der Müll-E-Mails verdient; Capture-Formulare, die zehn Felder verlangen und die Conversion killen; kein Abmeldelink; Massen-Mail von einem rohen Server direkt in Spam-Ordner senden; und "Marketing machen" ohne Möglichkeit, Impressions, CTR oder Conversion zu messen, sodass du nicht sagen kannst, was kaputt ist. Bring die Einwilligung zuerst in Ordnung - alles andere ist behebbar, eine Datenschutzbeschwerde ist es nicht. #### Business-ROI Eine E-Mail-Liste ist der einzige Marketing-Vermögenswert, den du voll besitzt - nicht gemietet von einer Plattform, die ihren Algorithmus über Nacht ändern kann. Jeder bestätigte, eingewilligte Lead ist eine Person, die du direkt, wiederholt, zu nahezu null Kosten erreichen kannst, weshalb eine gesunde Liste eines der wertvollsten Dinge ist, die ein kleines Unternehmen baut. Funnels verwandeln diese Liste automatisch in wiederkehrenden Umsatz, und Upsells an bestehende Kunden sind die günstigsten Verkäufe, die du je machst. Das Vokabular lässt dich den undichten Schritt finden und beheben, statt zu raten. Richtig und legal gemacht, verzinst sich diese Klempnerei über Jahre. #### Checkliste Du bist bereit weiterzugehen, wenn jedes davon stimmt, denn die nächste Lektion fügt die menschliche Aufsicht hinzu, die automatisierte Systeme sicher hält. - Impressions, CTR, Conversion, Lead, Funnel und Upsell aus dem Gedächtnis definieren. - Einen konkreten Lead Magnet und ein minimales Capture-Formular für dein Unternehmen beschreiben. - Erklären, warum Double Opt-in für ein EU- oder CH-Publikum rechtlich erforderlich ist. - Nennen, warum du von deiner eigenen Domain über einen Drittanbieter sendest. #### Ressourcen Das Datenschutz- und Einwilligungs-Material in Kurs 5 geht tiefer auf DSGVO- und FADP-Compliance und ist Pflichtlektüre, bevor du eine einzige echte Person in Europa oder der Schweiz anmailst. Der SESSION-PLAN vertagt den konkreten E-Mail-Anbieter für dieses Projekt, also wähle bei der Umsetzung einen seriösen Anbieter und folge seinen Authentifizierungs- und Double-Opt-in-Leitfäden, statt selbst zu basteln. Deine Datenschutzerklärung muss live und von jedem Formular verlinkt sein. #### Deine Aufgabe Entwirf einen Lead Magnet für dein Unternehmen und schreib die drei E-Mails eines minimalen Nurture-Funnels: die Willkommen-und-Liefer-E-Mail, eine reine Wert-E-Mail und eine sanfte Angebots-E-Mail. Skizziere den Double-Opt-in-Bestätigungsschritt. Du musst sie noch nicht senden; das Ziel ist ein konkreter, konformer Funnel auf Papier, den du an einem Nachmittag verdrahten könntest. #### Nächste Lektion Automatisierte Systeme sind mächtig und gelegentlich falsch, also halten die besten einen Menschen an den Punkten, die zählen. Die nächste Lektion behandelt Human-in-the-Loop-Design, das Stripe-Minions-Muster des Gründers und das Verwandeln jedes Fehlers in eine Regel, aus der das System lernt. ### 4.6 Human in the Loop: kontinuierlich lernende Systeme - Kanonische URL: https://agenticschool.dev/de/kurse/automation-agentic-systems/human-in-the-loop-continuous-learning-systems - Dauer: 26 min Zusammenfassung: Volle Autonomie scheitert heute, also setzen die besten agentischen Systeme einen Menschen an die Momente, die Urteilsvermögen brauchen, und lernen aus jeder Korrektur. Diese Lektion behandelt Genehmigungs-Checkpoints, das Stripe-Minions-Muster des Gründers - eine automatisierte Pipeline, in der jede Stufe einen Menschen per E-Mail um Genehmigung bittet, bevor es weitergeht -, Feedback-Schleifen, die das System verbessern, und das Festhalten jedes Gotchas als Regel. #### Überblick Volle Autonomie ist gerade jetzt eine Falle. Agents sind fähig, aber nicht zuverlässig genug, um unbeaufsichtigt an irgendetwas zu laufen, das Geld, Kunden oder Daten berührt, weil die Kosten eines selbstsicheren Fehlers zu hoch sind. Die Antwort ist nicht, Automation aufzugeben - es ist, einen Menschen genau an den Punkten zu halten, die Urteilsvermögen brauchen, das System überall sonst laufen zu lassen und jede Korrektur zurückzuspeisen, damit das System mit der Zeit weniger Aufsicht braucht. Diese Lektion lehrt, wo du Genehmigungs-Checkpoints platzierst, das konkrete Stripe-Minions-Muster, das der Gründer dieser School nutzt, und wie du jeden Gotcha in eine dauerhafte Regel verwandelst. #### Was du lernst Du lernst, warum volle Autonomie heute scheitert und wie du ehrlich darüber nachdenkst, wie du Genehmigungs-Checkpoints platzierst, sodass der menschliche Aufwand minimal, aber gut gezielt ist, das Stripe-Minions-Muster, bei dem jede Stufe einer Pipeline einen Menschen per E-Mail um Genehmigung bittet, bevor es weitergeht, und wie du Feedback-Schleifen baust, die jeden Fehler als Regel festhalten - sodass das System, das du diesen Monat fährst, schlauer ist als das vom letzten Monat. #### Voraussetzungen Die Automation und das Tool-Bauen aus früher in diesem Kurs, denn Human-in-the-Loop ist eine Kontrollschicht auf funktionierender Automation. Du solltest mit Webhooks und E-Mail-ausgelösten Aktionen aus den n8n- und E-Mail-Lektionen vertraut sein, da Genehmigungs-Checkpoints meist als "das System mailt einen Menschen und wartet auf eine Antwort oder einen Klick" umgesetzt werden. #### Das Problem Der Traum ist "einrichten und vergessen": ein Agent, der deine Pipeline von Anfang bis Ende fährt, während du schläfst. Die Realität 2026 ist, dass Agents die meiste Zeit richtig liegen und auf Weisen falsch, die gelegentlich teuer und schwer vorhersehbar sind. Übergib volle Autonomie an ein System, das Rechnungen zuordnet, Kunden erstattet oder E-Mails sendet, und der eine Fehler von fünfzig wird zu einer Erstattung an das falsche Konto oder einer E-Mail an die falsche Liste. Gründer übervertrauen entweder (und verbrennen sich) oder überkontrollieren (und verlieren die Automation ganz). Die Fähigkeit ist, die wenigen Checkpoints zu finden, an denen ein Mensch die meiste Sicherheit für die geringste Reibung hinzufügt. #### Wo Menschen hingehören Setz einen Menschen dorthin, wo ein Fehler teuer, unumkehrbar ist oder Kontext braucht, den das System nicht hat - und sonst nirgends. Die Kunst ist, Checkpoints wenige, aber entscheidend zu halten. Ein guter Checkpoint ist ein Moment des Urteils, kein Abnicken: wenn ein Mensch alles ohne Nachdenken genehmigt, ist der Checkpoint Theater, also gestalte sie so, dass nur die Fälle auftauchen, die wirklich eine Entscheidung brauchen. - Checkpoint, wo es teuer oder unumkehrbar ist: Geld bewegen, Daten löschen, an viele Kunden senden, alles, was du nicht rückgängig machen kannst. - Checkpoint, wo das System unsicher ist: Treffer mit geringer Konfidenz, mehrdeutige Inputs, alles ausserhalb der Fälle, die es gesehen hat. - Lass die selbstsichere, umkehrbare, risikoarme Mehrheit automatisch laufen. Die meisten Schritte in jeder Pipeline sind sicher voll zu automatisieren. - Mach die menschliche Entscheidung günstig: zeig den Kontext, die vorgeschlagene Aktion und ein Ein-Klick-Genehmigen oder -Ablehnen, sodass die Prüfung Sekunden statt Minuten dauert. #### Das Stripe-Minions-Muster Hier ist das konkrete Muster, das der Gründer dieser School fährt, Stripe Minions genannt, weil es aus Zahlungs- und Finanzautomation erwuchs, wo Fehler teuer sind. Die Idee: bau die Pipeline als Kette kleiner autonomer Arbeiter (die "Minions"), aber lass jede Stufe einen Menschen per E-Mail um Genehmigung bitten, bevor sie an die nächste übergibt. Jeder Minion macht seinen engen Job, schlägt das Ergebnis vor und pausiert. Der Mensch bekommt eine E-Mail mit der vorgeschlagenen Aktion und einem Genehmigen- oder Ablehnen-Link. Genehmigen, und der nächste Minion übernimmt automatisch; ablehnen, und die Pipeline stoppt oder leitet zur Korrektur. Das System macht die ganze Arbeit; der Mensch liefert das Urteil an den Toren. Es ist im Aufwand voll automatisiert und im Risiko voll beaufsichtigt, was genau die Balance ist, die Autonomie noch nicht allein liefern kann. - Zerleg den Job in kleine, einzweck-Stufen (Minions), jede mit einem klaren Output. - Nach jeder Stufe maile den verantwortlichen Menschen: hier ist, was ich als Nächstes vorschlage, genehmigen oder ablehnen. - Bei Genehmigung läuft der nächste Minion automatisch. Bei Ablehnung anhalten oder an eine Fix-Queue leiten - und festhalten, warum. - Die E-Mail IST die Oberfläche: kein Dashboard zu prüfen, die Arbeit kommt zum Menschen, der in Sekunden aus seinem Posteingang handelt. Dieses Muster ist, warum die E-Mail-ausgelöste Automation aus früher im Kurs zählt: ein Genehmigungs-Checkpoint ist nur ein Webhook, der auf einen Link-Klick feuert und die Pipeline fortsetzt. Du kannst das Ganze in n8n oder einer kleinen App mit den Tools bauen, die du schon hast. #### Feedback-Schleifen: jeder Gotcha wird zur Regel Ein menschlicher Checkpoint ist verschwendet, wenn das System für immer denselben Fehler macht. Der Multiplikator ist die Feedback-Schleife: jedes Mal, wenn ein Mensch etwas ablehnt oder korrigiert, hältst du fest, warum, und verwandelst es in eine Regel, der das System beim nächsten Mal folgt. Das ist der kontinuierlich lernende Teil, und es ist dieselbe Philosophie wie die CLAUDE.md-Skills-Library aus Kurs 2 - du sammelst hart erarbeitete Korrekturen in einem wachsenden Satz von Regeln, sodass das System mit der Nutzung besser wird. Über die Zeit schrumpfen die Checkpoints, die am häufigsten feuern, weil die Gotchas dahinter als Regeln kodiert wurden, und dem Menschen bleibt, nur wirklich neue Situationen zu prüfen. - Wenn ein Mensch eine Aktion ablehnt, logge den Input, den falschen Vorschlag, den richtigen und den Grund an einem Ort. - Verwandle wiederkehrende Ablehnungen in explizite Regeln, die das System automatisch anwendet (eine Prüfung, eine Prompt-Anweisung, eine Validierung). - Verfolge, welche Checkpoints am häufigsten feuern. Eine oft abgelehnte Stufe sagt dir genau, welche Regel ihr fehlt. - Behandle deinen Regelsatz als lebendes Dokument, das jede Woche wächst. Das System, das du nächsten Monat fährst, sollte weniger Aufsicht brauchen als heute. #### Typische Fehler Die schädlichen: volle Autonomie an ein System geben, das Geld oder Kunden berührt, und den Fehlermodus in Produktion entdecken; der entgegengesetzte Fehler, für alles menschliche Genehmigung zu verlangen, bis die Automation langsamer ist als es von Hand zu tun; Abnick-Checkpoints, bei denen Menschen ohne echte Prüfung genehmigen, was schlimmer als kein Checkpoint ist, weil es falsches Vertrauen herstellt; und - die häufigste Verschwendung - die Feedback-Schleife nie schliessen, sodass das System jede Woche denselben Fehler wiederholt, statt aus der ersten Korrektur zu lernen. #### Business-ROI Human-in-the-Loop ist, was Automation sicher genug macht, um sie tatsächlich auf der Arbeit einzusetzen, die zählt. Eine Pipeline, die 95 Prozent autonom handhabt und die riskanten 5 Prozent an einen menschlichen Posteingang leitet, macht das Volumen eines Teams, während sie die Sicherheit menschlichen Urteils auf den Fällen behält, die zählen. Die Feedback-Schleife verzinst sich: jeder festgehaltene Gotcha entfernt dauerhaft eine Fehlerklasse, sodass dieselbe Mannschaft mit der Zeit mehr handhabt. Für ein kleines Unternehmen ist das der Weg, den Betrieb zu skalieren, ohne das Personal zu skalieren - das System macht die Arbeit, Menschen machen das Urteil, und beide werden jede Woche besser. #### Checkliste Du bist bereit für die letzte Lektion, wenn jedes davon sitzt, denn sie verortet alles, was du gebaut hast, auf dem Autonomie-Spektrum. - In einem ehrlichen Satz erklären, warum volle Autonomie heute scheitert. - Die wenigen Checkpoints in einer echten Pipeline identifizieren, an denen ein Mensch die meiste Sicherheit für die geringste Reibung hinzufügt. - Das Stripe-Minions-Muster beschreiben: jede Stufe mailt einen Menschen zur Genehmigung, bevor es weitergeht. - Eine Feedback-Schleife beschreiben, die jede Ablehnung in eine Regel verwandelt, der das System beim nächsten Mal folgt. #### Ressourcen Das CLAUDE.md- und Skills-Library-Material aus Kurs 2 ist das direkte Pendant zur regel-festhaltenden Feedback-Schleife hier, also schau es nochmal an - dieselbe Disziplin kontinuierlichen Lernens gilt für Systeme wie für Agents. Die E-Mail- und Webhook-Tools aus früher in diesem Kurs sind, was du nutzt, um Genehmigungs-Checkpoints umzusetzen. Die /builds-Fallstudien zeigen diese Muster, wie sie in echten Gründer-Projekten laufen. #### Deine Aufgabe Nimm eine Automation, die du früher in diesem Kurs gebaut hast, und füge einen einzigen Genehmigungs-Checkpoint an ihrem riskantesten Schritt hinzu, umgesetzt als E-Mail mit einem Genehmigen- oder Ablehnen-Link im Stripe-Minions-Stil. Dann füge einen Ort hinzu, um jede Ablehnung mit ihrem Grund zu loggen. Lass es ein paar Mal laufen und verwandle die erste wiederkehrende Ablehnung in eine explizite Regel. Du hast jetzt ein System, das lernt. #### Nächste Lektion Du hast Autonomie scheitern sehen und gelernt, sie zu beaufsichtigen. Die letzte Lektion dieses Kurses zoomt heraus auf die fünf Stufen der LLM-Autonomie, erklärt, warum Validierung - nicht Generierung - der echte Blocker beim Aufstieg ist, und zeigt, wo du heute realistisch arbeitest. ### 4.7 Die 5 Stufen der LLM-Autonomie - Kanonische URL: https://agenticschool.dev/de/kurse/automation-agentic-systems/the-5-levels-of-llm-autonomy - Dauer: 24 min Zusammenfassung: Autonomie ist eine Leiter, kein Schalter. Diese Lektion legt fünf Stufen der LLM-Autonomie dar, von einem Level-1-Chat-Assistenten bis zu Level-5-voll-autonomen Ship-and-Learn-Schleifen, erklärt, warum Validierung (nicht Generierung) der echte Blocker beim Aufstieg ist, erkundet die KI-erschafft-KI-Rekursion und zeigt, wo du heute realistisch arbeitest und wie du eine Stufe aufsteigst, ohne dich zu verbrennen. #### Überblick Leute reden über Autonomie als an oder aus - entweder macht es die KI oder du. Es ist eigentlich eine Leiter mit deutlichen Sprossen, und zu wissen, auf welcher Sprosse ein System steht, sagt dir, wie sehr du ihm trauen kannst und was ein Aufstieg bräuchte. Diese Lektion legt fünf Stufen dar, von einem Level-1-Chat-Assistenten bis zu Level-5-voll-autonomen Ship-and-Learn-Schleifen, und macht dann das zentrale Argument des ganzen Kurses: das, was dich am Aufstieg hindert, ist fast nie die Fähigkeit des Modells zu generieren, es ist deine Fähigkeit zu validieren. Wo Validierung günstig und verlässlich ist, kann Autonomie steigen; wo nicht, bleibt ein Mensch in der Schleife. Wir schliessen mit KI-erschafft-KI-Rekursion und einer praktischen Antwort auf "wo sollte ich heute arbeiten". #### Was du lernst Du lernst die fünfstufige Autonomie-Skala und wie du jedes System darauf verortest, warum Validierung der echte Engpass ist statt Modellfähigkeit, was es bedeutet, dass KI KI erschafft, und warum das den Einsatz auf Validierung erhöht statt senkt, und eine konkrete Methode, um zu entscheiden, wo du jetzt arbeitest, und genau eine Stufe nach der anderen aufzusteigen, ohne Risiko einzugehen, das du nicht validieren kannst. #### Voraussetzungen Der volle Bogen dieses Kurses, denn ein System auf der Skala zu verorten zieht auf alles: Automations-Plattformen, Tool-Bau, Sandboxes und besonders die Human-in-the-Loop-Lektion, die eigentlich eine Lektion über Validierung ist. Die Modell- und Kontext-Lektionen aus Kurs 1 untermauern, warum Generierung nicht mehr der harte Teil ist. #### Das Problem Zwei entgegengesetzte Fehler dominieren. Ein Lager glaubt, das Modell sei jetzt klug genug, um alles autonom zu fahren, und liefert Systeme aus, die auf teure, überraschende Weisen scheitern. Das andere Lager ist von Fehlern so verbrannt, dass es KI dauerhaft auf Stufe eins hält, ins Chatfenster tippend, und den enormen Wert höherer Sprossen verpasst. Beide verschätzen sich beim selben Ding: sie denken, Autonomie sei dadurch begrenzt, wie clever das Modell ist. Ist sie nicht. Sie ist dadurch begrenzt, ob du den Output verlässlich und günstig prüfen kannst. Bring das gerade und die ganze Frage wird handhabbar. #### Die fünf Stufen Hier ist die Leiter. Der Sprung, der zählt, ist nicht von einem schwächeren Modell zu einem stärkeren - es ist von einem Menschen, der jeden Schritt prüft, zu einem System, das sich selbst prüft. Jede Sprosse entfernt einen Menschen aus einem Teil der Schleife, und du kannst einen Menschen nur aus einem Schritt entfernen, den du ohne ihn zu validieren gelernt hast. - Stufe 1 - Chat-Assistent: du fragst, es antwortet, du machst alles mit der Antwort. Das Modell generiert, du entscheidest und handelst. Alle Validierung ist menschlich, jedes Mal. - Stufe 2 - Assistierte Aktion: das Modell führt Aktionen aus, fragt aber bei jedem Schritt um Erlaubnis (ein Coding-Agent, der eine Änderung vorschlägt und wartet). Du validierst jede Aktion, bevor sie läuft. - Stufe 3 - Beaufsichtigte Pipeline: das System fährt mehrschrittige Workflows autonom, stoppt aber an Genehmigungs-Checkpoints für die riskanten Schritte - das Stripe-Minions-Muster. Du validierst die wenigen entscheidenden Momente, nicht jeden Schritt. - Stufe 4 - Begrenzte Autonomie: das System läuft von Anfang bis Ende innerhalb von Leitplanken und validiert das meiste seiner eigenen Arbeit (Tests, Schemata, Prüfungen), eskaliert nur bei echten Ausnahmen zu einem Menschen. Du validierst das System, nicht jeden Lauf. - Stufe 5 - Voll autonomes Ship-and-Learn: das System setzt Teilziele, handelt, validiert, liefert aus, beobachtet das Ergebnis und verbessert sich in einer geschlossenen Schleife selbst. Menschliche Aufmerksamkeit verlagert sich vom Tun zum Gestalten der Validierung, die das System auf sich selbst anwendet. #### Validierung ist der echte Blocker Das ist die tragende Idee des ganzen Kurses. Modelle wurden ausserordentlich gut im Generieren - Code schreiben, Daten extrahieren, Copy entwerfen - schneller, als fast jeder erwartet hat. Generierung ist für eine riesige Bandbreite von Aufgaben weitgehend gelöst. Was nicht im selben Tempo gelöst wurde, ist Validierung: verlässlich und günstig zu wissen, ob ein gegebener Output tatsächlich korrekt ist. Du kannst Autonomie nicht sicher über den Punkt heben, an dem du den Output validieren kannst, denn höhere Autonomie heisst nur, dass das System auf seiner eigenen Generierung handelt, ohne dass du prüfst. Also ist die echte Ingenieursarbeit agentischer Systeme nicht besseres Prompting - es ist der Bau günstiger, verlässlicher Validierung: Tests, Schemata, Type Checks, Plausibilitätsprüfungen, Konfidenzschwellen und die Genehmigungs-Checkpoints aus der letzten Lektion. Wo immer du Validierung automatisch und vertrauenswürdig machen kannst, kannst du eine Stufe aufsteigen. Wo nicht, bleibt ein Mensch in der Schleife, und das ist richtig, kein Versagen. - Generierung ist günstig und gut; Validierung ist das knappe, wertvolle Ding. Investiere deine Mühe dort. - Eine Stufe aufzusteigen heisst immer, eine menschliche Prüfung durch eine automatische zu ersetzen, der du traust. - Wenn du nicht beschreiben kannst, wie du einen Schritt ohne Mensch validieren würdest, bist du nicht bereit, diesen Schritt zu automatisieren. - Die besten agentischen Ingenieure sind Validierungs-Ingenieure - sie bauen die Prüfungen, die das System unbeaufsichtigt laufen lassen. #### KI, die KI erschafft Die Grenzsprosse ist Rekursion: Agents, die andere Agents bauen, testen und verbessern. Ein Agent, der ein Tool schreibt, Tests dafür generiert, sie laufen lässt und das Tool anhand der Ergebnisse verfeinert, macht in Minuten, was früher ein Entwicklungszyklus war - und es ist KI, die KI erschafft. Das komprimiert die Schleife drastisch und ist ein echter Vorgeschmack darauf, wohin Stufe fünf führt. Aber beachte, was es mit dem zentralen Argument macht: es entfernt das Validierungsproblem nicht, es konzentriert es. Wenn eine KI eine andere KI erschafft, ist das Einzige, das zwischen dir und sich aufaddierendem, unbeaufsichtigtem Fehler steht, die Validierungsschicht - die Tests, die Prüfungen, die Leitplanken. Rekursion erhöht den Einsatz auf Validierung, sie pensioniert ihn nicht. Die Teams, die hier gewinnen, bauen die Validierung, die Rekursion sicher laufen lässt, statt die Generierung zu bestaunen. #### Wo du heute arbeitest und wie du aufsteigst Sei ehrlich darüber, wo du stehst, und steig bewusst auf. Die meisten wertvollen realen Systeme sitzen 2026 auf Stufe drei: autonome Pipelines mit menschlicher Genehmigung an den riskanten Schritten. Das ist keine Begrenzung, für die man sich schämen muss; es ist der verantwortungsvolle Arbeitspunkt für alles, was Geld, Kunden oder Daten berührt, und es fängt den meisten Wert der Automation ein, während es die Sicherheit menschlichen Urteils behält. Steig genau eine Sprosse nach der anderen auf, und nur, indem du die Validierung baust, die die nächste Sprosse sicher macht. - Finde deine aktuelle Stufe für ein gegebenes System: wie viele menschliche Prüfungen braucht es noch, und an welchen Schritten? - Wähle einen menschlichen Checkpoint zum Entfernen. Frag: welche automatische Validierung würde mich diesem Schritt ohne Person trauen lassen? - Bau diese Validierung (einen Test, ein Schema, eine Konfidenzschwelle, eine Plausibilitätsprüfung) und beweise, dass sie die Fehler fängt, die der Mensch gefangen hat. - Erst dann entferne den Menschen aus diesem Schritt. Steig eine Sprosse, validiere sie in Produktion und wiederhole. Überspring nie Sprossen. #### Typische Fehler Die wiederkehrenden Fehler: direkt zu Stufe vier oder fünf springen, weil das Modell "klug genug wirkt", ohne Validierung, um seine Fehler zu fangen; aus Angst auf Stufe eins steckenbleiben und enormen Wert unautomatisiert lassen; bessere Generierung mit Bereitschaft für mehr Autonomie verwechseln, wenn Validierung das ist, was den Aufstieg tatsächlich begrenzt; und KI-erschafft-KI-Rekursion um ihrer selbst willen jagen, ohne die Validierungsschicht, die sie sicher hält. Steig auf der Stärke deiner Validierung auf, nie auf der Stärke des Modells allein. #### Business-ROI Die Autonomie-Leiter zu kennen verwandelt "sollten wir das automatisieren?" von einer Bauchentscheidung in eine klare Entscheidung: du automatisierst bis genau auf die Stufe, die deine Validierung tragen kann, und du investierst in Validierung, um weiter aufzusteigen. Dieser Fokus ist echtes Geld wert - er hält dich davon ab, unbeaufsichtigte Systeme auszuliefern, die teuer scheitern, und er hält dich davon ab, Wert liegenzulassen, indem du aus Angst zu wenig automatisierst. Die strategische Einsicht für jede Gründerin ist, dass Validierung, nicht Generierung, die knappe Fähigkeit dieser Ära ist. Die Unternehmen, die günstige, verlässliche Validierung bauen, werden bei höherer Autonomie, zu niedrigeren Kosten, mit mehr Sicherheit arbeiten als Wettbewerber, die nur dem nächsten Modell nachjagen. #### Checkliste Du hast Kurs 4 abgeschlossen, wenn jedes davon stimmt. Das ist ein echter Meilenstein - du kannst jetzt agentische Systeme gestalten, bauen und sicher betreiben. - Jedes System anhand seiner verbleibenden menschlichen Prüfungen auf der fünfstufigen Skala verorten. - Erklären, warum Validierung, nicht Generierung, das ist, was Autonomie begrenzt. - Beschreiben, was KI-erschafft-KI-Rekursion mit dem Validierungsproblem macht. - Deine aktuelle Stufe für ein echtes System nennen und die einzelne Validierung, die dich eine Sprosse aufsteigen liesse. #### Ressourcen Die Human-in-the-Loop-Lektion ist der praktische Begleiter zu dieser - Genehmigungs-Checkpoints sind Validierung, konkret gemacht. Kurs 5 verwandelt Validierung in eine Disziplin mit Tests, Linting und CI/CD und erkundet, wohin diese exponentielle Bahn führt. Kehre immer wieder zu der einen Frage zurück, die hier alles entscheidet: wie würde ich diesen Schritt ohne Mensch validieren? #### Deine Aufgabe Nimm ein System, das du quer durch diesen Kurs gebaut hast, und verorte es ehrlich auf der fünfstufigen Skala. Schreib den einzelnen menschlichen Checkpoint auf, den du als Nächstes entfernen würdest, die genaue automatische Validierung, die das Entfernen sicher machen würde, und wie du beweisen würdest, dass diese Validierung funktioniert. Dieser eine Absatz ist die nützlichste Planung, die du für jedes agentische System machen kannst, das du ab hier baust. #### Nächste Lektion Kurs 5 macht all das produktionsreif. Er verwandelt Validierung in eine echte Disziplin - Tests, Security, rechtliche Compliance, SEO und agent-first Design - und endet mit einem Capstone, in dem du dein eigenes agentisches Produkt von Anfang bis Ende baust und auslieferst. ### 5.1 Tests, Tests, Tests: TSC, Linting, Vitest, Playwright und CI/CD - Kanonische URL: https://agenticschool.dev/de/kurse/quality-security-agent-first/tests-tests-tests-tsc-linting-vitest-playwright-and-ci-cd - Dauer: 28 min Zusammenfassung: Agents bewegen sich schnell, was ein Sicherheitsnetz unerlässlich macht. Diese Lektion behandelt den vollen Quality-Stack: TypeScript-Type-Checking, Linting, Vitest für Unit-Tests, Playwright für End-to-End-Tests, einen Pre-Push-Hook und eine GitHub-Actions-Pipeline, sodass Regressionen vor dem Ausliefern gefangen werden statt danach, wenn ein Kunde sie findet. #### Überblick Es gibt den Mythos, dass die KI den Code schreibt und du deshalb keine Tests mehr brauchst. Das Gegenteil ist wahr. Ein Agent schreibt fröhlich eine funktionierende Funktion um 2 Uhr nachts neu, weil du um eine unzusammenhängende Änderung gebeten hast, und er hat keine Erinnerung daran, warum das alte Verhalten wichtig war. Tests sind, wie du künftigen Agents sagst, was nicht brechen darf. Diese Lektion baut das vierschichtige Quality Gate - Typen, Lint, Unit, End-to-End - und verdrahtet es in einen Pre-Push-Hook und eine CI-Pipeline, sodass Qualität von der Maschine erzwungen wird, nicht von deiner Disziplin. #### Was du lernst Du lernst, was jede Schicht des Quality-Stacks fängt, wie du einen Vitest-Unit-Test und einen Playwright-End-to-End-Test schreibst, die nach einem Refactor weiter funktionieren, wie du einen schlechten Push mit einem Git-Hook blockierst und wie du die ganze Suite automatisch bei jedem Push mit GitHub Actions laufen lässt. Am Ende kannst du einem Agent freie Hand in einem Repo geben und dem Gate vertrauen, seine Fehler zu fangen. #### Voraussetzungen Ein funktionierendes TypeScript-Projekt aus früheren Kursen und die Hooks-Lektion aus Kurs 2, da CI/CD nur die teamweite Version eines Pre-Push-Gates ist. Du musst kein Test-Experte sein. Der Sinn dieser Lektion ist, Testen zu einer Gewohnheit zu machen, die dein Agent für dich erledigt, keine Disziplin, an die du dich erinnern musst. #### Das Problem Wenn du einen Agent hart fährst, fasst er schnell viel Code an. Eine Änderung an einer Datei bricht still eine andere. Der Agent meldet Erfolg, weil die Datei, die er bearbeitet hat, richtig aussieht, und du entdeckst die Regression erst, wenn eine Seite in Produktion leer ist. Manuelles Testen skaliert nicht auf Agent-Tempo - du kannst nicht nach jeder Änderung durch jeden Flow klicken. Ohne ein automatisches Gate ist jede Agent-Session ein kleines Glücksspiel mit deinem Live-Produkt. Die Lösung ist, "funktioniert es noch?" zu einer Frage zu machen, die die Maschine in Sekunden beantwortet. #### Das vierschichtige Quality Gate Jede Schicht fängt eine andere Klasse von Bugs, und sie werden langsamer und gründlicher, je weiter du nach unten gehst. Fahr die schnellen ständig und die langsamen vor dem Ausliefern. Zusammen bilden sie ein Netz, das dicht genug ist, dass schnelle, agent-getriebene Änderungen sicher bleiben. - Type Check (tsc --noEmit): fängt Formfehler - eine Funktion, die mit den falschen Argumenten aufgerufen wird, eine Eigenschaft, die nicht existiert, ein null, das du zu behandeln vergessen hast. Sofort und kostenlos. - Lint (ESLint): fängt fehleranfällige Muster und Stil-Drift - ungenutzte Variablen, fehlende awaits, versehentliche console.logs. Hält agent-geschriebenen Code konsistent mit deinem. - Unit-Tests (Vitest): prüfen, dass deine Logik tatsächlich korrekt ist - eine Preisberechnung, eine Validierungsregel, ein Datumsformatierer. Schnell, bei jedem Speichern laufen lassen. - End-to-End-Tests (Playwright): fahren einen echten Browser durch ganze User-Journeys - anmelden, in den Warenkorb legen, auschecken. Langsam, aber sie beweisen, dass das echte Ding funktioniert. #### Einen Vitest-Unit-Test schreiben Unit-Tests sind klein und schnell. Du gibst einer Funktion einen Input und prüfst den Output. Der Trick, der sie Agent-Refactors überleben lässt: teste Verhalten, nicht Implementierung. Prüfe, was die Funktion für eine Nutzerin erzeugen soll, nie die privaten Schritte, die sie dafür geht. Dann kann der Agent die Interna frei umschreiben und der Test bewacht trotzdem den Vertrag. ```typescript import { describe, it, expect } from 'vitest' import { yearlyPricePerMonth } from './pricing' describe('yearlyPricePerMonth', () => { it('shows the discounted monthly figure for a yearly plan', () => { // Monthly is 17% above yearly, so yearly-per-month is monthly / 1.17. expect(yearlyPricePerMonth({ monthly: 117 })).toBe(100) }) it('never returns a negative price', () => { expect(yearlyPricePerMonth({ monthly: 0 })).toBeGreaterThanOrEqual(0) }) }) ``` Ein Vitest-Test, der Verhalten festnagelt, nicht Implementierung - lass ihn mit bun run test laufen Wenn du einen Agent bittest, ein Feature hinzuzufügen, füge deinem Spec eine Zeile hinzu: "schreib einen Vitest-Test dafür". Jetzt hinterlässt der Agent einen Stolperdraht, der das Feature vor dem nächsten Agent schützt, inklusive einer künftigen Version seiner selbst. #### Einen Playwright-End-to-End-Test schreiben Playwright startet einen echten Browser, besucht deine App und klickt sich wie eine Nutzerin durch. Es fängt die Bugs, die Unit-Tests nicht können: eine kaputte Route, einen Button, der nichts tut, ein Formular, das nie absendet. Schreib End-to-End-Tests zuerst für deine Geld-Pfade - die Handvoll Flows, bei denen ein Bruch dich einen Kunden kostet. Wähle Elemente nach dem, was die Nutzerin sieht, oder nach stabilen Test-IDs, nie nach brüchigem CSS, sodass ein Redesign nicht jeden Test bricht. ```typescript import { test, expect } from '@playwright/test' test('a visitor can reach the pricing page from the hero CTA', async ({ page, }) => { await page.goto('/') await page.getByRole('link', { name: 'See pricing' }).click() await expect(page).toHaveURL(/\/pricing/) await expect( page.getByRole('heading', { name: 'Pricing' }), ).toBeVisible() }) ``` Ein Playwright-Test für eine echte User-Journey - lass ihn mit bun run test:e2e laufen #### Der Pre-Push-Hook: dein lokales Gate Der erste Ort, das Gate zu erzwingen, ist deine eigene Maschine, im Moment bevor Code sie verlässt. Ein Git-Pre-Push-Hook fährt deine Prüfungen und verweigert den Push, wenn eine scheitert, sodass kaputter Code nie das Repo erreicht. Das ist dieselbe Idee, die du in Kurs 2 getroffen hast, jetzt auf die volle Suite gerichtet. Halt den lokalen Hook schnell - Typen, Lint und Unit-Tests - und lass die langsamere End-to-End-Suite in CI laufen. ```bash #!/usr/bin/env sh # .husky/pre-push - blockiert den Push, wenn eine Pruefung scheitert bun run typecheck || exit 1 bun run lint || exit 1 bun run test || exit 1 echo "All checks passed - pushing." ``` Ein Pre-Push-Hook, der die schnellen Schichten fährt, bevor Code deine Maschine verlässt Ein Hook, den du mit --no-verify überspringen kannst, ist ein Vorschlag, kein Gate. Der Hook ist dein schnelles Feedback; CI ist das Gate, das niemand umgehen kann. Du willst beide. #### GitHub Actions: das Gate, das niemand überspringen kann Continuous Integration fährt deine ganze Suite auf GitHubs Servern bei jedem Push und Pull Request, egal, was jemand lokal gefahren hat. Eine Workflow-Datei in .github/workflows sagt GitHub, was zu tun ist. Das Beispiel unten installiert Abhängigkeiten und fährt dann alle vier Schichten inklusive der End-to-End-Tests. Setz deinen Branch so, dass diese Prüfung bestehen muss, bevor irgendetwas merget, und eine Regression kann deinen Main-Branch schlicht nicht erreichen. ```yaml name: Quality gate on: push: branches: [main] pull_request: jobs: check: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: oven-sh/setup-bun@v2 - run: bun install --frozen-lockfile - run: bun run typecheck - run: bun run lint - run: bun run test - run: bunx playwright install --with-deps - run: bun run test:e2e ``` .github/workflows/quality.yml - das volle Gate, automatisch bei jedem Push gefahren #### Typische Fehler Die grossen: null Tests schreiben, weil "der Agent hat es schon geprüft" (er kann deine Live-App nicht sehen); Implementierungsdetails testen, sodass jeder Refactor die Suite rot färbt und du anfängst, sie zu ignorieren; den lokalen Hook so langsam machen, dass du ihn mit --no-verify umgehst; und CI haben, aber nicht verlangen, dass es vor dem Merge besteht, sodass es dekorativ wird. Teste Verhalten, halt das lokale Gate schnell und mach CI verpflichtend. #### Business-ROI Eine Regression, die einen Kunden erreicht, kostet dich Vertrauen, ein Support-Ticket und einen Notfall-Fix, oft zum denkbar schlechtesten Zeitpunkt. Ein Test, der sie fängt, kostet die paar Sekunden, die er zum Laufen braucht. Sobald das Gate existiert, kannst du Agents weit aggressiver arbeiten lassen, weil die Kosten eines Fehlers von "hat Produktion zerbrochen" auf "die Pipeline wurde rot, behebe es vor dem Merge" fallen. Das ist die echte Befreiung: Tests sind kein Overhead auf agentischer Entwicklung, sie sind, was aggressive agentische Entwicklung sicher macht. #### Checkliste Du bist bereit weiterzugehen, wenn jedes davon für ein echtes Projekt stimmt, nicht nur in der Theorie. - Du kannst erklären, was jede der vier Schichten fängt, das die anderen verpassen. - Mindestens ein Vitest-Test und ein Playwright-Test bestehen in deinem Projekt. - Ein Pre-Push-Hook fährt die schnellen Schichten und blockiert einen scheiternden Push. - Ein GitHub-Actions-Workflow fährt die volle Suite und ist vor dem Merge erforderlich. #### Ressourcen Setz die offiziellen Vitest- und Playwright-Docs für Matcher und Selektoren als Lesezeichen und die GitHub-Actions-Docs für Workflow-Syntax, da diese sich entwickeln. Füge "schreib einen Test dafür" zu deinen Standard-Spec-Sheet-Constraints hinzu, sodass jede Agent-Aufgabe einen Stolperdraht hinterlässt. Die Hooks-Lektion in Kurs 2 ist eine erneute Lektüre wert, jetzt, wo du die volle Suite verdrahtest. #### Deine Aufgabe Füge einem echten Projekt einen Vitest-Test und einen Playwright-Test hinzu, dann füge den Pre-Push-Hook und den GitHub-Actions-Workflow von oben hinzu. Brich bewusst etwas, das ein Agent brechen könnte - benenne eine Route um, ändere den Output einer Funktion - und bestätige, dass das Gate rot wird. Dieses Rot ist der ganze Sinn: es hat den Fehler gefangen, bevor ein Nutzer es tat. #### Nächste Lektion Qualität abgedeckt, härtet die nächste Lektion Security: Rate Limits auf jedem öffentlichen Endpunkt, CSP-Header, gespeicherte Credentials verschlüsseln und das Pre-Public-Audit, das verhindert, dass ein Secret leakt, wenn du ein Repo auf öffentlich schaltest. ### 5.2 Security-Essentials: Rate Limits, CSP-Header, Key-Verschlüsselung, Pre-Public-Repo-Audits - Kanonische URL: https://agenticschool.dev/de/kurse/quality-security-agent-first/security-essentials-rate-limits-csp-headers-key-encryption-pre-public-repo-audits - Dauer: 26 min Zusammenfassung: Security ist nicht optional, sobald echte Nutzer ankommen. Diese Lektion behandelt die Essentials, die jede App braucht: Rate Limits auf jedem öffentlichen Endpunkt, eine Content Security Policy zum Härten des Browsers, das Verschlüsseln gespeicherter Credentials, Audit-Logs und eine Pre-Public-Checkliste, damit ein Repo nie öffentlich geht mit einem Secret, das in seiner Historie vergraben ist. #### Überblick In dem Moment, in dem deine App im öffentlichen Internet ist, wird sie innerhalb von Minuten von Bots abgetastet. Du brauchst kein Security-Team, um gegen die gängigen Angriffe sicher zu sein, du brauchst eine Handvoll Essentials, konsequent angewandt: deckle jeden öffentlichen Endpunkt mit einem Rate Limit, sperre mit einer CSP ab, was der Browser ausführen wird, verschlüssele die Credentials, die du speicherst, logge, wer was getan hat, und schalte nie ein Repo auf öffentlich, ohne seine Historie auf Secrets zu auditieren. Diese Lektion macht jedes davon konkret. #### Was du lernst Du lernst, öffentlichen Endpunkten Rate Limits hinzuzufügen, einen Content-Security-Policy-Header zu setzen, gespeicherte Credentials at rest zu verschlüsseln, ein nützliches Audit-Log zu führen und ein Pre-Public-Repo-Audit zu fahren, das Secrets fängt, die sich in alten Commits verstecken. Das sind die Massnahmen, die ein Hobbyprojekt von etwas trennen, auf das du verantwortungsvoll echte Nutzer richten kannst. #### Voraussetzungen Die Secrets-Lektionen aus Kurs 1 und 3, da mehrere Massnahmen hier darauf aufbauen, Secrets in Umgebungsvariablen und aus dem Code herauszuhalten. Eine deploytе App mit mindestens einem öffentlichen Endpunkt oder Formular macht die Lektion konkret, aber du kannst alles ab dem ersten Commit auf dein nächstes Projekt anwenden. #### Das Problem Drei Versäumnisse schaden kleinen Bauenden immer wieder. Erstens: ein ungeschützter Endpunkt wird gehämmert - ein Login-Formular brute-forced, ein Kontaktformular zugespammt oder ein KI-Endpunkt in einer Schleife aufgerufen, bis deine Anbieter-Rechnung explodiert. Zweitens: ein gespeicherter API-Key oder ein Passwort sitzt im Klartext, sodass ein einziges Datenbank-Leak einem Angreifer alles in die Hand gibt. Drittens, und am häufigsten: eine Gründerin macht ein Repo öffentlich, um es zu teilen, und ein vor zwei Jahren committetes Secret ist jetzt für immer im offenen Internet. Jedes ist mit einer Gewohnheit vermeidbar. #### Rate-limite jeden öffentlichen Endpunkt Ein Rate Limit deckelt, wie oft ein einzelner Client einen Endpunkt in einem Zeitfenster treffen kann. Es ist die günstigste, hebelstärkste Security-Kontrolle, die du hast, und jeder Endpunkt, den ein Fremder erreichen kann, braucht eines: Login, Signup, Passwort-Reset, Kontaktformulare und vor allem jeder Endpunkt, der dich pro Aufruf Geld kostet, etwa einer, der ein LLM auslöst. Limitiere per IP für anonymen Traffic und per Nutzer oder API-Key für authentifizierten Traffic. Wenn das Limit überschritten wird, gib ein 429 zurück und stopp. ```typescript // Ein minimaler Fixed-Window-Limiter. In Produktion nutze einen geteilten Store // (Redis, Upstash oder deine DB), damit er über mehrere Server hinweg funktioniert. const hits = new Map() export function rateLimit(key: string, max = 10, windowMs = 60_000) { const now = Date.now() const entry = hits.get(key) if (!entry || now > entry.resetAt) { hits.set(key, { count: 1, resetAt: now + windowMs }) return { ok: true } } if (entry.count >= max) return { ok: false, retryAfter: entry.resetAt - now } entry.count += 1 return { ok: true } } // In deinem Handler: // const limit = rateLimit(`login:${ip}`, 5, 60_000) // if (!limit.ok) return new Response('Too many requests', { status: 429 }) ``` Eine Rate-Limiter-Skizze - deckle per IP für anonymen Traffic, per Nutzer oder Key für authentifizierten #### CSP-Header und gespeicherte Credentials verschlüsseln Eine Content Security Policy sagt dem Browser genau, welche Quellen für Scripts, Styles und Bilder er laden darf. Es ist deine stärkste Verteidigung gegen Cross-Site-Scripting: selbst wenn ein Angreifer ein script-Tag einschleust, weigert sich der Browser, es auszuführen, weil die Quelle nicht auf deiner Allowlist steht. Starte streng und lockere nur, was du musst. Separat sollte alles Sensible, das du speicherst - ein Drittanbieter-API-Key, ein OAuth-Token, ein Nutzer-Secret - at rest verschlüsselt sein, sodass ein Datenbank-Einbruch Chiffretext liefert, keine funktionierenden Credentials. Der Verschlüsselungs-Key selbst lebt in einer Umgebungsvariable, nie in der Datenbank, die er schützt. ```text Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; connect-src 'self' https://api.your-provider.com; frame-ancestors 'none'; base-uri 'self' ``` Eine CSP zum Start - standardmässig self, dann nur erlauben, was deine App wirklich braucht - default-src 'self' heisst: sofern nicht anders angegeben, nur von deiner eigenen Domain laden. - connect-src kontrolliert, welche APIs der Browser aufrufen darf - liste nur deine echten Backends. - frame-ancestors 'none' stoppt andere Sites, deine in einem iframe einzubetten (Clickjacking). - Verschlüssele gespeicherte Secrets mit einer Library, nicht von Hand; halt den Key in einer Env-Var, rotiere ihn, falls er je leakt. #### Audit-Logs: wissen, wer was getan hat Wenn etwas schiefgeht - eine Erstattung ausgestellt, ein Account gelöscht, ein Plan herabgestuft - musst du beantworten "wer hat das getan, wann und von wo". Ein Audit-Log ist eine nur-anhängende Aufzeichnung sensibler Aktionen: der Akteur, die Aktion, das Ziel, ein Zeitstempel und die Quell-IP. Es ist nicht dasselbe wie deine Anwendungs-Logs; es ist eine bewusste Spur für Security und Verantwortlichkeit. Logge jede Aktion, die Geld bewegt, Berechtigungen ändert oder die Daten eines anderen Nutzers berührt. Logge nie die Secrets selbst, nur, dass die Aktion passiert ist. #### Die Pre-Public-Repo-Checkliste Das ist die, die am härtesten beisst. Einen Key aus deinem neuesten Commit zu löschen entfernt ihn nicht aus der Historie - er sitzt immer noch in einem alten Commit, den jeder lesen kann, sobald das Repo öffentlich geht. Bevor du irgendein Repo von privat auf öffentlich schaltest, geh diese Checkliste jedes Mal durch. Wenn du ein Secret in der Historie findest, ist der einzige sichere Zug, dieses Secret als kompromittiert zu behandeln: rotiere es sofort, dann scrubbe die Historie. - Scanne die volle Historie auf Secrets, nicht nur die aktuellen Dateien. Nutze ein Tool wie gitleaks oder trufflehog: gitleaks detect --source . fängt Keys, Tokens und Passwörter über jeden Commit. - Bestätige, dass .env und jede Secret-Datei in .gitignore sind und nie committet wurden. - Prüfe auf hardcodete Keys, interne URLs, Kundendaten und Credentials in Code und Kommentaren. - Wenn je ein Secret committet wurde: rotiere es zuerst (nimm an, es ist schon öffentlich), dann schreib die Historie um, um es zu entfernen, bevor du öffentlich gehst. - Erst nach einem sauberen Scan schaltest du das Repo auf öffentlich. ```bash # Audite die ganze Git-Historie auf geleakte Secrets, bevor du öffentlich gehst gitleaks detect --source . --verbose # Wenn etwas gefunden wird, ROTIERE das Secret zuerst, dann scrubbe die Historie. ``` Lass das vor jedem Privat-zu-Öffentlich-Wechsel laufen - die Historie überlebt eine Löschung #### Typische Fehler Die wiederkehrenden: einen KI- oder E-Mail-Endpunkt ohne Rate Limit ausliefern und mit einer fünfstelligen Rechnung aufwachen; Drittanbieter-Tokens im Klartext speichern, sodass ein Leak jeden verbundenen Account kompromittiert; die CSP überspringen, weil sie fummelig ist, und dann ein XSS schlucken; und der Klassiker - ein Repo auf öffentlich schalten, um "das Projekt zu teilen", ohne die Historie zu auditieren, und einen Key leaken, der seit Monaten dort liegt. Jedes wird durch eine Gewohnheit in dieser Lektion verhindert. #### Business-ROI Security ist unsichtbar, wenn sie funktioniert, und katastrophal, wenn nicht. Ein geleakter Key kann ein Budget über Nacht leersaugen, ein Einbruch in gespeicherte Credentials kann ein Unternehmen beenden, und ein einziges Public-Repo-Leak hat Gründer echtes Geld und echte Kunden gekostet. Die Essentials hier kosten dich einen Nachmittag zum Aufsetzen und laufen dann für immer. Für ein agent-getriebenes Team zählt das doppelt: Agents generieren Endpunkte schnell, also muss die Disziplin von "jeder öffentliche Endpunkt bekommt ein Rate Limit, jedes Secret wird verschlüsselt, jedes Repo wird auditiert" eine Regel sein, der der Agent folgt, nicht etwas, an das du dich erinnerst. #### Checkliste Bestätige jedes davon, bevor du echte Nutzer auf irgendetwas richtest, das du gebaut hast. - Jeder öffentliche und geldausgebende Endpunkt hat ein Rate Limit, das bei Überschreitung 429 zurückgibt. - Ein Content-Security-Policy-Header ist gesetzt und so streng, wie deine App es erlaubt. - Gespeicherte Credentials und Tokens sind at rest verschlüsselt, mit dem Key in einer Env-Var. - Du hast einen Vollhistorie-Secret-Scan vor jedem öffentlichen Repo gefahren und alles Gefundene rotiert. #### Ressourcen Halt gitleaks oder trufflehog installiert und füge den Historie-Scan zu deinem Pre-Public-Ritual hinzu. Die OWASP Top 10 und MDNs CSP-Referenz sind die zeitlosen Quellen, wenn du Tiefe brauchst. Pack "rate-limite diesen Endpunkt" und "verschlüssele dieses gespeicherte Secret" in deine Projektregeln, sodass Agents sie ungefragt anwenden. #### Deine Aufgabe Füge einem echten Endpunkt ein Rate Limit hinzu und bestätige, dass es 429 zurückgibt, wenn du es überschreitest. Setz einen CSP-Header auf deine App und behebe, was er bricht, bis die Seite unter einer strengen Policy funktioniert. Dann fahr gitleaks gegen eines deiner Repos und lies den Output - selbst ein sauberes Ergebnis lehrt dich, der Prüfung zu trauen, bevor du je öffentlich gehst. #### Nächste Lektion Sicher und gehärtet, behandelt die nächste Lektion Recht und Compliance: DSGVO, rechtskonforme Cookie-Einwilligung inklusive Global Privacy Control und die US- und Schweizer Datenschutzgesetze, erklärt ohne Kopfweh. ### 5.3 Recht und Compliance: DSGVO, Cookie-Einwilligung, Datenschutzgesetze ohne Tränen - Kanonische URL: https://agenticschool.dev/de/kurse/quality-security-agent-first/legal-and-compliance-gdpr-cookie-consent-privacy-laws-without-tears - Dauer: 26 min Zusammenfassung: Beliebige Nutzerdaten zu sammeln bringt rechtliche Pflichten. Diese Lektion macht sie handhabbar: die Landschaft aus DSGVO, UK GDPR, Schweizer revFADP und CCPA/CPRA in klaren Worten, Rechtsgrundlage und echte Einwilligung, Cookie-Banner richtig gemacht inklusive Global Privacy Control, deine Datenschutzerklärung und dein Impressum, Datenexport- und Löschrechte und wann du tatsächlich einen AVV brauchst. #### Überblick Datenschutzrecht klingt erschreckend und ist meist gesunder Menschenverstand, aufgeschrieben. Sammle nur, was du brauchst, sag den Leuten, was du sammelst und warum, hol echte Erlaubnis, bevor du sie trackst, und lass sie ihre Daten auf Anfrage sehen und löschen. DSGVO, die UK GDPR, die Schweizer revFADP und die US-Bundesstaatengesetze teilen alle diesen Kern. Diese Lektion übersetzt die Landschaft in eine kurze Liste von Dingen, die du tatsächlich baust, mit dem schlichten Hinweis, dass nichts davon Rechtsberatung ist - im Zweifel frag eine Anwältin. #### Was du lernst Du lernst den geteilten Kern der grossen Datenschutzgesetze, was "Rechtsgrundlage" und "echte Einwilligung" in der Praxis bedeuten, wie du ein Cookie-Banner baust, das compliant ist (inklusive der Ehrung von Global Privacy Control), was deine Datenschutzerklärung und dein Impressum enthalten müssen, wie du Datenexport- und Löschanfragen handhabst und den einfachen Test dafür, wann du einen Auftragsverarbeitungsvertrag brauchst. #### Voraussetzungen Ein Produkt, das beliebige Nutzerdaten sammelt - eine E-Mail-Anmeldung, ein Account, Analytics - aus Kurs 3 oder deinem eigenen Projekt, da Compliance davon handelt, wie du diese Daten handhabst. Kein juristischer Hintergrund nötig. Diese Lektion ist praktische Orientierung, keine Rechtsberatung; für alles Heikle lass eine Fachperson deine konkrete Situation prüfen. #### Das Problem Die meisten kleinen Bauenden tun eines von zwei falschen Dingen. Sie ignorieren Datenschutzrecht entweder ganz, bis ein Nutzer oder eine Behörde eine unbequeme Frage stellt, oder sie erstarren, überzeugt, Compliance brauche eine Rechtsabteilung, die sie sich nicht leisten können. Die Wahrheit liegt dazwischen: eine Solo-Gründerin kann wirklich compliant sein, indem sie eine Handvoll Prinzipien befolgt und ein paar Standard-Seiten und ein funktionierendes Einwilligungs-Banner ausliefert. Die Kosten, es falsch zu machen - Bussen, Takedowns, verlorenes Vertrauen - sind weit höher als der Nachmittag, den es braucht, es richtig zu machen. #### Die Landschaft in klaren Worten Du musst nicht jedes Gesetz auswendig lernen. Sie reimen sich. Bau auf den strengsten gemeinsamen Nenner - effektiv DSGVO plus US-Opt-out-Rechte - und du bist fast überall abgedeckt. - DSGVO (EU) und UK GDPR: die strenge Basis. Du brauchst eine Rechtsgrundlage, um personenbezogene Daten zu verarbeiten, musst transparent sein, musst minimieren, was du sammelst, und musst Auskunfts- und Löschrechte ehren. Gilt, sobald du EU- oder UK-Nutzer hast, egal, wo du sitzt. - Schweizer revFADP: das revidierte Schweizer Bundesgesetz über den Datenschutz. Eng an der DSGVO ausgerichtet, sodass das Erfüllen der DSGVO es weitgehend abdeckt. Relevant, wenn du Schweizer Nutzer bedienst. - CCPA und CPRA (Kalifornien) und die Welle anderer US-Bundesstaatengesetze (Virginia, Colorado und mehr): verbraucherrechtsbasiert. Aufgebaut um das Recht zu wissen, zu löschen und sich gegen den Verkauf oder das Teilen personenbezogener Daten zu entscheiden. - Praktische Regel: gestalte nach DSGVO, füge ein klares Opt-out für US-Nutzer hinzu, und du erfüllst den strengsten gemeinsamen Nenner über alle hinweg. #### Rechtsgrundlage und echte Einwilligung Unter der DSGVO musst du für jedes bisschen personenbezogener Daten, das du verarbeitest, eine Rechtsgrundlage haben. Für ein kleines Produkt sind die zwei, die du am meisten nutzt, "Vertrag" (du brauchst die Daten, um den Dienst zu erbringen, für den der Nutzer sich angemeldet hat, etwa seine E-Mail, um seinen Account zu betreiben) und "Einwilligung" (der Nutzer hat aktiv zugestimmt, was du für Marketing und nicht-essenzielles Tracking brauchst). Echte Einwilligung ist spezifisch, informiert, freiwillig gegeben und so leicht zu widerrufen wie zu geben. Eine vorangekreuzte Box ist keine Einwilligung. Ein Banner, das nur "Akzeptieren" bietet, ist keine Einwilligung. Marketing in die Anmeldebedingungen zu bündeln ist keine Einwilligung. Wenn du nicht ehrlich sagen kannst, dass der Nutzer gewählt hat, hast du sie nicht. #### Cookie-Einwilligung richtig gemacht (inklusive Global Privacy Control) Die Regel ist einfach und Leute brechen sie ständig: nicht-essenzielle Cookies und Tracker - Analytics, Ads, alles, was den Nutzer profiliert - dürfen nicht laden, bis der Nutzer zustimmt. Essenzielle Cookies, die die Site funktionieren lassen, brauchen keine Einwilligung. Ein compliantes Banner gibt "Alle akzeptieren" und "Alle ablehnen" gleiche Prominenz, lässt den Nutzer pro Kategorie wählen und merkt sich die Wahl. Moderne Best Practice ehrt auch Global Privacy Control: wenn der Browser einer Besucherin das GPC-Signal sendet, behandle es automatisch als gültiges Opt-out und zeig nicht mal ein nervendes Banner für Tracking, das sie schon abgelehnt hat. ```typescript // Ehre Global Privacy Control, bevor du irgendein Tracking-Banner zeigst. const gpc = (navigator as Navigator & { globalPrivacyControl?: boolean }) .globalPrivacyControl if (gpc) { // Als gueltiges Opt-out behandeln: keine Tracker laden, nicht nerven. setConsent({ analytics: false, marketing: false }) } else if (!hasStoredConsent()) { showConsentBanner() // Alle ablehnen muss so leicht sein wie Alle akzeptieren. } // Analytics-/Marketing-Scripts NUR nach explizitem Opt-in laden. if (getConsent().analytics) loadAnalytics() ``` Ehre GPC, sperre Tracker hinter Opt-in und mach Alle ablehnen so leicht wie Alle akzeptieren #### Policy, Impressum und Nutzerrechte Ein paar Standard-Teile machen dich compliant und vertrauenswürdig. Sie sind langweilig zu schreiben und du machst es nur einmal. - Datenschutzerklärung: in klarer Sprache sagen, was du sammelst, warum, die Rechtsgrundlage, mit wem du es teilst (deine Auftragsverarbeiter), wie lange du es behältst und wie man dich kontaktiert oder sich beschwert. Verlinke sie in deinem Footer. - Impressum / rechtlicher Hinweis: erforderlich an Orten wie Deutschland, Österreich und der Schweiz. Nenne, wer hinter der Site steht - Name, Adresse und Kontakt -, damit Besucher wissen, mit wem sie es zu tun haben. - Auskunfts- und Löschrecht: ein Nutzer kann eine Kopie seiner Daten verlangen und dich bitten, sie zu löschen. Bau einen Weg, beides zu ehren. Selbst ein manueller Prozess ist bei kleinem Massstab in Ordnung, aber du musst es tatsächlich innerhalb der gesetzlichen Frist tun. - Datenexport: sei in der Lage, einem Nutzer seine Daten in einem portablen Format zu übergeben. Wenn deine Datenbank sauber ist (Kurs 3), ist das eine Query, kein Projekt. #### Wann du einen AVV brauchst Ein Auftragsverarbeitungsvertrag (AVV) ist ein Vertrag zwischen dir und einem Unternehmen, das in deinem Auftrag personenbezogene Daten verarbeitet - dein Hosting, deine Datenbank, dein E-Mail-Versender, dein Analytics-Anbieter. Unter der DSGVO brauchst du einen AVV mit jedem solchen Auftragsverarbeiter. Die gute Nachricht: seriöse Anbieter veröffentlichen einen Standard-AVV, den du einfach akzeptierst, oft automatisch in ihren Bedingungen. Der praktische Test ist "berührt dieser Dritte die personenbezogenen Daten meiner Nutzer?" Wenn ja, finde und akzeptiere seinen AVV und liste ihn als Auftragsverarbeiter in deiner Datenschutzerklärung. Wenn nur du die Daten berührst, brauchst du keinen. #### Typische Fehler Die häufigen: Google Analytics oder Ad-Pixel laden, bevor der Nutzer einwilligt (der mit Abstand häufigste Verstoss); ein Cookie-Banner mit einem grossen "Akzeptieren" und einem versteckten oder fehlenden "Ablehnen"; GPC und andere Browser-Signale ignorieren; keine Datenschutzerklärung oder eine kopierte, die über das, was du tatsächlich sammelst, lügt; und AVVs mit den Anbietern vergessen, auf die du dich verlässt. Keiner ist schwer zu beheben, und alle sind für eine Behörde oder einen Wettbewerber leicht zu erkennen. #### Business-ROI Compliance ist beides, Risikominderung und ein Vertrauenssignal. Die Kehrseite, sie zu ignorieren, ist real - DSGVO-Bussen skalieren mit dem Umsatz, und eine verpatzte Datenanfrage kann zu einer öffentlichen Beschwerde werden. Die Oberseite ist leiser, aber real: eine klare Datenschutzerklärung und ein ehrlicher Einwilligungs-Flow sagen Kunden, dass du ihre Daten ernst nimmst, was jedes Jahr mehr zählt. Bau es von Anfang an ein und es kostet einen Nachmittag; rüste es unter Druck nach, nachdem du Nutzer hast, und es kostet eine schmerzhafte Migration. Mach es früh. #### Checkliste Geh diese für jedes Produkt durch, das Nutzerdaten sammelt, bevor du es bewirbst. - Du kannst die Rechtsgrundlage für jede Datenkategorie nennen, die du sammelst. - Kein nicht-essenzieller Tracker lädt vor dem Opt-in, und GPC wird automatisch geehrt. - Dein Cookie-Banner bietet Alle ablehnen so leicht wie Alle akzeptieren und merkt sich die Wahl. - Eine echte Datenschutzerklärung und (wo erforderlich) ein Impressum sind in deinem Footer verlinkt. - Du kannst die Daten eines Nutzers auf Anfrage exportieren und löschen, und du hast einen AVV mit jedem Auftragsverarbeiter. #### Ressourcen Die offiziellen Seiten von ICO (UK), EDSA (EU), dem Schweizer EDÖB und der California Privacy Protection Agency sind die massgeblichen, zeitlosen Referenzen, und sie veröffentlichen Leitfäden in klarer Sprache für kleine Unternehmen. Eine seriöse Consent-Management-Plattform handhabt das Banner und GPC für dich, wenn du es lieber nicht baust. Für alles Heikle ist eine kurze Beratung mit einer Datenschutzanwältin gut investiertes Geld. Diese Lektion ist Orientierung, keine Rechtsberatung. #### Deine Aufgabe Auditiere eines deiner Projekte: liste jedes Stück personenbezogener Daten, das es sammelt, und die Rechtsgrundlage für jedes. Dann prüfe deinen Einwilligungs-Flow - feuert irgendein Tracker vor dem Opt-in, und funktioniert Alle ablehnen wirklich? Behebe, was scheitert. Wenn du noch keine Datenschutzerklärung hast, entwirf eine in klarer Sprache und verlinke sie in deinem Footer. #### Nächste Lektion Compliant und sicher, bringt dich die nächste Lektion an die Auffindbarkeit: klassisches SEO plus GEO/AEO, llms.txt und strukturierte Daten, der Favicon-im-SERP-Trick und die System-aus-Websites-Strategie, sodass dich sowohl Google als auch KI empfehlen. ### 5.4 SEO und GEO/AEO: von Google UND von KI empfohlen werden - Kanonische URL: https://agenticschool.dev/de/kurse/quality-security-agent-first/seo-and-geo-aeo-getting-recommended-by-google-and-by-ai - Dauer: 28 min Zusammenfassung: Auffindbarkeit hat jetzt zwei Kanäle: klassische Suche und KI-Assistenten. Diese Lektion behandelt die SEO-Grundlagen - Titel, Beschreibungen, Sitemaps, Search Console - plus GEO/AEO: llms.txt, sauberer Markdown-Content, strukturierte Daten und zitierfähig zu sein. Sie enthält den Favicon-im-SERP-Trick und die System-aus-Websites-Strategie, viele Nischen-Sites statt einer zu bauen. #### Überblick Zwanzig Jahre lang hiess gefunden zu werden, bei Google zu ranken. Jetzt wird die Hälfte deiner künftigen Kunden dich über einen KI-Assistenten entdecken, der das Web liest, ein paar Quellen auswählt und sie empfiehlt. Du musst beide Kanäle gewinnen, und die gute Nachricht ist, dass sie dasselbe belohnen: klaren, gut strukturierten, vertrauenswürdigen Content, den eine Maschine lesen und zitieren kann. Diese Lektion behandelt die SEO-Grundlagen und die neue GEO/AEO-Schicht - llms.txt, strukturierte Daten, Zitierfähigkeit - plus zwei Taktiken, die über ihrem Gewicht boxen: den Favicon-Trick und das System aus Websites. #### Was du lernst Du lernst die SEO-Grundlagen, die weiter zählen - Titel, Meta-Beschreibungen, Sitemaps und Search Console -, die SERP-Details wie Favicons, die die Click-Through-Rate heben, wie GEO/AEO und llms.txt deinen Content für KI-Assistenten zitierfähig machen, die Rolle von sauberem Markdown und strukturierten Daten und die System-aus-Websites-Strategie, viele fokussierte Sites statt einer ausufernden zu betreiben. #### Voraussetzungen Eine live, indexierte Site und die Search-Console-Grundlagen aus Kurs 3, da Auffindbarkeit darauf aufbaut, überhaupt indexierbar zu sein. Du solltest dich auch an die agentischen Oberflächen-Konzepte aus Kurs 4 erinnern - llms.txt und sauberer, maschinenlesbarer Content sind, wo SEO und agentisches Design sich treffen. #### Das Problem Zwei Fehlermodi sind häufig. Der erste ist, etwas Gutes zu bauen, das niemand finden kann, weil die Grundlagen fehlen - keine beschreibenden Titel, keine Sitemap, nie in der Search Console verifiziert. Der zweite ist neuer und gefährlicher: eine Site, die nur für Google optimiert ist und für KI-Assistenten unsichtbar, sodass du, wenn jemand Claude oder ChatGPT nach einer Empfehlung in deinem Feld fragt, nie erwähnt wirst. Einen Kanal zu gewinnen und den anderen zu ignorieren lässt die Hälfte deiner Auffindbarkeit auf dem Tisch liegen. #### SEO-Grundlagen, die weiter zählen Das Fundament hat sich nicht geändert: hilf sowohl Menschen als auch Crawlern, jede Seite zu verstehen, und verdiene Vertrauen. Bring diese in Ordnung, bevor du irgendetwas Cleveres jagst. - Title-Tag: eindeutig pro Seite, rund 50 bis 60 Zeichen, beginnend mit den Wörtern, die Leute tatsächlich suchen. Das ist deine Überschrift in den Ergebnissen und dein grösster Hebel auf die Click-Through-Rate. - Meta-Beschreibung: grob 140 bis 158 Zeichen, geschrieben, um den Klick zu verdienen, nicht um Keywords zu stopfen. Es ist deine Anzeige unter dem Titel. - Saubere Struktur: ein H1, logische Überschriften, schnelle Seiten, mobilfreundlich, beschreibende URLs. Crawler belohnen Klarheit. - Sitemap und Search Console: reiche eine XML-Sitemap ein und verifiziere die Site in der Google Search Console, damit du Impressions, Klicks und siehst, für welche Suchanfragen du rankst. - Vertrauen: echter Content, keine dünnen Seiten, interne Links und eingehende Links von Sites, die zählen. #### Der Favicon-im-SERP-Trick Hier ist ein kleiner, unterschätzter Vorteil. Auf Mobil und zunehmend auf Desktop zeigt Google das Favicon deiner Site neben deinem Suchergebnis. Ein knackiges, unverwechselbares, wiedererkennbares Favicon lässt deinen Eintrag in einer Wand aus Text herausstechen und hebt messbar die Click-Through-Rate, was wiederum Relevanz signalisiert und deinem Ranking helfen kann. Die meisten Leute liefern ein Standard- oder unscharfes Icon aus und lassen das liegen. Mach ein sauberes Favicon in den Grössen, die Google erwartet, referenziere es korrekt in deinen Head-Tags und bestätige, dass es tatsächlich angezeigt wird. Es sind zehn Minuten Arbeit für einen dauerhaften Vorteil bei jedem Ergebnis, für das du je rankst. #### GEO/AEO: KI dazu bringen, dich zu empfehlen GEO (Generative Engine Optimisation) und AEO (Answer Engine Optimisation) drehen sich darum, die Quelle zu sein, die ein KI-Assistent zum Lesen und Zitieren wählt. Die Mechanik unterscheidet sich von Google, aber der Geist ist derselbe: sei lesbar, sei strukturiert, sei vertrauenswürdig, sei eindeutig. KI-Assistenten bevorzugen Content, der die Frage direkt beantwortet, Fakten schlicht angibt und leicht zu parsen ist. Das mit Abstand nützlichste neue Artefakt ist llms.txt - eine schlichte Markdown-Karte deiner Site, die Assistenten auf deinen besten, saubersten Content verweist, so wie robots.txt und sitemap.xml Such-Crawler leiten. ```text # Your Company > One clear sentence on what you do and who it is for. ## Core pages - [Pricing](https://example.com/pricing.md): plans and what each includes - [How it works](https://example.com/how-it-works.md): the product in plain steps ## Guides - [Getting started](https://example.com/guides/start.md): first 10 minutes - [API reference](https://example.com/api.md): endpoints and examples ## About - [Founder](https://example.com/about.md): who is behind this and why ``` /llms.txt - eine Markdown-Karte, die KI-Assistenten auf deinen saubersten Content verweist - Serviere eine saubere .md-Version jeder wichtigen Seite, damit Assistenten Content bekommen, ohne durch dein Layout zu waten. - Füge strukturierte Daten (JSON-LD) für Artikel, Produkte, FAQs und deine Organisation hinzu, sodass sowohl Google als auch KI Fakten eindeutig parsen. - Schreib antwort-zuerst: beginne mit der direkten Antwort, dann das Detail. Assistenten zitieren den klaren Satz, nicht den vergrabenen. - Gib konkrete Fakten - Preise, Specs, Daten - schlicht an, denn das ist, was zitiert wird. #### Die System-aus-Websites-Strategie Hier ist eine Strategie, die der Gründer dieser School bewusst nutzt: statt alles in eine breite Site zu pferchen, betreib ein System aus fokussierten Nischen-Sites. Dreizehn eng thematisierte Sites, jede mit einem spezifischen Thema oder Publikum, schlagen eine Site, die versucht, für alles zu ranken. Jede Site kann die klarste, autoritativste Antwort in ihrer engen Nische sein, was genau das ist, was sowohl Google als auch KI-Assistenten belohnen. Die Sites verlinken untereinander, wo es dem Leser wirklich hilft, sodass Autorität sich über das System aufaddiert, statt dass jede Property bei null startet. Mit Agents ist das Aufstellen und Pflegen einer neuen fokussierten Site günstig, was diese Strategie weit praktischer macht, als sie war, als jede Site ein Team bedeutete. - Eine Site, eine klare Nische: leichter, die definitive Antwort zu werden, als eine Generalisten-Site es je kann. - Spezifität gewinnt Zitate: KI-Assistenten bevorzugen die fokussierte Quelle, die offensichtlich zur Frage passt. - Verlinke mit Absicht: verbinde Sites, wo es dem Leser hilft, sodass Autorität und Auffindbarkeit sich aufaddieren. - Agents machen es günstig: das Gerüst und die Pflege vieler kleiner Sites ist jetzt ein Nachmittag, keine Einstellung. #### Typische Fehler Die wiederkehrenden: doppelte oder fehlende Title-Tags, sodass jede Seite gleich in den Ergebnissen aussieht; keyword-gestopfte Beschreibungen, die wie Spam lesen und die Click-Through-Rate killen; nie in der Search Console verifizieren, sodass du im Blindflug bist; keine llms.txt und kein sauberes Markdown ausliefern, sodass KI-Assistenten dich überspringen; und deine Antwort drei Absätze tief vergraben, wo kein Assistent sie je zitieren wird. Beginne mit der Antwort, halt Seiten sauber und füttere sowohl Crawler als auch Assistenten. #### Business-ROI Auffindbarkeit verzinst sich und ist nahezu kostenlos, sobald sie funktioniert. Eine Seite, die rankt oder zitiert wird, bringt jeden Tag Besucher ohne laufende Kosten, was der günstigste Akquisekanal ist, den es gibt. Der Wandel zur KI-Auffindbarkeit ist die Chance: die meisten Wettbewerber optimieren noch nur für Google, also werden die Bauenden, die ihren Content jetzt zitierfähig machen, den KI-Empfehlungskanal besitzen, bevor er voll wird. Von einem Assistenten empfohlen zu werden, dem Millionen Menschen vertrauen, ist mehr wert als ein Google-Ranking auf Seite zwei, und gerade jetzt ist es weit offen. #### Checkliste Bestätige diese für jede Site, die du durch beide Kanäle auffindbar willst. - Jede Seite hat einen eindeutigen, such-geführten Titel und eine klickwürdige Meta-Beschreibung. - Eine Sitemap ist eingereicht und die Site ist in der Search Console verifiziert. - Ein knackiges Favicon wird neben deinem Ergebnis angezeigt, und strukturierte Daten sind vorhanden. - Eine llms.txt kartiert deinen besten Content und saubere .md-Versionen werden ausgeliefert. - Deine wichtigsten Antworten beginnen mit der Antwort, nicht mit der Vorgeschichte. #### Ressourcen Google Search Central und die Search-Console-Dokumentation sind die zeitlosen SEO-Referenzen; der llms.txt-Vorschlag und schema.org sind die GEO/AEO-Referenzen. Die Going-Live-Lektion in Kurs 3 behandelt das Search-Console-Setup, falls deins nicht erledigt ist. Beobachte deine Search-Console-Impressions und -Click-Through über Wochen - es ist die einzige Feedback-Schleife, die dir sagt, was tatsächlich funktioniert. #### Deine Aufgabe Wähle eine echte Seite und schreib ihren Titel und ihre Meta-Beschreibung neu, sodass sie mit dem beginnen, was Leute suchen, und den Klick verdienen. Liefere ein sauberes Favicon aus und bestätige, dass es in einem Suchergebnis erscheint. Dann schreib eine erste llms.txt für die Site, die deine besten Seiten kartiert. Du fütterst jetzt beide Kanäle - prüfe die Search Console in zwei Wochen, um den Effekt zu sehen. #### Nächste Lektion Von KI auffindbar zu sein führt direkt zur nächsten Idee: Produkte zu gestalten, die KI selbst gerne nutzt, wo die API das Produkt ist und die UI fast nebensächlich. ### 5.5 Agent-First-Produkte: warum KI deine API lieben muss - Kanonische URL: https://agenticschool.dev/de/kurse/quality-security-agent-first/agent-first-products-why-ai-must-love-your-api - Dauer: 26 min Zusammenfassung: Die nächste Welle von Nutzern umfasst KI-Agents. Ein Produkt, dessen API sauber, dokumentiert und eine Freude zum Aufrufen ist, wird von Agents und den Menschen, die sie lenken, übernommen. Diese Lektion behandelt agent-first Design und die API-über-UI-Philosophie anhand der BizCollect-Lektion des Gründers: OpenAPI-Docs, vorhersehbare Fehler, Self-Service-API-Keys und die Idee, dass KI in deine API verliebt sein sollte. #### Überblick Dreissig Jahre lang haben wir Produkte für Menschen gestaltet, die auf Bildschirme klicken. Diese Annahme bricht. Immer öfter ist das Ding, das dein Produkt nutzt, ein KI-Agent, der für eine Person handelt, und es sieht nie deine schöne UI - es liest deine Docs und ruft deine API auf. Ein agent-first Produkt behandelt die API als Hauptoberfläche und die UI als nur einen Client davon. Diese Lektion macht den Fall, zeigt, wie eine grossartige agent-zugewandte API aussieht, und erzählt die BizCollect-Geschichte, in der der Gründer dieser School es auf die harte Tour gelernt hat. #### Was du lernst Du lernst, warum Agents zu einer Kundenbasis werden, für die zu gestalten sich lohnt, was eine API zu einer Freude für einen Agent macht - auffindbare OpenAPI-Docs, vorhersehbare Fehler, Self-Service-Keys - und die konkreten Lektionen aus dem API-first-Bau von BizCollect. Du gehst hinaus und kannst jedes Produkt, das du baust, bewerten, indem du fragst "würde ein Agent das lieben oder dagegen kämpfen?". #### Voraussetzungen Die API- und Architektur-Lektionen aus früheren Kursen plus die Lektionen zur agentischen Oberfläche und Autonomie aus Kurs 4, da agent-first Design die architektonische Haltung ist, auf die diese Ideen zeigen. Ein Gefühl dafür, was ein OpenAPI-Spec ist, hilft, aber diese Lektion erklärt genug, um das Prinzip zu vermitteln. #### Das Problem Gründer stecken Monate in eine glatte Oberfläche und behandeln die API als Nachgedanken - undokumentiert, inkonsistent, hinter einem Verkaufsgespräch versperrt. Dann kommt ein Agent an, kann nicht herausfinden, wie er sich authentifiziert, trifft auf einen Fehler, der eine vage HTML-Seite zurückgibt, gibt auf und empfiehlt einen Wettbewerber, dessen API er tatsächlich lesen konnte. Den Agent kümmert nicht, wie hübsch dein Dashboard ist. Wenn er dich nicht sauber aufrufen kann, existierst du für ihn schlicht nicht. Während Agents zu denen werden, die Tools wählen, ist das eine existenzielle Lücke. #### Agents werden zum Kunden Denk darüber nach, wie Arbeit zunehmend passiert: eine Person sagt einem Agent "finde mir einen Lieferanten und platziere die Bestellung", "zieh diese Daten und leg sie in mein Sheet", "buche die günstigste Option, die passt". Der Agent entscheidet dann, welche Dienste er aufruft. Er wählt den, den er nutzen kann - klare Docs, vorhersehbares Verhalten, Self-Service-Zugang - und überspringt die, die einen Menschen in der Schleife brauchen. Der Mensch ist weiterhin der Kunde, aber der Agent ist der Nutzer, und er hat erbarmungslosen Geschmack: er verlässt alles Reibungslastige sofort und beschwert sich nie, er geht einfach. Für diesen Nutzer zu gestalten ist der neue Wettbewerbsvorteil. #### Wie eine API aussieht, die ein Agent liebt Eine agent-freundliche API ist eine, die ein Agent entdecken, sich authentifizieren und korrekt nutzen kann, ohne dass ein Mensch die Docs für ihn liest. Das läuft auf ein paar konkrete Eigenschaften hinaus. - Auffindbar: ein veröffentlichtes OpenAPI-Spec, sodass ein Agent jeden Endpunkt, Parameter und jede Response-Form lesen kann, plus eine llms.txt, die darauf verweist. - Self-Service-Keys: ein Nutzer (oder sein Agent) kann sich anmelden und einen API-Key ohne Verkaufsgespräch bekommen. Reibung hier killt die Agent-Adoption komplett. - Vorhersehbare Fehler: konsistente Statuscodes und ein strukturierter Fehler-Body, der sagt, was schiefging und wie man es behebt, sodass ein Agent sich erholen kann statt zu raten. - Stabil und konsistent: gleiche Benennung, gleiche Formen, gleiche Auth über Endpunkte hinweg, versioniert, sodass eine Änderung nie still einen Aufrufer bricht. - Ehrliche Docs: Beispiele, die tatsächlich laufen, Defaults, die der Realität entsprechen, und kein undokumentiertes Pflichtfeld. Agents trauen dem Spec wörtlich. ```yaml openapi: 3.1.0 info: title: BizCollect API version: 1.0.0 paths: /v1/businesses: get: summary: Search verified business records parameters: - name: region in: query required: true schema: { type: string } responses: '200': description: Matching business records '429': description: Rate limit exceeded - retry after the given seconds ``` Ein minimaler OpenAPI-Ausschnitt - das ist, was ein Agent liest, um deine API von allein zu lernen #### Vorhersehbare Fehler sind ein Feature Menschen wursteln sich durch einen verwirrenden Fehler; ein Agent braucht Struktur. Wenn etwas scheitert, gib einen konsistenten Statuscode und einen kleinen JSON-Body zurück, den der Agent parsen kann: einen stabilen Fehlercode, eine menschenlesbare Nachricht und, wo relevant, einen Hinweis, wie man sich erholt. Ein 429 sollte sagen, wie lange zu warten. Ein 400 sollte das Feld nennen, das falsch war. Ein 401 sollte sagen, der Key fehlt oder ist ungültig, nicht nur "unauthorized". Bring das in Ordnung und ein Agent korrigiert sich selbst und macht weiter; bring es falsch und er stockt oder halluziniert einen Fix. Vorhersehbare Fehler sind der Unterschied zwischen einer API, die ein Agent unbeaufsichtigt bedienen kann, und einer, die einen menschlichen Babysitter braucht. ```json { "error": { "code": "rate_limited", "message": "Too many requests. Retry after 30 seconds.", "retry_after_seconds": 30 } } ``` Ein strukturierter, erholbarer Fehler-Body, auf den ein Agent ohne Raten reagieren kann #### Die BizCollect-Lektion BizCollect, eines der eigenen Projekte des Gründers dieser School, war, wo das klick machte. Es sammelt und liefert Unternehmensdaten, und der erste Instinkt war der übliche: ein schönes Dashboard bauen, die Daten gut aussehen lassen, die API als Seitentür behandeln. Die Erkenntnis, die es änderte, war, dass fast niemand in einem Dashboard sitzen wollte - sie wollten die Daten in ihrem eigenen Workflow, zunehmend von einem Agent abgeholt. Also drehten wir es um: die API wurde das Produkt, mit einem veröffentlichten OpenAPI-Spec, Self-Service-Keys, vorhersehbaren strukturierten Fehlern und einer llms.txt, sodass Assistenten sie entdecken konnten. Die UI schrumpfte zu einem dünnen Client dieser API, nützlich für einen Menschen zum Herumstöbern, aber nicht mehr der Punkt. Die Adoption kam durch Agents und Entwickler, die in Minuten integrieren konnten, ohne je ein Gespräch zu buchen. Die Lektion verallgemeinert hart: bau die API zuerst, mach sie zu etwas, in das ein Agent sich verlieben kann, und lass die UI einer ihrer Clients sein statt des ganzen Produkts. #### Typische Fehler Die wiederkehrenden: API als Nachgedanken hinter einer polierten UI, sodass Agents dich nicht nutzen können; kein OpenAPI-Spec, sodass nichts deine Endpunkte entdecken kann; Keys hinter einem Verkaufsgespräch versperrt, was Self-Service-Adoption killt; inkonsistente oder vage Fehler, die einen Agent festfahren lassen; und Breaking Changes ohne Versionierung ausgeliefert, die still jeden Aufrufer brechen. Jeder davon ist eine geschlossene Tür zu der Kundenbasis, die am schnellsten wächst. #### Business-ROI Agent-first ist eine Distributionsstrategie, verkleidet als Architekturentscheidung. Eine API, die ein Agent in Minuten übernehmen kann, verbreitet sich durch jeden Agent und Workflow, der braucht, was du tust, mit null Vertriebsaufwand, während deine Wettbewerber noch Demos terminieren. Die Baukosten sind kaum höher - du hättest sowieso eine API gebraucht -, aber die Oberseite ist Zugang zu einer Kundenbasis, die sich aufaddiert, während Agents mehr Arbeit übernehmen. Die Gründer, die KI jetzt in ihre API verlieben, positionieren sich für die Richtung, in die Kaufentscheidungen gehen, nicht für die, wo sie waren. #### Checkliste Bewerte jedes Produkt, das du baust, gegen diese, bevor du es agent-ready nennst. - Ein veröffentlichtes OpenAPI-Spec beschreibt jeden Endpunkt, Parameter und jede Response. - Ein Nutzer oder sein Agent kann einen API-Key self-service bekommen, ohne Verkaufsgespräch. - Fehler sind konsistent, strukturiert und sagen dem Aufrufer, wie er sich erholt. - Die API ist versioniert und stabil, sodass eine Änderung nie still einen Aufrufer bricht. - Eine llms.txt und saubere Docs lassen einen Agent dich unbeaufsichtigt entdecken und übernehmen. #### Ressourcen Die OpenAPI-Spezifikation und die Stripe- und Anthropic-API-Docs sind der Goldstandard zum Studieren - lies sie, wie ein Agent es täte, und beachte, wie wenig Raten sie verlangen. Setz die Lektion zur agentischen Oberfläche aus Kurs 4 als Lesezeichen, da llms.txt und maschinenlesbare Docs sind, wo jene Lektion und diese sich treffen. Der Builds-Abschnitt zu BizCollect geht tiefer auf die Projektgeschichte ein. #### Deine Aufgabe Nimm ein Produkt oder einen Endpunkt, den du gebaut hast, und benote es, wie ein Agent es täte: könnte ein Agent deine Docs finden, einen Key ohne Mensch bekommen, dich korrekt aufrufen und sich von einem Fehler erholen - alles unbeaufsichtigt? Schreib jede Stelle auf, an der er feststecken würde, dann behebe die schlimmste. Selbst ein aufgeräumter, gut dokumentierter Endpunkt lehrt die ganze Denkweise. #### Nächste Lektion Für Agents zu gestalten wirft die offensichtliche Frage auf, wohin das alles führt. Die vorletzte Lektion zoomt heraus auf die exponentielle Kurve und die Marktchancen, die sie gerade jetzt öffnet. ### 5.6 Die exponentielle Kurve: wohin das alles führt - Kanonische URL: https://agenticschool.dev/de/kurse/quality-security-agent-first/the-exponential-curve-where-this-is-all-heading - Dauer: 24 min Zusammenfassung: Die Fähigkeit in diesem Feld verdoppelt sich grob alle paar Monate, und Menschen sind verdrahtet, linear zu fühlen, nicht exponentiell. Diese Lektion baut Intuition für diese Kurve, erklärt, warum das Planen um sie herum anders ist, und zeigt auf die Chancen, die sie schafft - Cybersecurity, Validierung und Verifikation, menschlicher Identitätsnachweis und das Verwandeln physischer Realität in digitale Daten. #### Überblick Alles in den vorherigen Kursen sitzt auf einem sich bewegenden Boden. Die Fähigkeit dieser Modelle hat sich grob alle paar Monate verdoppelt, und diese eine Tatsache bricht die Planung der meisten Leute, weil menschliche Intuition linear ist und die Kurve nicht. Diese Lektion ist der strategische Schritt zurück. Sie baut ein Gefühl für das Exponentielle, zeigt, warum "gut genug für jetzt"-Pläne schiefgehen, und kartiert, wo die dauerhaften Chancen sind - die neuen Probleme, die die Kurve selbst schneller schafft, als irgendjemand sie lösen kann. #### Was du lernst Du lernst, warum exponentieller Fortschritt so leicht zu unterschätzen ist, wie du für eine Fähigkeit planst, die sich weiter verdoppelt, statt für ein festes Ziel, und wo die grössten Marktöffnungen sind: KI-Systeme sichern, KI-Output validieren und verifizieren, beweisen, dass ein Mensch ein Mensch ist, und physische Realität in digitale Daten umwandeln. Das Ziel ist, sich vor die Kurve zu positionieren, statt auf sie zu reagieren. #### Voraussetzungen Die Lektion zu den 5 Stufen der Autonomie aus Kurs 4 und ein breites Gefühl für das ganze Programm, da diese Lektion synthetisiert statt einführt. Keine neuen Tools. Bring deine eigenen aktuellen Grenzen in den Sinn - der Punkt ist zu fragen, welche davon dauerhaft sind und welche bei der nächsten Verdopplung verdampfen. #### Das Problem Leute machen zwei entgegengesetzte Fehler über KI-Fortschritt, und beide kommen davon, die Kurve als eine gerade Linie zu fühlen. Der Pessimist sieht die heutigen Mängel - es halluziniert, es kann X nicht - und schliesst, das ganze Ding sei überhypt, ohne zu merken, dass diese Mängel temporär sind. Der Optimist nimmt an, eine Fähigkeit sei schon da, wenn sie zwei Verdopplungen entfernt ist, und baut auf Sand. Lineare Intuition macht dich in beide Richtungen falsch. Korrekt über Exponentielle nachzudenken ist eine Fähigkeit, und sie ändert, welche Wetten vernünftig aussehen. #### Das Exponentielle fühlen Die klassische Illustration: falte ein Blatt Papier fünfundvierzig Mal in der Mitte, und wenn du könntest, würde seine Dicke den Mond erreichen. Niemand fühlt das aus "falte es nochmal", weil jeder Schritt klein aussieht und die Summe unvorstellbar ist. KI-Fähigkeit verhält sich genauso. Eine Verdopplung alle paar Monate fühlt sich jedes Mal wie ein bescheidenes Update an, aber stapel eine Handvoll davon und das System am Ende ist kategorial anders als das, über das du am Anfang nachgedacht hast. Die praktische Konsequenz: jede Grenze, um die du heute herum gestaltest, hat eine kurze Haltbarkeit. Bau für die Bahn, nicht für die Momentaufnahme. - Jede Verdopplung fühlt sich inkrementell an; der kumulative Effekt nicht. Dein Bauch hinkt der Kurve immer hinterher. - Eine Fähigkeit, die heute "fast da" ist, ist oft ein paar Verdopplungen später bequem da - plan dafür, dass sie ankommt, nicht dafür, dass sie fehlt. - Umgekehrt nimm nicht an, etwas sei gelöst, bevor es das ist. Verfolge die Kurve, extrapoliere nicht aus einer einzelnen Demo. - Die ehrliche Haltung: behandle die heutigen Grenzen als temporär und die heutigen Stärken als einen Boden, der weiter steigt. #### Was das für die Planung bedeutet Wenn der Boden weiter steigt, planst du anders. Bau keinen Burggraben aus einer Fähigkeitslücke, die sich schliessen wird - "wir sind besser, weil die KI das noch nicht kann" ist ein Plan mit Verfallsdatum. Bau stattdessen dort, wo steigende Fähigkeit dich stärker macht: Workflows, Daten, Vertrauen, Distribution und Beziehungen, die sich aufaddieren, während die Modelle besser werden. Halt deine Architektur flexibel, damit du das nächste, weit bessere Modell ohne ein Rewrite einsetzen kannst (der modell-agnostische Instinkt aus Kurs 1 zahlt sich hier aus). Und neige dazu, schnell auszuliefern und zu lernen, denn die Baukosten fallen weiter, sodass die knappe Ressource zunehmend das Urteil darüber ist, was zu bauen ist, nicht die Fähigkeit, es zu bauen. #### Wo die Chancen sind Die reichsten Chancen liegen nicht darin, zu tun, was die Modelle schon gut können - das wird bei der nächsten Verdopplung zur Massenware. Sie liegen in den Problemen, die die Kurve schneller schafft, als sie sie löst. Während KI günstiger und fähiger wird, weiten sich vier Lücken, und jede ist ein Markt. - Cybersecurity: günstige, fähige KI ist ein Geschenk für Angreifer - automatisierte, skalierte, personalisierte Angriffe. Sich gegen KI-gestützte Bedrohungen zu verteidigen und die KI-Systeme zu sichern, die jetzt alle deployen, ist ein wachsender Markt ohne Decke. - Validierung und Verifikation: KI generiert Output in grossem Massstab, aber jemand muss prüfen, dass er korrekt, sicher und echt ist. Wie in Kurs 4 behandelt, ist Validierung der echte Blocker für Autonomie, was Tools, die KI-Output verifizieren, zu einer der dauerhaftesten Chancen im Feld macht. - Menschlicher Identitätsnachweis: wenn KI die Stimme, das Gesicht und das Schreiben einer Person perfekt imitieren kann, wird das Beweisen, dass ein Akteur ein echter, spezifischer Mensch ist, zu einem schweren und wertvollen Problem - für Zahlungen, Zugang, Vertrauen und Demokratie. - Physisch-zu-digitale Daten: die Modelle hungern nach frischen, realen Daten. Physische Realität - Dokumente, Inventar, Orte, Sensoren - in saubere digitale Daten umzuwandeln, die KI nutzen kann, ist eine tiefe, unterbebaute Chance. #### Sich vor die Kurve positionieren Der strategische Zug ist, für das zu bauen, wohin die Kurve geht, sodass deine Arbeit sich mit dem Fortschritt aufaddiert, statt von ihm überholt zu werden. Wähle Probleme, die wertvoller werden, während KI besser wird, nicht weniger. Ein Verifikations-Business ist mehr wert, je mehr KI-generierter Content existiert. Ein Menschen-Identitäts-Business ist mehr wert, je besser die Deepfakes werden. Ein Physisch-zu-digital-Business ist mehr wert, je hungriger die Modelle nach Daten sind. Positioniere dich dort und jede Verdopplung ist Rückenwind. Positioniere dich gegen die Kurve - wette darauf, dass dein Vorsprung eine Lücke ist, die sich schliesst - und jede Verdopplung ist ein Countdown. #### Typische Fehler Die wiederkehrenden Fehler: das ganze Feld wegen der heutigen Mängel abtun (linearer Pessimismus); annehmen, eine Fähigkeit sei schon verlässlich, wenn sie eine Verdopplung oder zwei entfernt ist (linearer Optimismus); einen Burggraben aus einer Fähigkeitslücke bauen, die sich offensichtlich schliesst; und sich so eng in ein Modell einsperren, dass du das nächste, weit bessere nicht reiten kannst. Die Heilung für alle ist dieselbe: respektiere die Kurve und bleib flexibel. #### Business-ROI Korrekt über Exponentielle nachzudenken ist die hebelstärkste strategische Fähigkeit in diesem Programm, denn sie bestimmt, welche Wetten du überhaupt platzierst. Gründer, die frühe Verdopplungen verinnerlicht und für die Bahn gebaut haben, fingen Wellen, die damals absurd aussahen und im Rückblick offensichtlich. Die Kosten, das falsch zu machen, sind nicht ein schlechtes Quartal, es ist, ein ganzes Business auf einem Fundament zu bauen, das das nächste Modell auflöst. Probleme zu wählen, die stärker werden, während KI stärker wird, ist, wie du die Kurve für dich arbeiten lässt statt gegen dich. #### Checkliste Stell dein Denken gegen diese auf die Probe, bevor du dich auf eine Richtung festlegst. - Du kannst erklären, warum eine Verdopplung alle paar Monate die lineare Intuition schlägt. - Du kannst eine temporäre Grenze von einer dauerhaften für dein eigenes Projekt unterscheiden. - Dein Vorsprung ist nicht eine Fähigkeitslücke, die das nächste Modell schliesst. - Du kannst eine Chance nennen, die wertvoller wird, während KI sich verbessert, nicht weniger. #### Ressourcen Lies die eigenen Fähigkeits- und Roadmap-Notizen der grossen Labs für die Reiserichtung und schau die Autonomie-Lektion aus Kurs 4 nochmal an, da Validierung als echter Blocker zentral dafür ist, wo die Chancen sitzen. Die nützlichste Übung ist fortlaufend: jedes Mal, wenn ein neues Modell landet, notiere, welche deiner alten Annahmen es gerade gebrochen hat. Dieses laufende Protokoll ist, wie du deine Intuition auf die Kurve kalibriert hältst. #### Deine Aufgabe Liste drei Grenzen, um die du gerade in einem Projekt herum gestaltest. Beurteile für jede ehrlich, ob sie dauerhaft ist oder sich wahrscheinlich innerhalb weniger Verdopplungen auflöst, und notiere, wie sich dein Plan ändert, wenn sie sich auflöst. Dann nenne eine Chance aus dieser Lektion - Cybersecurity, Validierung, menschliche Verifikation oder physisch-zu-digital -, auf die du realistisch hinbauen könntest. Das ist deine Karte für den Capstone. #### Nächste Lektion Du hast die Fähigkeiten und den strategischen Blick. Die letzte Lektion ist der Capstone: nimm ein echtes Problem und baue, teste, sichere, dokumentiere und liefere dein eigenes agentisches Produkt von Anfang bis Ende. ### 5.7 Capstone: dein eigenes agentisches Produkt von Anfang bis Ende bauen und ausliefern - Kanonische URL: https://agenticschool.dev/de/kurse/quality-security-agent-first/capstone-build-and-ship-your-own-agentic-product-end-to-end - Dauer: 32 min Zusammenfassung: Der Capstone bindet das ganze Programm zusammen. Du wählst ein kleines echtes Problem, spezifizierst es, baust es mit Claude Code mit allem aus den Kursen 1 bis 4, fährst die Quality Gates, sicherst es, machst es auffindbar mit llms.txt und einer API-Oberfläche, deployst es und teilst es in der Community - gegen eine klare Akzeptanzkriterien-Checkliste. #### Überblick Hier wird alles zu einem Workflow. Nicht fünf separate Fähigkeitssets, sondern eine einzige Schleife von der Idee zum Live-Produkt: ein echtes Problem abstecken, das Spec schreiben, es mit deinem Agent bauen, das Quality Gate fahren, die Security härten, es auffindbar und agent-first machen, deployen und vor Leute stellen. Das Ergebnis ist ein ausgeliefertes Ding, wie klein auch immer, plus der Beweis - für dich selbst -, dass du jede Idee wieder durch diese Schleife bringen kannst. Diese Lektion ist ein geführter Bau mit einer konkreten Akzeptanz-Checkliste, keine Lektüre. #### Was du lernst Du fährst die volle End-to-End-Schleife einmal, bewusst: erbarmungslos auf etwas Machbares abstecken, es so spezifizieren, wie Kurs 1 es lehrte, es mit Claude Code auf einem echten Stack bauen, es mit den Tests und der Security aus diesem Kurs schützen, es mit SEO und einer llms.txt auffindbar machen, ihm eine agent-first API-Oberfläche geben, es deployen und es teilen. Der Output ist ein Live-Produkt und ein wiederholbarer Prozess. #### Voraussetzungen Alle fünf Kurse. Der Capstone zieht auf jede Fähigkeit: Modellwahl und Prompting (Kurs 1), Agent-Meisterschaft (Kurs 2), der moderne Stack aus Auth, Daten und Zahlungen (Kurs 3), Automation und agentische Systeme (Kurs 4) und die Qualitäts-, Security-, Rechts-, SEO- und agent-first Lektionen dieses Kurses. Wenn sich eine davon wackelig anfühlt, mach einen schnellen Durchgang, bevor du startest - der Capstone setzt sie voraus. #### Das Problem Der mit Abstand häufigste Weg, auf dem ein Capstone stirbt, ist der Scope. Leute wählen etwas Riesiges und Inspirierendes, bauen vierzig Prozent davon, treffen die unordentliche Mitte und geben still auf. Ein unfertiges ambitioniertes Projekt lehrt weit weniger als ein fertiges winziges, denn das Ausliefern ist, wo du jedem Problem begegnest, das die Tutorials übersprungen haben. Die ganze Disziplin dieser Lektion ist, etwas zu wählen, das klein genug ist, um es fertig zu bekommen, und echt genug, um zu zählen, und es dann den ganzen Weg bis live zu tragen. #### Schritt eins: auf etwas abstecken, das du fertig bekommst Wähle ein kleines, echtes Problem - idealerweise eines, das du tatsächlich hast, oder eines, das an eine Chance aus der vorherigen Lektion anknüpft. Schneid es runter, bis es dir leicht peinlich ist, wie klein es ist, dann schneid noch einmal. Ein Tool, das eine nützliche Sache gut macht und live ist, schlägt eine Plattform, die zehn Dinge tut und nie ausliefert. Schreib den Scope als einen einzigen Satz, den du einem Fremden erklären könntest. - Ein Problem, ein Nutzer, ein klares Ergebnis. Wenn du es nicht in einem Satz sagen kannst, ist es zu gross. - Bevorzug ein echtes eigenes Jucken - du wirst wissen, wann es gut ist, und du wirst es tatsächlich nutzen. - Vertage erbarmungslos alles, was nicht die Kernschleife ist. Ein zweites Feature ist ein zweites Projekt. - Definiere fertig, bevor du startest, sodass du auslieferst, statt für immer zu polieren. #### Schritt zwei: spezifiziere es und bau es mit deinem Agent Verwandle den Scope in ein echtes Spec-Sheet - Ziel, Kontext, Constraints, Akzeptanzkriterien - so, wie Kurs 1 es lehrte, mit deinen Axiomen eingebacken. Wähle die richtige Modellstufe für jede Aufgabe, wähle einen Stack, den du deployen kannst, und fahr Claude Code mit Projektregeln in deiner CLAUDE.md, sodass es deinen Konventionen automatisch folgt. Bau zuerst die Kernschleife und bring sie lokal zum Laufen, bevor du irgendetwas drumherum hinzufügst. Bitte den Agent, vor dem Start gegen deinen Plan zu argumentieren - manche der besten Entscheidungen in einem Bau kommen daher, dass der Agent früh einen Fehler fängt. ```markdown ## Goal A tool that takes a business address and returns its opening hours as clean JSON. ## Context - Stack: this TanStack Start app, Convex for data, deploy on Vercel. - Follow the API patterns from the agent-first lesson. ## Constraints - TypeScript only. Every endpoint rate-limited. Secrets in env vars. - Publish an OpenAPI spec and an llms.txt. Self-serve API keys. - Add a Vitest test for the parser and a Playwright test for the happy path. ## Acceptance criteria - [ ] GET /v1/hours?address=... returns structured JSON or a clear error. - [ ] Rate limit returns 429 when exceeded. Errors are structured. - [ ] OpenAPI spec and llms.txt are live and accurate. - [ ] Quality gate (tsc, lint, vitest, playwright) is green in CI. - [ ] Deployed to a public URL over HTTPS. ``` Ein Capstone-Spec-Sheet, das die Qualitäts-, Security- und agent-first Kriterien einfaltet #### Schritt drei: gate, sichere und werde konform Bevor das irgendwo in die Nähe eines echten Nutzers kommt, fahr alles aus diesem Kurs. Bring das vierschichtige Quality Gate in Stellung und mach CI erforderlich. Wende die Security-Essentials an - rate-limite jeden öffentlichen Endpunkt, setz eine CSP, verschlüssele jedes gespeicherte Secret und fahr das Pre-Public-Historie-Audit, falls das Repo öffentlich wird. Wenn es beliebige personenbezogene Daten sammelt, mach den Datenschutz-Durchgang: Rechtsgrundlage, ein funktionierender Einwilligungs-Flow, eine Datenschutzerklärung. Das ist der Teil, den Einsteiger überspringen und Profis nie. Es ist auch, was eine Demo von einem Produkt trennt. - Qualität: tsc, lint, Vitest und Playwright alle grün, erzwungen durch einen Pre-Push-Hook und erforderliches CI. - Security: Rate Limits, CSP-Header, verschlüsselte Secrets und ein sauberer gitleaks-Scan vor jedem öffentlichen Repo. - Recht: wenn es personenbezogene Daten berührt, eine Rechtsgrundlage, ein konformer Einwilligungs-Flow und eine Datenschutzerklärung. - Agent-first: veröffentlichtes OpenAPI-Spec, vorhersehbare strukturierte Fehler, Self-Service-Keys. #### Schritt vier: liefere es aus und mach es auffindbar Deploye auf Vercel, verbinde eine Domain, falls du eine hast, und bestätige, dass es über HTTPS lädt, mit Secrets als Umgebungsvariablen gesetzt, nicht im Repo. Dann mach es durch beide Kanäle aus der SEO-Lektion auffindbar: echte Titel und Beschreibungen, eine Sitemap, Search Console, ein knackiges Favicon, strukturierte Daten und eine llms.txt plus saubere Docs, damit KI-Assistenten es entdecken und empfehlen können. Ein ausgeliefertes Produkt, das niemand finden kann, ist nur halb fertig - gib ihm einen Weg, von Menschen und von Agents entdeckt zu werden. #### Schritt fünf: teile es in der Community Der letzte Schritt ist kein optionaler Schnickschnack, er ist, wie du die Schleife schliesst. Poste dein ausgeliefertes Produkt in der Community: was es tut, was du gelernt hast, wo es schwerer war als erwartet, und den Live-Link. Teilen zwingt dich, tatsächlich fertig zu werden, lädt das Feedback ein, das Version zwei besser macht, und verbindet dich mit anderen Bauenden, die durch dieselbe Schleife gehen. Der Gründer dieser School lieferte unvollkommene Dinge öffentlich aus, lange bevor sie bereit waren, und diese Gewohnheit - ausliefern, teilen, lernen, wiederholen - verzinst sich schneller als jede Menge privaten Polierens. #### Typische Fehler Die Capstone-Killer: ein Scope so gross, dass er nie ausliefert; das Quality Gate überspringen, sodass es bricht, sobald du es änderst; Security überspringen, sodass der erste Bot es missbraucht; die API und Auffindbarkeit als Nachgedanken behandeln, sodass weder Menschen noch Agents es finden können; und es nie teilen, sodass du das Feedback und die Verantwortlichkeit verlierst, die das Fertigwerden verlangt. Klein, gegated, sicher, auffindbar, geteilt - in dieser Reihenfolge. #### Business-ROI Ein einziges ausgeliefertes Produkt lehrt mehr als ein Jahr Tutorials, denn das Ausliefern bringt jedes echte Problem auf einmal an die Oberfläche und erzwingt eine Entscheidung zu jedem. Es ist auch dein Fähigkeitsbeweis - für dich selbst, für Kunden und für jeden, mit dem du arbeiten willst. Und die Schleife, die du gerade gefahren bist, ist der Vermögenswert, nicht nur das Produkt: sobald du eine Idee vom Scope zu einem live, getesteten, sicheren, auffindbaren, agent-first Ding bringen kannst, kannst du es wieder und wieder tun, jedes Mal schneller. Diese wiederholbare Schleife ist die ganze Rendite dieses Programms. #### Checkliste Dein Capstone ist abgeschlossen - wirklich, nicht fast -, wenn jedes davon stimmt. Das ist das Akzeptanzkriterium für das ganze Programm. - Das Produkt löst ein echtes Problem und ist live unter einer öffentlichen URL über HTTPS. - Das vierschichtige Quality Gate ist grün und in CI erforderlich. - Jeder öffentliche Endpunkt ist rate-limitiert, Secrets sind verschlüsselt, und ein öffentliches Repo hat einen Historie-Scan bestanden. - Wenn es personenbezogene Daten sammelt, hat es eine Rechtsgrundlage, funktionierende Einwilligung und eine Datenschutzerklärung. - Es hat ein OpenAPI-Spec, vorhersehbare Fehler, Self-Service-Keys und eine llms.txt. - Es hat echte Titel, eine Sitemap, ein Favicon und ist in der Search Console verifiziert. - Du hast es in der Community mit dem Live-Link gepostet und mit dem, was du gelernt hast. #### Ressourcen Jede vorherige Lektion ist eine Ressource für diesen Bau - halt das Spec-Sheet-Template, den Quality-Gate-Workflow, die Security-Checkliste, die Datenschutz-Checkliste und die agent-first Checkliste offen, während du arbeitest. Der Builds-Abschnitt zeigt fertige Projekte von Anfang bis Ende, wenn du eine Referenz für Scope und Form willst. Die Community ist, wo du das Ergebnis teilst und wo die nächste Runde Feedback herkommt. #### Deine Aufgabe Bau es und liefere es aus. Wähle das kleine Problem, schreib das Spec, bau es mit deinem Agent, besteh das Quality Gate, sichere und werde konform, deploye es, mach es auffindbar und agent-first, dann poste es in der Community mit dem Live-Link. Hak jede Box auf der Checkliste oben ab. Wenn die letzte Box abgehakt ist, hast du nicht nur einen Kurs beendet - du hast bewiesen, dass du ein agentisches Produkt von Anfang bis Ende ausliefern kannst, allein, wieder und wieder. #### Was als Nächstes kommt Du hast das Programm abgeschlossen, aber das Feld hält nicht still und du solltest es auch nicht. Liefere weiter kleine Dinge aus, falte neue Tools ein, sobald sie auftauchen, und nutze das Changelog als deinen täglichen Tool-News-Hub, um aktuell zu bleiben. Bring deine Builds, deine Erfolge und deine festgefahrenen Momente in die Community - dort verzinst sich das Lernen weiter, nachdem die Kurse enden. Die Schleife, die du jetzt besitzt, ist der ganze Punkt: Idee, bauen, gaten, sichern, ausliefern, teilen, wiederholen. Geh und fahr sie nochmal. --- ## Grundlagen ### Was ist Node.js (und wie installierst du es) - Kanonische URL: https://agenticschool.dev/de/grundlagen/what-is-nodejs Node.js ist eine Runtime, mit der du JavaScript auf deinem Computer ausführst statt nur im Browser. Fast jedes moderne Web-Projekt braucht es, weil die Tools, die deine App bauen, starten und testen, selbst JavaScript-Programme sind, und Node.js ist das, was sie ausführt. Wenn ein Tutorial dir sagt, du sollst "npm install" oder "npm run dev" ausführen, funktioniert dieser Befehl nur, weil Node.js installiert ist. Stell es dir als den Motor vor, auf dem dein Projekt aufsetzt. #### Warum du Node.js brauchst Wenn du eine Website mit einem modernen Framework baust, schreibst du nicht nur Dateien, die ein Browser öffnet. Du startest einen Dev Server, installierst Pakete und kompilierst deinen Code. All diese Tools sind in JavaScript geschrieben und brauchen Node.js, um zu laufen. Ohne es scheitern die Befehle aus fast jedem Tutorial einfach mit "command not found". - Es startet den Dev Server, der deine Seite beim Bauen in der Vorschau zeigt. - Es führt npm aus, das Tool, das die Bibliotheken deines Projekts installiert. - Es führt Build-, Test- und Lint-Tools aus, die deinen Code veröffentlichen und prüfen. #### Wie du es installierst Der sicherste Weg, Node.js zu installieren, ist über die offizielle Website nodejs.org. Lade die LTS-Version herunter (Long Term Support), die stabile, für fast alle empfohlene Variante, und starte den Installer. Wenn er fertig ist, öffne ein frisches Terminal und prüfe, ob es geklappt hat. ```bash node --version npm --version ``` Beide Befehle sollten eine Versionsnummer ausgeben. Wenn ja, sind Node.js und npm bereit. #### Häufige Anfänger-Verwirrungen Node.js ist keine andere Sprache, es ist JavaScript an einem neuen Ort. Du "benutzt" Node.js auch die meiste Zeit nicht direkt. Du installierst es einmal, und dann nutzen die Tools, die du tatsächlich startest (npm, dein Dev Server, dein Framework), es im Hintergrund. Wenn ein Befehl direkt nach der Installation scheitert, ist die übliche Lösung, dein Terminal komplett zu schliessen und ein neues zu öffnen, damit es die neue Installation erkennt. Noch etwas verunsichert Leute: Die Versionsnummer zählt weniger, als man fürchtet. Solange du auf einem aktuellen LTS-Release bist, funktioniert fast jedes Tutorial und Projekt, und du musst nach dem Setup selten wieder an Node.js denken. Du musst es auch nicht ständig aktualisieren; eine jährliche Prüfung reicht den meisten völlig. ### Terminal-Grundlagen für absolute Anfänger - Kanonische URL: https://agenticschool.dev/de/grundlagen/terminal-basics Das Terminal ist ein Textfenster, in dem du Befehle eintippst, um deinem Computer zu sagen, was er tun soll, statt zu klicken. Anfangs wirkt es einschüchternd, aber du brauchst nur etwa fünf Befehle, um produktiv zu sein, und ein KI Coding Agent führt den Rest für dich aus. Alles, was du im Terminal tust, könntest du auch per Klick erledigen, aber Tippen ist schneller und ist die Art, wie fast jedes Entwickler-Tool benutzt werden will. #### Wie das Terminal funktioniert Zu jedem Zeitpunkt ist das Terminal "in" einem Ordner, dem aktuellen Verzeichnis. Befehle wirken auf diesen Ordner, ausser du sagst etwas anderes. Du bewegst dich zwischen Ordnern, schaust dir an, was in ihnen ist, und startest Programme. Das ist im Wesentlichen alles. #### Die Befehle, die du wirklich brauchst Diese fünf decken fast alles ab, was ein Anfänger tut. Du tippst einen Befehl, drückst Enter, und er läuft. ```bash pwd # zeigt den Ordner, in dem du gerade bist ls # listet die Dateien und Ordner hier auf cd my-app # wechselt in den Ordner namens my-app cd .. # geht einen Ordner nach oben mkdir test # erstellt einen neuen Ordner namens test ``` In Windows PowerShell gelten dieselben Ideen; "ls" und "cd" funktionieren auch dort. #### Häufige Anfänger-Verwirrungen Ein Terminal, das nach einem Befehl "einfach dasteht", bedeutet meist, dass der Befehl noch arbeitet, besonders ein Dev Server, der weiterlaufen soll, bis du ihn stoppst. Um einen laufenden Befehl zu stoppen, drücke Ctrl und C gleichzeitig. Pfade zählen: Ein Befehl scheitert oft schlicht, weil du im falschen Ordner bist, also führe "pwd" und "ls" aus, um zu prüfen, wo du bist, bevor du annimmst, dass etwas kaputt ist. Zwei weitere Gewohnheiten ersparen viel Mühe. Erstens kannst du mit der Pfeil-nach-oben-Taste deine vorherigen Befehle zurückholen, statt sie neu zu tippen, und mit der Tab-Taste einen langen Ordnernamen automatisch vervollständigen. Zweitens funktionieren auch Kopieren und Einfügen im Terminal, wobei das Tastenkürzel vom Rest deines Systems abweichen kann, also wenn Ctrl und V nichts tun, versuche einen Rechtsklick. Nichts davon musst du memorieren; du nimmst es innerhalb eines Tages echter Nutzung auf, und dein KI Agent erklärt unterwegs, was jeder Befehl tut. ### Was ist Git? Versionskontrolle erklärt - Kanonische URL: https://agenticschool.dev/de/grundlagen/what-is-git Git ist ein Versionskontroll-Tool, das Snapshots deines Projekts macht, sogenannte Commits, damit du immer zu einer funktionierenden Version zurück kannst. Stell es dir als unbegrenzte, beschriftete Undo-History für dein ganzes Projekt vor. Jedes Mal, wenn du einen Commit speicherst, hält Git genau fest, was sich geändert hat, und lässt dich später dorthin zurückkehren, was die Angst nimmt, die Anfänger vom Experimentieren abhält. Git läuft auf deinem eigenen Computer und funktioniert komplett offline. #### Warum Git zählt Ohne Versionskontrolle kann eine schlechte Änderung stundenlange Arbeit zerstören, und es gibt keinen sauberen Weg zurück. Mit Git ist eine schlechte Änderung nie eine Katastrophe, weil du einfach zum letzten guten Commit zurückkehrst. Es lässt auch mehrere Leute am selben Projekt arbeiten, ohne sich gegenseitig zu überschreiben, und es ist das Fundament, auf dem Dienste wie GitHub aufbauen. #### Der Kern-Workflow Die tägliche Schleife ist klein: Du änderst Dateien, stagest die, die du speichern willst, und committest sie mit einer kurzen Nachricht, die beschreibt, was sich geändert hat. Dein KI Agent führt diese oft für dich aus, aber es hilft, sie zu erkennen. ```bash git status # sehen, was sich geändert hat git add . # alle Änderungen stagen git commit -m "Add hero section" # einen beschrifteten Snapshot speichern ``` Eine Commit-Nachricht sollte in wenigen Worten sagen, was sich geändert hat und warum. #### Häufige Anfänger-Verwirrungen Git ist nicht dasselbe wie GitHub. Git ist das Tool auf deinem Computer; GitHub ist eine Website, die eine Kopie deines Git-Projekts online speichert. Ein "Commit" ist ein Speicherpunkt in Git, nicht dasselbe wie das Speichern einer Datei in deinem Editor; du kannst eine Datei viele Male speichern und erst committen, wenn du zufrieden bist. Und ein Commit veröffentlicht von sich aus nichts im Internet. Leute sorgen sich früh auch um Branches, aber du brauchst sie zum Start nicht. Ein Branch ist nur eine parallele Arbeitslinie, die du ausprobieren kannst, ohne deine Hauptversion zu berühren, und als Solo-Anfänger kannst du Branches getrost ignorieren, bis ein Projekt grösser wird. Die wichtigste Gewohnheit ist, oft mit klaren Nachrichten zu committen, sodass deine History wie eine Geschichte deiner Schritte liest und du jederzeit zu jedem Punkt zurück kannst. ### Was ist GitHub? Ein Leitfaden für Anfänger - Kanonische URL: https://agenticschool.dev/de/grundlagen/what-is-github GitHub ist eine Website, die deine Git-Projekte online speichert, damit du sie sichern, teilen und deployen kannst. Wenn Git das Tool ist, das Snapshots deines Projekts auf deinem Computer speichert, dann ist GitHub der Ort, an dem diese Snapshots in der Cloud leben. Dort wird der meiste Code der Welt aufbewahrt, und die meisten Hosting-Plattformen verbinden sich mit GitHub, um deine Seite automatisch zu deployen, sobald du neue Änderungen pushst. #### Was dir GitHub gibt GitHub verwandelt dein lokales Git-Projekt in etwas Dauerhaftes und Vernetztes. Dein Code ist abseits deines Laptops gesichert, andere können ihn reviewen und beitragen, und Deploy-Dienste beobachten dein Repository und deployen bei jeder Änderung neu. - Ein sicheres Backup deiner ganzen Projekt-History abseits der Maschine. - Zusammenarbeit: Issues, Reviews und Pull Requests für die Arbeit mit anderen. - Deployment: Hosts wie Vercel deployen automatisch, wenn du pushst. #### Öffentliche vs private Repositories Ein Repository (oder "Repo") ist ein Projekt auf GitHub. Es kann öffentlich sein, also für alle sichtbar, oder privat, also nur für eingeladene Personen. Für ein Business-Projekt setze standardmässig auf privat, damit dein Code und deine IP dir gehören. Du kannst es später jederzeit öffentlich machen, wenn du willst. #### Deinen Code pushen Nachdem du lokal mit Git committest, "pushst" du diese Commits zu GitHub, um sie hochzuladen. Beim ersten Mal verbindest du dein lokales Projekt mit einem Repo; danach ist Pushen ein Befehl. Die umgekehrte Richtung heisst "Pull", was Änderungen von GitHub zurück auf deinen Computer lädt und zählt, sobald du über zwei Maschinen oder mit anderen arbeitest. ```bash git push ``` Lädt deine lokalen Commits ins verbundene GitHub-Repository hoch. #### Häufige Anfänger-Verwirrungen Die grösste ist die Angst, dass Pushen deine Secrets preisgibt. Das kann passieren, wenn du unachtsam bist, weshalb Secrets in einer .env-Datei leben, die Git ignoriert. Pushe deinen Code, nie deine Keys. Leute verwechseln auch GitHub die Website mit Git dem Tool: Du kannst ein völlig gutes Git-Projekt haben, das GitHub nie berührt, und GitHub fügt einfach ein sicheres Online-Zuhause plus Zusammenarbeit obendrauf. Schliesslich musst du nicht jeden Button einer Repository-Seite verstehen, um produktiv zu sein. Dein Projekt verbinden, committen und pushen deckt fast alles ab, was ein Anfänger wochenlang tut. ### JSON, YAML und Markdown erklärt - Kanonische URL: https://agenticschool.dev/de/grundlagen/json-yaml-markdown JSON, YAML und Markdown sind drei Klartext-Formate, denen du beim Bauen ständig begegnest. JSON und YAML speichern beide strukturierte Daten wie Einstellungen und Listen, während Markdown für formatierten Text wie Dokumentation und Notizen da ist. Keines davon ist eine Programmiersprache; es sind nur vereinbarte Arten, Informationen so zu schreiben, dass sowohl Menschen als auch Programme sie lesen können. Sobald du die drei erkennst, hören die meisten Config-Dateien auf, beängstigend auszusehen. #### JSON: Daten für Maschinen JSON (JavaScript Object Notation) speichert Daten als Schlüssel-Wert-Paare, mit geschweiften Klammern und Anführungszeichen. Es ist überall: API-Antworten, Paket-Dateien, App-Einstellungen. Es ist streng, also bricht ein einziges fehlendes Komma oder Anführungszeichen es. ```json { "name": "my-app", "version": "1.0.0", "private": true } ``` Schlüssel und String-Werte stehen immer in doppelten Anführungszeichen. #### YAML: Daten für Menschen YAML speichert dieselbe Art Daten wie JSON, nutzt aber Einrückung statt Klammern, was es leichter von Hand lesbar und schreibbar macht. Es ist üblich in Workflow- und Deploy-Config. Der Haken: Abstände zählen. YAML nutzt Leerzeichen zur Einrückung, niemals Tabs. ```yaml name: my-app version: 1.0.0 private: true ``` Dieselben Daten wie das JSON oben, Einrückung statt Klammern. #### Markdown: formatiertes Schreiben Markdown ist für Text, nicht für Daten. Du fügst einfache Symbole zu Klartext hinzu, um Überschriften, Fettdruck, Listen und Links zu markieren, und es wird als schön formatierter Inhalt dargestellt. Diese Seite, die meisten READMEs und KI-Anweisungsdateien wie CLAUDE.md sind alle Markdown. ```markdown # Eine Überschrift Etwas **fetter** Text und eine Liste: - erster Eintrag - zweiter Eintrag ``` Ein "#" macht eine Überschrift; "**text**" macht ihn fett; "-" macht eine Liste. #### Wie du sie auseinanderhältst Eine schnelle Faustregel klärt die meiste Verwirrung. Wenn du geschweifte Klammern und viele Anführungszeichen siehst, ist es JSON. Wenn du saubere Einrückung mit Doppelpunkten und ohne Klammern siehst, ist es YAML. Wenn du "#"-Überschriften und "-"-Bullets siehst, die für einen Menschen gedacht sind, ist es Markdown. Du musst keines davon perfekt von Hand schreiben, weil dein KI Agent diese Dateien für dich erzeugt und bearbeitet. Es hilft, zu erkennen, was was ist, damit du, wenn ein Tool nach "einer YAML-Config" oder "einer JSON-Datei" fragt, weisst, was es erwartet, und einen offensichtlichen Fehler auf einen Blick siehst. ### VS Code Setup für Anfänger - Kanonische URL: https://agenticschool.dev/de/grundlagen/vs-code-setup VS Code (Visual Studio Code) ist ein kostenloser, weit verbreiteter Code-Editor, in dem du die Dateien deines Projekts schreibst, liest und organisierst. Es ist im Grunde ein leistungsfähiger Texteditor für Code, mit einem Datei-Explorer, einem eingebauten Terminal und einem Extension-Marktplatz. Du brauchst es nicht zwingend, um mit einem KI Agent zu bauen, aber es gibt dir einen bequemen Ort, um zu sehen, was der Agent tut, und um selbst kleine Änderungen zu machen. #### VS Code installieren Lade VS Code von der offiziellen Seite code.visualstudio.com herunter und starte den Installer für dein Betriebssystem. Es ist kostenlos und von Microsoft. Nach der Installation öffnest du ein Projekt über "Open Folder" und zeigst damit auf deinen Projektordner. #### Das eingebaute Terminal Eine der nützlichsten Funktionen für Anfänger ist das integrierte Terminal, damit du nicht zwischen Fenstern wechseln musst. Öffne es über das Menü (Terminal, dann New Terminal) und du bekommst ein Terminal, das bereits auf deinen Projektordner zeigt. Hier führst du Befehle wie "npm run dev" aus. #### Ein paar Extensions, die sich lohnen Extensions fügen VS Code Funktionen hinzu. Du brauchst zum Start nicht viele, und du kannst später jederzeit mehr hinzufügen. - Prettier: formatiert deinen Code beim Speichern sauber und konsistent. - ESLint: hebt wahrscheinliche Fehler hervor, während du arbeitest. - Ein Language Pack, falls du die Menüs in deiner eigenen Sprache willst. #### Häufige Anfänger-Verwirrungen VS Code kann wegen all der Panels überwältigend aussehen, aber du brauchst anfangs nur drei: den Datei-Baum links, um dein Projekt zu sehen, den Editor in der Mitte, um Dateien zu lesen und zu ändern, und das Terminal unten, um Befehle auszuführen. Alles andere kannst du ignorieren, bis du es willst. Eine häufige Sorge ist, ob das Öffnen der falschen Datei oder eines Panels etwas kaputtmacht; tut es nicht, VS Code bearbeitet Dateien nur, wenn du tatsächlich tippst und speicherst. Zwei kleine Komforteinstellungen helfen früh sehr: Schalte Zeilenumbruch ein, damit lange Zeilen sichtbar bleiben, und aktiviere Format on Save, damit Prettier deinen Code bei jedem Speichern automatisch aufräumt. ### Was ist eine .env-Datei? - Kanonische URL: https://agenticschool.dev/de/grundlagen/what-is-an-env-file Eine .env-Datei ist eine Klartext-Datei, die Secrets und Einstellungen wie API Keys und Passwörter getrennt von deinem Code speichert, damit sie nie versehentlich veröffentlicht werden. Der Name ist kurz für "environment" (Umgebung). Deine App liest Werte zur Laufzeit daraus, aber die Datei selbst bleibt privat und wird nie zu GitHub hochgeladen. Diese eine Gewohnheit richtig zu machen, ist das Beste, was ein Anfänger tun kann, um keinen Key zu leaken. #### Was in eine .env-Datei gehört Eine .env-Datei ist eine Liste von Name-Wert-Paaren, eines pro Zeile. Alles Sensible oder Umgebungsspezifische gehört hierhin statt fest in deine Quelldateien geschrieben. ```bash OPENAI_API_KEY=sk-your-secret-key DATABASE_URL=postgres://user:pass@host/db SITE_URL=http://localhost:3000 ``` Jede Zeile ist NAME=wert. Für einfache Werte braucht es keine Anführungszeichen. #### Die goldene Regel: raus aus Git Der ganze Sinn einer .env-Datei ist, dass sie privat bleibt. Du stellst sicher, dass Git sie nie trackt, indem du sie in einer .gitignore-Datei aufführst. Die Regel ist absolut: Secrets in .env, .env in .gitignore, und ein Key taucht nie in Code auf, der committet wird. ```bash # .gitignore .env .env.local ``` Sie hier aufzuführen sagt Git, .env zu ignorieren, damit sie nie hochgeladen wird. #### In der Produktion Auf einem echten Deployment lädst du deine .env-Datei auch nicht hoch. Stattdessen setzt du dieselben Namen und Werte als "Environment Variables" im Dashboard deines Hosts, zum Beispiel in Vercel. So hat die Produktion eigene, getrennte Keys, und ein Fehler in der Entwicklung kann nie Live-Daten berühren. #### Häufige Anfänger-Verwirrungen Eine häufige Verwechslung ist die zwischen dem geheimen Wert und seinem Namen. Dein Code verweist auf den Namen, wie OPENAI_API_KEY, und das echte Secret lebt nur in der .env-Datei und im Host-Dashboard, nie im committeten Code. Eine andere ist der Unterschied zwischen einer .env-Datei (für Secrets und Einstellungen) und .gitignore (der Liste der Dinge, die Git nie tracken soll); sie arbeiten zusammen, tun aber Verschiedenes. Falls du je versehentlich einen Key committest, lösche nicht einfach die Zeile und mach weiter. Behandle den Key als kompromittiert, rotiere ihn, indem du im Provider-Dashboard einen neuen erzeugst, und der alte wird für jeden, der ihn gesehen hat, nutzlos. Diese Gewohnheit früh zu lernen heisst, dass ein Ausrutscher eine kleine Unannehmlichkeit ist, keine Katastrophe. ### npm vs Bun: Package Manager erklärt - Kanonische URL: https://agenticschool.dev/de/grundlagen/npm-vs-bun npm und Bun sind Package Manager: Tools, die die Bibliotheken (Packages genannt), von denen dein Projekt abhängt, herunterladen und installieren. npm kommt mit Node.js gebündelt und ist der langjährige Standard, während Bun eine neuere, viel schnellere Alternative ist, die auch deinen Code ausführen kann. Beide lesen dieselbe package.json-Datei, die deine Abhängigkeiten auflistet, also ist der praktische Unterschied für Anfänger vor allem Geschwindigkeit und welche Befehle du tippst. #### Was ein Package Manager tut Moderne Apps werden aus hunderten kleiner, wiederverwendbarer Bibliotheken gebaut, statt von Grund auf geschrieben. Ein Package Manager liest die Abhängigkeitsliste deines Projekts, lädt sie herunter und hält ihre Versionen konsistent, damit dasselbe Projekt auf jeder Maschine gleich funktioniert. #### Dieselben Befehle, anderes Tool Die täglichen Befehle entsprechen sich zwischen npm und Bun fast eins zu eins, was den Wechsel einfach macht. ```bash npm install # npm: alle Abhängigkeiten installieren npm run dev # npm: das dev-Skript ausführen bun install # bun: dasselbe, schneller bun run dev # bun: das dev-Skript ausführen ``` Beachte, wie ähnlich sie sind. Bun ist in der Regel deutlich schneller. #### Was ein Anfänger nutzen sollte Wenn ein Tutorial npm nutzt, nutze npm; wenn es Bun nutzt, nutze Bun. Sie sind austauschbar genug, dass du beidem folgen kannst. npm ist garantiert vorhanden, weil es mit Node.js kommt. Bun lohnt sich, sobald du schnellere Installs willst, aber es ist ein zusätzliches Tool zum Einrichten. Wähle das, was dein Projekt oder Kurs schon nutzt, und bleib konsistent. #### Häufige Anfänger-Verwirrungen Das Wort "Package" klingt technisch, heisst aber nur ein wiederverwendbares Stück Code, das jemand anderes geschrieben und veröffentlicht hat, damit du es nicht musst. Wenn du install ausführst, lädt der Manager alle Packages, die dein Projekt auflistet, in einen Ordner namens node_modules. Dieser Ordner kann gross werden, was normal und harmlos ist, und er ist eines der Dinge, die du aus Git heraushältst, weil er jederzeit aus deiner Abhängigkeitsliste neu gebaut werden kann. Leute sorgen sich auch um die Lock-Datei (package-lock.json oder bun.lock), die nach dem Installieren auftaucht. Du bearbeitest sie nicht von Hand; sie pinnt einfach exakte Versionen, damit dein Projekt überall identisch installiert. Committe sie, und lass den Package Manager sie für dich aktualisieren. ### Was ist eine API? Ein Leitfaden in klarer Sprache - Kanonische URL: https://agenticschool.dev/de/grundlagen/what-is-an-api Eine API (Application Programming Interface) ist eine Art, wie zwei Programme miteinander reden und Daten austauschen. Statt dass ein Mensch auf einer Website herumklickt, sendet ein Programm eine Anfrage an ein anderes Programm und bekommt eine strukturierte Antwort zurück. Wenn deine App das Wetter zeigt, eine E-Mail sendet oder ein KI-Modell etwas fragt, ruft sie im Hintergrund eine API auf. APIs sind die Leitungen, die die Software, die du baust, mit dem Rest der Welt verbinden. #### Die Restaurant-Analogie Stell dir eine API wie eine Kellnerin vor. Du gehst nicht in die Küche und kochst; du gibst der Kellnerin deine Bestellung, sie bringt sie in die Küche und bringt dir dein Essen. Die API ist die Kellnerin: Du sendest eine Anfrage, die beschreibt, was du willst, und bekommst eine Antwort, ohne je wissen zu müssen, wie die Küche innen funktioniert. #### Anfragen und Antworten Eine Anfrage geht an eine URL (den Endpunkt), oft mit ein paar angehängten Daten. Die Antwort kommt meist als JSON zurück, ein strukturiertes Datenformat. Meistens kümmert sich dein Code oder dein KI Agent um die Details, aber die Form ist immer gleich: Du fragst, du erhältst eine strukturierte Antwort. ```json { "city": "Zurich", "temperature": 18, "condition": "cloudy" } ``` Eine typische API-Antwort: strukturierte Daten, bereit für ein Programm. #### API Keys und warum sie zählen Viele APIs verlangen einen API Key, einen geheimen String, der dich identifiziert und oft die Abrechnung steuert. Weil ein Key dich Geld kosten kann, wenn er geleakt wird, gehört er in eine .env-Datei und nie in Code, der committet wird. Das ist dieselbe Secrets-Disziplin, die jede Zugangsdaten in deinem Projekt schützt. #### Häufige Anfänger-Verwirrungen Ein paar Dinge stolpern Leute. Eine API ist keine Website, die du im Browser besuchst; sie ist ein Dienst, mit dem dein Programm spricht, und eine API-URL direkt zu besuchen zeigt oft nur Rohdaten oder einen Fehler, was normal ist. "Rate Limits" sind eine weitere Überraschung: Viele APIs begrenzen, wie viele Anfragen du in einem Zeitfenster machen kannst, also wenn Aufrufe plötzlich scheitern, gehst du vielleicht einfach zu schnell. Und verschiedene APIs nutzen leicht andere Regeln für Authentifizierung und Anfrageform, weshalb das Lesen der spezifischen API-Dokumentation zählt. Die gute Nachricht: Dein KI Agent liest diese Docs und schreibt den Anfrage-Code für dich, sodass du eine neue API souverän nutzen kannst, ohne ihre Details vorher zu memorieren. ### Was ist eine Datenbank? - Kanonische URL: https://agenticschool.dev/de/grundlagen/what-is-a-database Eine Datenbank ist ein organisierter Ort, um deine App-Daten zu speichern, damit du sie zuverlässig speichern, finden, ändern und löschen kannst. Wenn sich ein Nutzer registriert, einen Kommentar postet oder einen Kauf tätigt, muss diese Information irgendwo leben, das den Reload der Seite überlebt, und dieses Irgendwo ist eine Datenbank. Anders als eine einzelne Tabelle ist eine Datenbank gebaut, um auch bei Millionen Datensätzen und vielen gleichzeitigen Nutzern schnell und konsistent zu bleiben. #### Tabellen, Zeilen und Spalten Die häufigste Art, sich eine Datenbank vorzustellen, ist wie ein Satz von Tabellen. Jede Tabelle hält eine Art Ding (Nutzer, Bestellungen, Kommentare). Jede Zeile ist ein Datensatz, und jede Spalte ist ein Feld dieses Datensatzes, wie Name oder E-Mail. Die Datenbank hält diese organisiert und lässt dich sie schnell abfragen. #### SQL vs NoSQL Es gibt zwei grosse Familien. SQL-Datenbanken speichern Daten in strengen Tabellen mit definierten Spalten und sind super, wenn deine Daten eine klare Form haben. NoSQL-Datenbanken sind flexibler bei der Struktur und praktisch, wenn deine Daten variieren. Für die meisten Apps geht beides; die Wahl zählt weniger als die Grundlagen des Speicherns und Lesens richtig zu machen. #### Soft Deletes: eine Gewohnheit, die sich lohnt In echten Produkten löschst du Daten meist nicht dauerhaft in dem Moment, in dem ein Nutzer etwas löscht. Stattdessen markierst du sie als gelöscht, behältst aber die Zeile, was Soft Delete heisst. So können Daten wiederhergestellt werden und deine History bleibt intakt, was dich vor kostspieligen Fehlern schützt. #### Häufige Anfänger-Verwirrungen Eine Datenbank ist nicht dasselbe wie dein Code, und nicht dasselbe wie ein Backup. Dein Code liest aus der Datenbank und schreibt in sie, aber die Daten leben getrennt und überleben, auch wenn du deine App neu deployst. Leute nehmen auch an, sie müssten selbst einen Datenbank-Server betreiben und warten, was früher stimmte und heute meist optional ist: Moderne Plattformen hosten die Datenbank für dich, übernehmen Backups und lassen deinen KI Agent die Struktur in Code definieren. Schliesslich fragst du eine Datenbank nicht per Klick ab. Du stellst ihr Fragen mit Queries, und die meisten modernen Tools erzeugen diese Queries für dich, sodass du echte Daten modellieren und nutzen kannst, lange bevor du die Abfragesprache selbst lernst. ### Was ist DNS? Das Telefonbuch des Internets - Kanonische URL: https://agenticschool.dev/de/grundlagen/what-is-dns DNS (Domain Name System) ist das Telefonbuch des Internets: Es übersetzt einen menschenfreundlichen Domainnamen wie deineseite.com in die numerische Adresse des Servers, der dafür antworten soll. Computer finden einander über IP-Adressen, die schwer zu merken sind, also lässt dich DNS stattdessen einen Namen eintippen. Jedes Mal, wenn du eine Domain mit einer Website verbindest, fügst du DNS-Einträge hinzu, die deinen Namen auf den richtigen Server zeigen lassen. #### Wie eine Domain deine Seite findet Wenn jemand deine Domain eintippt, fragt sein Browser DNS "welche Adresse antwortet für diesen Namen?". DNS antwortet mit der Server-Adresse, und der Browser verbindet sich dorthin. Diese Abfrage passiert in Millisekunden und ist der Grund, warum du dir nie eine Zahlenreihe merken musst, um eine Website zu besuchen. #### Die Einträge, denen du wirklich begegnest Um eine Domain mit einem Host zu verbinden, fügst du ein paar Einträge bei deinem DNS-Anbieter hinzu. Als Anfänger brauchst du selten mehr als diese zwei. - A-Record: zeigt deine Domain direkt auf eine Server-IP-Adresse. - CNAME-Record: zeigt deine Domain auf einen anderen Domainnamen, üblich beim Verbinden mit einem Host. #### Propagation und HTTPS Nachdem du Einträge hinzufügst, müssen sie "propagieren", was einfach heisst, sich über das Internet verteilen, und kann von Minuten bis zu einem Tag dauern. Sobald deine Domain auf einen modernen Host wie Vercel zeigt, stellt er automatisch ein kostenloses HTTPS-Zertifikat aus, damit deine Seite sicher lädt. Viele verwalten DNS über Cloudflare für kostenloses HTTPS, ein schnelleres globales Netzwerk und Basisschutz. #### Häufige Anfänger-Verwirrungen Die häufigste ist Ungeduld. Du fügst die Einträge korrekt hinzu, die Seite lädt nicht sofort, und du nimmst an, etwas sei kaputt, obwohl die Propagation einfach Zeit braucht. Eine zweite ist, zu verwechseln, wo du die Domain gekauft hast und wo ihr DNS verwaltet wird; du kannst eine Domain an einem Ort kaufen und ihr DNS woanders verwalten, was genau passiert, wenn Leute DNS zu Cloudflare verschieben. Eine dritte ist zu vergessen, dass DNS den Namen nur auf einen Server zeigen lässt; es hostet deine Seite nicht. Du brauchst weiterhin einen Host wie Vercel, der deine tatsächliche Website betreibt, damit die Domain etwas zeigt. Dein Host sagt dir immer die genauen Einträge, also kopierst du sie am sichersten exakt und wartest dann. ### Was ist OAuth? Login mit Google erklärt - Kanonische URL: https://agenticschool.dev/de/grundlagen/what-is-oauth OAuth ist der Standard, der einen Nutzer sich in deiner App mit einem bestehenden Konto anmelden lässt, wie Google oder GitHub, ohne dir je sein Passwort zu geben. Wenn du auf "Mit Google fortfahren" klickst, ist OAuth das, was im Hintergrund passiert: Google bestätigt, wer der Nutzer ist, und sagt es deiner App, sodass du sein Passwort nie siehst oder speicherst. Es ist bequemer für Nutzer und sicherer für dich, weil du weniger Secrets hältst. #### Wie der Ablauf funktioniert Du schickst den Nutzer zum Anbieter (sagen wir Google), um sich anzumelden. Er stimmt zu, ein paar grundlegende Informationen mit deiner App zu teilen. Der Anbieter schickt den Nutzer dann zu deiner App zurück, zusammen mit einem Nachweis, wer er ist. Deine App vertraut diesem Nachweis, statt selbst ein Passwort zu verwalten. #### Warum es sicherer ist Passwörter korrekt zu speichern ist wirklich schwer und gefährlich, wenn man es falsch macht. OAuth bedeutet, dass du gar keine Passwörter speicherst, also verschwindet eine ganze Kategorie von Sicherheitsrisiko. Der Anbieter übernimmt die schwierigen Teile, einschliesslich Dingen wie Zwei-Faktor-Authentifizierung, für dich. #### Du baust es meist nicht selbst OAuth hat viele kleine, sicherheitssensible Details, also implementiert es fast niemand von Hand. Stattdessen nutzt du einen Authentifizierungs-Dienst wie Clerk, der es in ein paar Komponenten verpackt. Du aktivierst "Login mit Google", und der Dienst übernimmt den Ablauf, sodass du dich auf dein eigentliches Produkt konzentrieren kannst. #### Häufige Anfänger-Verwirrungen Leute vermischen oft drei verwandte Begriffe. Authentifizierung ist zu beweisen, wer du bist (einloggen), Autorisierung ist, was du tun darfst, sobald du drin bist, und OAuth ist der Standard, der einen Anbieter den Beweis-Teil für dich übernehmen lässt. Eine zweite Verwirrung ist zu denken, OAuth heisse, dass du kein E-Mail-und-Passwort-Login mehr anbieten kannst; kannst du, und die meisten Apps bieten beides nebeneinander. Eine dritte ist die Lücke zwischen Entwicklung und Produktion: Social Login funktioniert beim Bauen meist mit Test-Zugangsdaten und braucht dann vor dem Launch einen sorgfältigen Wechsel zu echten Anbieter-Einstellungen. Weil ein Auth-Dienst all das verwaltet, ist deine Aufgabe vor allem Konfiguration, nicht Kryptografie, was genau der Grund ist, warum es der empfohlene Weg ist. ### Was sind Tokens in KI? - Kanonische URL: https://agenticschool.dev/de/grundlagen/what-are-tokens In KI ist ein Token ein kleines Textstück, grob vier Zeichen oder drei Viertel eines englischen Wortes, in dem ein Sprachmodell liest und schreibt. Modelle sehen ganze Wörter nicht so, wie du es tust; sie zerlegen Text in Tokens, und sowohl der Preis, den du zahlst, als auch die Menge, die ein Modell auf einmal verarbeiten kann, werden in Tokens gemessen, nicht in Wörtern. Tokens zu verstehen ist der Schlüssel, um sowohl die Kosten als auch die Qualität von allem zu steuern, was du mit KI baust. #### Warum Tokens, nicht Wörter Modelle verarbeiten Text als Tokens, weil es ihnen erlaubt, jede Sprache, Code und seltsame Schreibweisen konsistent zu behandeln. Ein kurzes, häufiges Wort kann ein Token sein; ein langes oder ungewöhnliches Wort kann mehrere sein. Code und nicht-englischer Text kosten meist mehr Tokens als dieselbe Idee in schlichtem Englisch, was direkt deine Rechnung beeinflusst. #### Tokens und deine Rechnung KI-Preise werden pro Million Tokens angegeben und in Input (was du sendest) und Output (was das Modell zurückschreibt) aufgeteilt, wobei Output meist ein Vielfaches teurer ist. In einem Workflow, der tausende Male läuft, kann das Kürzen eines aufgeblähten Prompts deine Kosten drastisch senken. Weniger, aber relevanteren Text zu senden, ist fast immer der richtige Zug. #### Ein anderes "Token" in der Security Achtung vor einer Namensgleichheit. In KI ist ein Token ein Textstück. In Login und Security bedeutet ein "Token" etwas völlig anderes: einen geheimen String, der beweist, wer du bist, wie ein Access Token. Sie teilen ein Wort, sind aber unverwandte Konzepte, also lies den Kontext, um zu wissen, welches gemeint ist. #### Tokens und das Kontextfenster Tokens erklären auch eine Grenze, an die du stösst, das Kontextfenster: die maximale Anzahl Tokens, die ein Modell auf einmal berücksichtigen kann, inklusive deiner Anweisungen, eingefügter Dateien, des bisherigen Gesprächs und der Antwort, die es schreibt. Wenn das voll wird, vergisst das Modell praktisch die ältesten Teile. Darum verlieren lange, ausufernde Chats den Faden zu Dingen, die du früher gesagt hast, und darum gibt ein frisches Gespräch oft bessere Antworten als auf ein altes draufzupacken. Die praktische Erkenntnis ist dieselbe wie bei den Kosten: Sende weniger, aber relevanteren Text. Tokens sind die eine Einheit, die zusammenbindet, was ein Modell halten kann, wie gut es antwortet und was du zahlst, also macht dich ein grobes Gefühl dafür in allem besser, was du mit KI baust. ### Terminal vs Shell: Was ist der Unterschied? - Kanonische URL: https://agenticschool.dev/de/grundlagen/terminal-vs-shell Das Terminal ist das Fenster, in das du tippst, und die Shell ist das Programm, das in diesem Fenster läuft und deine Befehle tatsächlich versteht und ausführt. Die Begriffe werden austauschbar verwendet, und für den Alltag ist das in Ordnung, aber es sind zwei verschiedene Dinge. Das Terminal zeigt nur Text und nimmt deine Tastenanschläge entgegen; die Shell ist der Interpreter, wie bash, zsh oder PowerShell, der "ls" in eine echte Aktion verwandelt. #### Eine einfache Vorstellung Stell dir das Terminal als TV-Bildschirm vor und die Shell als den Sender, der darauf läuft. Der Bildschirm (Terminal) zeigt, was der Sender (Shell) schickt. Du kannst verschiedene Shells im selben Terminal laufen lassen, genauso wie du auf einem TV die Sender wechseln kannst. #### Häufige Shells, die du siehst Du musst keine Shell wählen, um loszulegen; dein System bringt eine mit. Aber die Namen tauchen in Anleitungen auf, also hilft es, sie zu erkennen. - bash und zsh: die häufigen Shells auf macOS und Linux. - PowerShell: die moderne Standard-Shell auf Windows. - Jede hat kleine Syntax-Unterschiede, weshalb ein Befehl in einer geht und in einer anderen nicht. #### Warum der Unterschied gelegentlich zählt Meistens kannst du die Unterscheidung ignorieren. Sie zählt, wenn ein Befehl aus einem Tutorial scheitert, weil du eine andere Shell nutzt als der Autor. Zum Beispiel unterscheidet sich, wie du eine Environment Variable setzt, zwischen bash und PowerShell. Wenn das passiert, behebt es meist sofort, wenn du deinem KI Agent sagst, welche Shell du nutzt. #### Häufige Anfänger-Verwirrungen Weil die Begriffe locker verwendet werden, denken Leute manchmal, eine neue Shell zu installieren heisse, ein neues Terminal zu installieren, oder umgekehrt. Sie sind getrennt: Du kannst dein Terminal behalten und die Shell darin wechseln, oder deine Shell behalten und eine andere Terminal-App nutzen. Eine weitere Quelle der Verwirrung ist, einen Befehl zu kopieren, der eine Funktion nutzt, die deine Shell nicht hat, und einen kryptischen Fehler zu sehen. Das ist nicht dein Computer, der kaputt ist; es ist ein Shell-Mismatch, und die Lösung ist meist eine kleine Anpassung des Befehls. Der nützlichste Zug, wenn etwas scheitert, ist, deinem KI Agent dein Betriebssystem und deine Shell zu nennen, was ihn die genaue Version des Befehls liefern lässt, die auf deinem Setup funktioniert. ### Localhost und Dev Server erklärt - Kanonische URL: https://agenticschool.dev/de/grundlagen/localhost-and-dev-servers Localhost heisst "dieser Computer", und ein Development Server (Dev Server) ist ein Programm, das deine Website lokal laufen lässt, sodass nur du sie beim Bauen siehst. Wenn du einen Befehl wie "npm run dev" ausführst, startet er einen Dev Server und gibt eine Adresse wie localhost:3000 aus. Diese Adresse zu öffnen zeigt deine Seite, aber sie lebt nur auf deiner Maschine und niemand sonst im Internet kann sie erreichen. Genau das willst du, bevor du bereit bist, öffentlich zu gehen. #### Was localhost und der Port bedeuten Eine localhost-Adresse sieht aus wie localhost:3000. "localhost" heisst immer dein eigener Computer, und die Zahl nach dem Doppelpunkt (der Port) ist nur, an welcher Tür der Dev Server lauscht. Verschiedene Tools nutzen verschiedene Ports, also ist 3000, 5173 oder Ähnliches normal und kein Grund zur Sorge. #### Warum der Dev Server besonders ist Ein Dev Server tut mehr, als deine Seite zu zeigen. Er beobachtet deine Dateien und aktualisiert die Seite im Moment, in dem du eine Änderung speicherst, was das Web-Bauen schnell anfühlen lässt. Weil er weiterläuft und beobachtet, "endet" der Befehl nicht und gibt dich nicht an einen Prompt zurück; das ist normal, kein Hänger. #### Lokal ist nicht dasselbe wie live Eine Seite auf localhost ist nicht im Internet. Den localhost-Link mit einem Freund zu teilen, funktioniert für ihn nicht, weil die Adresse auf jeder Maschine nur "dieser Computer" bedeutet. Um deine Seite online zu stellen, deployst du sie zu einem Host wie Vercel, der dir eine echte öffentliche URL gibt, die jeder öffnen kann. #### Häufige Anfänger-Verwirrungen Ein Klassiker ist die Meldung "port already in use", die schlicht heisst, dass von vorher noch ein Dev Server läuft. Die Lösung ist, den alten zu stoppen (Ctrl und C in seinem Terminal) oder das Tool den nächsten freien Port wählen zu lassen. Eine andere ist zu erwarten, dass Änderungen ohne laufenden Dev Server erscheinen; wenn du das Terminal schliesst, stoppt die lokale Seite, was normal ist. Leute verwechseln auch den Dev Server mit dem Production Build. Der Dev Server ist auf schnelles Feedback beim Arbeiten optimiert, nicht auf echte Besucher, also wird eine Live-Seite separat gebaut und deployt. Nichts davon musst du memorieren, aber "lokal" versus "live" früh zu erkennen erspart viel Kopfzerbrechen beim ersten Mal, wenn sich etwas anders verhält als erwartet. ### Repos und Versionskontrolle erklärt - Kanonische URL: https://agenticschool.dev/de/grundlagen/repos-and-version-control Ein Repository (oder "Repo") ist dein Projektordner, sobald er von einem Versionskontroll-Tool getrackt wird, und Versionskontrolle ist das System, das jede Änderung aufzeichnet, damit du immer zurück kannst. Einfach gesagt ist Versionskontrolle eine beschriftete, unbegrenzte Undo-History für dein ganzes Projekt, und das Repo ist das Projekt plus diese History. Das ist das Fundament, auf dem alles andere aufbaut: Backups, Zusammenarbeit und Deployment beginnen alle mit einem Repo unter Versionskontrolle. #### Was Versionskontrolle dir gibt Versionskontrolle verwandelt einen Ordner voller Dateien in etwas, mit dem du furchtlos experimentieren kannst. Jede bedeutsame Änderung wird als Snapshot gespeichert, zu dem du zurück kannst, also ist eine schlechte Änderung nie dauerhaft. Sie zeichnet auch auf, wer was warum geändert hat, was in dem Moment essenziell wird, in dem mehr als eine Person das Projekt anfasst. #### Lokales Repo vs Remote Repo Dein Repo lebt auf deinem Computer (das lokale Repo) und hat meist eine Kopie online (das Remote Repo), am häufigsten auf GitHub. Du arbeitest lokal und "pushst" deine gespeicherten Änderungen ins Remote, um sie zu sichern und zu teilen. Die beiden bleiben synchron, während du Änderungen pushst und pullst. #### Warum das fürs Shippen zählt Ein Repo ist nicht nur für Sicherheit, es ist das, womit sich Hosting-Plattformen verbinden. Wenn dein Projekt ein Repo auf GitHub ist, kann ein Host wie Vercel es beobachten und deine Live-Seite automatisch neu deployen, jedes Mal, wenn du pushst. Ein sauberes Repo unter Versionskontrolle ist also die Auffahrt zum tatsächlichen Shippen deiner Arbeit. #### Häufige Anfänger-Verwirrungen Ein Repo kann sich wie ein mysteriöser Spezialordner anfühlen, aber es ist wirklich nur dein normaler Projektordner mit einer angehängten, versteckten Aufzeichnung der Änderungen. Du bearbeitest Dateien weiterhin auf dieselbe Art. Leute nehmen auch an, ein Repo heisse automatisch, dass alles öffentlich oder gesichert ist; keines stimmt, bis du in ein Remote pushst und seine Sichtbarkeit wählst, und ein brandneues Business-Repo sollte standardmässig privat sein. Ein weiterer Punkt, den man früh verinnerlichen sollte: Die History ist nur so nützlich wie deine Commits. Committest du selten mit vagen Nachrichten, ist das Sicherheitsnetz schwach; committest du oft mit klaren Nachrichten, kannst du mit Vertrauen zu jedem Moment zurück. Diese eine Gewohnheit verwandelt Versionskontrolle von einer Pflicht in eine echte Superkraft. ### Was ist TypeScript? - Kanonische URL: https://agenticschool.dev/de/grundlagen/what-is-typescript TypeScript ist JavaScript mit einer zusätzlichen Schicht Typprüfung, die Fehler abfängt, bevor du deinen Code je ausführst. Es ist dieselbe Sprache, die du schon schreibst, plus Labels, die sagen, welche Art von Wert jedes Ding sein soll, wie Text, eine Zahl oder eine Liste. Wenn du sie aus Versehen vertauschst, warnt dich TypeScript sofort, statt den Fehler später bei einem Nutzer auftauchen zu lassen. Die meisten modernen Projekte, dieses eingeschlossen, nutzen es genau dafür. #### Typen sind Leitplanken Ein Typ ist nur ein Versprechen, was ein Wert ist. Wenn eine Funktion eine Zahl erwartet und du ihr Text gibst, markiert TypeScript es, während du tippst, in deinem Editor, bevor irgendetwas läuft. Das verwandelt eine Klasse frustrierender Laufzeit-Bugs in klare Meldungen, die du in Sekunden behebst. ```typescript function double(n: number) { return n * 2 } double("5") // TypeScript-Fehler: ein String ist keine Zahl ``` Das ": number"-Label ist der Typ. TypeScript fängt den falschen Input ab. #### Es kompiliert zu JavaScript Browser und Node.js führen TypeScript nicht direkt aus. Ein Build-Schritt verwandelt dein TypeScript in schlichtes JavaScript und entfernt die Typ-Labels. TypeScript ist also rein ein Tool für dich beim Schreiben; was tatsächlich ausgeliefert wird, ist gewöhnliches JavaScript. #### Warum es beim Bauen mit KI hilft Wenn ein KI Agent deinen Code bearbeitet, wirkt TypeScript wie ein automatischer Reviewer. Wenn eine Änderung einen erwarteten Typ bricht, scheitert die Typprüfung lautstark, was Fehler abfängt, bevor sie deine Nutzer erreichen. Diese schnelle Feedback-Schleife ist ein Grund, warum agent-gebaute Projekte so stark auf TypeScript setzen. #### Häufige Anfänger-Verwirrungen Die roten Schlangenlinien unter deinem Code können sich wie Fehler anfühlen, die alles stoppen, aber meistens sind es Warnungen, die auf ein echtes Problem zeigen, das du beheben solltest, kein Absturz. Ein Typfehler heisst "dieser Wert hat nicht die Form, die ich erwartet habe", und die Meldung sagt dir meist genau, was schiefging. Anfänger sorgen sich auch, sie müssten überall Typen von Hand hinzufügen; in der Praxis erkennt TypeScript die meisten Typen selbst, und dein Agent fügt den Rest hinzu. Schliesslich verwechsle die scheiternde Typprüfung nicht damit, dass deine App zur Laufzeit kaputt ist. Der ganze Sinn ist, dass TypeScript das Problem abfängt, bevor du etwas ausführst, also ist eine scheiternde Typprüfung das System, das seine Arbeit tut, kein Zeichen, dass etwas brennt. ### Was ist ein Framework? - Kanonische URL: https://agenticschool.dev/de/grundlagen/what-is-a-framework Ein Framework ist eine fertige Struktur, um Apps zu bauen, die die üblichen, schwierigen Teile für dich übernimmt, damit du nicht jedes Mal mit einer leeren Seite anfängst. Statt Routing, Rendering und Projektstruktur von Hand zu verdrahten, gibt dir ein Framework sinnvolle Voreinstellungen und Konventionen, und du füllst aus, was deine App einzigartig macht. Fast jede moderne Website baut auf einem, weil es Monate an Verkabelung in etwas verwandelt, das du in Minuten aufstellst. #### Ein Haus mit schon stehenden Wänden Stell dir ein Framework wie ein Haus vor, in dem Fundament, Wände und Leitungen schon da sind. Du gestaltest weiterhin die Räume und entscheidest, wie du darin lebst, aber du giesst keinen Beton. Das Framework trifft die Entscheidungen, die für fast jede App gleich sind, und lässt dich frei, dich auf die Teile zu konzentrieren, die tatsächlich deine sind. #### Frameworks, von denen du hörst Du musst diese nicht meistern, nur die Namen erkennen, wenn ein Agent oder Tutorial eines erwähnt. - Next.js: ein beliebtes React-Framework für vollwertige Web-Apps. - Astro: super für schnelle, inhaltsreiche Seiten und Marketing-Seiten. - TanStack Start: ein modernes React-Framework, von genau diesem Projekt genutzt. #### Warum es fürs Bauen mit KI zählt Ein Framework gibt einem KI Agent eine bekannte Struktur, in der er arbeitet, mit klaren Konventionen, wo was hingehört. Das macht den Agent verlässlicher, weil er eine vertraute Form ausfüllt, statt eine zu erfinden. Ein gängiges Framework zu wählen ist eine der einfachsten Arten, bessere Ergebnisse aus agent-gebauten Projekten zu bekommen. #### Häufige Anfänger-Verwirrungen Es ist leicht zu denken, du müsstest das "beste" Framework wählen, bevor du anfangen kannst, und an dieser Entscheidung zu erstarren. In Wirklichkeit trägt dich jedes gängige Framework weit, und später zu wechseln ist selten und selten fatal, also sind die Kosten einer nicht perfekten Wahl gering. Leute vermischen Frameworks auch mit Sprachen: Ein Framework baut auf einer Sprache auf, also sind React-Frameworks wie Next.js oder TanStack Start darunter immer noch JavaScript und TypeScript. Und ein Framework ist kein No-Code-Tool, das deine App für dich baut; es ist ein strukturierter Startpunkt, in dem du baust. Die Hebelwirkung kommt davon, ein vertrautes Framework mit einem KI Agent zu paaren, der seine Konventionen kennt und die Form viel schneller ausfüllt als von Grund auf zu bauen. --- ## Glossar ### KI Agent - Kanonische URL: https://agenticschool.dev/de/glossar/ai-agent Ein KI Agent ist ein Software-System, das ein grosses Sprachmodell nutzt, um ein Ziel zu verfolgen: Es entscheidet, was als Nächstes zu tun ist, führt eine Aktion aus, beobachtet das Ergebnis und wiederholt diese Schleife, bis die Aufgabe erledigt ist. Der Hauptunterschied zu einem normalen Chatbot ist die Schleife und die Tools: Statt nur mit Text zu antworten, kann ein Agent Tools aufrufen (im Web suchen, Code ausführen, eine API abfragen, eine Datei bearbeiten), lesen, was zurückkommt, und seinen nächsten Schritt anpassen. Ein KI Agent ist also das Modell plus die Fähigkeit zu handeln plus die Autonomie, seine eigenen Schritte zu einem Ergebnis zu wählen, das du vorgibst. #### Agent vs Chatbot vs Assistent Ein Chatbot beantwortet eine Nachricht nach der anderen und handelt nicht auf der Welt. Ein KI Agent bekommt ein Ziel und arbeitet über mehrere Schritte darauf hin und wählt die Aktionen selbst. Die Grenze ist Autonomie plus Tool-Nutzung, nicht das zugrunde liegende Modell. - Chatbot: Du schickst eine Nachricht, er antwortet mit Text. Keine Aktionen, keine Schleife. - Assistent: Hilft bei einer Aufgabe, aber du steuerst jeden Schritt. - KI Agent: Du setzt ein Ziel, er plant, ruft Tools auf, prüft Ergebnisse und iteriert bis fertig. #### Die Agent-Schleife Fast jeder KI Agent läuft in derselben Schleife: Das Modell liest das Ziel und den aktuellen Zustand, entscheidet sich für eine Aktion, das System führt sie aus (ein Tool-Aufruf), das Ergebnis fliesst zurück, und die Schleife wiederholt sich. Dieser Zyklus aus Wahrnehmen, Entscheiden, Handeln, Beobachten ist das, was einen Agenten Arbeit erledigen lässt, die ein einzelner Prompt nicht schafft, etwa einen fehlschlagenden Test reparieren oder ein kleines Feature von Anfang bis Ende ausliefern. #### Ein konkretes Beispiel Ein Coding Agent wie Claude Code ist ein klares Beispiel. Du sagst ihm "füge ein Kontaktformular hinzu und mach, dass die Tests durchlaufen". Er liest deine Dateien (ein Tool), schreibt neuen Code (ein Tool), führt die Testsuite aus (ein Tool), sieht einen Fehler, bearbeitet den Code erneut und lässt die Tests wieder laufen, bis sie grün sind. Du setzt das Ziel einmal; der Agent wählte und führte jeden Schritt dazwischen aus. Das ist der agentische Unterschied in der Praxis. ### Agentic AI - Kanonische URL: https://agenticschool.dev/de/glossar/agentic-ai Agentic AI ist künstliche Intelligenz, die autonom auf ein Ziel hin handelt: Sie plant ihre eigenen Schritte und nutzt Tools, um dorthin zu gelangen, statt nur auf Anfrage eine einzelne Antwort zu liefern. Wo generative KI dir für jeden Prompt eine Ausgabe gibt (einen Absatz, ein Bild, einen Codeblock), nimmt Agentic AI ein Ziel und treibt einen mehrstufigen Prozess voran, um es zu erreichen: Sie entscheidet, was zu tun ist, tut es, prüft das Ergebnis und macht weiter. Kurz gesagt: Generative KI erzeugt Inhalte; Agentic AI erledigt Dinge. Sie ist die breitere Fähigkeit, die einzelne KI Agents in die Praxis umsetzen. #### Agentic AI vs generative KI Sie sind keine Gegensätze; Agentic AI baut meist auf generativen Modellen auf. Der Unterschied liegt darin, was das System mit dem Modell macht. Generative KI antwortet. Agentic AI handelt: Sie setzt Teilziele, ruft Tools auf und passt sich an das an, was sie beobachtet, alles, um ein Ergebnis zu erreichen, das du einmal definiert hast. - Generative KI: Prompt rein, Inhalt raus. Ein Schritt, keine Aktionen auf der Welt. - Agentic AI: Ziel rein, Ergebnis raus. Viele Schritte, echte Aktionen, Selbstkorrektur. - Ein "KI Agent" ist ein einzelnes konkretes System, das agentisches Verhalten zeigt. #### Was ein System agentisch macht Drei Eigenschaften tauchen über agentische Systeme hinweg auf: Autonomie (es wählt seinen nächsten Schritt selbst), Tool-Nutzung (es kann handeln, nicht nur reden) und eine Feedback-Schleife (es beobachtet Ergebnisse und passt sich an). Je mehr einer Aufgabe ein System tragen kann, ohne dass du jeden Schritt steuerst, desto agentischer ist es. Oft wird das auf einem Spektrum beschrieben, von einem einfachen Assistenten bis hin zu voll autonomen Multi-Agent-Systemen. #### Wo du es schon siehst Coding Agents, die ein Ticket nehmen und einen funktionierenden Pull Request öffnen, Research Agents, die Quellen sammeln und zusammenführen, und Automationen, die auf ein Ereignis warten und eine mehrstufige Aufgabe erledigen, sind alle Agentic AI. Für Builder ist die praktische Erkenntnis: Agentic AI verlagert deine Arbeit vom Schreiben jeder Anweisung hin zum Setzen klarer Ziele, dem Bereitstellen der richtigen Tools und des richtigen Kontexts und dem Behalten der Verifizierung im Loop. ### Vibe Coding - Kanonische URL: https://agenticschool.dev/de/glossar/vibe-coding Vibe Coding ist eine Art, Software zu bauen, bei der du in natürlicher Sprache beschreibst, was du willst, und ein KI-Coding-Tool den Code schreiben lässt, sodass du über das Ergebnis steuerst statt jede Zeile selbst zu lesen und zu schreiben. Den Begriff prägte Andrej Karpathy im Februar 2025 mit den Worten "I just see stuff, say stuff, run stuff, and copy-paste stuff, and it mostly works", und er wurde vom Collins Dictionary zum Wort des Jahres 2025 gekürt. Kurz gesagt: Beim Vibe Coding gibst du den Vibe und das Ziel vor, die KI liefert die Umsetzung, und du prüfst, ob sie tut, was du wolltest. #### Wie Vibe Coding funktioniert Du promptest ein KI-Tool in Alltagssprache ("füge einen Dark-Mode-Toggle hinzu", "behebe diesen Fehler"), es generiert oder bearbeitet den Code, du führst ihn aus und machst weiter, indem du die nächste Änderung beschreibst. Du verlässt dich auf die Ausgabe und die laufende App, um den Fortschritt zu beurteilen, statt den Code genau zu prüfen. Das macht das Bauen schnell und zugänglich, bedeutet aber auch, dass du Code vertraust, den du vielleicht nicht vollständig verstehst. - Du beschreibst das Ziel in klarer Sprache, nicht in Code. - Die KI schreibt, bearbeitet und führt den Code oft für dich aus. - Du beurteilst den Erfolg am Ergebnis und promptest dann die nächste Änderung. #### Wo es glänzt und wo es beisst Vibe Coding ist ideal für Prototypen, Wegwerf-Skripte, das Lernen und um schnell eine erste Version auf den Bildschirm zu bekommen. Das Risiko zeigt sich, wenn vibe-codete Software zu echten Nutzern geht: Code, den du nie geprüft hast, kann Sicherheitslücken verstecken, in Sonderfällen brechen oder unwartbar werden. Die ehrliche Praxis ist, beim Erkunden frei zu vibe-coden und dann langsamer zu werden, den Code zu lesen, Tests hinzuzufügen und ihn zu härten, bevor irgendetwas live geht. #### Vibe Coding vs Agentic Engineering Vibe Coding und Agentic Engineering nutzen beide KI zum Schreiben von Code, sind aber nicht dasselbe. Vibe Coding optimiert auf Tempo und Gefühl und nimmt in Kauf, das Ergebnis nicht zu verstehen. Agentic Engineering behält dich am Steuer: Du treibst weiterhin einen KI Agent, aber mit klaren Zielen, Tests, Reviews und Verifizierung, sodass das Ergebnis produktionsreif ist. Sieh Vibe Coding als die unterhaltsame Auffahrt und Agentic Engineering als den Weg, daraus etwas zu machen, dem du in Produktion vertrauen kannst. ### MCP (Model Context Protocol) - Kanonische URL: https://agenticschool.dev/de/glossar/mcp MCP (Model Context Protocol) ist ein offener Standard, der KI-Modelle über eine einzige gemeinsame Schnittstelle mit externen Tools, Datenquellen und Diensten verbindet, statt dass jede App ihre eigene Integration erfindet. Es wird oft als USB-C-Anschluss für KI beschrieben: Jedes MCP-kompatible Modell kann sich an jeden MCP-Server anschliessen und sofort nutzen, was er bietet. Ein MCP-Server stellt drei Arten von Fähigkeiten bereit - Tools (Aktionen, die das Modell ausführen kann), Resources (Daten zum Lesen) und Prompts (wiederverwendbare Vorlagen) - sodass ein Modell in der echten Welt arbeiten kann, ohne für jede Verbindung eigenen Klebecode zu brauchen. #### Warum es MCP gibt Vor MCP bedeutete das Verbinden eines Modells mit einer Datenbank, einem Dateisystem oder einer API massgeschneiderten Integrationscode für jede Paarung, was nicht skaliert. MCP standardisiert diesen Vertrag einmal: Schreibe einen MCP-Server für ein System, und jeder MCP-fähige Client (Claude Code, eine IDE, eine Chat-App) kann ihn nutzen. Von Anthropic Ende 2024 eingeführt, ist es zum De-facto-Standard geworden, mit offiziellen SDKs für TypeScript, Python, C#, Java und Swift und Hunderten öffentlichen Servern bis 2026. #### Tools, Resources und Prompts Ein MCP-Server kann jede Mischung aus drei Primitiven bereitstellen, jedes mit einer standardisierten Art, es aufzulisten und zu nutzen. - Tools: Aktionen, die das Modell aufrufen kann, etwa "führe eine Abfrage aus" oder "erstelle eine Datei". Das ist Tool Calling über ein gemeinsames Protokoll. - Resources: Daten zum Lesen, die das Modell holen kann, etwa ein Dokument, eine Datenbankzeile oder ein Log. - Prompts: wiederverwendbare Prompt-Vorlagen, die ein Server anbietet, damit Clients einen konsistenten Startpunkt erhalten. #### Wie eine Verbindung funktioniert Eine Host-Anwendung (die KI-App) betreibt einen oder mehrere Clients, und jeder Client hält eine dedizierte Verbindung zu genau einem MCP-Server. Wenn das Modell handeln muss, bittet es den Client, ein Tool auf dem Server aufzurufen; der Server erledigt die eigentliche Arbeit (etwa eine SQL-Abfrage) und gibt ein strukturiertes Ergebnis zurück, das das Modell lesen kann. Das Modell berührt die Datenbank nie direkt, was Berechtigungen und Sicherheit im Server hält, wo du sie kontrollierst. ### llms.txt - Kanonische URL: https://agenticschool.dev/de/glossar/llms-txt llms.txt ist eine einfache Markdown-Datei, die du im Wurzelverzeichnis deiner Website ablegst (unter /llms.txt), um KI-Systemen eine saubere, kuratierte Karte deiner wichtigsten Inhalte zu geben. Statt ein Modell zu zwingen, dein HTML, deine Werbung und Skripte zu crawlen und zu erraten, reichst du ihm eine kurze strukturierte Zusammenfassung plus Links zu den Seiten, die zählen. Sie wurde im September 2024 von Jeremy Howard von Answer.AI vorgeschlagen und ist für KI-Leser ungefähr das, was eine Sitemap oder robots.txt für Such-Crawler ist: eine freundliche, maschinen-zuerst gedachte Eingangstür zu deiner Site. #### Wie die Datei aussieht Das Format ist bewusst klein. Eine gültige llms.txt beginnt mit einer einzigen H1 mit dem Namen deiner Site oder deines Projekts (der einzige strikt erforderliche Teil), gefolgt von einem Blockquote mit einer ein- bis zweisätzigen Zusammenfassung, dann optionale Abschnitte. Jeder Abschnitt ist eine H2-Überschrift mit einer Markdown-Liste von Links, wobei jeder Link aus Titel, URL und einer kurzen Beschreibung besteht. In der Praxis kuratiert eine gute Datei rund 15 bis 60 deiner wichtigsten Seiten, statt alles aufzulisten. ```markdown # Dein Site-Name > Eine Zeile dazu, was deine Site ist und für wen. ## Docs - [Erste Schritte](https://example.com/start): In fünf Minuten startklar. - [API-Referenz](https://example.com/api): Jeder Endpunkt mit Beispielen. ``` Eine minimale, spec-korrekte llms.txt: H1, Blockquote-Zusammenfassung, dann H2-Link-Abschnitte. #### llms.txt vs llms-full.txt Es gibt zwei verwandte Dateien. llms.txt ist der kurze, kuratierte Index aus Links und Beschreibungen. Die optionale llms-full.txt fügt den eigentlichen Inhalt dieser Seiten zu einem grossen Dokument zusammen, sodass ein System, das deinen ganzen Korpus in einer Anfrage will, ihn greifen kann. Viele Sites veröffentlichen beide: den Index zum Entdecken und die volle Datei zum tiefen Einlesen. #### Hilft es wirklich? Die Verbreitung ist real, aber uneinheitlich. Entwickler-Tools wie Cursor und viele Dokumentationsplattformen lesen llms.txt, und Anthropic dokumentiert Unterstützung dafür, aber bis 2026 haben sich Google und OpenAI nicht offiziell zur Nutzung verpflichtet. Behandle llms.txt also als kostengünstigen, markenpassenden Teil deiner AEO- und GEO-Strategie statt als garantierten Ranking-Hebel: Sie macht deine Site günstig und eindeutig für KI verständlich und ergänzt guten Inhalt und eine Sitemap, ersetzt sie aber nicht. ### Agent Harness - Kanonische URL: https://agenticschool.dev/de/glossar/agent-harness Ein Agent Harness ist das Software-Gerüst, das um ein KI-Modell gelegt wird und es zu einem funktionierenden Agenten macht: Es betreibt die Schleife, die das Modell aufruft, verarbeitet die Tool-Aufrufe des Modells, verwaltet Kontext und Memory, setzt Sicherheit durch und entscheidet, wann gestoppt wird. Das Modell selbst sagt nur die nächsten Tokens voraus; das Harness ist alles drumherum, das es wahrnehmen, handeln und auf ein Ziel hin iterieren lässt. Eine praktische Wahrheit 2026 ist, dass das Harness oft so wichtig ist wie das Modell, denn zwei Tools mit demselben Modell können sich je nach Qualität ihres Harness sehr unterschiedlich verhalten. #### Was das Harness tut Das Harness ist die Laufzeit, die einen ganzen Agent-Lauf orchestriert. Es baut den Prompt, stellt die verfügbaren Tools bereit, führt die vom Modell angeforderten Tool-Aufrufe aus, gibt Ergebnisse zurück, verdichtet oder kürzt den Kontext, wenn er voll wird, hält den Zustand über Schritte hinweg fest und wendet Leitplanken wie Berechtigungsprüfungen und Stoppbedingungen an. - Betreibt die Schleife: Modell aufrufen, angeforderte Tools ausführen, Ergebnisse zurückgeben, wiederholen. - Verwaltet Kontext: setzt den Prompt zusammen, verdichtet die Historie, handhabt das Context Window. - Setzt Sicherheit durch: Berechtigungen, Freigaben für riskante Aktionen und wann gestoppt wird. #### Harness vs Scaffolding vs Modell Diese Begriffe verschwimmen, daher hilft es, sie zu trennen. Scaffolding ist das Setup vor dem ersten Prompt (Tools definieren, System Prompt, Konfiguration). Das Harness ist alles, was danach passiert: Tools verteilen, Kontext verdichten, Regeln durchsetzen, Zustand über Schritte hinweg halten. Das Modell ist die Reasoning-Engine im Inneren. Claude Code, Codex CLI, Cursor, Aider und Cline sind alle Beispiele für Agent Harnesses, und ihre Muster nähern sich einander an. #### Warum es bei der Tool-Wahl zählt Weil das Harness Kontextverwaltung, Tool-Zugriff und Sicherheit steuert, ist die Wahl eines KI-Coding-Tools weitgehend eine Wahl des Harness, nicht nur des Modells. Ein starkes Harness hält das Modell bei langen Aufgaben auf Kurs, vermeidet, das Context Window zu verbrennen, und stoppt, bevor es etwas Zerstörerisches tut. Wenn Leute sagen, ein Coding Agent "fühle sich schlauer an", meinen sie oft, dass sein Harness besser gebaut ist. ### Subagent - Kanonische URL: https://agenticschool.dev/de/glossar/subagent Ein Subagent ist ein spezialisierter KI Agent, an den ein Hauptagent eine fokussierte Aufgabe delegiert, der in seinem eigenen separaten Context Window mit eigenem System Prompt und eigenem abgegrenzten Satz an Tools läuft. Statt dass ein Agent alles in einer einzigen Konversation erledigt, übergibt der Hauptagent einen Job (prüfe diesen Code, recherchiere dieses Thema, führe diese Tests aus) an einen Subagent, der die Arbeit isoliert erledigt und nur eine saubere Zusammenfassung zurückgibt. Das hält die Hauptkonversation aufgeräumt und erlaubt es, jeden Subagent darauf zu trimmen, eine Sache gut zu machen. #### Wie Subagents funktionieren Wenn der Hauptagent einen Subagent startet, beginnt dieser von vorn: Er sieht nur seinen eigenen System Prompt und die Delegationsnachricht, nicht die gesamte Historie der Hauptsitzung. Er arbeitet mit einem schmalen Toolset und schmalen Berechtigungen, erledigt seine Aufgabe und gibt ein kurzes Ergebnis zurück. Weil sein Kontext isoliert ist, bleibt all die laute Zwischenarbeit (Suchergebnisse, Logs, Datei-Dumps) aus dem Context Window des Hauptagenten heraus. - Separates Context Window: Der Subagent erbt nicht die ganze Hauptkonversation. - Eigener System Prompt: ein kurzer, fokussierter Auftrag, auf seinen einen Job getrimmt. - Abgegrenzte Tools und Berechtigungen: nur was die Aufgabe braucht, oft nur lesend. #### Warum Subagents helfen Der grosse Gewinn ist Kontext-Hygiene. Eine Nebenaufgabe, die deine Hauptsitzung mit Ausgaben fluten würde (Dutzende Dateien lesen, Logs durchsuchen), passiert stattdessen im Subagent und gibt nur die Zusammenfassung zurück, sodass der Hauptagent fokussiert bleibt und das Context Window nicht vollläuft. Ein fokussierter Auftrag macht den Subagent bei seiner Spezialaufgabe auch zuverlässiger als einen einzelnen Agenten, der alles jongliert. #### Ein konkretes Beispiel In Claude Code kannst du einen "Code-Reviewer"-Subagent mit einem nur lesenden Toolset und einem kurzen Review-Auftrag definieren. Nachdem der Hauptagent ein Feature geschrieben hat, delegiert er das Review an diesen Subagent, der den Diff in seinem eigenen Kontext prüft und eine knappe Liste von Problemen zurückgibt. Der Hauptagent behebt sie dann, ohne je das ganze Review-Reasoning in sein eigenes Window geladen zu haben. ### Tool Calling - Kanonische URL: https://agenticschool.dev/de/glossar/tool-calling Tool Calling, auch Function Calling genannt, ist, wenn ein KI-Modell strukturierte Ausgabe (meist JSON) erzeugt, die dein Programm bittet, eine bestimmte Funktion auszuführen, statt nur mit Text zu antworten. Das Modell führt die Funktion nicht selbst aus; es wählt, welches Tool genutzt wird, füllt die Argumente in einem Format aus, das einem von dir definierten Schema entspricht, und dein Code führt sie aus und gibt das Ergebnis zurück. Tool Calling ist der Kernmechanismus, der aus einem Chatbot einen Agenten macht: So holt ein Modell Live-Daten, führt Code aus, fragt eine Datenbank ab oder sendet eine E-Mail. #### Wie Tool Calling funktioniert Du gibst dem Modell eine Liste von Tools, jedes beschrieben durch ein JSON-Schema: den Tool-Namen, was es tut und die Parameter mit ihren Typen. Wenn das Modell entscheidet, dass ein Tool nötig ist, gibt es einen strukturierten Aufruf mit dem gewählten Tool und den Argumenten zurück. Deine Laufzeit parst das, führt die echte Funktion aus und gibt die Ausgabe an das Modell zurück, damit es weitermachen kann - vielleicht weitere Tools aufrufend -, bis es antworten kann. - Du definierst Tools als JSON-Schemas: Name, Beschreibung, typisierte Parameter. - Das Modell gibt einen strukturierten Aufruf zurück (Tool-Name plus Argumente), nicht freien Text. - Dein Code führt die Funktion aus und gibt das Ergebnis an das Modell zurück. #### Warum es zählt Tool Calling überbrückt probabilistisches Reasoning und deterministische Ausführung. Das Modell ist gut darin, zu entscheiden, was zu tun ist; dein Code ist gut darin, es zuverlässig zu tun. Indem du das Modell zwingst, einen strukturierten Aufruf auszugeben, der einem Schema entspricht, bekommst du verlässliche, maschinenlesbare Aktionen, statt zu hoffen, dass es eine Anfrage in Prosa korrekt formatiert. Das ist die Grundlage unter KI Agents und unter Standards wie MCP, die Tools über ein gemeinsames Protokoll bereitstellen. #### Tool Calling und MCP Tool Calling ist der lokale Mechanismus: Tools, die für ein Modell in einer App definiert sind. MCP (Model Context Protocol) standardisiert es über das Ökosystem hinweg, sodass ein MCP-Server Tools anbieten kann, die jeder MCP-fähige Client ohne eigene Verdrahtung aufrufen kann. Einfach gesagt: Tool Calling ist das Verb, und MCP ist eine weit verbreitete Art, diese Tools überall wiederverwendbar zu machen. ### System Prompt - Kanonische URL: https://agenticschool.dev/de/glossar/system-prompt Ein System Prompt ist die stehende Anweisung, die einem KI-Modell vor jeder Nutzernachricht gegeben wird und ihm sagt, wer es ist, wie es sich verhalten, welchen Regeln es folgen und welches Format es nutzen soll. Wo ein User Prompt die konkrete Anfrage ist, die du tippst, ist der System Prompt der dauerhafte Kontext, der die ganze Konversation rahmt: Rolle, Tonfall, Einschränkungen des Modells und alle Tools oder Wissensstände, die es voraussetzen soll. Er wird einmal vom Entwickler (oder von dir in einer Settings-Datei) gesetzt und gilt für jeden Schritt, bis er sich ändert. #### System Prompt vs User Prompt Die beiden arbeiten zusammen, erfüllen aber verschiedene Aufgaben. Der System Prompt ist die Konfiguration; der User Prompt ist die Aufgabe. Modelle sind darauf trainiert, den System Prompt als höher priorisierte, stehende Leitlinie zu behandeln, also gehören dorthin Regeln, die unabhängig davon gelten sollen, was der Nutzer fragt. - System Prompt: Rolle, Regeln, Tonfall, Format, Einschränkungen. Einmal gesetzt, gilt durchgehend. - User Prompt: die konkrete Frage oder Anweisung für diesen Schritt. - Das Modell gewichtet den System Prompt als dauerhaften, höher priorisierten Kontext. #### Was in einen guten System Prompt gehört Ein starker System Prompt nennt die Rolle ("du bist ein erfahrener TypeScript-Engineer"), die Regeln ("nie Em-Dashes verwenden", "immer die Tests ausführen"), das erwartete Ausgabeformat und jeden Kontext, den das Modell als gegeben behandeln soll. Halte ihn klar und spezifisch; vage System Prompts erzeugen vages Verhalten. In Agent-Tools wirken Dateien wie eine Projekt-Anweisungsdatei als System Prompt, der dem Agenten deine Konventionen beibringt. #### System Prompts in Agents In einem Agent Harness ist der System Prompt Teil dessen, was das Harness jeden Schritt zusammensetzt, und er zählt gegen das Context Window, also sollte er fokussiert statt aufgebläht sein. Subagents gehen weiter: Jeder Subagent bekommt seinen eigenen kurzen, spezialisierten System Prompt, der auf seine eine Aufgabe getrimmt ist, was ein Grund ist, warum sie sich zuverlässig verhalten. Weil der System Prompt bei jeder Anfrage gesendet wird, ist er auch ein erstklassiger Kandidat für Prompt Caching, um Kosten zu senken. ### Context Window - Kanonische URL: https://agenticschool.dev/de/glossar/context-window Ein Context Window ist die maximale Textmenge, die ein KI-Modell auf einmal berücksichtigen kann, gemessen in Tokens. Es umfasst alles, was im Spiel ist: den System Prompt, die Dateien oder Daten, die du einfügst, die bisherige Konversation und die Antwort, die das Modell schreibt. Stell es dir als das Arbeitsgedächtnis des Modells vor: Alles im Window kann die Antwort beeinflussen, und sobald das Window voll ist, fällt der älteste Inhalt praktisch aus dem Blick. Die Grösse des Context Window zu kennen und zu steuern, was du hineinlegst, ist zentral für gute, bezahlbare Ergebnisse. #### Warum das Context Window zählt Das Context Window setzt eine harte Obergrenze, wie viel das Modell auf einen Schlag berücksichtigen kann. Wenn deine Anweisungen, dein Code und der Verlauf es überschreiten, muss etwas gestrichen oder zusammengefasst werden, und das Modell kann Details verlieren, die du früher gegeben hast. Darum verlieren lange, ausufernde Chats den Faden, und darum schlägt eine frische, fokussierte Konversation oft das Anhäufen auf einer alten. - Alles zählt: System Prompt, eingefügte Dateien, Verlauf und die Ausgabe teilen sich das Window. - Wenn es voll wird, wird der älteste Inhalt gestrichen oder verdichtet und kann vergessen werden. - Grösser ist nicht immer besser: Ein vollgestopftes Window kann das entscheidende Detail trotzdem begraben. #### Grössen und das "Lost in the Middle"-Problem Context Windows sind gross geworden, mit führenden Modellen 2026, die Hunderttausende Tokens bieten, und manche eine Million erreichen, genug, um eine ganze Codebase zu halten. Aber mehr Platz ist kein Freibier: Modelle können Informationen weniger Aufmerksamkeit schenken, die in der Mitte eines langen Kontexts vergraben sind, ein Effekt, der oft "Lost in the Middle" genannt wird. Den wichtigsten Kontext also nahe an Anfang oder Ende zu setzen und ihn relevant zu halten, schlägt weiterhin das Hineinkippen von allem. #### Das Context Window steuern Agent Harnesses stecken hier viel Aufwand hinein: Sie verdichten ältere Schritte zu Zusammenfassungen, kürzen irrelevanten Inhalt und lagern laute Nebenarbeit an Subagents aus, damit das Haupt-Window sauber bleibt. Die praktische Regel für dich ist dieselbe wie bei den Kosten: weniger, aber relevanteren Text senden. Gute Kontextverwaltung ist eine eigene Disziplin, manchmal Context Engineering genannt, und eine der hebelstärksten Fähigkeiten beim Bauen mit Agents. ### Prompt Caching - Kanonische URL: https://agenticschool.dev/de/glossar/prompt-caching Prompt Caching ist eine Funktion, die den verarbeiteten Zustand eines wiederholten Prompt-Teils speichert, sodass spätere Anfragen ihn wiederverwenden, statt erneut für die Verarbeitung zu zahlen. Wenn viele Anfragen denselben langen Anfang teilen - einen grossen System Prompt, Tool-Definitionen oder ein Dokument, nach dem du immer wieder fragst -, lässt Caching das Modell die Neuberechnung überspringen, was sowohl Kosten als auch Latenz senkt. In der Claude API kostet ein Cache-Read zum Beispiel etwa ein Zehntel des normalen Input-Preises, ein Rabatt von rund 90 Prozent auf den gecachten Teil. #### Wie Prompt Caching funktioniert Du markierst einen Punkt in deinem Prompt als Cache-Breakpoint. Der Anbieter speichert den codierten Zustand von allem bis zu diesem Punkt, und die nächste Anfrage, die mit denselben exakten Bytes beginnt, liest aus dem Cache statt neu zu berechnen. Der Treffer muss exakt sein: Weicht auch nur ein Token im Anfang ab, gibt es einen Cache-Miss und du zahlst den vollen Preis. Auch die Reihenfolge zählt, denn der Prompt wird als Tools, dann System Prompt, dann Messages gehasht. - Setze den stabilen, wiederholten Inhalt nach vorne (Tools, System Prompt, lange Dokumente). - Markiere danach einen Cache-Breakpoint; der Anfang bis dorthin wird gecacht. - Eine spätere Anfrage mit identischem Anfang liest den Cache günstig. #### Was es kostet und spart Es gibt einen kleinen Aufschlag, um den Cache zu schreiben, und eine grosse Ersparnis, ihn zu lesen. In der Claude API kostet ein Cache-Write etwa das 1,25-Fache des normalen Inputs für eine Lebensdauer von 5 Minuten (oder das 2-Fache für 1 Stunde), während ein Cache-Read etwa das 0,1-Fache des Inputs kostet, eine Ersparnis von rund 90 Prozent. Der Cache ist flüchtig mit einer kurzen Lebensdauer, die sich bei jedem Read zurücksetzt, sodass eine rege Konversation ihren Cache warmhält, ohne die Write-Kosten erneut zu zahlen. #### Wann man es nutzt Prompt Caching zahlt sich aus, wann immer du einen grossen, stabilen Anfang über viele Aufrufe wiederverwendest: einen langen System Prompt, einen festen Satz an Tool-Definitionen, ein Wissensdokument oder einen Mehrschritt-Chat, in dem der frühe Kontext gleich bleibt. Es hilft nicht bei einmaligen Prompts, die sich nie wiederholen. Weil die Ersparnis nur für den unveränderten Anfang gilt, strukturiere deine Prompts so, dass die konstanten Teile zuerst und die variablen Teile zuletzt kommen. ### AI IDE - Kanonische URL: https://agenticschool.dev/de/glossar/ai-ide Eine AI IDE ist ein Code-Editor (Integrated Development Environment) mit einem KI-Coding-Agent, der tief eingebaut ist, sodass die KI dein ganzes Projekt verstehen, Code über viele Dateien hinweg schreiben und bearbeiten und Aufgaben erledigen kann, ohne dass du den Editor verlässt. Sie geht über einfaches Autocomplete hinaus: Eine AI IDE hat projektweiten Kontext, ein Chat- oder Agent-Panel und die Fähigkeit, mehrere Dateien gleichzeitig zu ändern, die du inline prüfst. Cursor und Windsurf sind die bekanntesten Beispiele, und viele klassische Editoren ergänzen jetzt AI-IDE-Funktionen über Erweiterungen. #### AI IDE vs Autocomplete vs Terminal-Agent Es gibt ein Spektrum an KI-Coding-Tools. Eine AI IDE sitzt in der Mitte: Sie ist ein vollwertiger Editor, in dem die KI dein Projekt sieht und über Dateien hinweg bearbeitet, während du die Änderungen visuell prüfst. Das ist mehr als Inline-Autocomplete und etwas anderes als ein terminalbasierter Agent. - Autocomplete (wie Copilot): schlägt die nächsten Zeilen vor, während du tippst. - AI IDE (wie Cursor, Windsurf): vollwertiger Editor mit projektbewusstem Agent, der über Dateien hinweg bearbeitet. - Terminal-Agent (wie Claude Code, Codex CLI): ein Agent, der im Terminal lebt und dein Repo steuert. #### Was einen Editor zur AI IDE macht Die prägenden Merkmale sind projektweites Verständnis und agentisches Bearbeiten. Die KI kann deine Codebase indexieren, Fragen dazu beantworten und koordinierte Änderungen über mehrere Dateien hinweg anwenden, dann einen Diff zum Annehmen oder Ablehnen zeigen. Du bleibst an einem Ort, um zu chatten, zu generieren, zu bearbeiten und zu prüfen, was eine enge Feedback-Schleife hält. Im Inneren ist eine AI IDE ein Agent Harness mit einem grafischen Editor als Front-End. #### Wie man wählt AI IDEs passen zu Leuten, die einen visuellen Editor mögen und jede Änderung im Kontext sehen und freigeben wollen, was sie zum Lernen und für Frontend-Arbeit angenehm macht. Terminal-Agents passen zu denen, die maximale Automation und Scripting wollen. Viele Builder nutzen beides: eine AI IDE für handnahes Bearbeiten und einen Terminal-Agent für längere, autonomere Aufgaben. Die richtige Wahl hängt davon ab, ob du einen visuellen, review-lastigen Workflow oder einen handsfreieren bevorzugst. ### Workflow Automation - Kanonische URL: https://agenticschool.dev/de/glossar/workflow-automation Workflow Automation ist der Einsatz von Software, um einen mehrstufigen Prozess automatisch auszuführen, sodass eine sich wiederholende Aufgabe von selbst geschieht, statt dass jemand jeden Schritt von Hand macht. Ein Workflow ist einfach eine Abfolge: Ein Trigger startet ihn (eine neue E-Mail, ein Formular, ein Zeitplan), dann läuft eine Reihe von Aktionen der Reihe nach (Daten speichern, eine Nachricht senden, einen Datensatz aktualisieren). Tools wie n8n, Zapier und Make lassen dich diese Abläufe visuell bauen, und KI hinzuzufügen macht aus starren Automationen solche, die in klarer Sprache lesen, entscheiden und schreiben können. #### Trigger, Aktionen, Ergebnis Jede Automation folgt derselben Form. Etwas stösst sie an, dann laufen Schritte automatisch, bis der Job erledigt ist, ohne dass jemand sich durch jeden einzelnen klickt. - Trigger: das Ereignis, das den Ablauf startet (neuer Lead, eingehende E-Mail, eine Uhrzeit). - Aktionen: die geordneten Schritte, die laufen (filtern, transformieren, eine API aufrufen, benachrichtigen). - Ergebnis: das früher manuelle Resultat geschieht nun jedes Mal, konsistent. #### Wie KI es verändert Klassische Automation ist regelbasiert: wenn dies, dann genau das. Sie bricht an allem Unscharfen, etwa eine Freitext-E-Mail zu verstehen oder ein Dokument zusammenzufassen. Einen KI-Schritt in einen Workflow zu setzen, übernimmt die unsauberen Teile: Er kann eine Nachricht klassifizieren, die Schlüsselfelder extrahieren, eine Antwort entwerfen oder entscheiden, welcher Zweig zu nehmen ist. Hier beginnt Workflow Automation sich mit KI Agents zu überschneiden, die darauf noch eine eigene Entscheidungsschleife legen. #### Automation vs Agents Eine Workflow Automation läuft einen festen Pfad, den du entworfen hast; sie ist vorhersehbar und leicht zu prüfen. Ein KI Agent entscheidet seine eigenen Schritte auf ein Ziel hin, was flexibler, aber weniger vorhersehbar ist. Viele echte Systeme mischen beides: einen deterministischen Workflow für die zuverlässige Verrohrung, mit einem KI- oder Agent-Schritt, wo Urteilsvermögen nötig ist. Für den Business-Einsatz hält es zuverlässig und messbar, mit einer klaren Automation zu starten und Intelligenz nur dort zu ergänzen, wo sie sich lohnt. ### GEO (Generative Engine Optimization) - Kanonische URL: https://agenticschool.dev/de/glossar/geo GEO (Generative Engine Optimization) ist die Praxis, deine Inhalte und deine Online-Präsenz so zu optimieren, dass generative KI-Tools - ChatGPT, Google AI Overviews, Gemini, Perplexity und andere - deine Marke zitieren, erwähnen oder empfehlen, wenn Leute ihnen Fragen stellen. Wo klassisches SEO darauf zielt, einen blauen Link in einer Suchergebnisseite zu ranken, zielt GEO darauf, Teil der KI-generierten Antwort selbst zu sein. Da immer mehr Leute Antworten von KI bekommen, statt zu Websites durchzuklicken, ist GEO der Weg geworden, in dieser neuen, antwort-zuerst gedachten Oberfläche sichtbar zu bleiben. #### Wie sich GEO von SEO unterscheidet SEO und GEO teilen ein Fundament (guter, vertrauenswürdiger Inhalt), zielen aber auf verschiedene Oberflächen. SEO optimiert, um Links in einer klassischen Suchmaschine zu ranken. GEO optimiert, um in einer KI-generierten Antwort eingeschlossen und zitiert zu werden, wo es vielleicht gar keine Linkliste gibt, nur eine zusammengesetzte Antwort, die ein paar Quellen erwähnt. - SEO: einen klickbaren Link in einer Suchergebnisseite ranken. - GEO: in einer KI-generierten Antwort zitiert, genannt oder empfohlen werden. - Beide belohnen klaren, korrekten, autoritativen Inhalt; GEO ergänzt Maschinenlesbarkeit. #### Wie GEO und AEO zusammenhängen GEO und AEO (Answer Engine Optimization) überschneiden sich stark und werden oft synonym verwendet, doch es gibt eine nützliche Unterscheidung. AEO konzentriert sich darauf, als die direkte, faktische Antwort auf eine konkrete Frage zurückgegeben zu werden. GEO ist breiter: Es konzentriert sich darauf, die Narrative und Empfehlungen zu beeinflussen, die KI rund um ein Thema bildet, sodass deine Marke darin eingewoben ist, wie die KI über dein Feld spricht, nicht nur für einen Fakt zitiert wird. #### Wie GEO in der Praxis aussieht Praktisches GEO heisst, Inhalte zu schreiben, die eine KI zuversichtlich zitieren kann: klare Definitionen zuerst, strukturierte Überschriften und FAQs, korrekte und aktuelle Fakten sowie zitierbare Aussagen. Es heisst auch starke, vertrauenswürdige Signale (ein echter Autor, konsistente Erwähnungen im Web) und deine Site maschinenlesbar zu machen, inklusive strukturierter Daten und einer llms.txt-Datei. Das Ziel ist, die Quelle zu sein, nach der eine KI greift und die sie sich sicher zu zitieren traut, wenn sie eine Frage in deinem Feld beantwortet. ### AEO (Answer Engine Optimization) - Kanonische URL: https://agenticschool.dev/de/glossar/aeo AEO (Answer Engine Optimization) ist die Praxis, deine Inhalte so zu optimieren, dass KI-Antwortmaschinen - Google AI Overviews, ChatGPT, Perplexity und ähnliche - sie als die direkte, autoritative Antwort auf eine Frage zurückgeben. Statt einen Klick auf einer Ergebnisseite gewinnen zu wollen, zielt AEO darauf, deinen Inhalt zur Antwort selbst zu machen, zum Snippet oder Zitat, das die Antwortmaschine zeigt, wenn jemand fragt. Es ist die Disziplin, eine Autorität auf Faktenebene zu werden, der eine KI genug vertraut, um sie zu zitieren. #### Warum AEO jetzt zählt Ein wachsender Anteil der Fragen wird direkt von KI beantwortet, ohne Klick auf eine Website. Wenn dein Inhalt nicht so strukturiert ist, dass er als Antwort gewählt wird, kannst du unsichtbar sein, selbst wenn du die besten Informationen hast. AEO schliesst diese Lücke, indem es deine Antworten leicht auffindbar, zitierbar und vertrauenswürdig macht, sodass du in der antwort-zuerst gedachten Welt präsent bleibst statt nur auf Seite eins der Links. #### Wie man für Antworten optimiert AEO belohnt Inhalte, die sich wie eine saubere Antwort lesen. Die Muster sind konkret und wiederholbar. - Beantworte die Frage direkt im ersten oder zweiten Satz und führe dann aus. - Nutze klare frageförmige Überschriften und eine FAQ, sodass jede Antwort für sich steht. - Ergänze strukturierte Daten (FAQ, How-To, Article), damit Maschinen deine Antworten zuverlässig parsen. - Halte Fakten korrekt, aktuell und zitierbar, mit echter Autorenschaft dahinter. #### AEO vs GEO vs SEO Diese drei sind Schichten, keine Rivalen. SEO optimiert, um Links in der Suche zu ranken. AEO optimiert, um die direkte Antwort zu sein, die eine Maschine zurückgibt. GEO ist noch breiter und optimiert, um zitiert und in die Narrative eingewoben zu werden, die generative KI rund um ein Thema bildet. AEO und GEO überschneiden sich so stark, dass viele Teams sie als eine Anstrengung behandeln; die einfachste Einordnung ist, dass es bei AEO darum geht, die Antwort zu sein, und bei GEO, Teil der Geschichte zu sein. --- ## Ratgeber ### Claude Code Tutorial fuer Einsteiger - Kanonische URL: https://agenticschool.dev/de/ratgeber/how-to-use-claude-code Claude Code ist Anthropics Terminal-basierter AI-Coding-Agent: Du führst einen Befehl in deinem Projekt aus, beschreibst in normaler Sprache, was du willst, und der Agent liest deine Dateien, plant, editiert Code, führt Befehle aus und prüft seine eigene Arbeit in einem Loop. Dieses komplette Einsteiger-Tutorial bringt dich von "nichts installiert" zu einer produktiven ersten Session: wie du Claude Code installierst, startest, den Plan-Edit-Run-Review-Workflow nutzt, der ihn zuverlässig macht, die CLAUDE.md schreibst, die ihm deine Regeln beibringt, und wo es weitergeht zu Subagents, Hooks, Skills und MCP. Alles hier ist Stand Juni 2026 und gegen die offizielle Doku geprüft. #### Was Claude Code ist (und was nicht) Claude Code ist ein Agent Harness: Software, die ein Claude-Modell in einen Loop mit Tools (Dateien lesen, Dateien editieren, Shell-Befehle ausführen, im Web suchen) und das Urteilsvermögen einpackt, sie auf ein Ziel hin einzusetzen, das du setzt. Er läuft im Terminal, in VS Code und JetBrains, in einer Desktop-App und im Web. Er ist nicht nur Autocomplete und kein Chat-Fenster, das dir Snippets zum Einfügen gibt: Er arbeitet direkt in deinem Repository, macht Multi-File-Änderungen, führt deine Tests aus und iteriert, bis die Aufgabe erledigt ist. Du behältst die Kontrolle, indem du prüfst, was er vorschlägt, und die wichtigen Aktionen freigibst. - Er lebt, wo dein Code lebt: im Terminal, in deinem Editor oder im Browser-Tab. - Er handelt, schlägt nicht nur vor: Er editiert Dateien und führt Befehle aus, dann liest er die Ergebnisse. - Du beaufsichtigst: Er fragt bei sensiblen Aktionen um Erlaubnis, und du prüfst seine Pläne und Diffs. - Er braucht einen Account: Claude Pro, Max, Team, Enterprise oder Console (pro Token). Der kostenlose Claude.ai-Plan enthält Claude Code nicht. #### Claude Code installieren Der empfohlene Weg, Claude Code 2026 zu installieren, ist der native Installer, der keine Node.js-Abhängigkeit hat und sich im Hintergrund selbst aktualisiert. Führe den Einzeiler für deine Plattform aus und bestätige dann, dass es geklappt hat. Wenn du npm bevorzugst, funktioniert das Paket weiterhin und installiert dasselbe Binary, braucht aber Node.js 18 oder neuer und aktualisiert sich nicht so sauber. Installiere niemals mit sudo: Ein root-eigenes npm-Verzeichnis verursacht bei jeder künftigen Installation Permission-Fehler. ```bash # macOS, Linux, WSL (recommended native installer) curl -fsSL https://claude.ai/install.sh | bash # Windows PowerShell irm https://claude.ai/install.ps1 | iex # npm fallback (needs Node.js 18+, do NOT use sudo) npm install -g @anthropic-ai/claude-code # Confirm it installed claude --version ``` Installiere Claude Code mit dem nativen Installer oder per npm als Fallback, dann prüfe die Version. Wenn etwas seltsam aussieht, führe "claude doctor" für einen Gesundheits-Check deiner Installation und Konfiguration aus. Auf nativem Windows ist Git for Windows optional, lässt Claude Code aber Git Bash für Shell-Befehle nutzen. #### Deine erste Session Öffne ein Terminal in dem Projekt, an dem du arbeiten willst, und führe "claude" aus. Beim ersten Mal führt es dich durch den Login via Browser. Sobald du drin bist, bist du an einem interaktiven Prompt: Tippe eine Anfrage in normalem Deutsch oder Englisch und drück Enter. Fang klein an, um Vertrauen aufzubauen, zum Beispiel "erkläre, was dieses Projekt macht" oder "finde, wo der Hero der Startseite gerendert wird". Claude Code liest die relevanten Dateien selbst, du musst also keinen Code einfügen. Wenn du die Session beenden willst, tippe /exit, und um später weiterzumachen, führe "claude -c" aus, um deine letzte Session in dem Ordner fortzusetzen. ```bash # Start Claude Code in the current project claude # Continue your most recent session in this folder claude -c # Resume a specific past session from a list claude --resume ``` Eine Claude-Code-Session starten, fortsetzen und wieder aufnehmen. #### Der Kern-Workflow: plan, edit, run, review Die eine Gewohnheit, die Claude Code zuverlässig macht, ist: planen, bevor du ihn editieren lässt. Drück Shift+Tab, um in den Plan-Modus zu gehen: Claude erkundet deine Codebasis und schlägt vor, was er vorhat, ohne eine einzige Datei zu ändern, damit du günstig gegensteuern kannst, bevor Code geschrieben wird. Gib den Plan frei, lass ihn die Edits machen, lass ihn deine Tests oder den Dev-Server laufen, und prüfe dann den Diff, bevor du committest. Dieser Explore-Plan-Implement-Commit-Loop hält den Agenten ehrlich und fängt eine falsche Richtung ab, solange sie noch gratis zu beheben ist. - Plan: Drück Shift+Tab für den Plan-Modus, damit Claude Änderungen vor dem Editieren vorschlägt. Nutze ihn für alles, was mehrere Dateien, das Schema oder Security berührt. - Edit: Gib den Plan frei und lass Claude die Multi-File-Änderungen machen. - Run: Lass ihn deine Tests, den Type-Checker oder den Dev-Server laufen, damit er echte Ergebnisse sieht, nicht Annahmen. - Review: Lies den Diff und committe. Du bist das Quality Gate, bevor Code dauerhaft wird. #### CLAUDE.md: dem Agenten deine Regeln beibringen CLAUDE.md ist eine einfache Markdown-Datei im Wurzelverzeichnis deines Repos, die Claude Code zu Beginn jeder Session automatisch liest und als stehende Anweisungen behandelt. Sie ist das wirkungsvollste Upgrade, das du machen kannst: Schreib deinen Stack, deine Konventionen, dein Quality Gate und deinen Ton einmal hinein, und der Agent hört auf, sie bei jeder Aufgabe neu zu entscheiden. Erzeuge eine Startdatei mit /init, das dein Projekt scannt und eine CLAUDE.md entwirft, und kürze sie dann auf die Regeln, die du tatsächlich immer wieder korrigierst. Halte sie knapp, denn sie wird jede Runde neu geladen und frisst dasselbe Context Window, das deine Aufgabe braucht. ```markdown # Project Rules ## Stack - TypeScript only. Package manager is bun, never npm. ## Conventions - Use rounded-sm for border-radius. Never use em dashes; use "-". ## Quality - Before saying a task is done, run: bun run lint && bun run typecheck && bun run test. ## Tone - Direct and concise. No filler. ``` Eine kompakte CLAUDE.md zum Anpassen. Führe /init aus, um einen Startpunkt zu erzeugen. #### Tiefer einsteigen: die vier Skills, die dich zum Power-User machen Sobald die Basics sitzen, machen vier Features aus Claude Code statt einem hilfreichen Assistenten einen zuverlässigen Teamkollegen. Jedes hat seinen eigenen Deep-Dive-Guide in diesem Cluster. Subagents lassen dich laute Nebenarbeit an einen frischen Kontext delegieren, damit deine Hauptsession scharf bleibt. Hooks lassen deine Quality Gates automatisch laufen, damit keine kaputte Änderung durchrutscht. Skills und Slash Commands packen deine besten Workflows in Ein-Wort-Trigger. Und MCP verbindet den Agenten mit deinen Datenbanken, Browsern und Services. Lies sie in beliebiger Reihenfolge; zusammen sind sie der Unterschied zwischen Claude Code nutzen und Claude Code meistern. - Subagents: Delegiere Recherche, Review oder Tests an einen spezialisierten Agenten in eigenem Context Window. Siehe den Claude Code Subagents Guide. - Hooks: Feuere Shell-Befehle automatisch bei Lifecycle-Events, um Formatierung, Tests und Sicherheit durchzusetzen. Siehe den Claude Code Hooks Guide. - Skills und Slash Commands: Halte einen wiederholten Workflow als wiederverwendbaren /command oder Skill fest. Siehe den Skills-und-Commands-Guide. - MCP: Verbinde externe Tools und Daten über ein Standardprotokoll. Siehe den MCP-Setup-Guide. ### Claude Code Subagents erklaert (mit Beispielen) - Kanonische URL: https://agenticschool.dev/de/ratgeber/claude-code-subagents Ein Claude Code Subagent ist ein spezialisierter Assistent, an den der Hauptagent eine fokussierte Aufgabe delegiert, der in seinem eigenen separaten Context Window mit eigenem System Prompt und eigenem, eingegrenztem Tool-Set läuft. Statt dass die Hauptsession alles macht und sich mit lautem Output füllt, übergibt sie einen Job (prüfe diesen Code, recherchiere diese Frage, führe diese Tests aus) an einen Subagent, der isoliert arbeitet und nur eine saubere Zusammenfassung zurückgibt. Dieser Guide erklärt, was Subagents sind, wann sie sich lohnen, welche Built-in-Subagents Claude Code mitbringt und wie genau du eigene mit dem /agents-Befehl oder einer Markdown-Datei in .claude/agents erstellst. #### Was ein Subagent tatsächlich ist Jeder Subagent läuft in seinem eigenen Context Window mit einem eigenen System Prompt, spezifischem Tool-Zugriff und unabhängigen Permissions. Wenn Claude auf eine Aufgabe trifft, die zur Beschreibung eines Subagents passt, delegiert er an diesen Subagent, der unabhängig arbeitet und sein Ergebnis zurückgibt. Das Schlüsselwort ist Isolation: All die unordentliche Zwischenarbeit, das Dutzend Dateien, das er gelesen hat, die fehlgeschlagenen Ansätze, der rohe Befehls-Output, bleibt im Fenster des Subagents und berührt die Hauptkonversation nie. Der Hauptagent bekommt nur die Schlussfolgerung. - Separates Context Window: Der Subagent erbt nicht deine ganze Hauptkonversation. - Eigener System Prompt: ein kurzes, fokussiertes Briefing, auf seinen einen Job zugeschnitten. - Eingegrenzte Tools und Permissions: nur was die Aufgabe braucht, oft read-only. - Gibt eine Zusammenfassung zurück: Die laute Arbeit wird absorbiert, die Hauptsession bekommt das saubere Ergebnis. #### Wann du einen Subagent nutzt Greif zu einem Subagent, wenn eine Nebenaufgabe deine Hauptkonversation mit Suchergebnissen, Logs oder Dateiinhalten fluten würde, auf die du nie wieder zurückgreifst. Der Subagent erledigt diese Arbeit in seinem eigenen Kontext und gibt nur die Antwort zurück, sodass dein Hauptfenster scharf bleibt und du die Performance-Klippe vermeidest, die zuschlägt, wenn sich ein Context Window mit Lärm füllt. Definiere einen eigenen Subagent, wenn du immer wieder dieselbe Art Arbeiter mit denselben Anweisungen startest: einen Code Reviewer, einen Test-Writer, einen Docs-Generator. - Kontext schonen: Halte Exploration und Massen-Lesen aus deiner Hauptkonversation heraus. - Constraints durchsetzen: Beschränke einen Subagent auf read-only Tools, damit ein Reviewer nicht editieren kann. - Verhalten spezialisieren: Ein fokussierter System Prompt macht ihn bei seinem einen Job zuverlässiger. - Kosten steuern: Leite enge Arbeit an ein schnelleres, günstigeres Modell wie Haiku. #### Built-in Subagents, die du schon hast Claude Code bringt Built-in-Subagents mit, die er automatisch nutzt, sodass du von Subagents profitierst, bevor du je einen erstellst. Explore ist ein schneller, read-only Agent zum Durchsuchen und Verstehen einer Codebasis, oft auf Haiku, um ihn günstig zu halten. Plan ist der Recherche-Agent, der im Plan-Modus Kontext sammelt, bevor er einen Plan vorschlägt. General-purpose erledigt komplexe, mehrstufige Aufgaben, die sowohl Exploration als auch Änderungen brauchen. Du kannst einen Built-in-Typ bei Bedarf über Permissions blockieren, aber meistens lässt du sie ihren Job machen. - Explore: schnelle, read-only Codebase-Suche und -Analyse (oft Haiku). - Plan: read-only Recherche-Agent, der im Plan-Modus Kontext sammelt. - General-purpose: Voll-Tool-Agent für komplexe, mehrstufige Arbeit. #### Einen eigenen Subagent erstellen Subagents sind Markdown-Dateien mit YAML-Frontmatter. Der einfachste Weg, einen zu erstellen, ist der /agents-Befehl, der ein geführtes Interface öffnet, in dem du den Subagent benennst, seine Beschreibung schreibst, seine Tools und sein Modell wählst und Claude den System Prompt für dich entwerfen lassen kannst. Projekt-Subagents leben in .claude/agents/ (committe sie in die Versionskontrolle, damit dein Team sie teilt); persönliche leben in ~/.claude/agents/ und folgen dir über Projekte hinweg. Im Frontmatter sind nur name und description Pflicht; die description ist das, was Claude liest, um zu entscheiden, wann er delegiert, also schreib sie klar. ```markdown --- name: code-reviewer description: Reviews code for quality and best practices. Use proactively after code changes. tools: Read, Glob, Grep model: sonnet --- You are a senior code reviewer. When invoked, analyse the changed code and return a concise, prioritised list of issues covering correctness, security and readability. Do not edit files; only report. Cite the file and line for each issue and suggest the smallest fix. ``` Ein echter read-only Code-Reviewer-Subagent unter .claude/agents/code-reviewer.md. Nur name und description sind Pflicht. Direkt auf der Platte angelegte Dateien werden beim Session-Start geladen, also starte Claude Code neu (oder erstell ihn über /agents, was sofort wirkt), um eine neue Datei zu übernehmen. Das model-Feld akzeptiert sonnet, opus, haiku oder inherit; das tools-Feld erbt standardmässig alle Tools, wenn du es weglässt. #### Subagents aufrufen und mit ihnen arbeiten Meistens rufst du einen Subagent nicht von Hand auf: Claude liest die description jedes Subagents und delegiert automatisch, wenn eine Aufgabe passt. Du kannst ihn auch explizit anstossen, zum Beispiel "nutze den code-reviewer Agent, um diesen Diff zu prüfen". Ein gutes Muster ist, das Feature mit deinem Hauptagenten zu schreiben und dann das Review an einen read-only Reviewer-Subagent zu delegieren, der den Diff in seinem eigenen Kontext inspiziert und eine knappe Issue-Liste zurückgibt, woraufhin der Hauptagent sie behebt. Weil das Review-Reasoning nie in dein Hauptfenster geladen wurde, bleibt die Session sauber. ### Claude Code Hooks: Quality Gates automatisieren - Kanonische URL: https://agenticschool.dev/de/ratgeber/claude-code-hooks Claude Code Hooks sind Shell-Befehle, die Claude Code automatisch an bestimmten Punkten in seinem Lebenszyklus ausführt, damit du deine Quality Gates deterministisch durchsetzt, statt zu hoffen, dass der Agent sich daran erinnert. Wo eine CLAUDE.md-Regel ein Vorschlag ist, dem das Modell folgen kann oder nicht, feuert ein Hook immer: Er kann deinen Formatter nach jedem Datei-Schreibvorgang ausführen, deine Tests laufen lassen, bevor der Agent stoppt, oder einen gefährlichen Befehl direkt blockieren. Dieser Guide erklärt die Hook-Events, wie Hooks konfiguriert werden, und ein praktisches Setup, das du heute übernehmen kannst. #### Was ein Hook tatsächlich ist Jeder Hook hat drei Teile: ein Event (der Lifecycle-Moment, in dem er feuert), einen optionalen Matcher (ein Filter, damit er nur für bestimmte Tools läuft) und eine Action (der Shell-Befehl, den er ausführt). Wenn ein Hook feuert, übergibt Claude Code ihm JSON über die Standardeingabe, das das Event beschreibt (Session-ID, Arbeitsverzeichnis, den Tool-Namen und seinen Input), und dein Skript entscheidet, was zu tun ist. Der Exit-Code des Befehls steuert den Ablauf: Exit 0 heisst weitermachen, und ein Exit ungleich null (konventionell 2) blockiert die Aktion und gibt deine Nachricht an den Agenten zurück, damit er reagieren kann. - Event: wann der Hook feuert (zum Beispiel nachdem ein Tool gelaufen ist). - Matcher: ein optionaler Filter, zum Beispiel nur bei Datei-Edits. - Action: der Shell-Befehl, den Claude Code ausführt. #### Die Lifecycle-Events, die du hooken kannst Hooks decken den vollen Tool-Lebenszyklus ab. Die, die du am meisten nutzt, sind PreToolUse und PostToolUse (rund um jeden Tool-Aufruf), Stop (wenn der Agent fertig werden will) und SessionStart (wenn eine Session beginnt). Für feinere Kontrolle gibt es weitere. - PreToolUse: bevor ein Tool läuft - die Aktion validieren oder blockieren. - PostToolUse: nachdem ein Tool gelaufen ist - formatieren, linten oder das Ergebnis prüfen. - UserPromptSubmit: wenn du einen Prompt schickst - Kontext einfügen oder Input absichern. - Stop und SubagentStop: wenn der Agent (oder ein Subagent) stoppen will - Tests als letztes Gate laufen lassen. - SessionStart und Notification: Session-Setup und wenn der Agent deine Aufmerksamkeit braucht. #### Wo Hooks konfiguriert werden Hooks leben in deiner Claude Code settings.json. Leg teamweite, nicht verhandelbare Gates in die Projektdatei unter .claude/settings.json, damit alle dieselben Leitplanken teilen, und behalte persönliche Vorlieben in deinen User-Settings. Jeder Eintrag paart ein Event mit einem Matcher und dem Befehl, der laufen soll. ```json { "hooks": { "PostToolUse": [ { "matcher": "Edit|Write", "hooks": [ { "type": "command", "command": "bun run lint --fix" } ] } ] } } ``` Ein PostToolUse-Hook, der deinen Linter nach jedem Datei-Edit oder -Write laufen lässt. #### Ein praktisches Quality-Gate-Setup Das wirkungsvollste Setup ist klein: bei jedem Write formatieren und linten, und deine Testsuite als Stop-Gate laufen lassen, damit der Agent eine Aufgabe nicht mit roten Tests für erledigt erklären kann. Füge einen PreToolUse-Guard hinzu, wenn du destruktive Shell-Befehle blockieren willst. Halte Hook-Skripte schnell und idempotent, weil sie oft laufen, und schreib bei einem Block eine klare Nachricht auf die Standardfehlerausgabe, damit der Agent weiss, wie er es behebt. ### Claude Code Skills und Slash Commands - Kanonische URL: https://agenticschool.dev/de/ratgeber/claude-code-skills-and-commands Claude Code Skills und Slash Commands sind wiederverwendbare, benannte Workflows: Statt dieselben mehrstufigen Anweisungen neu zu tippen, rufst du einen auf, und der Agent führt deine bewährten Schritte mit dem richtigen Kontext bereits geladen aus. Stand 2026 sind Custom Slash Commands in Skills aufgegangen: Eine Datei unter .claude/commands/deploy.md und ein Skill unter .claude/skills/deploy/SKILL.md erstellen beide den /deploy-Befehl und funktionieren gleich. Dieser Guide zeigt dir, wie du einen Slash Command und eine SKILL.md erstellst, wie Argumente und dynamischer Kontext funktionieren, wo sie leben und wann Claude einen Skill automatisch lädt versus wann du ihn selbst auslöst. #### Skills und Commands sind jetzt eins Jahrelang hatte Claude Code zwei getrennte Features: Slash Commands (eine Markdown-Datei, die du mit /name ausgelöst hast) und Skills (eine reichere, in sich geschlossene Fähigkeit). 2026 wurden sie vereinheitlicht. Custom Commands sind in Skills aufgegangen, sodass beide einen Slash Command erstellen und gleich funktionieren. Deine bestehenden .claude/commands/-Dateien funktionieren weiter, und Skills fügen einfach optionale Features obendrauf hinzu: ein Verzeichnis für Begleitdateien, Frontmatter, um zu steuern, wer sie aufruft, und die Fähigkeit, dass Claude sie automatisch lädt, wenn sie relevant sind. Claude Code Skills folgen dem offenen Agent-Skills-Standard, sodass derselbe Skill über Tools hinweg funktionieren kann. - Eine Datei unter .claude/commands/deploy.md erstellt /deploy. - Ein Skill unter .claude/skills/deploy/SKILL.md erstellt ebenfalls /deploy. - Skills ergänzen: Begleitdateien, Invocation-Kontrolle und automatisches Laden per description. - Bestehende .claude/commands/-Dateien funktionieren weiter; Skills sind der empfohlene Weg nach vorn. #### Einen Slash Command erstellen Der einfachste wiederverwendbare Workflow ist eine Markdown-Datei, deren Name zum Befehl wird. Leg eine Datei in .claude/commands/ (Projekt) oder ~/.claude/commands/ (persönlich) ab, und Claude Code stellt sie als Slash Command bereit. Nutze den $ARGUMENTS-Platzhalter, um alles zu erfassen, was du nach dem Befehl tippst, oder positionale $1, $2 für einzelne Argumente. Eine description im YAML-Frontmatter erscheint als Hilfetext. Das ist perfekt für eine einzelne, klar definierte Aktion, die du oft auslöst. ```markdown --- description: Investigate and fix a GitHub issue by number. argument-hint: [issue-number] --- Fix GitHub issue #$ARGUMENTS. First read the issue with the gh CLI, then find the relevant code, propose a fix in plan mode, and only implement after I approve. Run the test suite before you say it is done. ``` Ein Slash Command unter .claude/commands/fix-issue.md, aufgerufen als "/fix-issue 123". $ARGUMENTS erfasst die 123. #### Eine SKILL.md schreiben Ein Skill ist ein Verzeichnis mit einer SKILL.md-Datei in der Wurzel: YAML-Frontmatter plus Markdown-Anweisungen und optional gebündelte Skripte, Templates oder Referenzdateien. Der Verzeichnisname wird zum Befehl, den du tippst, und die description ist das, was Claude liest, um zu entscheiden, wann er den Skill automatisch lädt, also ist eine scharfe description die halbe Miete. Nur die description ist empfohlen; alles andere ist optional. Skills glänzen, wenn ein Workflow mehrstufig ist, eigene Assets hat, oder du willst, dass Claude ihn von selbst aufruft, wenn der Moment passt. ```markdown --- description: Summarise uncommitted changes and flag risks. Use when the user asks what changed or wants a commit message. allowed-tools: Read, Grep --- ## Current changes !`git diff HEAD` ## Instructions Summarise the changes above in two or three bullet points, then list any risks such as missing error handling, hardcoded values, or tests that need updating. If the diff is empty, say there are no uncommitted changes. ``` Eine SKILL.md unter .claude/skills/summarize-changes/SKILL.md, aufgerufen als /summarize-changes oder automatisch über ihre description geladen. Die Zeile mit !`git diff HEAD` ist dynamische Kontext-Injektion: Claude Code führt den Befehl aus und ersetzt die Zeile durch dessen Output, bevor das Modell den Skill sieht, sodass die Anweisungen mit deinem echten Diff bereits eingefügt ankommen. Halte den Body knapp, denn sobald ein Skill geladen ist, bleibt sein Inhalt über die Runden hinweg im Kontext. #### Wo sie leben und wer sie aufruft Projekt-Skills leben in .claude/skills//SKILL.md und gelten für dieses Repo; persönliche Skills leben in ~/.claude/skills//SKILL.md und folgen dir überallhin. Claude kann einen Skill automatisch aufrufen, wenn deine Anfrage zu seiner description passt, oder du löst ihn direkt mit /name aus. Wenn ein Workflow nur laufen soll, wenn du danach fragst (etwa ein Deploy), setze disable-model-invocation: true, damit Claude ihn nie von selbst auslöst. Um einen reinen Wissens-Skill aus dem Slash-Menü auszublenden, setze user-invocable: false. - Projekt: .claude/skills//SKILL.md - mit dem Repo geteilt. - Persönlich: ~/.claude/skills//SKILL.md - all deine Projekte. - Automatisch per description aufgerufen oder direkt mit /name ausgelöst. - disable-model-invocation: true macht einen Skill manuell-only; user-invocable: false blendet ihn aus dem /-Menü aus. #### Wann was passt Das Signal, irgendetwas zu verpacken, ist Wiederholung: Beim zweiten Mal, dass du den Agenten auf dieselbe Sequenz briefst, halte sie fest. Dann wähle die Form danach, wie reich sie ist. Eine einzelne klare Aktion ohne Assets ist eine reine Command-Datei. Ein mehrstufiger Prozess mit eigenen Templates, Skripten oder Referenzdocs, oder einer, den Claude automatisch laden soll, ist ein Skill. Du kannst mit einem Command starten und ihn später zu einem Skill ausbauen. Halte deine Library klein und fokussiert: zwei oder drei, zu denen du wirklich greifst, schlagen zwanzig, die du vergisst. ### MCP in Claude Code einrichten - Kanonische URL: https://agenticschool.dev/de/ratgeber/claude-code-mcp-setup MCP (Model Context Protocol) ist ein offener Standard, der Claude Code über eine gemeinsame Schnittstelle mit externen Tools, Datenbanken und Services verbindet, damit der Agent diese Systeme direkt lesen und auf ihnen handeln kann, statt dass du Daten in den Chat kopierst. Dieser Guide zeigt dir genau, wie du MCP in Claude Code einrichtest: was dir das Verbinden eines Servers bringt, wie du einen mit dem Befehl claude mcp add für jeden Transport hinzufügst, die Scopes, die entscheiden, wer die Verbindung teilt, wie du mit /mcp verifizierst und authentifizierst, und welche gängigen Server sich zum Starten lohnen. Jeder Befehl hier ist Stand Juni 2026. #### Was MCP dir in Claude Code bringt Verbinde einen Server, wenn du dich dabei ertappst, Daten aus einem anderen Tool in den Chat zu kopieren, etwa einem Issue-Tracker, einer Datenbank oder einem Monitoring-Dashboard. Einmal verbunden, kann Claude dieses System direkt lesen und darauf handeln. Ein MCP Server stellt Tools (Aktionen, die der Agent ausführen kann), Resources (read-only Daten, die er abrufen kann) und Prompts (wiederverwendbare Templates) bereit, und weil MCP ein gemeinsamer Standard ist, wird eine Integration einmal pro Tool geschrieben und funktioniert über jeden MCP-fähigen Client. Deshalb breitete sich die Unterstützung so schnell aus und deshalb gibt es jetzt einen MCP Server für fast alles, was du verbinden möchtest. - Aus einem Issue-Tracker implementieren: "Bau das in JIRA ENG-4521 beschriebene Feature und öffne einen PR." - Eine Datenbank direkt abfragen, statt Zeilen in den Chat zu kopieren. - Designs, Monitoring-Daten und andere Services integrieren, die der Agent sonst nicht sehen könnte. - Tools, Resources und Prompts: auszuführende Aktionen, lesbare Daten, wiederverwendbare Templates. #### Einen Server mit claude mcp add hinzufügen Der schnellste Weg, einen Server zu verbinden, ist der Befehl claude mcp add. Es gibt drei Transports. HTTP ist die empfohlene Wahl für entfernte, Cloud-basierte Server. Stdio führt einen Server als lokalen Prozess auf deiner Maschine aus, ideal für Tools, die direkten Systemzugriff brauchen. SSE existiert ebenfalls, ist aber zugunsten von HTTP deprecated. Bei stdio-Servern trennt der doppelte Bindestrich die eigenen Optionen von Claude vom Befehl, der den Server startet, und alles danach wird unverändert an den Server übergeben. ```bash # Remote HTTP server (recommended for cloud services) claude mcp add --transport http notion https://mcp.notion.com/mcp # HTTP server with a bearer token claude mcp add --transport http secure-api https://api.example.com/mcp \ --header "Authorization: Bearer your-token" # Local stdio server (note the -- before the command) claude mcp add --transport stdio airtable \ --env AIRTABLE_API_KEY=YOUR_KEY -- npx -y airtable-mcp-server ``` Entfernte HTTP- und lokale stdio-MCP-Server mit claude mcp add hinzufügen. SSE existiert auch, ist aber deprecated. #### Einen Scope wählen Das --scope-Flag entscheidet, wer den Server nutzen kann und wo die Config gespeichert wird. Local (der Standard) hält ihn auf dich im aktuellen Projekt beschränkt. Project teilt ihn mit allen über eine committete .mcp.json-Datei in der Repo-Wurzel, also ist ein project-scoped Server die richtige Wahl für Verbindungen, die dein ganzes Team braucht. User macht ihn über all deine Projekte verfügbar. Server, die Credentials brauchen, sollten sie über Umgebungsvariablen (das --env-Flag) bekommen, nie als hartkodierte Keys, sodass dieselbe .env-Disziplin gilt und Secrets aus der committeten Config bleiben. ```json { "mcpServers": { "filesystem": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-filesystem", "./data"] }, "playwright": { "command": "npx", "args": ["-y", "@playwright/mcp@latest"] } } } ``` Eine project-scoped .mcp.json (ins Repo committet), die einen Filesystem-Server und einen Playwright-Browser-Server verbindet. Project-scoped Server aus .mcp.json werden nicht automatisch vertraut: Sie erscheinen als "pending approval", bis du sie prüfst und freigibst, wenn du Claude interaktiv ausführst, was dich davor schützt, untrusted Server-Code auszuführen, den ein Teamkollege hinzugefügt hat. #### Verifizieren und authentifizieren Nachdem du einen Server hinzugefügt hast, bestätige, dass er funktioniert. Aus der Shell zeigt "claude mcp list" alle konfigurierten Server und ihren Status, "claude mcp get " zeigt Details zu einem, und "claude mcp remove " löscht ihn. Innerhalb einer Claude-Code-Session zeigt das /mcp-Panel jeden verbundenen Server, seine Tool-Anzahl, und lässt dich mit Servern authentifizieren, die OAuth 2.0 verlangen, indem es dich durch den Browser-Login führt. Wenn eine Anfrage einen Server braucht, der noch verbindet, wartet Claude auf ihn, bevor er weitermacht. ```bash # List all configured servers and their status claude mcp list # Details for one server claude mcp get notion # Remove a server claude mcp remove notion # Inside a session: check status and authenticate (OAuth) /mcp ``` MCP Server verwalten und verifizieren. Nutze /mcp in einer Session, um per OAuth zu authentifizieren. #### Gängige Server und bewusst verbinden Gute erste Verbindungen sind der Filesystem-Server (auf einen Ordner begrenzt), der Playwright-Server (damit der Agent einen echten Browser steuern kann) und ein Datenbank-Server für deinen Stack. Aber verbinde bewusst: Jeder Server fügt seine Tool-Definitionen zu deinem Context Window hinzu, also hat jeder reale, laufende Kosten. Ein MCP Server ist ausserdem Drittanbieter-Code mit Zugriff auf deine Systeme, also prüfe, was du verbindest, genau wie eine Abhängigkeit. Oft erledigt ein CLI-Tool, das du schon hast und in deiner CLAUDE.md benennst, den Job mit weniger Overhead als ein dedizierter Server. Drei Server, die du nutzt, schlagen fünfzehn, die deinen Kontext aufblähen. ### Was ist Agentic Engineering? Der Pillar Guide 2026 - Kanonische URL: https://agenticschool.dev/de/ratgeber/what-is-agentic-engineering Agentic Engineering ist die Disziplin, echte Software zu bauen, indem du AI Coding Agents steuerst, die Code in einem Loop planen, schreiben und ausführen, während du das Ziel, den Kontext und die Verifikation besitzt. Statt den meisten Code selbst zu tippen, setzt du ein klares Ziel, gibst dem Agenten die Tools und die Doku, die er braucht, lässt ihn die Codebasis erkunden, einen Plan vorschlagen, die Edits machen und die Tests laufen, und dann prüfst du und entscheidest, was ausgeliefert wird. Es ist das professionelle, verantwortbare Gegenstück zum "vibe coding": dieselben Agents, aber mit Struktur, Urteilsvermögen und Quality Gates eingesetzt, sodass das Ergebnis etwas ist, das du in Produktion bringen und für das du geradestehen kannst. Dieser Pillar Guide definiert Agentic Engineering präzise, zeigt, wie es sich von vibe coding und von klassischer Entwicklung unterscheidet, schlüsselt den Kern-Loop und die Skills auf, die es belohnt, listet die Tools auf, auf denen das Feld 2026 läuft, und gibt dir einen Weg, es zu lernen. Alles hier ist Stand Juni 2026. #### Eine präzise Definition Agentic Engineering ist Softwareentwicklung, bei der AI Coding Agents den grössten Teil des Tippens übernehmen und ein menschlicher Engineer die Regie führt. Ein Agent ist ein Modell, eingepackt in einen Loop mit Tools: Er kann deine Dateien lesen, sie editieren, Shell-Befehle ausführen und die Ergebnisse lesen, dann iteriert er auf ein Ziel hin. Agentic Engineering ist die Praxis, diese Agents bewusst zu nutzen, mit drei Dingen, die du fest in menschlicher Hand behältst: das Ziel definieren, den Kontext und die Tools vorbereiten, die der Agent braucht, und das Ergebnis verifizieren. Der Begriff bekam Gewicht durch Praktiker wie Simon Willison, der ihn rund um genau diese menschengeführten Säulen rahmt, und Builder wie Indy Dev Dan, die den Agentic-Coding-Workflow populär machten. Die Kurzform: Du hörst auf, der Tipper zu sein, und wirst der Lead, der die Richtung setzt und die Qualität garantiert. - Goal Definition: Sag präzise, was "fertig" heisst, bevor der Agent startet, nicht vage. - Kontext und Tools vorbereiten: Gib dem Agenten die Doku, Dateien, Befehle und Zugriffe, die er braucht (eine CLAUDE.md, MCP Server, ein sauberes Repo). - Verifikation: Prüfe den Plan und den Diff, lass die Tests laufen und entscheide, was sicher auslieferbar ist. Du bist das Quality Gate. - Der Agent macht den Rest: erkunden, planen, editieren und ausführen in einem Loop, den du beaufsichtigst. #### Agentic Engineering vs vibe coding Vibe coding, der Begriff, den Andrej Karpathy am 2. Februar 2025 prägte, ist das andere Ende des Spektrums: Du "gibst dich den Vibes hin", promptest das Modell, akzeptierst die Änderungen, ohne sie wirklich zu lesen, schickst auftretende Fehler zurück und vergisst, dass der Code überhaupt existiert. Es ist brillant für einen Wochenend-Prototyp, ein Wegwerf-Skript oder eine Demo, wo Tempo zählt und nichts auf dem Spiel steht. Agentic Engineering nutzt dieselben Agents, weigert sich aber, die Teile zu überspringen, die Software vertrauenswürdig machen. Du liest den Plan, du liest den Diff, du hältst die Tests grün, und du verstehst, was ausgeliefert wurde. Die ehrliche Formulierung vieler Praktiker ist, dass vibe coding einen Prototyp beschreibt, während Agentic Engineering ein Produktionssystem beschreibt. Unser dedizierter Vergleich geht tiefer, aber der Unterschied in einem Satz ist Verantwortung: Beim vibe coding prüft niemand; beim Agentic Engineering bist du es. - Vibe coding: prompten, akzeptieren, ausführen, wiederholen. Kein Review, keine Tests, kein echtes Verständnis. Toll für Prototypen und Wegwerf-Code. - Agentic Engineering: prompten, aber planen, den Diff prüfen, das Quality Gate laufen lassen und das Ergebnis besitzen. Für Produktion gebaut. - Dieselben Tools, andere Disziplin. Der Agent ist identisch; die Strenge drumherum nicht. - Siehe den Guide Vibe Coding vs Agentic Engineering für den vollen, ehrlichen Vergleich und wann was richtig ist. #### Wie es sich von klassischer Entwicklung unterscheidet Klassische Entwicklung heisst, ein Mensch schreibt den Code Zeile für Zeile, mit Autocomplete und einem Debugger als Helfern. Agentic Engineering kehrt das Verhältnis um: Der Agent generiert und führt den meisten Code aus, und deine Zeit wandert die Stack hinauf zu der Arbeit, die wirklich menschliches Urteilsvermögen braucht. Der Flaschenhals verschiebt sich davon, wie schnell du tippen kannst, dahin, wie klar du ein Ziel spezifizieren kannst, wie gut du den Agent-Kontext vorbereitet hast und wie rigoros du verifizierst. Die Skills, die sich auszahlen, sind nicht Syntax auswendig zu lernen, sondern präzise Specs zu schreiben, eine saubere Architektur zu entwerfen, die der Agent navigieren kann, Diffs schnell zu lesen und Quality Gates zu bauen, die Fehler automatisch fangen. Die Engineers, die gewinnen, sind nicht die, die sich gegen Agents wehren; es sind die, die lernen, sie gut zu steuern. - Deine knappe Ressource verschiebt sich von Tipp-Tempo zu Klarheit der Absicht und Qualität des Reviews. - Architektur und Benennung zählen mehr, denn eine saubere Codebasis kann ein Agent navigieren und du prüfen. - Specs, Tests und CLAUDE.md-artige Regeln werden zu erstklassigen Artefakten, nicht zu Nachgedanken. - Du bleibst der verantwortliche Engineer: Der Agent schlägt vor, du entscheidest. #### Der Kern-Loop Jeder zuverlässige agentische Workflow läuft denselben Loop, egal welches Tool du nutzt: explore, plan, implement, verify. Zuerst erkundet der Agent deine Codebasis, um den echten Zustand zu verstehen, statt zu raten. Dann schlägt er einen Plan vor, den du günstig korrigieren kannst, bevor Code geschrieben wird, denn eine falsche Richtung, die im Plan erwischt wird, kostet nichts, und eine falsche Richtung, die nach einem tausendzeiligen Diff erwischt wird, kostet viel. Dann implementiert er die Änderung und lässt deine Tests, den Type-Checker oder den Dev-Server laufen, damit er von echten Ergebnissen ausgeht, nicht von Annahmen. Schliesslich verifizierst du: Lies den Diff, bestätige, dass das Gate grün ist, und committe. Die eine Gewohnheit, die Leute mit grossartigen Ergebnissen von frustrierten Leuten trennt, ist, vor dem Editieren zu planen und den Verify-Schritt nie zu überspringen. - Explore: Lass den Agenten den relevanten Code lesen, damit er auf der Realität handelt, nicht auf einer Vermutung. - Plan: Lass ihn seinen Ansatz vorschlagen, bevor er Dateien berührt, und korrigiere ihn, solange das gratis ist. - Implement: Gib den Plan frei, lass ihn die Edits machen und die Befehle ausführen. - Verify: Lies den Diff, halte die Tests grün und entscheide, was ausgeliefert wird. Loop bis fertig. #### Die Tools des Feldes 2026 Agentic Engineering läuft auf einem kleinen, sich schnell bewegenden Stack. Der Agent Harness ist der Kern: ein Terminal- oder IDE-Agent, der ein Modell in den Explore-Plan-Implement-Verify-Loop einpackt. Claude Code (Anthropic) und Codex CLI (OpenAI) sind die führenden Terminal-Agents; Cursor ist die führende agentische IDE. Darunter sitzt ein Frontier-Modell (Opus, Sonnet, GPT oder Gemini Tiers), gewählt nach Aufgabe und Budget. Um den Agenten herum verdrahtest du Kontext und Tools: eine CLAUDE.md oder AGENTS.md, die ihm deine Regeln beibringt, MCP Server, die ihn mit deinen Datenbanken, Browsern und Services verbinden, Hooks, die Quality Gates automatisch durchsetzen, und Subagents, die laute Nebenarbeit aus deinem Hauptkontext halten. Nichts davon ist exotisch; es ist das Alltags-Set von jemandem, der heute mit Agents ausliefert. - Harness: Claude Code oder Codex CLI im Terminal, Cursor als agentische IDE. Siehe Claude Code vs Codex CLI. - Modell: Wähle Opus, Sonnet, GPT oder Gemini Tiers nach Aufgaben-Schwierigkeit und Kosten. - Kontext: eine CLAUDE.md / AGENTS.md mit stehenden Regeln, plus MCP Server für Live-Daten und Aktionen. - Leitplanken: Hooks für deterministische Quality Gates und Subagents für Kontext-Isolation. #### Wie du Agentic Engineering lernst Du lernst es wie jedes Handwerk: indem du etwas Echtes lieferst und dann jedes Mal die Disziplin straffst. Beginne damit, mit einem Harness von Anfang bis Ende flüssig zu werden, unser Guide How to Use Claude Code ist die schnellste Auffahrt. Dann verinnerliche den Loop und die Review-Gewohnheiten an einem kleinen Projekt, das dir wirklich am Herzen liegt. Von dort folge einem strukturierten Pfad, der dich von deiner ersten ausgelieferten App durch den modernen App-Stack, Automatisierung und Agent-First-Quality-Praktiken führt. Die Agentic Engineering Roadmap legt diese Zero-to-Shipping-Sequenz aus und verlinkt jeden Schritt, und wenn dich ein Begriff stolpern lässt, definiert das Glossar das Vokabular (Agentic AI, AI Agent, Agent Harness, vibe coding) in klarer Sprache. - Werde mit einem Harness flüssig: Starte mit How to Use Claude Code. - Liefere ein kleines echtes Projekt, um die Explore-Plan-Implement-Verify-Gewohnheit aufzubauen. - Folge der Agentic Engineering Roadmap von der ersten App bis zur Agent-First-Produktion. - Stütze dich auf das Glossar fürs Vokabular: Agentic AI, AI Agent, Agent Harness, vibe coding. ### Vibe Coding vs Agentic Engineering: Der Unterschied - Kanonische URL: https://agenticschool.dev/de/ratgeber/vibe-coding-vs-agentic-engineering Vibe coding und Agentic Engineering heissen beide, Software mit AI Coding Agents zu bauen, aber sie sitzen an entgegengesetzten Enden eines Reglers: wie sehr du dem Output ohne Prüfung vertraust. Vibe coding, der Begriff, den Andrej Karpathy im Februar 2025 prägte, ist, den Agenten laufen zu lassen und zu akzeptieren, was er produziert, ohne es wirklich zu lesen, was wunderbar für Prototypen und elend für Produktion ist. Agentic Engineering nutzt dieselben Agents, hält aber einen Menschen fest im Loop: Du planst, prüfst den Diff, lässt die Tests laufen und besitzt, was ausgeliefert wird. Dieser Guide definiert beide ehrlich, zeigt, wo jedes wirklich hingehört, und erklärt, warum Agentic Engineering der Ansatz ist, der über eine Wochenend-Demo hinaus skaliert. Er ist Stand Juni 2026 und passt zu unserem Pillar, Was ist Agentic Engineering. #### Was vibe coding wirklich heisst Vibe coding ist eine konkrete, echte Sache, nicht nur eine Abwertung. Andrej Karpathy beschrieb es am 2. Februar 2025 als "eine neue Art zu coden, bei der du dich völlig den Vibes hingibst, die Exponentiale umarmst und vergisst, dass der Code überhaupt existiert". In der Praxis heisst es, dass du mit dem Agenten redest, seine Änderungen akzeptierst, ohne den Diff zu prüfen, jeden Fehler direkt zur Behebung zurückschickst und die Codebasis organisch wachsen lässt. Das prägende Merkmal ist, dass du den Code nicht wirklich prüfst oder verstehst; du steuerst danach, ob das Ding zu funktionieren scheint. Für ein Wegwerf-Skript, einen Hackathon-Beitrag, ein schnelles persönliches Tool oder ein UI-Experiment ist das ein vollkommen rationaler Tausch: Tempo vor Strenge, wenn nichts auf dem Spiel steht. - Von Andrej Karpathy geprägt, Februar 2025; von Collins zum Wort des Jahres gekürt. - Du akzeptierst den Diff, ohne ihn zu lesen, und schickst Fehler zur Behebung an den Agenten zurück. - Du steuerst danach, "ob es läuft", nicht danach, den Code zu verstehen. - Wirklich toll für Prototypen, Demos, Skripte und spielerisches Lernen. #### Was Agentic Engineering wirklich heisst Agentic Engineering nutzt dieselben Agents, weigert sich aber, die Schritte zu überspringen, die Software vertrauenswürdig machen. Du definierst das Ziel präzise, bereitest den Kontext und die Tools vor, die der Agent braucht, lässt ihn erkunden und einen Plan vorschlagen, dann liest du diesen Plan, liest den Diff, den er produziert, hältst deine Tests und Type-Checks grün und entscheidest, was ausgeliefert wird. Der Mensch bleibt der verantwortliche Engineer. Wo vibe coding auf Tempo optimiert, optimiert Agentic Engineering auf Software, die du echten Nutzern vorsetzen und sechs Monate später warten kannst. Unser Pillar Guide schlüsselt die Disziplin vollständig auf; die Kurzversion ist, dass der Agent das Tippen macht und du die Regie und die Verifikation. - Du besitzt Goal Definition, Kontext-Vorbereitung und Verifikation; der Agent macht den Rest. - Du liest den Plan und den Diff, und ein Quality Gate (Lint, Types, Tests) muss bestehen. - Du verstehst, was ausgeliefert wurde, sodass du es später erweitern und debuggen kannst. - Für Produktion und Langlebigkeit gebaut, nicht nur dafür, etwas auf den Bildschirm zu bekommen. #### Ein ehrliches Nebeneinander Die zwei sind weniger Rivalen als dasselbe Tool mit anderer Disziplin genutzt. Den Kontrast klar zu benennen macht es leicht zu wissen, in welchem Modus du bist, und bewusst umzuschalten statt aus Versehen. - Review: vibe coding überspringt den Diff; Agentic Engineering liest jeden Diff, der zählt. - Tests: vibe coding lässt sie selten laufen; Agentic Engineering behandelt ein grünes Gate als nicht verhandelbar. - Verständnis: vibe coding vergisst, dass der Code existiert; Agentic Engineering hält dich fähig, ihn zu erklären. - Bester Fit: vibe coding für Prototypen und Wegwerf-Code; Agentic Engineering für alles Echte oder Geteilte. - Risiko: vibe coding kann stille Bugs und Sicherheitslücken ausliefern; Agentic Engineering fängt sie am Gate. #### Wann vibe coding völlig in Ordnung ist Vibe coding als immer falsch zu behandeln ist sein eigener Fehler. Wenn die Einsätze niedrig und die Lebensdauer kurz ist, ist die Strenge von vollem Agentic Engineering verschwendete Mühe. Vibe einen Prototyp, um zu testen, ob eine Idee überhaupt das Bauen wert ist. Vibe ein einmaliges Daten-Bereinigungs-Skript, das du einmal laufen lässt und löschst. Vibe eine UI-Skizze, um drei Layouts zu erfühlen, bevor du dich auf eines festlegst. Vibe, während du lernst, wo schnell Dinge kaputtmachen der Weg ist, sie zu verstehen. Die Falle ist nicht vibe coding selbst; es ist, etwas zu vibe-coden, das stillschweigend in Produktion aufsteigt, ohne je das Review, die Tests und das Verständnis zu bekommen, das Produktion verlangt. #### Warum Agentic Engineering skaliert Vibe coding stösst in dem Moment an eine Wand, in dem Code leben muss. Ungeprüfter Output sammelt Bugs an, die du nicht gesehen hast, Sicherheitsprobleme, die niemand geprüft hat, und Architektur-Drift, die die nächste Änderung schwerer macht als die letzte, bis sich der Agent selbst in dem Chaos verliert, das er angerichtet hat. Agentic Engineering skaliert genau deshalb, weil sich die Disziplin zu deinen Gunsten verzinst: Saubere Architektur und klare Specs machen den Agenten effektiver, automatische Quality Gates fangen Regressionen gratis, und dein eigenes Verständnis bedeutet, dass du das System weiter erweitern kannst, statt von ihm gefangen zu sein. Dieselben Agents, die einen fragilen vibe-codeten Haufen produzieren, produzieren eine wartbare Codebasis, wenn du sie steuerst und verifizierst. Das ist die ganze Wette von Agentic Engineering, und die Agentic Engineering Roadmap zeigt, wie du die Gewohnheit aufbaust. - Ungeprüfter Code verzinst sich zu Bugs, Sicherheitslücken und Architektur-Drift. - Quality Gates und saubere Specs machen jede spätere Änderung günstiger, nicht teurer. - Dein eigenes System zu verstehen lässt dich weiter ausliefern, statt steckenzubleiben. - Befördere einen vibe-codeten Prototyp in dem Moment, in dem er zählt: Füge Review, Tests und Struktur hinzu. ### Die Agentic Engineering Roadmap (Zero to Shipping) - Kanonische URL: https://agenticschool.dev/de/ratgeber/agentic-engineering-roadmap Das ist die Roadmap, um Agentic Engineering von Zero to Shipping zu lernen: ein sequenzierter Pfad, der dich davon, nie einen Coding Agent ausgeführt zu haben, dahin bringt, Produktionssoftware zu bauen und auszuliefern, die du steuerst und verifizierst. Agentic Engineering ist die Disziplin, echte Software zu bauen, indem du AI Agents steuerst, während du das Ziel, den Kontext und die Qualität besitzt, und man lernt es durch Tun, Stufe um Stufe. Unten ist die genaue Reihenfolge, sie durchzugehen, gemappt auf die fünf Kurse des Campus und die Deep-Dive-Guides für jeden Schritt, sodass du nie rätselst, was als Nächstes zu lernen ist. Arbeite von oben nach unten; jede Stufe setzt die davor voraus. Alles hier ist Stand Juni 2026 und passt zu unserem Pillar, Was ist Agentic Engineering. #### Wie du diese Roadmap nutzt Versuch nicht, alles auf einmal zu lernen. Der schnellste Weg, die Reise zu ruinieren, ist, über Subagents und MCP zu lesen, bevor du eine einzige Sache ausgeliefert hast. Geh der Reihe nach: Bring eine App live, dann vertiefe deine Beherrschung des Agenten, dann lerne den Produktions-Stack, dann Automatisierung, dann die Quality- und Agent-First-Praktiken, die deine Arbeit vertrauenswürdig machen. Jede Stufe unten benennt den Kurs, der sie lehrt, und die Guides, die bei den kniffligsten Teilen tiefer gehen. Bau auf jeder Stufe etwas Echtes, statt Tutorials zu sammeln, denn der Loop klickt nur, wenn du ihn an deinem eigenen Projekt gespürt hast. - Geh der Reihe nach; jede Stufe baut auf der letzten auf. - Liefere auf jeder Stufe etwas Echtes, nicht nur lesen. - Nutze den verlinkten Kurs für den Pfad und die verlinkten Guides für die Deep Dives. - Greif aufs Glossar zurück, wann immer ein Begriff neu ist. #### Stufe 1: Foundations - liefere deine erste App Beginne hier, selbst wenn du nie ein Terminal geöffnet hast. Der Foundations-Kurs bringt dich davon, zu verstehen, wie LLMs und Coding Agents wirklich funktionieren, über das Installieren von Claude Code und Codex, gutes Prompten, das Scaffolden eines Projekts, bis zum Ausliefern einer echten Website ins öffentliche Internet. Am Ende hast du den ganzen Bogen einmal gemacht: aus einer Idee wird eine deployte App. Der Begleit-Guide hier ist How to Use Claude Code, der dich in deiner ersten Session produktiv macht, und das zugrunde liegende Modell- und Harness-Vokabular steht im Glossar, wenn du die Definitionen willst. - Kurs: Foundations - From Zero to Your First Shipped App. - Guide: How to Use Claude Code (deine erste produktive Session). - Ergebnis: eine echte Website ins Internet deployt, der ganze Bogen einmal gemacht. - Glossar: AI Agent, Agent Harness, Agentic AI. #### Stufe 2: Claude Code Mastery - steuere den Agenten gut Sobald du ausliefern kannst, vertiefe deine Beherrschung des Harness, damit der Agent ein zuverlässiger Teamkollege wird statt eines Spielautomaten. Der Claude-Code-Mastery-Kurs deckt ab, ihm deine Regeln mit CLAUDE.md beizubringen, Workflows als Skills und Commands zu verpacken, Quality Gates mit Hooks zu automatisieren, Tools mit MCP zu verbinden, Multi-Agent-Workflows mit Subagents zu fahren und Kontext zu managen, ohne Geld zu verbrennen. Hier wird der Explore-Plan-Implement-Verify-Loop zur zweiten Natur. Stütze dich auf den Claude-Code-Cluster der Guides für jedes Feature: Subagents, Hooks, Skills und Commands und MCP-Setup. - Kurs: Claude Code Mastery - Becoming a Power User. - Guides: Claude Code Subagents, Hooks, Skills und Slash Commands und MCP-Setup. - Ergebnis: Der Explore-Plan-Implement-Verify-Loop wird Gewohnheit, keine Mühe. - Glossar: Subagent, System Prompt, Context Window, Prompt Caching. #### Stufe 3: The Modern App Stack - bau etwas Echtes Jetzt bau ein Produkt, nicht nur eine Seite. Der Modern-App-Stack-Kurs verdrahtet, wie echte Apps zusammenpassen: Authentifizierung und OAuth mit Clerk, eine reaktive Datenbank mit Convex, sicheres Secret-Handling, Zahlungen mit Stripe und die Migration von Entwicklung zu Produktion. Das ist die Stufe, auf der Agentic Engineering aufhört, ein Coding-Trick zu sein, und dazu wird, wie du eine funktionierende SaaS zusammenbaust. Du steuerst den Agenten über eine Multi-Service-Codebasis, während du die Architektur sauber genug hältst, dass er (und du) sie navigieren kann. - Kurs: The Modern App Stack - Auth, Data and Payments. - Ergebnis: eine produktionsförmige App mit Auth, einer Datenbank und Zahlungen. - Skill-Fokus: einen Agenten über eine echte Multi-Service-Codebasis steuern. - Glossar: AI IDE, Tool Calling. #### Stufe 4: Automation and Agentic Systems - lass es sich selbst betreiben Mit einem Produkt im Rücken geh von einzelnen Aufgaben zu Systemen über. Der Automation-and-Agentic-Systems-Kurs vergleicht n8n, Zapier und Trigger.dev, automatisiert den Browser mit Playwright, führt Code sicher in Sandboxes aus, baut deine eigenen AI-Tools auf APIs und entwirft Human-in-the-Loop-Systeme mit dem richtigen Autonomie-Level. Hier baust du die Workflows und Tools, die weiterlaufen, wenn du weggehst, und hier werden die fünf Levels der LLM-Autonomie zu einer praktischen Design-Entscheidung statt zu einem Konzept. - Kurs: Automation and Agentic Systems. - Ergebnis: Workflows und Tools, die ohne dein Babysitten laufen. - Skill-Fokus: das richtige Autonomie-Level wählen und einen Menschen im Loop halten. - Glossar: Workflow Automation, Tool Calling. #### Stufe 5: Quality, Security and Agent-First - liefere es richtig aus Die letzte Stufe macht deine Arbeit produktionstauglich und auffindbar für Menschen wie für AI. Der Kurs Quality, Security and the Agent-First Business deckt Tests und CI/CD, Sicherheit und Datenschutz, Auffindbarkeit durch SEO und GEO/AEO, das Entwerfen von Agent-First-Produkten, deren APIs andere Agents gern nutzen, und ein Capstone ab, in dem du ein komplettes agentisches Produkt von Anfang bis Ende baust und auslieferst. Schliess das ab, und du lernst Agentic Engineering nicht mehr; du praktizierst es. Von hier liefere weiter aus und kehre zu den Deep-Dive-Guides zurück, wann immer ein Projekt dich in neues Terrain drängt. - Kurs: Quality, Security and the Agent-First Business. - Ergebnis: ein komplettes agentisches Produkt, ausgeliefert und auffindbar für Menschen und AI. - Skill-Fokus: Tests, Security, GEO/AEO und Agent-First-API-Design. - Glossar: GEO, AEO, llms.txt. ### Was ist ein MCP Server? (und wie du einen baust) - Kanonische URL: https://agenticschool.dev/de/ratgeber/what-is-an-mcp-server Ein MCP Server ist ein kleines Programm, das einem AI Agent Tools, Daten und Prompt-Templates über das Model Context Protocol bereitstellt, den offenen Standard, der jede MCP-fähige App mit ihm verbinden lässt. Statt für jedes Modell und jedes Tool eine eigene Integration zu schreiben, implementierst du einen MCP Server für deinen Service, und jeder MCP Client (Claude Code, Cursor, Claude Desktop und mehr) kann ihn nutzen. Der Agent kann dann deinen Server aufrufen, um Aktionen auszuführen, deine Daten zu lesen und deine Prompts wiederzuverwenden, ohne dass du irgendetwas in den Chat kopierst. Dieser Guide erklärt genau, was ein MCP Server ist, wie die Host-Client-Server-Architektur funktioniert, die drei Dinge, die ein Server bereitstellt, wie du einen minimalen in TypeScript baust, und die gängigen Server, die du kennen solltest. Alles hier ist Stand Juni 2026; um einen in deinen eigenen Agenten zu verdrahten, siehe unseren Guide MCP in Claude Code einrichten. #### Was ein MCP Server ist MCP (Model Context Protocol) ist ein offener Standard, der AI Agents über eine gemeinsame Schnittstelle mit externen Tools, Daten und Services verbindet. Ein MCP Server ist das Stück, das du (oder ein Anbieter) schreibst und das vor einer bestimmten Fähigkeit sitzt: einer Datenbank, einem Browser, einem Issue-Tracker, einem Filesystem, einer API. Er bewirbt, was er kann, und jeder MCP Client kann ihn entdecken und nutzen. Der Grund, warum sich MCP so schnell ausbreitete, ist, dass es ein N-mal-M-Problem löst: Vor MCP brauchte jedes Tool eine massgeschneiderte Integration für jeden Agenten; mit MCP wird ein Tool einmal integriert und funktioniert überall. Also gibt es heute einen MCP Server für fast alles, was ein Agent erreichen soll. - Ein Server umhüllt eine Fähigkeit (eine Datenbank, einen Browser, eine API) und stellt sie Agents bereit. - Er spricht das Model Context Protocol, sodass jeder MCP Client ihn ohne eigenen Klebe-Code nutzen kann. - Schreib die Integration einmal; jede MCP-fähige App profitiert. Deshalb breitete sich die Unterstützung schnell aus. - Siehe den Glossar-Eintrag zu MCP für die Kurzdefinition und Tool Calling dafür, wie Agents es aufrufen. #### Wie er funktioniert: Host, Client und Server MCP nutzt eine Client-Server-Architektur auf Basis von JSON-RPC 2.0, mit drei Beteiligten. Der Host ist die AI-Anwendung, die du nutzt, etwa Claude Code oder Cursor. Wenn der Host startet, erstellt er einen MCP Client pro konfiguriertem Server, und jeder Client hält seine eigene dedizierte, zustandsbehaftete Verbindung zu einem MCP Server. Der Server ist das Programm, das die Fähigkeit bereitstellt. Nachrichten fliessen als JSON-RPC-Requests, -Responses und -Notifications über einen Transport. Es gibt zwei gebräuchliche Transports: stdio, bei dem der Host den Server als lokalen Kindprozess spawnt und sie über Standardein- und -ausgabe reden, und Streamable HTTP, genutzt für entfernte, Cloud-gehostete Server. Ein Host kann viele Client-Server-Verbindungen gleichzeitig fahren, so erreicht ein Agent ein Filesystem, einen Browser und eine Datenbank in derselben Session. - Host: die AI-App (Claude Code, Cursor, Claude Desktop), mit der der Nutzer interagiert. - Client: einer pro Server, vom Host erstellt, der eine dedizierte Verbindung hält. - Server: dein Programm, das eine Fähigkeit bereitstellt und JSON-RPC 2.0 spricht. - Transport: stdio für lokale Server, Streamable HTTP für entfernte (SSE ist deprecated). #### Was ein Server bereitstellt: Tools, Resources und Prompts Ein MCP Server kann drei Arten von Primitive bereitstellen, und ein gegebener Server implementiert die, die für ihn Sinn ergeben. Tools sind Aktionen, die das Modell aufrufen kann, etwa "führe diese Query aus" oder "erstelle dieses Issue"; jedes Tool deklariert ein Input-Schema, damit der Agent weiss, wie er es aufruft. Resources sind read-only Daten, die der Agent abrufen kann, etwa der Inhalt einer Datei oder ein Datenbank-Record, adressiert per URI. Prompts sind wiederverwendbare Templates, die der Server anbietet, oft dem Nutzer als Slash Commands oder Quick Actions präsentiert. Tools sind bei Weitem am häufigsten, weil der Hauptwert von MCP ist, einen Agenten auf einem System handeln zu lassen, nicht es nur zu lesen. - Tools: Aktionen, die der Agent aufrufen kann (eine DB abfragen, einen PR öffnen, einen Browser steuern). Jedes hat ein Input-Schema. - Resources: read-only Daten, die der Agent per URI abrufen kann (Dateiinhalte, Records). - Prompts: wiederverwendbare Templates, die der Server bietet, oft als Slash Commands gezeigt. - Ein Server deklariert, welche Primitive er unterstützt; die meisten führen mit Tools. #### Bau einen minimalen MCP Server Der schnellste Weg, einen Server zu verstehen, ist, einen winzigen zu bauen. Das offizielle TypeScript SDK kommt als Paket @modelcontextprotocol/server und lässt dich einen funktionierenden stdio-Server in wenigen Zeilen aufstellen: Erstelle einen McpServer, registriere ein Tool mit einem Namen, einer Beschreibung und einem Zod-Input-Schema, dann verbinde ihn über einen StdioServerTransport. Das Beispiel unten stellt ein greet-Tool bereit. Speichere es, zeig deinen MCP Client auf den Befehl, der es ausführt (für Claude Code ist das claude mcp add --transport stdio), und der Agent kann greet aufrufen. Ein Python SDK (FastMCP) bietet dieselbe Form, falls du Python bevorzugst. ```typescript // server.ts - a minimal MCP server exposing one tool over stdio import { McpServer } from '@modelcontextprotocol/server' import { StdioServerTransport } from '@modelcontextprotocol/server/stdio' import * as z from 'zod' const server = new McpServer({ name: 'greeting-server', version: '1.0.0' }) // Register a tool: a name, a description, and a Zod input schema. server.registerTool( 'greet', { description: 'Greet someone by name', inputSchema: z.object({ name: z.string() }), }, async ({ name }) => ({ content: [{ type: 'text', text: `Hello, ${name}!` }], }), ) // Connect over stdio: the host spawns this file and talks via stdin/stdout. const transport = new StdioServerTransport() await server.connect(transport) ``` Ein minimaler MCP Server in TypeScript mit einem Tool über stdio, mit dem offiziellen @modelcontextprotocol/server SDK. Halte server.ts frei von console.log auf stdout: Ein stdio-Server nutzt stdout für das JSON-RPC-Protokoll, logge also stattdessen auf stderr. Von hier fügst du weitere Tools, Resources und Prompts genauso hinzu und wechselst zu Streamable HTTP, wenn du den Server entfernt hosten willst. #### MCP Server vs eine reine API Eine berechtigte Frage ist, warum ein Agent einen MCP Server braucht, wenn der zugrunde liegende Service schon eine REST-API hat. Der Unterschied ist Discovery und Selbstbeschreibung. Eine REST-API braucht einen Menschen, der ihre Doku liest und für jeden Client Integrations-Code schreibt; ein MCP Server bewirbt seine Tools, deren Schemas und Beschreibungen in einem Standard, den der Agent beim Verbinden liest, sodass der Agent automatisch lernt, wie er ihn nutzt, und derselbe Server über jeden MCP Client funktioniert. MCP ersetzt deine API nicht; es ist eine dünne, agentenfreundliche Schicht davor. Für interne Einzelfälle mag ein CLI, das der Agent aufrufen kann, einfacher sein, aber für alles, was viele Agents und Apps nutzen sollen, ist ein MCP Server die interoperable Wahl. - Eine REST-API braucht pro Client Integrations-Code; ein MCP Server ist selbstbeschreibend und überall wiederverwendet. - Der Agent liest Tool-Schemas und -Beschreibungen beim Verbinden, also weiss er, wie er sie aufruft. - MCP sitzt als agentenfreundliche Schicht vor deiner API, es ersetzt sie nicht. - Für einen privaten Einzelfall mag ein CLI einfacher sein; für geteilte Nutzung gewinnt ein Server. #### Gängige Server, die du kennen solltest Du musst selten einen Server von Grund auf bauen, weil das Ökosystem die gängigen Fälle schon abdeckt. Gute erste Verbindungen sind der Filesystem-Server (auf einen Ordner begrenzt, damit der Agent Projektdateien lesen und schreiben kann), der Playwright-Server (damit der Agent einen echten Browser steuern kann, um zu testen oder zu scrapen) und ein Datenbank-Server für deinen Stack. Darüber hinaus gibt es Server für Issue-Tracker, Design-Tools, Monitoring und die meisten grossen SaaS-Produkte. Verbinde aber bewusst: Jeder Server fügt seine Tool-Definitionen zum Agent-Kontext hinzu, also hat jeder laufende Kosten, und ein Server ist Drittanbieter-Code mit Zugriff auf deine Systeme, also prüfe ihn wie jede Abhängigkeit. Unser Guide MCP in Claude Code einrichten führt durch das sichere Hinzufügen, Scopen und Verifizieren von Servern. - Filesystem-Server: Dateien in einem begrenzten Ordner lesen und schreiben. - Playwright-Server: den Agenten einen echten Browser steuern lassen. - Datenbank-Server: deine Daten direkt abfragen, statt Zeilen in den Chat zu kopieren. - Verbinde wenige und prüfe jeden: Jeder Server kostet Kontext und ist Drittanbieter-Code. ### KI Agent selbst bauen - Kanonische URL: https://agenticschool.dev/de/ratgeber/how-to-build-an-ai-agent Ein KI Agent ist ein Sprachmodell, eingepackt in einen Loop, der Tools aufrufen, die Ergebnisse lesen und entscheiden kann, was als Nächstes zu tun ist, und das wiederholt, bis ein Ziel erreicht ist. Einen selbst zu bauen ist viel einfacher, als der Hype suggeriert: Im Kern ist es eine while-Schleife um ein Modell, das Tool Calling unterstützt. Du gibst dem Modell ein Ziel und ein Set Funktionen, es bittet darum, eine auszuführen, du führst sie aus, gibst das Ergebnis zurück, und es macht weiter, bis es fertig ist. Dieser Guide bringt dich von der Definition zu einem konkreten, minimalen Agent, den du heute laufen lassen kannst, dann hoch über die Stufen der Autonomie und das, was sich ändert, wenn ein Agent in Production geht. Wir bauen den Loop erst von Hand, damit du genau verstehst, was passiert, und zeigen dann die SDKs, die das für dich tun. Alles hier ist Stand Juni 2026. #### Was ein KI Agent tatsächlich ist Ein KI Agent ist Software, die ein Sprachmodell nutzt, um in einem Loop zu entscheiden und zu handeln, statt nur einmal zu antworten. Das Modell ist das Gehirn, aber ein Gehirn ohne Hände kann nichts tun, also gibst du ihm Tools: Funktionen, die es aufrufen kann, um eine Datei zu lesen, eine Datenbank abzufragen, im Web zu suchen oder eine API zu treffen. Der Agent läuft in einem Loop: Das Modell bekommt das Ziel und die Liste verfügbarer Tools, es antwortet entweder oder bittet, ein Tool aufzurufen, dein Code führt dieses Tool aus und gibt das Ergebnis zurück, und das Modell nutzt das Ergebnis, um seinen nächsten Schritt zu entscheiden. Dieser Loop ist die ganze Idee. "Agentic AI" ist der breitere Begriff für so gebaute Systeme; ein "KI Agent" ist ein solches System. Für die präzisen Definitionen siehe die Glossar-Einträge zu AI Agent, Agentic AI, Tool Calling und dem Agent Harness. - Modell: der Reasoning-Kern, der entscheidet, was zu tun ist (ein LLM, das Tool Calling unterstützt). - Tools: Funktionen, die das Modell aufrufen kann, um auf die Welt zu wirken, jede mit Name, Beschreibung und Input-Schema. - Loop: Modell entscheidet, dein Code führt das gewählte Tool aus, das Ergebnis geht zurück, wiederholen, bis fertig. - Siehe das Glossar: AI Agent, Agentic AI, Tool Calling, Agent Harness für die formalen Definitionen. #### Der Build-Loop, Schritt für Schritt Jeder Agent, vom zehnzeiligen Skript bis Claude Code, läuft denselben Loop. Du schickst dem Modell die bisherige Konversation plus die Tool-Definitionen. Das Modell antwortet auf eine von zwei Arten: mit einer finalen Antwort (es ist fertig) oder mit der Bitte, ein oder mehrere Tools aufzurufen. Wenn es ein Tool will, führt dein Code dieses Tool aus, fängt den Output ab, hängt ihn als Tool-Ergebnis an die Konversation an und schickt alles zurück. Das Modell liest das Ergebnis und entscheidet erneut. Du loopst weiter, bis das Modell eine finale Antwort liefert oder du ein Sicherheitslimit an Iterationen erreichst. Die beiden nicht verhandelbaren Leitplanken sind eine maximale Anzahl Runden, damit ein verwirrter Agent nicht ewig loopt, und die Validierung von Tool-Inputs, denn das Modell bittet dich, echten Code mit selbst gewählten Argumenten auszuführen. - Schick Ziel, Konversationsverlauf und Tool-Definitionen ans Modell. - Gibt das Modell eine finale Antwort zurück, stoppe und gib sie zurück. - Bittet es um ein Tool, validiere den Input, führe das Tool aus, hänge das Ergebnis an und loope. - Begrenze immer die Anzahl Iterationen und validiere Tool-Argumente, bevor du ausführst. #### Ein minimaler Agent, den du bauen kannst Hier ist der kleinste Agent, der etwas Echtes tut: ein Modell mit einem Tool (ein Rechner), das den Tool-Calling-Loop von Hand gegen die Anthropic Messages API läuft. Das Muster ist für jeden Anbieter identisch, der Tool Calling unterstützt. Das Modell bekommt die Frage und die Tool-Definition; wenn es mit stop_reason "tool_use" antwortet, führen wir das Tool aus, schicken ein tool_result zurück und loopen, bis es eine reine Textantwort gibt. Lies ihn einmal, und der Zauber verschwindet: Ein Agent ist ein Loop, ein Modell und ein Dictionary von Funktionen. ```python # pip install anthropic # A minimal agent: one tool, the tool-calling loop by hand. import anthropic client = anthropic.Anthropic() # reads ANTHROPIC_API_KEY from the env # 1) Define the tools: a name, a description, and an input schema. tools = [ { "name": "calculator", "description": "Evaluate a basic arithmetic expression.", "input_schema": { "type": "object", "properties": {"expression": {"type": "string"}}, "required": ["expression"], }, } ] # 2) Map tool names to the real functions that run them. def calculator(expression: str) -> str: # Real code: validate hard. A toy eval is fine only for a demo. allowed = set("0123456789+-*/(). ") if not set(expression) <= allowed: return "error: invalid characters" return str(eval(expression)) # demo only; never eval untrusted input in prod TOOLS = {"calculator": calculator} # 3) The loop. def run_agent(goal: str, max_turns: int = 8) -> str: messages = [{"role": "user", "content": goal}] for _ in range(max_turns): resp = client.messages.create( model="claude-sonnet-4-5", max_tokens=1024, tools=tools, messages=messages, ) if resp.stop_reason != "tool_use": return "".join(b.text for b in resp.content if b.type == "text") messages.append({"role": "assistant", "content": resp.content}) results = [] for block in resp.content: if block.type == "tool_use": out = TOOLS[block.name](**block.input) results.append({ "type": "tool_result", "tool_use_id": block.id, "content": out, }) messages.append({"role": "user", "content": results}) return "stopped: hit the turn limit" print(run_agent("What is 4321 * 1234, then add 99?")) ``` Ein kompletter minimaler Agent in Python: ein Tool, der Modell-plus-Tool-Calling-Loop von Hand. Dieselbe Form funktioniert mit jedem Tool-Calling-Modell. Das ist wirklich alles, was ein Agent ist. Um ihn nützlich zu machen, fügst du mehr Tools hinzu (eine Datei lesen, deine API aufrufen, eine Datenbank abfragen), gibst jedem eine präzise Beschreibung, damit das Modell weiss, wann es es nutzt, und härtest den Ausführungspfad. Das eval im Rechner ist nur für die Demo; führe nie vom Modell gewählten Code oder Ausdrücke ohne strenge Validierung oder eine Sandbox aus. #### Nutze ein Framework, sobald du den Loop verstehst Den Loop einmal von Hand zu bauen ist der beste Weg, Agenten zu verstehen, aber in Production greifst du zu einem Framework, das Loop, Retries, Streaming, Sessions und Permissions für dich übernimmt. 2026 sind die zwei direktesten Wege das Claude Agent SDK, das denselben Agent-Loop, dasselbe Tool-Set und Context Management bietet, die Claude Code antreiben (installiere @anthropic-ai/claude-agent-sdk für TypeScript oder claude-agent-sdk für Python), und das OpenAI Agents SDK, ein leichtgewichtiges Python- und TypeScript-Framework, das jede Funktion mit automatischer Schema-Generierung in ein Tool verwandelt (pip install openai-agents). Beide geben dir Tool Calling, mehrstufige Loops, Human-in-the-Loop-Checkpoints, Subagents und erstklassige MCP-Unterstützung out of the box. Das Prinzip ist dasselbe, das du gerade gebaut hast; das SDK entfernt nur die Plumbing. - Claude Agent SDK: derselbe Loop und dieselben Tools, die Claude Code laufen lassen, programmierbar in Python und TypeScript, mit eingebautem MCP und Subagents. - OpenAI Agents SDK: ein leichtgewichtiges Multi-Agent-Framework, das jede Funktion in ein validiertes Tool verwandelt (pip install openai-agents). - Beide übernehmen Loop, Retries, Streaming, Sessions und Permissions, die du sonst von Hand schreiben würdest. - Verbinde externe Tools über MCP statt über bespoke Glue; siehe Was ist ein MCP Server. #### Die Stufen der Autonomie Nicht jeder Agent sollte voll autonom sein, und die richtige Stufe zu wählen ist eine Design-Entscheidung, kein Default. Denk an eine Leiter. Ganz unten schlägt das Modell nur vor, und ein Mensch macht alles. Eine Sprosse höher entwirft es, und ein Mensch gibt jede Aktion frei. Höher handelt es autonom bei risikoarmen Schritten, pausiert aber bei allem Sensiblen zur Freigabe (ein Human-in-the-Loop-Checkpoint). Ganz oben läuft es einen ganzen Workflow unbeaufsichtigt. Die richtige Stufe hängt von den Kosten eines Fehlers ab: Je mehr ein Fehler wehtut, desto mehr menschliche Aufsicht behältst du. Die meisten zuverlässigen Production-Agenten sitzen in der Mitte, voll autonom bei sicheren, umkehrbaren Aktionen und gegated beim Rest. Der Kurs Automation und Agentic Systems behandelt das als die 5 Stufen der LLM-Autonomie. - Nur vorschlagen: Der Agent schlägt vor, ein Mensch macht alles. Geringstes Risiko, geringste Hebelwirkung. - Entwerfen und freigeben: Der Agent bereitet die Aktion vor, ein Mensch bestätigt, bevor sie läuft. - Autonom mit Checkpoints: Er handelt bei sicheren Schritten und pausiert bei riskanten zur Freigabe. - Voll unbeaufsichtigt: Er läuft den ganzen Workflow allein; reserviere das für risikoarme, umkehrbare Aufgaben. #### Deinen Agent production-fähig machen Ein Demo-Agent und ein Production-Agent unterscheiden sich in allem rund um den Loop. Das Modell und die Tools sind der einfache Teil; Zuverlässigkeit ist die Arbeit. Validiere jeden Tool-Input, denn das Modell wählt die Argumente. Führe alles, was Code ausführt oder die Aussenwelt berührt, in einer Sandbox mit Timeouts und Resource-Limits aus, nie auf einer Maschine, die dir wichtig ist. Logge jeden Schritt (das Ziel, jeden Tool-Aufruf, jedes Ergebnis), damit du siehst, was der Agent getan hat, und ihn debuggen kannst, wenn es schiefgeht. Begrenze Iterationen und Kosten, damit ein verwirrter Agent nicht ewig loopt oder eine Rechnung hochtreibt. Und behalte einen Menschen im Loop für irreversible oder sensible Aktionen. Das sind dieselben Lektionen, die die Founder-Builds auf die harte Tour gelernt haben: CallAssistant gab seinem Voice-Agent eng definierte Tools, weil es am Telefon kein "bist du sicher?" gibt, und CodeCourier führte untrusted Code nur in einer Wegwerf-Sandbox aus. - Validiere Tool-Inputs und führe Code-ausführende Tools in einer Sandbox mit Timeouts und Limits aus. - Logge das Ziel, jeden Tool-Aufruf und jedes Ergebnis, damit der Agent beobachtbar und debugbar ist. - Begrenze Iterationen und Ausgaben, damit ein durchgehender Loop dich nicht Zeit oder Geld kostet. - Gate irreversible oder sensible Aktionen hinter einem Human-in-the-Loop-Freigabeschritt. - Lerne aus echten Builds: CallAssistant (enge Tools) und CodeCourier (Sandboxing) auf der Builds-Seite. ### SaaS mit KI bauen (Modern Stack) - Kanonische URL: https://agenticschool.dev/de/ratgeber/build-a-saas-with-ai Du kannst 2026 ein echtes SaaS bauen und ausliefern, indem du einen AI-Coding-Agent über einen kleinen, bewährten Stack steuerst, und dieser Pillar-Guide ist die Karte, um das von Anfang bis Ende zu tun: von der Idee zum Scaffold, zur Authentifizierung, zur Datenbank, zu Payments, zum Livegang. Die Arbeit ist nicht mehr, jede Zeile zu tippen; sie ist, die richtigen Teile zu wählen, sie sauber zu verdrahten und zu verifizieren, was der Agent baut. Der Stack, den wir lehren, ist der, den ein Solo-Founder tatsächlich ausliefern und warten kann: ein modernes Framework für die App, Clerk für Auth, Convex für die Datenbank, Stripe für Payments und ein Agent wie Claude Code, der den Build steuert. Dieser Guide gibt dir die ganze Sequenz und verlinkt die Deep Dives, die Vergleiche hinter jeder Wahl und den Kurs, der jede Stufe im Detail durchgeht. Alles hier ist Stand Juni 2026. #### Der Modern SaaS Stack in einem Bild Ein SaaS sind dieselben drei Schichten wie jede App (ein Frontend, das der User sieht, ein Backend, das Logik und Secrets hält, und eine Datenbank, die Daten speichert) plus die wenigen Services, die aus einer App ein Business machen: Authentifizierung, damit User Accounts haben, eine Datenbank, die in Echtzeit synchronisiert, und Payments, damit du abrechnen kannst. Der 2026-Default für einen Solo-Founder oder ein kleines Team ist ein Framework für die App, Clerk für Auth, Convex für die reaktive Datenbank und Stripe für Payments, alles von einem Coding-Agent zusammengeklebt, den du steuerst. Du musst nicht genau diese Tools nutzen, aber du brauchst eine gute Wahl in jedem Slot. Unser Cornerstone-Artikel, Modern App Stack erklärt, legt das ganze Bild dar; dieser Guide ist der Build-Pfad hindurch. - App-Framework: rendert die UI und liefert die App aus (Next.js, TanStack Start, Astro und andere). - Auth: User-Accounts, Login und OAuth, von einem Provider übernommen, damit du nie selbst Passwörter speicherst. - Datenbank: wo deine Daten leben und synchronisieren; Convex ist reaktiv, sodass die UI live aktualisiert. - Payments: Stripe für Checkout, Subscriptions und Webhooks. Siehe den Artikel Modern App Stack erklärt für die ganze Karte. #### Schritt 1: von der Idee zum Scaffold Beginne damit, die Idee auf einen Job einzuengen, den dein Produkt gut macht, und lass dann deinen Agent das Projekt scaffolden. Die Disziplin, die hier zählt, ist Scope: Ein SaaS, das eine Sache klar macht, schlägt eines, das zehn Dinge vage macht, genau wie der favicon-maker-Build gelernt hat. Lass deinen Coding-Agent das Framework, die Versionskontrolle und einen Dev-Server aufsetzen und bring eine leere App lokal zum Laufen, bevor du irgendetwas hinzufügst. Schreib eine CLAUDE.md mit deinem Stack und deinen Konventionen, damit der Agent vom ersten Commit an auf deinen Regeln baut. Das Ziel dieser Stufe ist ein laufendes Skelett, das du deployen kannst, kein Feature, denn die leere Hülle früh auszuliefern entschärft alles, was folgt. - Eng auf einen Kern-Job einengen; widersteh Feature-Creep, bevor du irgendetwas ausgeliefert hast. - Lass den Agent Framework, Git und einen Dev-Server scaffolden und lokal laufen. - Füge eine CLAUDE.md hinzu, damit der Agent von Anfang an deinem Stack und deinen Konventionen folgt. - Course 3 Lektion: Architecture 101 erklärt, wie die Teile zusammenpassen, bevor du sie verdrahtest. #### Schritt 2: Authentifizierung mit Clerk hinzufügen Fast jedes SaaS braucht Accounts, und du solltest Login nie von Grund auf bauen: Eigene Auth zu rollen ist, wie Secrets leaken und Sessions brechen. Ein Auth-Provider übernimmt Signup, Login, OAuth (mit Google und anderen anmelden), Sessions und Sicherheit für dich, also verdrahtest du ein paar Komponenten und schützt deine Routes. Clerk ist der Default, den wir lehren, weil es schnell zu integrieren ist und sauber mit diesem Stack zusammenpasst, aber Auth0 und Supabase Auth sind je nach Bedarf valide Wahlen. Wir schlüsseln diese Entscheidung im Vergleich Clerk vs Auth0 vs Supabase Auth auf; was du auch wählst, das Prinzip ist dasselbe: Delegiere den sicherheitskritischen Teil an Spezialisten. Der Modern App Stack Kurs geht die komplette Clerk-Integration durch, inklusive Google OAuth und dem Dev-zu-Production-Schritt. - Roll nie deine eigene Auth; ein Provider übernimmt Login, OAuth, Sessions und Sicherheit. - Clerk ist hier der Default; wäge es in unserem Vergleich gegen Auth0 und Supabase Auth ab. - Verdrahte die Auth-Komponenten, dann schütze die Routes und Daten, die einen eingeloggten User brauchen. - Course 3 Lektion: Clerk-Authentifizierung und OAuth von Dev bis Production. #### Schritt 3: deine Daten in Convex modellieren Dein SaaS braucht einen Ort, um Daten zu speichern, die einen Refresh überleben und über User geteilt werden, und die moderne Wahl für diesen Stack ist Convex: eine reaktive Datenbank, bei der deine Queries die UI automatisch aktualisieren, wenn sich die zugrunde liegenden Daten ändern, sodass du weit weniger Synchronisations-Code schreibst. Du definierst dein Schema, schreibst Funktionen, die Daten lesen und schreiben, und das Frontend abonniert live Ergebnisse. Convex ist nicht die einzige Option (Supabase und Firebase sind starke Alternativen mit anderen Trade-offs), und wir legen diese Entscheidung im Vergleich Convex vs Supabase vs Firebase dar. Der Grund, warum reaktive Daten für einen Solo-Founder zählen, ist Hebelwirkung: Die Datenbank, die die Live-Updates für dich macht, ist ein System weniger, das du bauen und debuggen musst. Der Modern App Stack Kurs behandelt das Modellieren von Daten und das Schreiben von Convex-Funktionen vollständig. - Eine Datenbank speichert Daten dauerhaft und teilt sie über User und Sessions. - Convex ist reaktiv: Queries aktualisieren die UI live, also schreibst du weniger Sync-Code. - Vergleiche es gegen Supabase und Firebase in unserem Backend-Vergleich, bevor du dich festlegst. - Course 3 Lektion: Convex, deine reaktive Datenbank. Entwirf die API und das Schema vor der UI, wie der BizCollect-Build gelernt hat. #### Schritt 4: Kunden mit Stripe abrechnen Ein SaaS ist ein Business, also braucht es Payments, und Stripe ist der Standard für Checkout, Subscriptions und die Webhooks, die deine App mit dem synchron halten, was ein Kunde tatsächlich bezahlt hat. Der Ablauf hat zwei Hälften. Erst Checkout und Subscriptions: Du erstellst Products und Prices, schickst den Kunden zu Stripe zum Zahlen und bringst ihn zurück. Dann die Webhooks: Stripe sagt deinem Backend, wenn eine Zahlung erfolgreich ist, eine Subscription erneuert oder eine Karte fehlschlägt, und dein Code aktualisiert den User-Datensatz entsprechend. Die Falle, in die Einsteiger tappen, ist, den Redirect als Source of Truth zu behandeln; der Webhook ist es. Geh immer sicher mit Secrets um und halte deine Stripe-Keys aus dem Frontend-Code und aus Git heraus. Der Modern App Stack Kurs behandelt Stripe in zwei Lektionen: Checkout und Subscriptions, dann Webhooks, Proration und Coupons. - Stripe übernimmt Checkout, Subscriptions und die Billing-Edge-Cases, die du nicht selbst bauen solltest. - Webhooks, nicht der Redirect, sind die Source of Truth dafür, was ein Kunde bezahlt hat. - Halte Stripe-Secret-Keys im Backend und aus der Versionskontrolle heraus. - Course 3 Lektionen: Stripe Teil 1 (Checkout, Subscriptions) und Stripe Teil 2 (Webhooks, Proration, Coupons). #### Schritt 5: liefere es aus Die letzte Stufe ist die, die Einsteiger aufschieben und früh machen sollten: die App von deiner Maschine ins öffentliche Internet zu bringen, in Production, mit echten Keys. Das heisst, jeden Service (Auth, Datenbank, Payments) von seinem Entwicklungsmodus in Production zu bewegen, Umgebungsvariablen und Secrets korrekt zu behandeln, deine Domain aufzusetzen und die Seite bei der Search Console einzureichen, damit sie gefunden werden kann. Ausliefern ist kein einmaliges Ereignis am Ende; es ist ein Loop, den du vom leeren Scaffold an laufen lassen solltest, damit der Livegang langweilig statt furchteinflössend ist. Der Modern App Stack Kurs schliesst mit genau dem: der Dev-zu-Production-Migration, Search Console und Performance. Sobald es live ist, steuerst du den Agent, um Features genauso hinzuzufügen, wie du das Skelett gebaut hast, und verifizierst jede Änderung, bevor sie ausgeliefert wird. - Bewege Auth, Datenbank und Payments vom Entwicklungs- in den Production-Modus mit echten Keys. - Behandle Secrets und Umgebungsvariablen korrekt; committe nie Keys. - Setze deine Domain auf und reiche die Seite bei der Search Console ein, damit sie gefunden wird. - Course 3 Lektion: Livegang, die Dev-zu-Prod-Migration, Search Console und Performance. #### Steuere den Agent, vibe ihn nicht nur Ein SaaS mit KI zu bauen ist der klarste Fall für Agentic Engineering statt Vibe Coding. Ein Wochenend-Prototyp kann gevibet werden, aber ein Produkt mit echten Usern, ihren Daten und ihrem Geld kann es nicht: Ein stiller Bug in deinem Stripe-Webhook oder eine ungeschützte Convex-Query ist die Art Fehler, die Vertrauen oder Geld kostet. Also steuerst du den Agent und verifizierst seine Arbeit: plane, bevor er editiert, lies die Diffs bei allem, was Auth, Daten oder Payments berührt, und halte ein Quality Gate (Lint, Types, Tests) grün. Dieselben Agenten, die einen fragilen Haufen produzieren, wenn du alles ungeprüft annimmst, produzieren ein wartbares SaaS, wenn du der Engineer of Record bleibst. Echte Produkte werden so gebaut; der CallAssistant-Build ist ein funktionierendes SaaS, ausgeliefert auf genau dieser Disziplin, und der Pillar Was ist Agentic Engineering erklärt die Denkweise vollständig. - Vibe einen Prototyp; steuere und verifiziere alles mit echten Usern, Daten oder Payments. - Plane vor dem Editieren und lies jeden Diff, der Auth, Daten oder Geld berührt. - Halte ein Quality Gate grün, damit keine Regression in Production rutschen kann. - Siehe den CallAssistant-Build für ein ausgeliefertes SaaS und den Pillar Was ist Agentic Engineering für die Disziplin. ### KI Automatisierung fuer Unternehmen - Kanonische URL: https://agenticschool.dev/de/ratgeber/ai-automation-for-business KI-Automatisierung fuer Unternehmen heisst, KI und Workflow-Tools zu nutzen, um deinem Team repetitive, regelbasierte Arbeit abzunehmen, damit es seine Zeit für das verbringt, was wirklich einen Menschen braucht. Gut gemacht ist es eines der renditestärksten Dinge, die ein kleines Unternehmen 2026 tun kann, und schlecht gemacht ein teures Wissenschaftsprojekt. Dieses Playbook ist die praktische Version: wie du die erste zu automatisierende Aufgabe wählst, wann du ein Tool kaufst statt selbst baust, wie du zwischen n8n, Zapier und Make wählst, wie echte Automatisierungen aussehen und wie du die Rendite ehrlich misst, damit du die, die sich rechnen, weiter machst und die, die es nicht tun, einstellst. Es ist für die Person geschrieben, die entscheidet, wohin Automatisierung gehört, nicht nur für die, die sie baut, und es passt zum Kurs Automation und Agentic Systems. Alles hier ist Stand Juni 2026. #### Wo anfangen: die richtige erste Aufgabe wählen Der grösste Fehler ist, mit der spannendsten Aufgabe statt mit der am besten automatisierbaren zu beginnen. Der beste erste Kandidat ist langweilig: eine Aufgabe, die oft passiert, jedes Mal denselben Schritten folgt, einen klaren Trigger und einen klaren Output hat und aktuell echte Stunden frisst. Etwas Seltenes oder Urteilslastiges zu automatisieren ist schwer und renditeschwach; eine häufige, regelbasierte Routinearbeit zu automatisieren ist einfach und rechnet sich schnell. Such die Arbeit, die Leute still überspringen oder inkonsistent machen, weil sie lästig ist, derselbe Instinkt hinter dem s2p-Build, der das Posten jedes Releases auf jeden Kanal automatisierte, weil der Founder aus Faulheit immer wieder Kanäle übersprang. Workflow-Automatisierung ist der Oberbegriff dafür, Services zu verbinden, sodass ein Trigger eine Kette von Schritten auslöst; beginne dort, wo diese Form sauber passt. - Hohe Frequenz: Sie passiert täglich oder mehrmals pro Woche, sodass gesparte Minuten sich aufsummieren. - Regelbasiert: Dieselben Inputs ergeben dieselben Schritte, mit wenig nötigem Urteil. - Klarer Trigger und Output: Etwas startet sie (ein Formular, eine E-Mail, ein Timer) und etwas Konkretes kommt heraus. - Aktuell schmerzhaft: Leute überspringen sie, machen sie spät oder inkonsistent. Siehe den s2p-Build als echtes Beispiel. #### Build vs Buy: die ehrliche Entscheidung Die meisten Automatisierungen solltest du kaufen oder zusammensetzen, nicht bauen. Wenn ein Standard-Tool oder eine Workflow-Plattform den Job schon macht, nutze sie: Deine Zeit ist besser in die Teile deines Business investiert, die kein Anbieter verkauft. Bau deine eigene nur, wenn der Workflow zentral dafür ist, wie du dich differenzierst, wenn kein Tool ohne hässliche Workarounds passt, oder wenn die Per-Use-Kosten eines gehosteten Tools schneller wachsen als die Kosten, es zu besitzen. Eine gute Sequenz ist, mit der schnellsten Option zu prototypen, um zu beweisen, dass der Workflow das Automatisieren überhaupt wert ist, und dann die bewährten, volumenstarken auf etwas zu verschieben, das du kontrollierst. Der Kurs Automation und Agentic Systems formuliert dieselbe Regel: Bevor du eine Custom-App baust, frag, ob ein Workflow-Tool es in einem Nachmittag erledigen kann. - Kaufe oder setze per Default zusammen; bau nur, wenn der Workflow zentral ist oder kein Tool passt. - Prototype schnell, um zu validieren, dass der Workflow das Automatisieren wert ist, bevor du investierst. - Verschiebe bewährte, volumenstarke Workflows auf etwas, das du kontrollierst, wenn Kosten oder Komplexität wachsen. - Course 4 Lektion: Workflow Automation erklärt, wann ein Custom-Build eine Plattform schlägt. #### Eine Plattform wählen: n8n vs Zapier vs Make Die drei Plattformen, die für Business-Automatisierung zählen, unterscheiden sich am meisten darin, wie sie abrechnen und wie viel Kontrolle du bekommst, und dieser Unterschied treibt die Kosten bei Volumen. Zapier rechnet pro Task ab, wobei jeder Schritt, der läuft, zählt, also ist es am einfachsten zu starten und am teuersten, wenn Volumen und Schrittzahl wachsen. Make rechnet pro Operation ab (jede Aktion) und sitzt in der Mitte. n8n rechnet pro Workflow-Execution ab, zählt einen ganzen Lauf unabhängig von der Schrittzahl, und es ist Open-Source und selbst hostbar, sodass ein vielschrittiger Workflow auf n8n dramatisch günstiger laufen kann als auf einem Per-Task-Plan. Die praktische Regel: Prototype in Zapier wegen seines riesigen Integrations-Katalogs, dann verschiebe volumenstarke oder vielschrittige Workflows auf selbst gehostetes n8n. Unser Vergleich n8n vs Zapier vs Make schlüsselt die Trade-offs vollständig auf. - Zapier: am einfachsten zu starten, der breiteste Integrations-Katalog, pro Task abgerechnet (jeder Schritt zählt). Gut bei niedrigem Volumen, teuer bei hohem. - Make: visuell und fähig, pro Operation abgerechnet (jede Aktion). Ein Mittelweg bei den Kosten. - n8n: Open-Source und selbst hostbar, pro Workflow-Execution abgerechnet (ein ganzer Lauf ist eins), sodass vielschrittige Workflows günstig bleiben. Am besten für Volumen und Kontrolle. - Faustregel: Prototype in Zapier, verschiebe volumenstarke Glue auf selbst gehostetes n8n. Siehe den vollständigen Vergleich. #### Echte Workflow-Beispiele Automatisierung wird schnell konkret, sobald du echte Formen siehst. Eine Release-zu-Social-Pipeline verwandelt eine einzige veröffentlichte Änderung automatisch in formatierte Posts über jeden Kanal, hält sie konsistent und überspringt nie einen, genau das ist der s2p-Build. E-Mail-Automatisierung entwirft, sendet und folgt nach, während sie ein menschliches Freigabe-Gate für alles ausserhalb der bekannt-sicheren Fälle behält, sodass sie Zeit spart, ohne wie ein Bot zu klingen, wie es der AutoMail-Build tut. Dokument-zu-Daten-Automatisierung liest ein unordentliches Rechnungsfoto und schreibt eine saubere Datenbankzeile, markiert die Felder mit niedriger Confidence für einen Menschen, das ist der invoice-automation-Build. Der gemeinsame Faden ist nicht die KI; es ist zuverlässige Plumbing um einen klaren Trigger und einen klaren Output, mit einem Menschen, der die Ränder beobachtet. - Release zu Social: Eine Source of Truth wird zu konsistenten Posts überall (der s2p-Build). - E-Mail mit menschlichem Gate: automatisch entwerfen und nachfassen, die unsicheren Fälle freigeben (der AutoMail-Build). - Dokument zu Daten: ein Rechnungsfoto in eine validierte Datenbankzeile lesen, Felder mit niedriger Confidence markieren (der invoice-automation-Build). - Der KI-Schritt ist der einfache Teil; zuverlässige Trigger, Retries und Idempotenz sind, wo Automatisierung gelingt oder scheitert. #### Behalte einen Menschen im Loop Der schnellste Weg, Vertrauen in Automatisierung zu verlieren, ist, ihr am ersten Tag volle Autonomie zu geben und zuzusehen, wie sie selbstbewusst das Falsche tut. Automatisierung verdient Vertrauen schrittweise: Beginne damit, dass das System entwirft und ein Mensch freigibt, befördere eine Kategorie erst zu voll automatisch, sobald sie sich bewährt hat, und behalte ein menschliches Gate bei allem Irreversiblen oder Kundenseitigen. Das ist kein Versagen der Automatisierung; es ist das, was Automatisierung sicher verlässlich macht, und es ist das Muster hinter jedem verlässlichen System, das die Founder-Builds beschreiben. Passe die Autonomie an die Kosten eines Fehlers an. Ein fehlgeposteter Tweet ist erholbar; eine falsche Rechnung nahe am Geld von jemandem nicht. Der Kurs Automation und Agentic Systems behandelt Human-in-the-Loop-Design und die 5 Stufen der Autonomie als bewusste Wahl. - Beginne mit Entwerfen-und-Freigeben; weite Autonomie nur aus, wenn jede Kategorie sie verdient. - Behalte ein menschliches Gate bei allem Irreversiblen, Finanziellen oder Kundenseitigen. - Passe Autonomie an die Kosten eines Fehlers an, nicht daran, wie beeindruckend volle Automatisierung wirkt. - Course 4 Lektionen: Human in the Loop und die 5 Stufen der LLM-Autonomie. #### Den ROI ehrlich messen Automatisierung verdient nur zu überleben, wenn sie sich rechnet, und das heisst, sie davor und danach zu messen, statt anzunehmen. Die Rendite ist einfach zu durchdenken: Schätze die Stunden, die die Aufgabe jetzt braucht, und die vollen Kosten dieser Stunden, zieh die Zeit ab, die die Automatisierung noch braucht (Aufsicht, Fixes, die gelegentliche manuelle Ausnahme), und die Kosten der Tools, und vergleiche das mit dem Setup-Aufwand für eine Amortisationszeit. Die ehrliche Version zählt auch die qualitativen Gewinne, die Automatisierung liefert und die eine Stoppuhr verpasst: Konsistenz (der Kanal, der nie übersprungen wird), weniger Fehler und schnellere Durchlaufzeit. Verfolge ein paar echte Zahlen pro Automatisierung, stell die ein, die sich nicht amortisieren, und verdopple die, die es tun. Widersteh dem Zählen von Fantasie-Ersparnissen; eine Automatisierung, die ständiges Babysitting braucht, spart nicht die Stunden, die du denkst. - Gesparte Zeit = Stunden, die die Aufgabe brauchte, minus die Zeit, die die Automatisierung noch braucht (Aufsicht, Ausnahmen). - Gespartes Geld = gesparte Zeit mal die vollen Stundenkosten, minus Tool-Kosten. - Amortisationszeit = Setup-Aufwand geteilt durch monatliche Ersparnis; unter ein paar Monaten ist meist ein klarer Gewinn. - Zähle auch Konsistenz und weniger Fehler, aber nie Ersparnisse, die eine Automatisierung nicht tatsächlich liefert. ### Prompt Patterns fuer Coding Agents - Kanonische URL: https://agenticschool.dev/de/ratgeber/prompt-patterns-for-coding-agents Ein Coding Agent ist nur so gut wie der Auftrag, den du ihm gibst, und der Unterschied zwischen einer frustrierenden und einer zuverlässigen Session ist selten das Modell, sondern der Prompt. Einen Coding Agent zu prompten ist nicht dasselbe wie mit einem Chatbot zu plaudern: Der Agent liest deine Dateien, führt Befehle aus und handelt in einem Loop, also setzt ein guter Prompt die Rolle, definiert, wie "fertig" aussieht, zeigt die Form einer guten Antwort, zerlegt grosse Arbeit in prüfbare Schritte und sagt dem Agenten, wie er seinen eigenen Output verifiziert. Dieser Guide sammelt die Prompt Patterns, die mit Coding Agents wie Claude Code und Codex CLI verlässlich funktionieren, mit konkreten Beispielen zum Anpassen, und die Anti-Patterns, die still deine Zeit und Tokens verschwenden. Alles hier ist Stand Juni 2026 und passt zur Foundations-Lektion zum Prompt Engineering. #### Warum das Prompten eines Coding Agents anders ist Ein Chatbot antwortet einmal; ein Coding Agent arbeitet in einem Loop, liest dein Repository, editiert Dateien, führt deine Tests aus und reagiert auf die Ergebnisse. Das ändert, was ein guter Prompt leisten muss. Du fragst nicht nach einem Snippet, du briefst einen Teamkollegen, der echte Aktionen in deiner Codebasis ausführt, also muss der Prompt die Absicht tragen (was du willst und warum), die Constraints (deinen Stack, deine Konventionen und was er nicht anfassen soll) und eine Definition von "fertig", gegen die der Agent sich selbst prüfen kann. Der grösste Hebel ist, die stehenden Regeln ganz aus dem Prompt zu nehmen: Schreib deinen Stack, deine Konventionen und dein Quality Gate in eine CLAUDE.md oder AGENTS.md, damit jeder Prompt von deinen Regeln startet und der Prompt selbst nur die Aufgabe tragen muss. Die Patterns unten setzen dieses Fundament voraus und konzentrieren sich auf den Auftrag pro Aufgabe. - Der Agent handelt: Er editiert Dateien und führt Befehle aus, also wird vage Absicht zu falschen Änderungen, nicht nur zu einem falschen Satz. - Stehende Regeln gehören in CLAUDE.md oder AGENTS.md, nicht in jeden Prompt; siehe How to Use Claude Code. - Ein guter Prompt pro Aufgabe trägt Absicht, Constraints und eine prüfbare Definition von "fertig". - Kontext ist endlich: Ein fokussierter Prompt lässt dem Agenten Platz, Code zu lesen und zu denken. Siehe das Glossar zum Context Window. #### Pattern 1: Rolle und Spec Der verlässlichste Einstieg ist, die Rolle zu nennen, die der Agent annehmen soll, und dann die Aufgabe als enge, testbare Spec statt als Wunsch zu spezifizieren. Eine Spec nennt das Ziel, die Constraints, die Dateien oder den Bereich im Scope und die Akzeptanzkriterien, die entscheiden, wann es fertig ist. "Mach den Login besser" ist ein Wunsch; die Version unten ist eine Spec. Die Rollen-Zeile fokussiert das Modell (ein Senior Engineer reviewt anders als ein Tutor), und die Akzeptanzkriterien geben dem Agenten etwas Konkretes zum Verifizieren, was ihn davon abhält, zu früh den Sieg zu erklären. Halte die Spec auf das Wesentliche: Jede Zeile überzuspezifizieren nimmt dem Agenten die Fähigkeit, gute lokale Entscheidungen zu treffen. ```markdown Role: act as a senior backend engineer on this codebase. Goal: add rate limiting to the public /api/contact endpoint. Constraints: - Use the existing Convex rate-limit helper; do not add a new dependency. - Limit to 5 requests per minute per IP. Return 429 with a clear JSON body. - Touch only the contact route and its test; leave other endpoints alone. Done when: - A new test proves the 6th request in a minute gets a 429. - `bun run lint && bun run typecheck && bun run test` all pass. Plan first (do not edit yet), show me the plan, and wait for my go-ahead. ``` Das Rolle-und-Spec-Pattern: eine Rolle, ein Ziel, explizite Constraints und Akzeptanzkriterien, gegen die der Agent prüfen kann. #### Pattern 2: zeig ein Beispiel (Few-Shot) Modelle matchen Muster, also ist der schnellste Weg zu Output in der gewünschten Form, eines zu zeigen. Wenn du eine neue Datei, Komponente, einen Test oder eine Migration brauchst, die wie die schon vorhandenen aussehen soll, zeig dem Agenten ein bestehendes Beispiel und bitte ihn, derselben Struktur zu folgen: "Schreib den neuen Endpoint genauso wie src/api/users.ts, inklusive Test-Datei." Dieses Few-Shot-Pattern funktioniert, weil deine Codebasis der beste Style Guide ist, den du hast, und es schlägt das Beschreiben deiner Konventionen in Prosa. Für Output, auf den du nicht zeigen kannst, gib ein winziges Inline-Beispiel des erwarteten Formats (eine Beispiel-Logzeile, eine JSON-Form, einen Commit-Message-Stil), damit der Agent ein Ziel zum Matchen hat. - Zeig auf eine bestehende Datei: "Folge der Struktur von src/api/users.ts und ihrem Test." - Deine Codebasis ist dein Style Guide; ein Beispiel schlägt einen Absatz Konventionen. - Für neue Formate inline ein winziges Sample des exakten Outputs (eine Logzeile, eine JSON-Form). - Ein scharfes Beispiel übertrifft meist mehrere vage Anweisungen. #### Pattern 3: grosse Arbeit in Schritte zerlegen Grosse, vage Anfragen sind, wo Agenten abdriften: Aufgefordert, "das Dashboard zu bauen", treffen sie hundert Entscheidungen, die du anders getroffen hättest, und vergraben die Fehler in einem riesigen Diff. Die Lösung ist Decomposition. Entweder zerlegst du die Arbeit selbst in eine Sequenz kleiner, separat reviewbarer Aufgaben, oder du bittest den Agenten, zuerst einen Plan vorzuschlagen, und gibst ihn frei, bevor Code geschrieben wird. Plan-First ist die wirkungsvollste Gewohnheit mit Coding Agents: Eine falsche Richtung, im Plan abgefangen, kostet nichts, während derselbe Fehler nach einem tausendzeiligen Diff echte Zeit kostet. In Claude Code ist das der Plan-Modus (Shift+Tab); in jedem Agenten kannst du einfach anweisen "plan first, do not edit, show me the steps". Dann implementiere einen Schritt, reviewe, und geh zum nächsten. - Teile eine grosse Aufgabe in kleine, separat reviewbare Schritte statt einen Mega-Prompt. - Bitte um einen Plan vor den Edits; einen Plan zu korrigieren ist gratis, einen riesigen Diff nicht. - Implementiere einen Schritt, reviewe den Diff, dann mach weiter; halte jede Änderung lesbar klein. - Kleinere Schritte halten auch das Context Window sauber, sodass der Agent über die Aufgabe scharf bleibt. #### Pattern 4: einen Verification Loop bauen Das definierende Merkmal eines Coding Agents ist, dass er Dinge ausführen kann, also sagen die besten Prompts ihm, wie er seine eigene Arbeit prüft und weitermacht, bis die Prüfung besteht. Statt "fix den fehlschlagenden Test" sag "führe die Test-Suite aus, fix, was rot ist, und führe sie wieder aus; hör nicht auf, bis sie grün ist". Statt darauf zu vertrauen, dass eine Änderung funktioniert, sag dem Agenten, er soll den Type-Checker, den Linter und die Tests laufen lassen und den tatsächlichen Output lesen statt anzunehmen. Das macht aus dem Agenten statt einem One-Shot-Generator einen geschlossenen Loop, der sich in echten Ergebnissen verankert. Die stärkste Version backt den Loop in dein Projekt ein, sodass er nicht mal ein Prompt ist: Hooks, die dein Gate automatisch laufen lassen (siehe den Claude Code Hooks Guide), bedeuten, dass der Agent an den Standard gehalten wird, egal ob du daran denkst zu fragen. - Bitte den Agenten, das Gate (Types, Lint, Tests) laufen zu lassen und den echten Output zu lesen, nicht anzunehmen. - Lass ihn iterieren: "fix und führe erneut aus, bis die Suite grün ist", nicht einen einzelnen Durchlauf. - Für UI oder Verhalten lass ihn den Dev-Server oder einen Playwright-Check laufen, damit er das echte Ergebnis sieht. - Automatisiere den Loop mit Hooks, sodass Verifikation jedes Mal passiert, nicht nur wenn du dran denkst. #### Pattern 5: gib dem Agenten den richtigen Kontext, nicht allen Agenten scheitern öfter an fehlendem Kontext als an einem schwachen Modell: Aufgefordert, eine API ohne ihre Docs zu nutzen, raten sie. Also bring dem Agenten, was er braucht, bewusst. Zeig auf die relevanten Dateien, füg den Fehler vollständig ein, verlink die Doku, nenn die exakte Funktion. Aber widersteh der gegenteiligen Falle, alles abzuladen: Ein Context Window vollgestopft mit zwanzig Dateien und einer langen Historie verschlechtert die Qualität, weil das Modell das wichtige Detail im Rauschen verliert (der "Lost in the Middle"-Effekt). Die Kunst ist Kuratierung: genug Kontext zum Gelingen, wenig genug, um scharf zu bleiben. Das ist der Kern des Context Engineering, und unser Context-Engineering-Guide geht tief auf das Managen des Windows über eine lange Aufgabe ein. - Nenn die exakten Dateien, füg den vollständigen Fehler ein und verlink die Doku, die der Agent braucht. - Lad nicht das ganze Repo ab; relevanter Kontext schlägt maximalen Kontext jedes Mal. - Achte auf "Lost in the Middle": ein Schlüssel-Detail in einem riesigen Prompt vergraben wird ignoriert. - Siehe den Context-Engineering-Guide und das Glossar zum Context Window und System Prompt. #### Anti-Patterns, die du vermeidest Der meiste Prompting-Schmerz kommt aus einer kurzen Liste wiederholbarer Fehler. Sie zu benennen macht sie in den eigenen Gewohnheiten leicht zu erkennen. Die Heilung für jeden ist ein Pattern von oben: sei spezifisch, zeig ein Beispiel, zerlege, verifiziere und kuratiere den Kontext. - Vage Wünsche: "mach es besser" gibt dem Agenten nichts zum Verifizieren. Nenn eine Spec und Akzeptanzkriterien. - Der Mega-Prompt: eine riesige Anfrage, die hundert Entscheidungen in einem nicht reviewbaren Diff vergräbt. Zerlege und plane zuerst. - Vertrauen ohne Verifikation: Output annehmen, den du den Agenten nicht testen liessest. Bau einen Verification Loop. - Context Dumping: alles einfügen, sodass das Signal ertrinkt. Kuratiere auf das, was die Aufgabe braucht. - Regeln jede Runde neu tippen: Stack und Konventionen gehören in CLAUDE.md oder AGENTS.md, nicht in jeden Prompt. - Höflichkeit als Anweisung: "bitte versuch vielleicht" liest sich als optional. Sei direkt; Constraints sind Regeln, keine Vorschläge. ### Context Engineering erklaert - Kanonische URL: https://agenticschool.dev/de/ratgeber/context-engineering Context Engineering ist die Praxis, bewusst zu managen, was ein KI-Agent gerade in seinem Context Window hält, damit er über eine lange Aufgabe genau und schnell bleibt, statt langsam in Verwirrung abzudriften. Das Context Window ist das Arbeitsgedächtnis des Modells: der System Prompt, deine Regeln, die Dateien, die es gelesen hat, die verfügbaren Tools, die bisherige Konversation. Es ist endlich, und die wichtigste Tatsache darüber ist, dass die Qualität sinkt, während es sich füllt, nicht sanft, sondern mit einer Klippe. Context Engineering ist, wie du die richtigen Dinge im Window behältst und die falschen draussen: durch Compaction, Retrieval, Reihenfolge und Prompt Caching zur Kostenkontrolle. Dieser Guide erklärt, was das Window füllt, warum ein volles Window schadet, und die Techniken, die agentische Arbeit zuverlässig halten. Alles hier ist Stand Juni 2026 und passt zur Context-Engineering-Lektion in Kurs 2. #### Was das Context Window tatsächlich hält Das Context Window ist alles, was das Modell sehen kann, wenn es seine nächste Antwort generiert, gemessen in Tokens (Text-Stücke, grob vier Zeichen je Token). Für einen Coding Agent füllt es sich mit mehr als deiner letzten Nachricht: dem System Prompt, der den Agenten definiert, deinen CLAUDE.md- oder AGENTS.md-Regeln, den Definitionen jedes verbundenen Tools und MCP-Servers, jeder Datei, die der Agent gelesen hat, jedem Befehls-Output, den er gesehen hat, und der gesamten bisherigen Konversation. All das konkurriert um dasselbe endliche Budget. Das Mental Model, das zählt: Kontext ist eine knappe Ressource, die du ausgibst, und alles, was du lädst (ein gesprächiger MCP-Server, eine riesige Datei, ein langes Hin und Her), ist Budget, das die eigentliche Aufgabe nicht mehr hat. Siehe das Glossar zum Context Window für die formale Definition. - Der System Prompt und deine CLAUDE.md- / AGENTS.md-Regeln, jede Runde neu geladen. - Tool- und MCP-Server-Definitionen, weshalb das Verbinden vieler Server teuer ist. - Jede gelesene Datei und jeder Befehls-Output, was sich während einer Aufgabe schnell aufsummiert. - Die gesamte Konversations-Historie; lange Sessions tragen ihre ganze Vergangenheit mit. #### Warum ein volles Window schadet: die Performance-Klippe Es ist verlockend zu denken, ein grösseres Context Window heisse, du müsstest dir keine Sorgen mehr machen, aber das Gegenteil stimmt: Die Modellqualität sinkt deutlich, bevor das Window technisch voll ist, und sie sinkt scharf. Während das Window sich mit Dateien, Historie und Rauschen füllt, hat das Modell mehr zu beachten und verliert eher den Faden, widerspricht einer früheren Anweisung oder vergisst eine Constraint vom Anfang der Konversation. Das ist die "Performance-Klippe", und sie ist der Grund, warum ein 1M-Token-Window nicht heisst, dass du 1M Tokens hineinschütten solltest. Die praktische Erkenntnis ist kontraintuitiv, aber verlässlich: Ein kleinerer, gut kuratierter Kontext übertrifft meist einen grösseren, vollgestopften. Context Engineering existiert genau, um dich auf der guten Seite dieser Klippe zu halten. - Die Qualität fällt, bevor das Window voll ist, und der Fall ist eine Klippe, kein sanftes Gefälle. - Ein vollgestopftes Window lässt das Modell Fäden verlieren, sich widersprechen und Constraints fallen lassen. - Ein grosser Maximalkontext ist eine Decke, kein Ziel; füll ihn nicht, weil du kannst. - Ein kuratierter kleiner Kontext schlägt einen aufgeblähten grossen, die zentrale Regel des Context Engineering. #### Lost in the Middle "Lost in the Middle" ist ein gut dokumentiertes Verhalten von Sprachmodellen: Sie beachten Information am Anfang und am Ende ihres Kontexts am verlässlichsten und am wenigsten verlässlich Information, die in der Mitte vergraben ist. Eine entscheidende Anweisung oder die eine relevante Tatsache, in die Mitte eines langen Prompts oder einer langen Konversation fallen gelassen, ist das, was am ehesten ignoriert wird. Die praktische Konsequenz prägt, wie du Kontext anordnest. Setz die wichtigsten Anweisungen und das relevanteste Material dorthin, wo das Modell hinschaut: nahe dem Anfang (deine stehenden Regeln) und nahe dem Ende (die unmittelbare Aufgabe und die Schlüssel-Datei). Nimm nicht an, dass das Modell etwas nutzt, nur weil es irgendwo im Window steht. Position ist Hebel. - Modelle beachten Anfang und Ende des Kontexts am besten, die Mitte am schlechtesten. - Eine Schlüssel-Anweisung mitten im Prompt vergraben wird am ehesten ignoriert. - Setz stehende Regeln nahe an den Anfang und die unmittelbare Aufgabe und Schlüssel-Datei nahe ans Ende. - Im Window zu sein heisst nicht, genutzt zu werden; Position bestimmt Aufmerksamkeit. #### Compaction, Handovers und Resets Wenn eine Session lang läuft, brauchst du Wege, Gewicht abzuwerfen, ohne den Faden zu verlieren. Drei Techniken erledigen das meiste. Compaction fasst die bisherige Konversation in kompakter Form zusammen und macht weiter, befreit das Window; der Haken ist, dass automatische Compaction still Details fallen lässt, die dir wichtig waren, also steuere sie, indem du dem Agenten sagst, was er vor der Compaction bewahren soll. Ein Handover beendet eine Session und startet eine frische mit einer sauberen, bewussten Zusammenfassung, die du schreibst, was dir einen weit aufgeräumteren Kontext gibt, als eine Session stundenlang ausufern zu lassen. Ein Reset wirft einen Kontext weg, der verwirrt ist, und startet neu mit einem engen Prompt, was oft schneller ist, als einen entgleisten Agenten zurück auf Kurs zu argumentieren. Zu wissen, wann man zu welchem greift, ist der praktische Kern der Fähigkeit. - Compaction: zusammenfassen und weitermachen, um das Window zu befreien; steuere sie, damit sie behält, was zählt. - Handover: die Session beenden und frisch starten mit einer sauberen Zusammenfassung, die du kontrollierst. - Reset: einen verwirrten Kontext verwerfen und mit einem engen Prompt neu starten statt zu argumentieren. - Subagents helfen auch: Delegiere laute Arbeit, sodass ihr Output nie in deinem Haupt-Window landet. #### Retrieval: nur reinbringen, was gebraucht wird Der gegenteilige Fehlermodus zum vollgestopften Window ist, dass die richtige Information nie ankommt. Retrieval ist, wie du genau das relevante Stück bei Bedarf hereinholst, statt alles vorzuladen. Für einen Coding Agent ist das meist konkret und unglamourös: Lass den Agenten die Codebasis durchsuchen und nur die Dateien lesen, die eine Aufgabe berührt, statt das ganze Repo einzufügen; zeig ihm die eine Doku-Seite, die er braucht; lass ihn nach der Funktion greppen statt das Verzeichnis zu laden. Das Prinzip hinter Retrieval-Augmented-Patterns ist dasselbe, ob es eine Vektordatenbank oder ein Agent ist, der grep ausführt: Hol genau das, was die Aufgabe braucht, wenn sie es braucht, damit das Window Signal hält statt einen hoffnungsvollen Haufen vielleicht-relevanten Materials. - Hol die spezifische Datei, Doku oder den Datensatz, den die Aufgabe braucht, nicht alles potenziell Relevante. - Lass einen Coding Agent bei Bedarf suchen und lesen, statt das ganze Repo vorzuladen. - Retrieval hält das Window voll Signal, was das Modell auf der guten Seite der Klippe hält. - Dieselbe Idee skaliert hoch zur Vektorsuche; das Ziel ist immer relevant-bei-Bedarf, nicht alles-auf-Verdacht. #### Prompt Caching: die Kosten eines grossen Kontexts kontrollieren Ein grosser, stabiler Kontext ist teuer, weil das Modell jeden seiner Tokens bei jeder Anfrage neu verarbeitet, und du zahlst diese Input-Tokens jedes Mal. Prompt Caching löst die Kostenseite: Du markierst ein stabiles Präfix (deinen System Prompt, Regeln, Tool-Definitionen, ein grosses Referenzdokument) als cachebar, und nachfolgende Anfragen, die mit denselben exakten Bytes beginnen, lesen es aus dem Cache statt es neu zu berechnen. Auf der Claude API ist die Ökonomie im Juni 2026 klar: Ein Cache-Write kostet etwa das 1,25-Fache eines normalen Input-Tokens für die Standard-Lebensdauer von fünf Minuten (oder das 2-Fache für die Ein-Stunden-Option), und ein Cache-Read kostet nur etwa das 0,1-Fache, ein Zehntel des Preises. Ein gecachtes Präfix amortisiert sich also innerhalb von ein paar Wiederverwendungen. Der Cache ist ein Präfix-Cache, also zählt die Reihenfolge: Setz deinen stabilen Inhalt zuerst und deinen wechselnden Inhalt zuletzt, und ein einziges geändertes Token vor dem Breakpoint erzwingt einen vollen Re-Write. Caching reduziert nicht, wie viel Kontext das Modell beachtet, nur was du zahlst, um ihn zu senden, also ergänzt es Kuratierung, statt sie zu ersetzen. - Caching verwendet den enkodierten Zustand eines stabilen Präfix wieder, sodass es nicht jede Anfrage neu berechnet wird. - Auf der Claude API (Juni 2026): Cache-Writes etwa 1,25x Input (5-Minuten-Standard, 2x für 1 Stunde), Cache-Reads etwa 0,1x. - Es ist ein Präfix-Cache: Halte stabilen Inhalt zuerst und wechselnden Inhalt zuletzt, sonst erzwingst du einen Re-Write. - Caching senkt Kosten, nicht Aufmerksamkeit; du kuratierst das Window weiterhin. Siehe das Glossar zu Prompt Caching. #### Eine praktische Context-Engineering-Checkliste Setz die Ideen zu Gewohnheiten zusammen, die du ohne Nachdenken ausführst. Nichts davon braucht spezielles Tooling; es ist Disziplin darüber, was du lädst und wann du aufräumst. Ein künftiger Begleiter ist das Token- und Context-Estimator-Tool auf diesem Campus, mit dem du Text einfügen und sehen wirst, wie viel eines Modell-Windows er füllt, bevor du ihn sendest; vorerst tragen dich die Regeln unten. - Halte stehende Regeln in CLAUDE.md oder AGENTS.md, und halte diese Datei knapp; sie lädt jede Runde. - Lad die Dateien, die die Aufgabe braucht, nicht das ganze Repo; lass den Agenten bei Bedarf retrieven. - Setz die wichtigste Anweisung nahe an den Anfang und die unmittelbare Aufgabe nahe ans Ende. - Compacte, übergib oder resette, wenn eine Session lang oder verwirrt wird; lass sie nicht ausufern. - Cache grosse stabile Präfixe zur Kostenkontrolle, mit stabilem Inhalt zuerst. - Delegiere laute Nebenarbeit an einen Subagent, sodass sein Output aus deinem Haupt-Window bleibt. ### GEO vs SEO vs AEO - Kanonische URL: https://agenticschool.dev/de/ratgeber/geo-vs-seo-vs-aeo GEO, SEO und AEO sind drei überlappende Disziplinen, um gefunden zu werden, und 2026 brauchst du alle drei, weil Discovery jetzt an zwei Orten passiert: klassischen Suchergebnissen und KI-Antworten. SEO (Search Engine Optimization) ist das langjährige Handwerk, in Google und Bing zu ranken. AEO (Answer Engine Optimization) dreht sich darum, die Quelle zu sein, die eine Answer Engine extrahiert, wenn sie eine direkte Antwort gibt. GEO (Generative Engine Optimization) dreht sich darum, in den synthetisierten Antworten generativer Assistenten wie ChatGPT, Perplexity und Claude zitiert und empfohlen zu werden. Sie teilen die meisten ihrer Taktiken und unterscheiden sich darin, worauf sie optimieren. Dieser Guide definiert jede genau, zeigt, wie sie zusammenhängen, und gibt dir eine praktische Checkliste (Structured Data, llms.txt, Answer-First-Content), die du heute anwenden kannst. Alles hier ist Stand Juni 2026 und passt zur SEO-und-GEO/AEO-Lektion in Kurs 5. #### Die drei Begriffe, definiert Es ist leicht, diese als Buzzwords zu behandeln, also pinn fest, was jeder tatsächlich bedeutet. SEO optimiert auf das Ranking in klassischen Suchergebnissen: die blauen Links auf Google und Bing, getrieben von Relevanz, Autorität und Crawlbarkeit. AEO optimiert auf die Antwort-Ebene: als Quelle ausgewählt zu werden, wenn eine Engine eine direkte Antwort, ein Featured Snippet, eine Sprachantwort oder eine KI-Antwortbox liefert, indem du eine spezifische Tatsache, Definition oder Empfehlung leicht extrahierbar machst. GEO optimiert auf generative Antworten: gewählt und zitiert zu werden, wenn ein Assistent wie ChatGPT oder Perplexity eine Antwort aus mehreren Quellen synthetisiert. Die saubere Art, den Unterschied zu halten: SEO rankt Seiten, AEO liefert die Antwort, GEO verdient die Zitierung. Siehe die Glossar-Einträge zu GEO und AEO für die eigenständigen Definitionen. - SEO: in klassischen Suchergebnissen (Google, Bing) ranken durch Relevanz, Autorität und Crawlbarkeit. - AEO: die Quelle sein, die für eine direkte Antwort extrahiert wird (Snippets, Sprache, KI-Antwortboxen). - GEO: in der synthetisierten Antwort eines generativen Assistenten zitiert und empfohlen werden. - Kurzform: SEO rankt die Seite, AEO liefert die Antwort, GEO verdient die Zitierung. #### Wie sie sich unterscheiden und warum sie überlappen Die drei sind keine Rivalen; sie sind Schichten einer Strategie. SEO schafft die Basis-Sichtbarkeit, AEO macht deinen Content extrahierbar für direkte Antworten, und GEO positioniert ihn als vertrauenswürdiges Referenzmaterial, das ein Assistent zitiert. Der Grund, warum du sie nicht getrennt jagen musst, ist, dass sie dasselbe Zugrundeliegende belohnen: klaren, gut strukturierten, vertrauenswürdigen Content, den eine Maschine lesen, verstehen und dem sie vertrauen kann. Die Unterschiede liegen in der Betonung. SEO kümmert sich stark um Links und Ranking-Signale. AEO kümmert sich darum, eine spezifische Frage sauber und früh auf der Seite zu beantworten. GEO kümmert sich um die Signale, die ein Modell als Proxy für Glaubwürdigkeit nutzt: klare Attribution, zitierbare Aussagen, Statistiken und Zitate. Optimiere das gemeinsame Fundament gut, und du bedienst alle drei auf einmal; dann tune die Betonung pro Kanal. - Sie sind Schichten einer Strategie, keine konkurrierenden Taktiken; SEO ist die Basis, AEO und GEO bauen darauf. - Alle drei belohnen dasselbe: klaren, strukturierten, vertrauenswürdigen, maschinenlesbaren Content. - Die Betonung unterscheidet sich: SEO lehnt auf Autorität und Links, AEO auf saubere extrahierbare Antworten, GEO auf Zitierbarkeit. - Generative Engines behandeln Attribution, Zitate, Statistiken und Quellenangaben als Glaubwürdigkeits-Signale. #### Schreib Answer-First-Content Die grösste einzelne Verschiebung für AEO und GEO ist, Content so zu strukturieren, dass eine Maschine die Antwort sauber herauslösen kann. Führ mit der Antwort: Beginne die Seite oder einen Abschnitt damit, die Frage, auf die er zielt, direkt in ein oder zwei eigenständigen Sätzen zu beantworten, dann erweitere. Eine Überschrift als echte Frage formuliert ("Was ist GEO?"), gefolgt von einer sofortigen, zitierbaren Definition, ist weit extrahierbarer als ein Absatz, der sich erst drei Sätze lang aufwärmt. Halte Behauptungen spezifisch und attributierbar, denn Modelle bevorzugen Content, der sich glaubwürdig liest: Nenn Quellen, nimm echte Statistiken auf und nutze klare, zitierbare Aussagen. Ein FAQ-Abschnitt ist eines der wertvollsten Formate, weil jedes Frage-Antwort-Paar eine vorgefertigte, extrahierbare Antwort ist, die direkt darauf abbildet, wie Leute Assistenten befragen. - Antwort zuerst: Beginne jeden Abschnitt damit, seine Frage in ein oder zwei eigenständigen Sätzen zu beantworten. - Formuliere Überschriften als die Fragen, die Leute tatsächlich stellen, und beantworte sie sofort darunter. - Nutze einen echten FAQ-Abschnitt; jedes Frage-Antwort-Paar ist eine fertig extrahierbare Antwort. - Sei spezifisch und attributierbar: Statistiken, klare zitierbare Behauptungen und genannte Quellen lesen sich glaubwürdig. #### Füg Structured Data hinzu Structured Data ist Markup (meist JSON-LD mit dem Schema.org-Vokabular), das Maschinen genau sagt, was dein Content ist, und das Raten beseitigt. Es ist fundamental für alle drei Disziplinen, weil es Such- und Answer-Engines erlaubt, deine Seite zuverlässig zu parsen, statt ihre Bedeutung abzuleiten. Die wertvollen Typen für eine Content-Site sind FAQPage (markiere deine FAQ, sodass jede Frage und Antwort maschinenlesbar ist), Article oder BlogPosting (deklariere Autor, Daten und Headline), HowTo (markiere Schritt-für-Schritt-Guides), BreadcrumbList (drückt die Site-Struktur aus) und Organization oder Person (etabliert, wer hinter dem Content steht, was die Glaubwürdigkeits-Signale füttert, die GEO belohnt). Mach das Markup korrekt und validiere es; kaputte Structured Data hilft niemandem. Dieser Campus emittiert genau diese Typen auf seinen Content-Seiten, die praktische Version des Ratschlags. - Nutze JSON-LD mit Schema.org-Typen, damit Maschinen deinen Content parsen statt zu raten. - Wertvolle Typen: FAQPage, Article/BlogPosting, HowTo, BreadcrumbList, Organization/Person. - Organization- und Person-Markup etabliert, wer hinter dem Content steht, und füttert GEO-Glaubwürdigkeits-Signale. - Validiere dein Markup; kaputte Structured Data ist schlimmer als keine. #### Veröffentliche eine llms.txt und sauberes Markdown llms.txt ist ein einfacher vorgeschlagener Standard: eine Markdown-Datei im Wurzelverzeichnis deiner Site (/llms.txt), die KI-Crawlern eine saubere, kuratierte Karte deines wichtigsten Contents gibt, frei von Navigation, Werbung und Skripten, die eine normale HTML-Seite zumüllen. Es ist eine Agent-First-Höflichkeit, die deine Site billiger und klarer für ein Modell verständlich macht, was genau im Geist von GEO und AEO liegt. Paare sie mit sauberem, semantischem HTML und, wo du kannst, Markdown-Versionen deiner Seiten, sodass der Content, den ein Modell liest, der Content ist, der zählt, statt einer Markup-Suppe. Derselbe Instinkt, der eine Site gut für Assistenten macht (Klarheit, Struktur, kein Ballast), macht sie auch gut für menschliche Leser. Siehe den Glossar-Eintrag zu llms.txt für das Format. - Veröffentliche /llms.txt: eine Markdown-Karte deines Schlüssel-Contents für KI-Crawler, ohne den Seiten-Ballast. - Liefere sauberes, semantisches HTML und Markdown-Twins, wo du kannst, sodass Modelle Signal lesen, keine Suppe. - Es ist eine Agent-First-Höflichkeit, die zum Agent-First-Products-Ansatz beim Bauen passt. - Siehe das Glossar zu llms.txt für das genaue Format und das llms.txt-Generator-Tool, sobald es kommt. #### Gib klassisches SEO nicht auf Im Eifer hin zu KI-Antworten vergisst man leicht, dass die Grundlagen weiterhin das meiste Gewicht tragen, und eine Answer Engine stützt sich oft auf Seiten, die ohnehin gut ranken. Also mach die SEO-Basics weiter: klare, überzeugende Title Tags und Meta Descriptions, eine Sitemap, eine saubere URL-Struktur, schnelle Seiten und eine eingerichtete Search Console, damit du siehst, wie du abschneidest. Autorität und Vertrauen (E-E-A-T: Experience, Expertise, Authoritativeness, Trustworthiness) zählen für alle drei Kanäle, weil sowohl Google als auch die Assistenten Quellen surfacen wollen, auf die sie sich verlassen können. Die ehrliche Einordnung für 2026 ist, dass GEO und AEO kein Ersatz für SEO sind, sondern eine zusätzliche Schicht auf einem soliden SEO-Fundament. Bau das Fundament, dann optimiere auf die Antwort und die Zitierung. - Behalte die SEO-Basics: Title Tags, Meta Descriptions, Sitemaps, saubere URLs, schnelle Seiten, Search Console. - Assistenten zitieren oft Seiten, die schon ranken, also füttert SEO AEO und GEO, statt mit ihnen zu konkurrieren. - E-E-A-T (Experience, Expertise, Authoritativeness, Trust) zählt über alle drei Kanäle. - Behandle GEO und AEO als Schicht auf solidem SEO, nicht als Ersatz dafür. ### Codex CLI Tutorial deutsch - Kanonische URL: https://agenticschool.dev/de/ratgeber/codex-cli-tutorial Codex CLI ist OpenAIs Terminal-basierter Coding Agent: Du führst einen Befehl in deinem Projekt aus, beschreibst in normaler Sprache, was du willst, und der Agent liest deine Dateien, plant, editiert Code und führt Befehle in deinem Terminal aus. Dieses Tutorial bringt dich von "nichts installiert" zu einem produktiven ersten Workflow: wie du Codex CLI installierst, dich anmeldest (mit deinem ChatGPT-Account oder einem API-Key), ihm mit einer AGENTS.md Projektregeln gibst und eine erste Aufgabe sicher ausführst. Wenn du ihn gegen Anthropics Agent abwägst, siehe unseren Vergleich Claude Code vs Codex CLI; die zwei sind nahe Verwandte und die Gewohnheiten übertragen sich. Alles hier wurde im Juni 2026 gegen die offizielle OpenAI-Codex-Doku geprüft, und weil dieses Tool sich schnell entwickelt, sind die exakten Befehle der Teil, den du gegen die Doku doppelt prüfen solltest. #### Was Codex CLI ist Codex CLI ist ein Agent Harness von OpenAI: ein leichtgewichtiger Coding Agent, der in deinem Terminal läuft, ein Modell in einen Loop mit Tools (Dateien lesen, Dateien editieren, Shell-Befehle ausführen) einpackt und direkt in deinem Repository auf ein Ziel hin arbeitet, das du setzt. Wie Claude Code gibt er dir nicht nur Snippets zum Einfügen; er macht Multi-File-Änderungen und führt Befehle aus, und du behältst die Kontrolle, indem du prüfst, was er vorschlägt, und die wichtigen Aktionen freigibst. Er ist Open-Source und wuchs schnell: Anfang 2026 hatte er zwei Millionen wöchentlich aktive Nutzer überschritten. Das Projekt-Konfigurationsmodell ist AGENTS.md, eine offene, tool-agnostische Konvention, um einem Coding Agent seine stehenden Anweisungen zu geben, das Codex-Äquivalent zu Claude Codes CLAUDE.md. Siehe das Glossar zum Agent Harness für das zugrundeliegende Konzept. - Ein Terminal-Coding-Agent, der Code in deinem Repo liest, editiert und ausführt, kein Autocomplete. - Du beaufsichtigst: Er schlägt Aktionen vor und du gibst die wichtigen frei. - Open-Source, mit mehr als zwei Millionen wöchentlich aktiven Nutzern Anfang 2026. - Konfiguriert mit AGENTS.md, einer offenen, tool-agnostischen Konvention für stehende Anweisungen. #### Codex CLI installieren Installiere Codex CLI mit npm oder Homebrew. Die npm-Installation legt das codex-Binary global auf deinen Pfad und braucht Node.js 18 oder neuer; der Homebrew-Cask ist die bequeme Option auf macOS. Wähl eines, dann bestätige, dass es auf deinem Pfad ist. Diese Befehle sind Stand Juni 2026 gegen den offiziellen Quickstart, aber weil das Tool sich schnell bewegt, prüfe die OpenAI-Codex-Doku, falls sich etwas verschoben hat. ```bash # npm (needs Node.js 18+) npm install -g @openai/codex # Homebrew on macOS brew install --cask codex # Confirm it is installed and on your path codex --version ``` Installiere Codex CLI mit npm oder Homebrew, dann prüfe die Version. Im Juni 2026 gegen die offizielle Doku geprüft. #### Anmelden Beim ersten Start fordert Codex dich zur Authentifizierung auf, und du hast zwei Wege. Der empfohlene für die meisten ist die Anmeldung mit deinem ChatGPT-Account, der Codex als Teil eines bezahlten ChatGPT-Plans (Plus, Pro, Business, Edu oder Enterprise) nutzt. Die Alternative ist ein OpenAI-API-Key, pro Token abgerechnet, die richtige Wahl für Automatisierung, CI oder wenn du nutzungsbasierte Abrechnung bevorzugst; beachte, dass sich manche Funktionalität zwischen beiden unterscheiden kann. Um einen Key zu nutzen, setz ihn als Umgebungsvariable vor dem Start, oder folge dem In-App-Login-Flow für ChatGPT. Führ einfach codex aus und wähl "Sign in with ChatGPT", wenn du dazu aufgefordert wirst. ```bash # Start Codex; on first run it walks you through sign-in codex # Option A (recommended): choose "Sign in with ChatGPT" in the prompt # uses your paid ChatGPT plan (Plus, Pro, Business, Edu, Enterprise) # Option B: authenticate with an API key (good for CI and automation) export OPENAI_API_KEY="your-api-key" codex ``` Authentifiziere mit deinem ChatGPT-Account (empfohlen) oder einem OpenAI-API-Key für Automatisierung und CI. #### Ihm mit AGENTS.md Regeln geben AGENTS.md ist, wie du Codex die stehenden Regeln deines Projekts beibringst, dieselbe Rolle, die CLAUDE.md für Claude Code spielt, und weil es eine offene Konvention ist, lesen sie viele Agenten. Codex baut beim Start eine Instruction Chain, läuft von einer globalen Datei hinunter zu deinem aktuellen Verzeichnis und verkettet sie, wobei Dateien näher an deinem Arbeitsverzeichnis bei einem Konflikt Vorrang haben. Das heisst drei nützliche Scopes: eine globale ~/.codex/AGENTS.md für deine persönlichen Defaults, eine AGENTS.md im Wurzelverzeichnis deines Repos für Projektregeln, die alle teilen, und verschachtelte AGENTS.md-Dateien in Unterverzeichnissen für bereichsspezifische Overrides. Halte sie fokussiert auf Setup, Konventionen und Test-Anforderungen; Codex respektiert ein Standard-Grössenlimit (etwa 32 KiB über die Chain), und wie jede Datei mit stehenden Anweisungen schlägt eine knappe eine ausufernde. ```markdown # AGENTS.md (at your repository root) ## Setup - Install with `bun install`. The dev server is `bun run dev`. ## Conventions - TypeScript only. Use "-" not em dashes. Border radius is always rounded-sm. ## Tests and quality gate - Before you call a task done, run: bun run lint && bun run typecheck && bun run test. ## Out of scope - Do not edit files under /generated; they are built, not hand-edited. ``` Eine kompakte AGENTS.md im Repo-Wurzelverzeichnis. Codex liest global, dann Projekt, dann verschachtelte Dateien, die nächste gewinnt. #### Deine erste Aufgabe Öffne ein Terminal in dem Projekt, an dem du arbeiten willst, und führe codex aus. Fang klein an, um Vertrauen aufzubauen: Bitte ihn, das Projekt zu erklären oder zu finden, wo etwas liegt, bevor du ihn etwas ändern lässt. Wenn du eine Änderung verlangst, lass ihn bevorzugt zuerst seinen Ansatz vorschlagen, prüfe die Änderung, die er macht, und halte deine Tests grün. Eine Sicherheitsgewohnheit, die die Doku empfiehlt, ist, einen sauberen Git-Checkpoint vor einer Aufgabe und wieder danach zu committen, sodass eine Änderung, die dir nicht gefällt, einen git restore entfernt ist. Codex bietet Approval-Modi, die steuern, wie viel er ohne Nachfragen tun darf; beginne vorsichtiger, wo er fragt, bevor er Befehle ausführt oder editiert, und lockere ihn erst, sobald du dem Workflow auf einem Repo vertraust. - Führe codex in deinem Projekt aus; beginne mit einer Nur-Lesen-Anfrage wie "explain what this project does". - Für Edits lass ihn den Ansatz vorschlagen, dann prüfe den Diff, bevor du ihn akzeptierst. - Committe einen Git-Checkpoint vor und nach einer Aufgabe, sodass du sauber zurückrollen kannst. - Beginne mit einem vorsichtigen Approval-Modus (er fragt vor dem Handeln) und lockere ihn erst, wenn du ihm vertraust. #### Wie es weitergeht Sobald die Basics sitzen, sind die Gewohnheiten, die Codex zuverlässig machen, dieselben, die jeden Coding Agent zuverlässig machen, und sie übertragen sich direkt aus unseren anderen Guides. Lehn dich an den Guide Prompt Patterns fuer Coding Agents für das gute Briefen, den Context-Engineering-Guide für ein scharfes Window bei langen Aufgaben und die Pillar What Is Agentic Engineering für die Disziplin, zu dirigieren und zu verifizieren statt ungeprüften Output zu akzeptieren. Wenn du auch Anthropics Agent nutzt, legt der Vergleich Claude Code vs Codex CLI dar, wo jeder passt, und der Foundations-Kurs installiert und führt beide nebeneinander aus. - Prompt Patterns fuer Coding Agents: wie du Codex mit einer Spec, Beispielen und einem Verification Loop briefst. - Context Engineering: halte sein Context Window über lange Aufgaben scharf. - Claude Code vs Codex CLI: welcher Terminal-Agent zu welchem Job passt. - Foundations-Kurs: installiert und führt Claude Code und Codex nebeneinander aus. --- ## Vergleiche ### Claude Code vs Codex CLI (Vergleich 2026) - Kanonische URL: https://agenticschool.dev/de/vergleich/claude-code-vs-codex-cli Claude Code und Codex CLI sind 2026 die zwei führenden Terminal-basierten KI Coding Agents. Beide leben in deinem Terminal, lesen und bearbeiten dein Repo, führen Befehle aus und arbeiten über viele Schritte auf ein Ziel hin, aber sie treffen unterschiedliche Abwägungen. Claude Code (Anthropic) setzt auf Reasoning-Tiefe und beaufsichtigte Autonomie und ist Closed-Source; Codex CLI (OpenAI) ist Open-Source, Rust-native und setzt auf Geschwindigkeit, Parallelität und niedrigere Kosten pro Token. Diese Seite vergleicht sie ehrlich, damit du den richtigen für deine Arbeit wählst, nicht den mit dem lautesten Marketing. #### Claude Code Reasoning-first Terminal-Agent von Anthropic. Komplexe Features, Refactorings, Architektur und Frontend-Arbeit, bei der die Ergebnisqualität zählt. #### Codex CLI Open-Source, schneller, kosteneffizienter Agent von OpenAI. Autonome und langlaufende Aufgaben, DevOps und kostensensible Workflows mit hohem Volumen. Wähle Claude Code, wenn Ergebnisqualität und Reasoning am wichtigsten sind: komplexe Features, Refactorings und Frontend-Arbeit, bei der du beaufsichtigst und gleich beim ersten Mal sauberen Code willst. Wähle Codex CLI, wenn dir Open-Source, niedrigere Kosten pro Token oder langlaufende autonome und DevOps-Aufgaben im Volumen wichtig sind. Viele Teams nutzen beide: Claude Code für die schwere, beaufsichtigte Arbeit und Codex CLI für günstige, parallele, automatisierte Läufe. 2026 gibt es keinen alleinigen Sieger; die richtige Antwort hängt davon ab, ob dein Engpass Qualität oder Kosten und Autonomie ist. ### Claude Code vs Cursor (Vergleich 2026) - Kanonische URL: https://agenticschool.dev/de/vergleich/claude-code-vs-cursor Claude Code und Cursor sind 2026 zwei der beliebtesten Arten, mit KI zu coden, aber es sind unterschiedliche Werkzeuge. Claude Code (Anthropic) ist ein Terminal-basierter Coding-Agent: Du führst einen Befehl in deinem Projekt aus und er liest, plant, bearbeitet und führt deinen Code in einer Schleife aus, während du beaufsichtigst. Cursor ist eine KI-first IDE, ein Fork von VS Code, bei dem die KI in einen vertrauten Editor eingewoben ist, mit Inline-Autocomplete, einem Agent-Panel und visueller Diff-Prüfung. Keiner ist strikt "besser"; sie passen zu unterschiedlichen Arbeitsweisen. Diese Seite vergleicht sie ehrlich bei Oberfläche, Modellen, Preisen und Autonomie, damit du den passenden für deine Art zu bauen wählst, und viele Entwickler nutzen gern beide. #### Claude Code Terminal-nativer Coding-Agent von Anthropic. Entwickler, die im Terminal leben und einen tief autonomen Agent für Multi-File-Features, Refactorings und repo-weite Arbeit wollen. #### Cursor KI-first IDE auf Basis eines VS-Code-Forks. Entwickler, die KI in einem vertrauten visuellen Editor wollen, mit schnellem Autocomplete und Diff-Prüfung nebeneinander. Wähle Cursor, wenn du KI in einem vertrauten, visuellen Editor willst: erstklassiges Autocomplete, Diff-Prüfung nebeneinander und einen In-IDE-Agent, mit der Freiheit, zwischen Anthropic-, OpenAI- und Google-Modellen zu wechseln. Wähle Claude Code, wenn du im Terminal lebst, die tiefste agentische Autonomie bei schwerer Multi-File-Arbeit willst und sein CLAUDE.md-, Hooks-, Skills-, MCP- und Subagent-Ökosystem schätzt. Die ehrliche Wahrheit 2026 ist, dass diese komplementär sind, nicht Rivalen: ein verbreitetes Setup ist Cursor als täglicher Editor für enge, geprüfte Edits und Claude Code im Terminal für die schweren, autonomen Aufgaben. Wähle danach, wie du arbeiten und prüfen willst, nicht danach, wer den lauteren Benchmark hat. ### Beste KI Coding Tools 2026 - Kanonische URL: https://agenticschool.dev/de/vergleich/best-ai-coding-tools Es gibt 2026 nicht das eine beste KI Coding Tool; es gibt das beste für dich. Der Markt hat sich in klare Formen aufgeteilt: Terminal-Coding-Agents (Claude Code, Codex CLI, Aider), KI-first IDEs (Cursor, Windsurf) und der In-Editor-Assistent, der alles begann (GitHub Copilot). Diese Übersicht vergleicht die sechs Tools, zwischen denen die meisten wählen, ehrlich, mit echten Vor- und Nachteilen für jedes und einer Empfehlung nach Anwendungsfall, denn das richtige Tool hängt davon ab, wie du arbeitest, von deinem Budget und davon, wie viel Autonomie du willst. Wo zwei direkt gegeneinander antreten, haben wir eigene Tiefenvergleiche (Claude Code vs Cursor und Claude Code vs Codex CLI) unten verlinkt. Die Fakten hier sind aktuell per Juni 2026; Preise ändern sich schnell, daher beschreiben wir das Modell statt fragiler exakter Zahlen. #### Claude Code Reasoning-first Terminal-Coding-Agent (Anthropic). Komplexe Multi-File-Features, Refactorings und repo-weite Arbeit, bei der Ergebnisqualität und tiefe Autonomie am wichtigsten sind. #### Cursor Die führende KI-first IDE (VS-Code-Fork). Entwickler, die KI in einem vertrauten visuellen Editor mit gutem Autocomplete und Diff-Prüfung wollen. #### Codex CLI Open-Source, schneller, kosteneffizienter Terminal-Agent (OpenAI). Autonome und langlaufende Aufgaben, DevOps und kostensensible Automation mit hohem Volumen. #### GitHub Copilot Der ursprüngliche In-Editor-KI-Assistent (GitHub). Teams, die schon auf GitHub sind und KI-Completion, Chat und Agent-Modus in VS Code, JetBrains und dem GitHub-Flow wollen. #### Windsurf KI IDE mit dem Cascade-Agent (jetzt Teil von Cognition). Einsteiger und agentik-lastige Workflows, die einen sanften, visuellen Einstieg in einen KI-Editor wollen. #### Aider Open-Source, git-nativer Terminal-Pair-Programmer. Entwickler, die ein kostenloses, modell-unabhängiges Terminal-Tool mit enger Git-Integration und voller Kostenkontrolle wollen. Für die höchste Ergebnisqualität bei komplexer Multi-File-Arbeit führt Claude Code 2026 die Terminal-Agents an. Willst du KI in einem vertrauten visuellen Editor, ist Cursor die beste KI IDE im Gesamtpaket, mit Windsurf als sanfterer, einsteigerfreundlicherer Alternative. Für kostensensible, autonome oder volumenstarke Läufe ist Codex CLI die starke Open-Source-Wahl, und Aider die kostenlose, modell-unabhängige, git-native Option, wenn du volle Kontrolle über Kosten und Modelle willst. Lebt dein Team auf GitHub und willst du einfach fähige KI in deinem bestehenden Editor, ist GitHub Copilot der Weg des geringsten Widerstands. Die ehrliche Antwort: die meisten ernsthaften Entwickler nutzen zwei, eine IDE für enge, geprüfte Edits und einen Terminal-Agent für die schwere Arbeit. Nutze die Direktvergleiche unten, um zwischen den nächsten Paaren zu wählen. ### Opus vs Sonnet vs Haiku: Welches Claude-Modell? (2026) - Kanonische URL: https://agenticschool.dev/de/vergleich/opus-vs-sonnet-vs-haiku Anthropic liefert Claude in drei Grössen, und die richtige zu wählen ist der einfachste, grösste Hebel auf Qualität und Rechnung zugleich. Opus ist das fähigste Modell für das härteste Reasoning, Sonnet der ausgewogene Arbeitsesel, der die meisten Coding- und Agent-Aufgaben gut meistert, und Haiku das schnelle, günstige Modell für volumenstarke und latenzkritische Arbeit. Sie teilen dieselben Kernfähigkeiten und 2026 einen 1M-Token-Kontext zum Standardpreis; was sich ändert, sind Reasoning-Tiefe, Tempo und Kosten pro Token. Diese Seite vergleicht sie ehrlich, damit du das Modell zur Aufgabe passt, statt Opus für Arbeit zu zahlen, die Haiku erledigen würde, oder ein wirklich schweres Problem an Haiku zu schicken und frustriert zu sein. Sie passt zu unserem Artikel Choosing an AI Model. Die Preise sind Listenpreise Stand 2026 und ändern sich über die Zeit. #### Claude Opus Das fähigste Claude, für die härtesten Probleme. Komplexes Reasoning, knifflige Multi-File-Refactorings, Architektur und die agentischen Aufgaben, bei denen Qualität am wichtigsten ist. #### Claude Sonnet Der ausgewogene Arbeitsesel fürs tägliche Bauen. Die meiste tägliche Coding-, Agent-Loop- und Content-Arbeit, bei der du starke Qualität zu vernünftigem Preis willst. #### Claude Haiku Das schnelle, günstige Modell für Volumen und Latenz. Volumenstarke Klassifikation, Extraktion, einfache Edits, Subagent-Nebenarbeit und alles Latenzkritische. Mach Sonnet zu deinem Standard: es meistert die grosse Mehrheit der Coding- und Agent-Arbeit zu einem starken Qualität-zu-Kosten-Verhältnis, weshalb Claude Code es standardmässig nutzt. Greif zu Opus bei den wirklich schweren Problemen, komplexem Reasoning, kniffligen Refactorings und Architektur, wo sich seine zusätzliche Tiefe auszahlt, indem es beim ersten Mal richtig liegt. Steig auf Haiku ab für volumenstarke, einfache oder latenzkritische Arbeit wie Klassifikation, Extraktion und read-only Subagents, wo Tempo und Kosten mehr zählen als Spitzen-Reasoning. Ein starkes Muster ist, sie zu mischen: ein stärkeres Modell führt, während Haiku die günstige, schmale Nebenarbeit macht. Um die Kosten weiter zu senken, nutze Prompt-Caching für wiederholten Kontext und Batch-Verarbeitung für nicht dringende Jobs. Im Zweifel starte auf Sonnet und wechsle erst hoch oder runter, wenn eine Aufgabe es klar verlangt. ### n8n vs Zapier vs Make (Vergleich 2026) - Kanonische URL: https://agenticschool.dev/de/vergleich/n8n-vs-zapier-vs-make n8n, Zapier und Make sind 2026 die drei Automations-Plattformen, zwischen denen die meisten wählen, um Apps zu verbinden und Workflows auszuführen, ohne für jede Integration Glue-Code zu schreiben. Sie lösen dasselbe Problem unterschiedlich: Zapier ist am einfachsten, breitesten und am stärksten gemanagt; Make ist der visuelle, operation-bepreiste Mittelweg für verzweigte Logik; und n8n ist die Open-Source-, self-hostbare, entwicklernahe Option, die bei hohem Volumen dramatisch günstiger wird. Der Haken: jede bepreist die Nutzung anders (Zapier pro Task, Make pro Operation, n8n pro Workflow-Ausführung), was rohe Preisschilder irreführend macht. Diese Seite vergleicht sie ehrlich bei Preismodell, Self-Hosting, Bedienbarkeit und KI-Funktionen, damit du die Plattform zu deiner echten Last passt. Sie passt zu unserer Course-4-Lektion zur Wahl zwischen n8n, Zapier und Trigger.dev. #### n8n Open-Source, self-hostbare Workflow-Automation. Entwickler und technische Teams, die niedrige Kosten bei Volumen, Self-Hosting und volle Kontrolle über Daten und Logik wollen. #### Zapier Das einfachste, breiteste gemanagte Automations-Tool. Nicht-technische Nutzer und Teams, die die breiteste App-Abdeckung und das schnellste, einfachste Setup wollen. #### Make Visuelle, operation-bepreiste Automation mit reicher Logik. Nutzer, die einen visuellen Builder für komplexe, verzweigte Workflows zu niedrigeren Kosten als Zapier wollen. Wähle Zapier, wenn du nicht-technisch bist oder das schnellste Setup und die breiteste App-Abdeckung schätzt und dein Volumen klein genug ist, dass Pro-Task-Preise angenehm bleiben. Wähle Make, wenn du einen visuellen Builder für komplexe, verzweigte Workflows zu deutlich niedrigeren Kosten als Zapier willst und mit einer gemanagten Cloud zufrieden bist. Wähle n8n, wenn du technisch bist, hohes Volumen fährst oder Self-Hosting und Datenkontrolle brauchst: Pro-Ausführung-Preise und die Self-Host-Option machen es bei Skalierung mit Abstand am günstigsten, und seine 2.0-KI- und Agent-Funktionen passen zu agentischen Workflows. Die ehrliche Faustregel: starte auf Zapier oder Make, um einen Workflow schnell zu beweisen, und wechsle zu self-hosted n8n, sobald Volumen, Kosten oder Anforderungen an Datenresidenz Pro-Task-Preise schmerzen lassen. Passe die Plattform zu deiner Last, nicht zu einem Preisschild, denn die drei zählen die Nutzung in unterschiedlichen Einheiten. ### Cursor vs Windsurf vs Copilot (Vergleich 2026) - Kanonische URL: https://agenticschool.dev/de/vergleich/cursor-vs-windsurf-vs-copilot Cursor, Windsurf und GitHub Copilot sind 2026 die drei beliebtesten Arten, KI in einen grafischen Editor zu bringen, und die Wahl hängt davon ab, wie sehr du den Editor wechseln und wie viel Autonomie du willst. Cursor (Anysphere) und Windsurf (jetzt Teil von Cognition) sind KI-first IDEs: Forks von VS Code, bei denen die KI in den Editor eingewoben ist, mit einem Agent, der über Dateien hinweg plant und bearbeitet. GitHub Copilot ist der Assistent, der die Kategorie begründet hat, und er bleibt eine Extension in dem Editor, den du schon nutzt, statt einer neuen App. Keiner ist strikt am besten; sie passen zu unterschiedlichen Gewohnheiten, Budgets und Team-Bedürfnissen. Diese Seite vergleicht sie ehrlich bei Oberfläche, Modellen, Preisen und Autonomie, damit du den passenden für deine Art zu bauen wählst. Willst du auch einen Terminal-Agent im Mix, sieh dir unsere Übersicht Best AI Coding Tools an. Die Fakten sind aktuell per Juni 2026; Preise ändern sich schnell, daher beschreiben wir das Modell statt fragiler exakter Zahlen. #### Cursor Die führende KI-first IDE (VS-Code-Fork). Entwickler, die die fähigste agentische IDE mit gutem Autocomplete, Multi-Model-Wahl und Diff-Prüfung nebeneinander wollen. #### Windsurf Einsteigerfreundliche KI IDE mit dem Cascade-Agent. Leute, die einen sauberen, wenig steuerungsintensiven agentischen Editor und einen grosszügigen Free-Tier zum Lernen wollen, mit Weg zu längeren autonomen Läufen. #### GitHub Copilot Der ursprüngliche In-Editor-KI-Assistent (GitHub). Teams, die schon auf GitHub sind und fähige KI in ihrem bestehenden Editor mit der breitesten IDE-Unterstützung und planbarer Enterprise-Governance wollen. Wähle Cursor, wenn du 2026 die fähigste KI IDE willst: erstklassiges Autocomplete, Multi-Model-Routing, Diff-Prüfung nebeneinander und tiefe agentische Funktionen, und es dir nichts ausmacht, in seinen Editor zu wechseln oder an starken Tagen einen Nutzungspool zu beobachten. Wähle Windsurf, wenn du einen sanfteren, wenig steuerungsintensiven agentischen Editor und einen wirklich nützlichen Free-Tier zum Lernen willst, mit einem Weg zu längeren autonomen Läufen über Cognition, und ein kleineres Ökosystem und die neueren Quota-Limits akzeptierst. Wähle GitHub Copilot, wenn dein Team auf GitHub lebt und du fähige KI im Editor willst, den du schon nutzt, mit der breitesten IDE-Abdeckung, dem günstigsten Einstieg und der stärksten Enterprise-Governance, und etwas rohe agentische Tiefe gegen Stabilität tauschst. Die ehrliche Faustregel: Cursor für Power und Autonomie, Windsurf zum Lernen und Hands-off-Bleiben, Copilot, um KI ohne Tool-Wechsel zu ergänzen. Wähle nach deinem Workflow und wie viel Autonomie du willst, nicht nach einem einzelnen Benchmark. ### Convex vs Supabase vs Firebase (Vergleich 2026) - Kanonische URL: https://agenticschool.dev/de/vergleich/convex-vs-supabase-vs-firebase Convex, Supabase und Firebase sind 2026 die drei Backends, zwischen denen die meisten Indie-Hacker und kleinen Teams wählen, um eine Datenbank, Auth, Storage und APIs zu ergänzen, ohne Server von Grund auf aufzusetzen. Sie haben unterschiedliche Formen: Convex ist ein reaktives, TypeScript-natives Backend, bei dem deine Queries Funktionen sind und die UI standardmässig in Echtzeit aktualisiert; Supabase ist gemanagtes Postgres mit Auth, Storage, Edge-Functions und sofortigen REST-APIs, und es ist Open-Source und self-hostbar; Firebase ist Googles reife, mobile-first Plattform auf Basis der Firestore-NoSQL-Datenbank mit der tiefsten Offline-Unterstützung. Die Wahl hängt meist von deinem Datenmodell ab (SQL vs Dokument vs reaktiv), davon, wie wichtig dir Echtzeit ist, und davon, ob du self-hosten können willst. Diese Seite vergleicht sie ehrlich, damit du das Backend zu deiner App passt. Sie passt zu unserem Artikel Modern App Stack Explained und der Convex-Lektion aus Course 3. Die Fakten sind aktuell per Juni 2026, und Preismodelle ändern sich über die Zeit. #### Convex Reaktives, TypeScript-natives Backend mit Echtzeit standardmässig. TypeScript-Apps, die Echtzeit-Reaktivität, durchgängige Typsicherheit und das geringste Backend-Wiring wollen. #### Supabase Open-Source-Postgres-Backend mit Auth, Storage und APIs. Teams, die eine echte relationale SQL-Datenbank, die Option zum Self-Hosting und eine vollständige Open-Source-Backend-Suite wollen. #### Firebase Googles reifes, mobile-first BaaS auf Firestore. Mobile und Offline-first Apps, die kampferprobte SDKs und Google-Cloud-Integration wollen. Wähle Convex, wenn du eine TypeScript-App baust und Echtzeit-Reaktivität sowie durchgängige Typsicherheit mit dem geringsten Backend-Wiring willst; es passt am natürlichsten, wenn Live-Updates Kern des Produkts sind, mit dem Kompromiss einer source-available Lizenz und eines jüngeren Ökosystems. Wähle Supabase, wenn du eine echte relationale SQL-Datenbank, die Freiheit zum Self-Hosting und eine vollständige Open-Source-Suite aus Datenbank, Auth, Storage und Functions willst; es ist der vielseitigste Allrounder und am sichersten gegen Lock-in. Wähle Firebase, wenn du eine mobile oder Offline-first App lieferst und seine reifen SDKs und Google-Cloud-Integration schätzt, und nur-gehosteten Lock-in sowie Pro-Lese-Preise akzeptierst, die bei Skalierung schwer vorhersehbar sind. Die ehrliche Faustregel: Convex für reaktive TypeScript-Apps, Supabase für SQL und Open-Source-Kontrolle, Firebase für Mobile. Wie diese in einen vollen modernen Stack neben Auth und Payments passen, zeigt unser Artikel Modern App Stack Explained, und Auth-Provider vergleichst du auf unserer Seite Clerk vs Auth0 vs Supabase Auth. ### Clerk vs Auth0 vs Supabase Auth (Vergleich 2026) - Kanonische URL: https://agenticschool.dev/de/vergleich/clerk-vs-auth0-vs-supabase-auth Clerk, Auth0 und Supabase Auth sind 2026 die drei Authentifizierungs-Provider, zwischen denen die meisten Teams wählen, um Sign-up, Login, Sessions und Zugriffskontrolle zu handhaben, ohne Auth von Grund auf zu bauen, dem Teil einer App, den du wirklich nicht falsch machen willst. Sie zielen auf unterschiedliche Nutzer: Clerk führt bei der Developer Experience mit Drop-in-UI-Komponenten und dem reibungslosesten Setup; Auth0 (ein Okta-Produkt) ist der Enterprise-Standard für SAML Single Sign-on, Compliance und fortgeschrittene Sicherheit; und Supabase Auth kommt gebündelt mit einer Supabase-Postgres-Datenbank und Row Level Security, mit dem grosszügigsten Free-Tier und den niedrigsten Kosten bei Skalierung. Alle drei setzen unter der Haube moderne Standards wie OAuth und OpenID Connect um. Diese Seite vergleicht sie ehrlich bei Developer Experience, Free-Tiers, Kosten bei Skalierung und Offenheit, damit du den Provider zu deinem Projekt passt. Für den Standard, auf dem sie bauen, sieh dir unseren Was ist OAuth Erklärer an, und wählst du auch eine Datenbank, sieh dir unseren Vergleich Convex vs Supabase vs Firebase an. Die Preise sind Stand 2026 und ändern sich über die Zeit. #### Clerk Die beste Developer Experience mit Drop-in-Auth-UI. Indie-Hacker und SaaS-Teams, die schöne vorgefertigte Auth-UI und den schnellsten Weg in die Produktion wollen. #### Auth0 Der Enterprise-Standard für SSO und Compliance (Okta). Enterprises und B2B-SaaS, die SAML SSO, fortgeschrittene Sicherheitsrichtlinien und starke Compliance brauchen. #### Supabase Auth Open-Source-Auth gebündelt mit einer Postgres-Datenbank. Teams, die schon auf Supabase sind, oder alle, die die günstigste Auth bei Skalierung mit der Option zum Self-Hosting wollen. Wähle Clerk, wenn du die beste Developer Experience und den schnellsten Weg in die Produktion willst: Drop-in-UI-Komponenten, moderne Funktionen wie Passkeys und ein grosszügiger Free-Tier machen es zum Favoriten für Indie-Hacker und React- oder Next.js-SaaS, und du akzeptierst, dass es gemanagt und pro MAU bepreist ist. Wähle Auth0, wenn du ein Enterprise oder B2B-SaaS bist, das SAML Single Sign-on, fortgeschrittene Sicherheitsrichtlinien und breite Compliance braucht; es ist am fähigsten und am kampferprobtesten, mit dem Kompromiss, dass Pro-MAU-Preise bei Skalierung teuer werden. Wähle Supabase Auth, wenn du schon auf Supabase bist oder die günstigste Auth bei Skalierung mit der Option zum Self-Hosting willst; es passt natürlich zu Postgres und Row Level Security und hat den grosszügigsten Free-Tier, zum Preis von weniger polierten UI-Komponenten und leichteren Enterprise-Funktionen. Die ehrliche Faustregel: Clerk für Developer Experience, Auth0 für Enterprise-Bedürfnisse, Supabase Auth für Kosten und Offenheit. Alle drei bauen auf Standards wie OAuth und OpenID Connect, erklärt in unserem Was ist OAuth Ratgeber. --- ## Tools ### llms.txt Generator - Kanonische URL: https://agenticschool.dev/de/tools/llms-txt-generator Dieser kostenlose llms.txt Generator baut in Sekunden eine spec-korrekte llms.txt-Datei für deine Website. Gib deinen Site-Namen, eine einzeilige Zusammenfassung und deine wichtigsten Seiten ein, und er erzeugt eine Markdown-Datei, die du kopieren oder herunterladen und ins Wurzelverzeichnis deiner Domain legen kannst. Alles läuft in deinem Browser: Nichts wird an einen Server gesendet, es gibt keine Anmeldung und keine Kosten. Unter dem Tool findest du eine kurze Erklärung, was llms.txt ist und warum es für das Verstandenwerden durch KI wichtig ist. #### Was ist llms.txt? llms.txt ist eine einfache Markdown-Datei, die du ins Wurzelverzeichnis deiner Site legst (unter /llms.txt), um KI-Systemen eine saubere, kuratierte Landkarte deiner wichtigsten Inhalte zu geben. Statt ein Modell zu zwingen, dein HTML zu crawlen und zu raten, gibst du ihm eine kurze, strukturierte Zusammenfassung plus Links zu den Seiten, die zählen. Für KI-Leser ist es ungefähr das, was eine Sitemap oder robots.txt für Suchcrawler ist: ein freundlicher, maschinenorientierter Einstiegspunkt. #### Das Format in einer Minute Die Spezifikation ist bewusst klein. Eine gültige llms.txt beginnt mit einem einzelnen H1 mit deinem Site- oder Projektnamen (der einzige Pflichtteil), gefolgt von einem Blockquote mit einer kurzen Zusammenfassung, dann optionalen Abschnitten. Jeder Abschnitt ist eine H2-Überschrift mit einer Markdown-Liste von Links, wobei jeder Link als Titel, URL und kurze Beschreibung geschrieben ist. ```markdown # Dein Site-Name > Eine einzeilige Zusammenfassung, was deine Site ist und für wen. ## Docs - [Erste Schritte](https://example.com/start): In fünf Minuten einrichten. - [API-Referenz](https://example.com/api): Jeder Endpunkt mit Beispielen. ## Optional - [Volltext](https://example.com/llms-full.txt): Die ganze Site als ein Dokument. ``` Eine minimale, spec-korrekte llms.txt: H1, Blockquote-Zusammenfassung, dann H2-Link-Abschnitte. #### Warum es für AEO zählt Da immer mehr Menschen KI-Assistenten Fragen stellen, statt in ein Suchfeld zu tippen, wird sauber von diesen Systemen lesbar zu sein Teil davon, gefunden zu werden. Eine gute llms.txt macht es günstig und eindeutig für eine KI, zu verstehen, was deine Site bietet, und auf die richtige Seite zu verlinken, was der Kern der Answer Engine Optimization (AEO) ist. Sie ersetzt weder guten Inhalt noch eine Sitemap; sie ergänzt sie, indem sie Maschinen-Lesern eine kuratierte Eingangstür gibt. #### Wie du die Datei nutzt Erzeuge die Datei mit dem Tool oben, speichere sie dann als llms.txt und lade sie ins Wurzelverzeichnis deiner Domain hoch, damit sie unter deinesite.com/llms.txt erreichbar ist. Halte sie kurz und kuratiert: Verlinke die Handvoll Seiten, die deine Site am besten repräsentieren, statt jeder URL. Aktualisiere sie, wenn sich deine wichtigsten Seiten ändern, und überlege, zusätzlich eine umfangreichere llms-full.txt mit vollständigeren Inhalten für Systeme zu veröffentlichen, die den ganzen Korpus in einer Anfrage wollen. ### LLM Kostenrechner - Kanonische URL: https://agenticschool.dev/de/tools/llm-cost-calculator Dieser kostenlose LLM Kostenrechner schätzt, was dich der Betrieb eines grossen Sprachmodells in der Produktion kostet. Wähle zwei Modelle, gib deine Input- und Output-Tokens (oder Wörter, die er für dich umrechnet) und dein monatliches Aufrufvolumen ein, und schalte Prompt Caching und Batch-Verarbeitung dazu, um die Ersparnis zu sehen. Er zeigt die Kosten pro Aufruf und pro Monat für beide Modelle nebeneinander auf Basis aktueller Listenpreise von 2026, damit du ein Budget abschätzen oder das günstigste Modell wählen kannst, bevor du eine Zeile Code schreibst. Alles läuft in deinem Browser: keine Anmeldung, kein API-Key, nichts verlässt dein Gerät. #### Wie LLM-Preise wirklich funktionieren Fast jede LLM API rechnet pro Token ab, nicht pro Anfrage, und nennt den Preis pro Million Tokens. Ein Token sind grob vier Zeichen englischer Text, also sind rund 750 Wörter etwa 1.000 Tokens. Deine Rechnung für einen Aufruf ist einfach die gesendeten Input-Tokens mal dem Input-Preis plus die erzeugten Output-Tokens mal dem Output-Preis, heruntergebrochen auf deine tatsächlichen Token-Zahlen. Weil Anbieter pro Million angeben, übernimmt der Rechner oben diese Division für dich und multipliziert mit deinem monatlichen Volumen für echte Monatskosten. #### Warum Input und Output unterschiedlich kosten Output-Tokens kosten fast immer ein Mehrfaches der Input-Tokens, weil Text zu erzeugen rechenintensiver ist als ihn zu lesen. Bei den Claude-Modellen 2026 ist der Output zum Beispiel das Fünffache des Input-Preises (rund USD 5 Input und USD 25 Output pro Million Tokens für Opus, rund USD 3 und USD 15 für Sonnet und rund USD 1 und USD 5 für Haiku). Deshalb kann ein Chatbot, der lange Antworten gibt, weit mehr kosten als einer mit kurzen, und deshalb ist das Kürzen der Output-Länge oft der grösste einzelne Hebel auf deine Rechnung. Der Rechner trennt beide Seiten, damit du genau siehst, wohin das Geld fliesst. #### Prompt Caching und Batch-Rabatte Zwei Funktionen können deine Kosten drastisch senken, und die Schalter oben bilden beide ab. Prompt Caching verwendet einen grossen, unveränderten Anfang wieder (einen System-Prompt, Tool-Definitionen oder abgerufene Dokumente), sodass wiederholter Input zu etwa einem Zehntel des normalen Input-Preises berechnet wird; es betrifft nur die Input-Seite, weshalb der Rechner allein den Input rabattiert. Batch-Verarbeitung führt nicht dringende Jobs asynchron zum etwa halben Preis auf beiden Seiten aus, im Tausch gegen langsamere Bearbeitung nach bestem Bemühen. Wenn deine Arbeitslast Kontext wiederverwendet oder Latenz toleriert, zählen diese beiden Einstellungen oft mehr als die Modellwahl. #### Das günstigste Modell wählen, das noch funktioniert Das günstigste Modell ist nicht immer die beste Wahl: ein schwächeres Modell, das drei Wiederholungen braucht, kann mehr kosten als ein stärkeres, das es beim ersten Mal richtig macht. Der ehrliche Weg ist, mit dem kleinsten Modell zu starten, das die Aufgabe zuverlässig löst, seinen echten Token-Verbrauch zu messen und erst hochzugehen, wenn die Qualität es klar verlangt. Nutze diesen Rechner zusammen mit unserem Vergleich Opus vs Sonnet vs Haiku und unserem Artikel zur Modellwahl, um das Modell zur Aufgabe zu passen, und schätze die Rechnung, bevor du dich festlegst. Für hohes Volumen kombinierst du ein starkes Leitmodell mit einem günstigeren für enge Nebenaufgaben. ### Token- und Kontextfenster-Schätzer - Kanonische URL: https://agenticschool.dev/de/tools/token-context-estimator Dieser kostenlose Token- und Kontextfenster-Schätzer sagt dir in Sekunden, wie viele Tokens ein Text ungefähr hat und ob er in jedes grosse Modell-Kontextfenster passt. Füge einen Prompt, ein Dokument oder ein ganzes Transkript ein, und er zeigt eine Token-Schätzung plus eine Füllanzeige und ein klares Passt oder Passt nicht für Claude, GPT und Gemini, dazu einen ungefähren Input-Preis. Er nutzt eine schnelle Zeichen-pro-Token-Heuristik, ist also eine Schätzung und kein exakter Tokenizer, was perfekt ist, um Kontext schnell abzuschätzen, bevor du baust. Alles läuft in deinem Browser: keine Anmeldung, kein Upload, nichts verlässt dein Gerät. #### Was ist ein Token? Ein Token ist die Einheit, die ein Sprachmodell tatsächlich liest und schreibt. Es ist weder ein Wort noch ein Zeichen, sondern etwas dazwischen: ein häufiges kurzes Wort ist oft ein einzelnes Token, während ein langes oder seltenes Wort in mehrere aufgeteilt wird. Als grobe Regel für Englisch ist ein Token etwa vier Zeichen, und 1.000 Tokens sind rund 750 Wörter. Modelle rechnen pro Token ab und messen ihre Grenzen in Tokens, weshalb es richtig ist, Tokens und nicht Wörter zu schätzen, um einen Prompt oder ein Dokument abzumessen. #### Was ist ein Kontextfenster? Das Kontextfenster ist die maximale Anzahl Tokens, die ein Modell auf einmal im Blick halten kann, gezählt werden sowohl dein Input als auch der erzeugte Output. Übersteigt dein Text das Fenster, kann das Modell nicht alles sehen, und du musst kürzen, aufteilen oder zusammenfassen. 2026 sind die Fenster gross: Claude Opus und Sonnet bieten rund eine Million Tokens, Gemini-Modelle erreichen ebenfalls eine Million, andere liegen zwischen zwei- und vierhunderttausend. Die Füllanzeigen oben zeigen, wie viel jedes Fensters dein Text nutzen würde, damit du auf einen Blick siehst, was passt. #### Warum dies eine Schätzung und kein exakter Zähler ist Eine echte Token-Zahl hängt vom spezifischen Tokenizer ab, den jede Modellfamilie nutzt, und die unterscheiden sich zwischen Claude, GPT und Gemini und sogar zwischen Versionen. Jeden Tokenizer in ein Browser-Tool zu packen wäre schwer und würde trotzdem nur ein Modell auf einmal treffen. Stattdessen nutzt dieses Tool die weit verbreitete Vier-Zeichen-pro-Token-Heuristik, die nah genug zum Planen für typische englische Prosa ist, aber bei Code, anderen Sprachen oder Text voller Symbole und Zahlen danebenliegen kann. Behandle die Zahl als verlässlichen Richtwert und prüfe mit dem Anbieter-Tokenizer, wenn eine exakte Zahl zählt. #### Die Schätzung nutzen, um Kosten und Kontext zu planen Sobald du weisst, wie viele Tokens dein Text ungefähr hat, werden zwei Entscheidungen einfacher. Erstens, ob er passt: liegt ein Dokument nahe an oder über einem Modellfenster, plane es aufzuteilen, nur die relevanten Teile abzurufen oder ein Modell mit grösserem Fenster zu wählen. Zweitens, was es kostet: der ungefähre Input-Preis neben jedem Modell ist ein Startpunkt, und der vollständige LLM Kostenrechner lässt dich Output-Tokens, Monatsvolumen, Caching und Batch-Rabatte für eine komplette Schätzung ergänzen. Für das tiefere Warum siehe unsere Glossareinträge zu Tokens und zum Kontextfenster und unseren Ratgeber zum Context Engineering. ### KI-Automatisierung ROI-Rechner - Kanonische URL: https://agenticschool.dev/de/tools/ai-automation-roi-calculator Dieser kostenlose ROI-Rechner für KI-Automatisierung macht aus dem vagen Gefühl "das sollten wir automatisieren" echte Zahlen. Gib ein, wie viel Zeit eine wiederkehrende Aufgabe heute kostet (Stunden pro Woche, wie viele Personen, der voll belastete Stundensatz), wie viel davon eine Automatisierung übernehmen kann, plus den einmaligen Einrichtungsaufwand und die monatlichen Tool-Kosten, und er zeigt die gesparte Zeit pro Monat und Jahr, die Brutto- und Netto-Ersparnis pro Monat, die jährliche Ersparnis im Normalbetrieb, die Amortisationszeit und den ROI im ersten Jahr. Alles läuft in deinem Browser: keine Anmeldung, kein API-Key, nichts verlässt dein Gerät. Nutze ihn, um eine Automatisierungsidee zu prüfen, bevor du sie baust. #### Wie sich der Automatisierungs-ROI berechnet Die Rechnung ist einfacher, als die meisten Tabellen es aussehen lassen. Ermittle zuerst die Zeit, die die Aufgabe heute kostet: Stunden pro Woche mal Anzahl Personen ergeben die gesamten Wochenstunden, und der automatisierbare Anteil sagt dir, wie viele dieser Stunden eine Automatisierung wegnimmt. Multipliziere die gesparten Stunden mit deinem belasteten Stundensatz für die Brutto-Ersparnis. Ziehe dann die laufenden Kosten der Automatisierung ab (die monatliche Tool- oder Abo-Gebühr) für die Netto-Ersparnis pro Monat. Der Rechner oben rechnet Wochenwerte mit 4,33 Wochen pro Monat in Monatswerte um, damit die Zahlen zu einem echten Kalender passen und nicht zu einer glatten Vier-Wochen-Näherung. #### Amortisationszeit und ROI im ersten Jahr Zwei Zahlen entscheiden, ob eine Automatisierung den Bau wert ist. Die Amortisationszeit ist, wie viele Monate die Netto-Ersparnis braucht, um die einmalige Investition wieder hereinzuholen (die Einrichtungsstunden zu deinem Stundensatz plus zusätzliche Einrichtungskosten). Eine Amortisation unter drei bis sechs Monaten ist meist ein klares Ja. Der ROI im ersten Jahr vergleicht den Netto-Nutzen über zwölf Monate mit allem, was du in diesem Jahr hineinsteckst (die einmalige Einrichtung plus zwölf Monate Tool-Kosten), als Prozentsatz. Ein positiver ROI heisst, die Automatisierung trägt sich im Jahr selbst; ist die Netto-Ersparnis pro Monat negativ, markiert das Tool, dass sie sich gar nicht amortisiert, was genauso nützlich ist, früh zu wissen. #### Nimm einen belasteten Stundensatz, kein Gehalt Der grösste Fehler ist, einen blossen Gehaltswert zu nehmen. Der ehrliche Wert ist die voll belasteten Kosten einer Stunde: Gehalt plus Lohnnebenkosten, Benefits, Software, Büro und die Opportunitätskosten dessen, was diese Person stattdessen tun könnte. Als grobe Regel liegen die belasteten Kosten oft beim 1,3- bis 1,5-Fachen des Grundstundenlohns. Der belastete Wert hält die Ersparnis glaubwürdig und verhindert, dass du den Fall überzeichnest. Sei beim automatisierbaren Anteil genauso ehrlich: kaum eine Aufgabe geht auf 100 Prozent, weil Sonderfälle, Ausnahmen und Prüfung weiterhin einen Menschen brauchen. Realistische 60 bis 80 Prozent schlagen meist optimistische 100 Prozent, die nie eintreten. #### Von der Schätzung zur echten Automatisierung Ein starker ROI auf dem Papier ist ein Startpunkt, keine Ziellinie. Die Ersparnis zeigt sich nur, wenn die Automatisierung angenommen, am Laufen gehalten und vertraut wird, weshalb es klug ist, mit einer schmerzhaften, repetitiven, regelbasierten Aufgabe zu starten statt mit einem ausufernden Prozess. Sehen die Zahlen hier gut aus, ist die nächste Entscheidung, wie du es baust: eine No-Code-Plattform wie n8n, Zapier oder Make für einfache Connector-Workflows oder ein eigenes Skript oder ein Agent für alles mit echter Logik. Lies unseren Ratgeber zur KI-Automatisierung fürs Business, um das erste Projekt abzustecken, vergleiche die wichtigsten No-Code-Plattformen vor der Wahl und nutze diesen Rechner als schnellen Bauchgefühl-Check vor jeder Automatisierung, die du erwägst. ### Welches KI-Coding-Tool soll ich nutzen? - Kanonische URL: https://agenticschool.dev/de/tools/ai-coding-tool-quiz Dieses kostenlose Quiz empfiehlt das KI-Coding-Tool, das zu deiner Arbeitsweise passt. Beantworte sieben kurze Fragen dazu, wo du programmierst, wie viel Autonomie du willst, deine Erfahrung, dein Budget, die Grösse deiner Codebasis und ob Open Source zählt, und es schlägt eines der führenden Tools von 2026 vor: Claude Code, Cursor, GitHub Copilot, Windsurf, Codex CLI oder Aider. Du bekommst eine klare Empfehlung mit kurzer Begründung und einen direkten Link zum ehrlichen Vergleich dahinter. Alles läuft in deinem Browser: keine Anmeldung, kein Tracking, nichts verlässt dein Gerät. Es ist ein Startpunkt, um das Feld einzugrenzen, kein in Stein gemeisseltes Urteil. #### Die grösste Weiche: Terminal-Agent oder IDE-Assistent Vor jedem Quiz sortiert eine Frage das meiste Feld: Willst du im Terminal oder in deinem Editor arbeiten? Terminal-first Agents wie Claude Code, Codex CLI und Aider führen mehrstufige Aufgaben von der Kommandozeile aus, lesen und bearbeiten viele Dateien auf einmal und handeln mit echter Autonomie. Editor-basierte Tools wie Cursor, Windsurf und GitHub Copilot leben dort, wo du ohnehin Code schreibst, und halten dich mit Inline-Vorschlägen, Chat und gezielten Bearbeitungen im Spiel. Keines ist abstrakt besser; sie passen zu unterschiedlichen Naturellen und Workflows. Das Quiz gewichtet diese Antwort am stärksten, weil sie das stärkste Einzelsignal dafür ist, welches Tool dir im Alltag wirklich Freude macht. #### Autonomie, Budget und die Art deiner Arbeit Nach der Umgebung verfeinern drei Dinge die Wahl. Autonomie ist, wie viel das Tool unbeaufsichtigt tun soll: volle mehrstufige Ausführung deutet auf Agents wie Claude Code, enge Schritt-für-Schritt-Zusammenarbeit passt zu Cursor und Windsurf, und reine Inline-Autovervollständigung ist klassisches Copilot-Terrain. Das Budget steuert das Ergebnis ebenfalls: eine Open-Source- oder Null-Kosten-Anforderung spricht für Aider, gutes Verhältnis zu kleiner Monatsgebühr für Copilot, und ein ergebnisorientiertes Budget öffnet die Frontier-Agents. Schliesslich zählt die Art der Arbeit: grosse Refactorings und grosse Codebasen belohnen einen fähigen Agent, Lernen beim Bauen passt zu einem sanften Assistenten, und schnelle Einmal-Skripte passen zu einem schnellen Kommandozeilen-Tool. Das Quiz verbindet all das zu einer Empfehlung. #### Warum das Ergebnis ein Startpunkt ist, kein letztes Wort Kein Quiz kennt deinen genauen Stack, dein Team oder deinen Geschmack, und diese Tools ändern sich schnell. Die Empfehlung soll sechs Optionen auf einen starken Kandidaten eingrenzen, den du zuerst probieren kannst, mit einem ehrlichen Zweitplatzierten, der einen Blick wert ist. Behandle sie wie einen kundigen Freund, der dir eine Richtung zeigt, und prüfe dann mit eigenen Händen: fast jedes Tool hat eine kostenlose Stufe oder Testphase, und eine Stunde an einer echten Aufgabe sagt mehr als jedes Quiz. Das Ergebnis verlinkt direkt zum ausführlichen Vergleich hinter der Wahl, damit du Spec-Tabelle, Vor- und Nachteile und das Fazit lesen und mit offenen Augen entscheiden kannst. Für die volle Übersicht stellt unser Hub zu den besten KI-Coding-Tools jede Option nebeneinander, und unser Ratgeber zur Nutzung von Claude Code zeigt, wie sich ein Terminal-Agent in der Praxis anfühlt. --- ## Wissen ### Wie LLMs wirklich funktionieren: Tokens, Kontext und der Performance-Cliff - Kanonische URL: https://agenticschool.dev/de/wissen/how-llms-work Ein grosses Sprachmodell macht eine Sache bemerkenswert gut: Es sagt das nächste Token voraus, basierend auf allem, was es gesehen hat. Sobald du Tokens, das Kontextfenster und den Performance-Cliff bei langen Eingaben verstehst, fühlt sich die Arbeit mit jedem Modell nicht mehr wie Raten an. Dieser Leitfaden erklärt alle drei in klarer Sprache, mit den wenigen Zahlen, die 2026 wirklich zählen, damit du jedes Modell gut steuerst und dem Tool nicht mehr ein Verhalten vorwirfst, das völlig vorhersehbar ist. #### Tokens, nicht Wörter Ein Modell sieht Wörter nie so, wie du es tust. Dein Text wird zuerst in Tokens zerlegt - häufige Zeichenblöcke, grob vier Zeichen oder drei Viertel eines englischen Wortes. Zwei Dinge werden in Tokens gemessen: der Preis, den du zahlst, und die Menge, die ein Modell auf einmal halten kann. Darum kann ein günstiges Modell bei langen Dokumenten teuer werden, und darum kosten Code oder andere Sprachen mehr Tokens als dieselbe Idee in schlichtem Englisch. Der Preis wird pro Million Tokens angegeben und in Input und Output aufgeteilt, wobei Output meist ein Vielfaches des Inputs kostet. #### Das Kontextfenster Das Kontextfenster ist die maximale Anzahl Tokens, die ein Modell auf einmal berücksichtigen kann: deine Anweisungen, die eingefügten Dateien, der Gesprächsverlauf und die Antwort, die es gerade schreibt, alles zusammengezählt. Stell es dir als den Schreibtisch des Modells vor. Alles Relevante muss gleichzeitig auf den Tisch passen, und wenn der Tisch voll ist, fällt etwas runter und wird praktisch vergessen. Darum verliert ein langer Chat den Faden zu Anweisungen vom Anfang. 2026 hat ein starkes Modell typisch ein Fenster von rund 200.000 Tokens, manche werben mit einer Million oder mehr. #### Der Performance-Cliff Mehr Kontext ist nicht dasselbe wie bessere Antworten. Während du ein Kontextfenster füllst, sinkt die Qualität lange bevor du die harte Grenze erreichst. Modelle achten am besten auf Anfang und Ende einer langen Eingabe und werden in der Mitte unscharf - ein Muster, das oft "lost in the middle" heisst. Ein Fenster mit einer Million Tokens klingt grossartig, aber die Antwortqualität bei einem vollgepackten Fenster ist oft schlechter als bei einem knappen, gut gewählten Prompt. Das ist der Performance-Cliff, und die Lehre ist deutlich: Relevanz schlägt Menge jedes Mal. #### Warum riesige Kontextfenster enttäuschen Du wirst Modelle sehen, die mit enormen Kontextfenstern werben, und annehmen, sie seien strikt besser. In der Praxis enttäuschen sie oft, aus genau dem Grund oben. Ein Modell kann technisch eine Million Tokens annehmen und trotzdem schlechter antworten als ein fokussierter Prompt, weil die Qualität fällt, je voller das Fenster wird. Behandle ein riesiges Fenster als gelegentliche Versicherung für ein wirklich grosses Dokument, nicht als Erlaubnis, mit dem Kuratieren dessen, was du sendest, aufzuhören. #### Wie du das in der Praxis nutzt Die praktischen Erkenntnisse sind einfach. Sende weniger, aber das richtige Weniger. Starte frische Gespräche, statt auf lange draufzupacken. Wenn eine Antwort schlecht ist, sind deine ersten beiden Fragen, ob dein Kontext zu gross ist und ob die relevante Information tatsächlich nah am Anfang oder Ende steht. In einem Workflow, der tausende Male läuft, kann das Kürzen eines aufgeblähten Prompts deine Rechnung drastisch senken und die Antworten zugleich verbessern. #### Warum das für dein Business zählt Tokens sind Geld und Kontextdisziplin ist Qualität. Ein Team, das das versteht, schreibt knappere Prompts, wählt günstigere Modelle für einfache Aufgaben und bekommt verlässlichere Ergebnisse, was weniger Nacharbeit bedeutet. Den Cliff zu verstehen ist das mit Abstand wirkungsvollste, das eine nicht-technische Gründerin lernen kann, bevor sie KI in grossem Massstab einsetzt, weil es jede nachgelagerte Entscheidung zu Modellen, Prompts und Agents verändert. ### Claude Code fürs Business: Setup, Workflows und Sicherheit - Kanonische URL: https://agenticschool.dev/de/wissen/claude-code-for-business Claude Code ist ein Coding Agent, der direkt in deinem Terminal arbeitet: Er liest und bearbeitet Dateien, führt Befehle aus und übernimmt ganze Aufgaben. Für ein Business ist das attraktiv, wirft aber sofort Fragen zu Sicherheit, Berechtigungen und Governance auf. Dieser Leitfaden zeigt, wie Teams Claude Code sauber einführen, vom ersten Setup über wiederholbare Workflows bis zu klaren Regeln, die Tempo ermöglichen, ohne die Kontrolle zu verlieren. #### Was Claude Code im Business tut Claude Code ist kein Chatfenster, es ist ein Agent, der in deinem Projekt handelt. Er versteht eine Aufgabe, liest die relevanten Dateien, schlägt einen Plan vor, macht die Änderungen, führt deine Tests aus und präsentiert das Ergebnis als prüfbaren Diff. Für ein Business heisst das, dass kleine Fixes, Refactorings, Dokumentation und Testabdeckung beschleunigt werden können, ohne dass eine erfahrene Person jeden Schritt von Hand macht. Der Hebel liegt darin, repetitive Engineering-Arbeit zu delegieren und menschliche Zeit für Architektur, Reviews und Entscheidungen zu reservieren. #### Einstieg: Installation und erstes Projekt Starte mit einem sauberen Arbeitsbereich: einem klar strukturierten Repository, einem funktionierenden Test-Befehl und einem Account mit definierten Berechtigungen. Installiere Claude Code, öffne dein Projekt und beginne mit einer kleinen, klar abgegrenzten Aufgabe statt mit einem grossen Umbau. Beobachte, wie der Agent plant und arbeitet, und lerne, wo du eingreifst. Dieser erste bewusst kleine Lauf bringt dir mehr bei als jede Theorie, weil er zeigt, wie der Agent über deinen echten Code nachdenkt und wo Kontext fehlt. #### Projektregeln mit CLAUDE.md Wiederholbares Verhalten kommt aus Projektregeln. Eine CLAUDE.md-Datei in deinem Repository beschreibt, wie sich der Agent verhalten soll: welche Befehle erlaubt sind, welche Code-Konventionen gelten, wie Tests laufen und welche Bereiche tabu sind. Gute Regeln senken Reibung dramatisch, weil der Agent nicht bei jeder Aufgabe neu raten muss, wie dein Projekt funktioniert. Behandle die Datei als lebende Dokumentation: jede wiederkehrende Korrektur aus einem Review gehört als Regel hinein, damit der nächste Lauf schlauer startet. #### Sichere Workflows und Berechtigungen Sicherheit beginnt mit minimalen Rechten. Der Agent sollte nur auf die Repositories, Verzeichnisse und Befehle zugreifen, die er für eine Aufgabe wirklich braucht. Halt Secrets und API-Keys aus dem Client und aus Logs heraus und arbeite mit Umgebungsvariablen statt hartcodierter Keys. Lass riskante Befehle nicht blind laufen; definiere, welche Aktionen eine Bestätigung verlangen. So bleibt Tempo möglich, ohne dass ein einzelner Lauf Produktivdaten oder Zugänge gefährdet. #### Vom Issue zum Pull Request Der produktivste Business-Workflow läuft von einem klaren Issue zu einem sauberen Pull Request. Schreib das Issue mit Ziel, Kontext und Akzeptanzkriterien, damit der Agent weiss, wann die Aufgabe erledigt ist. Lass ihn die Änderung in kleinen, prüfbaren Diffs umsetzen und Tests ergänzen. Der entstehende Pull Request geht dann wie jeder andere durch ein menschliches Review. Das integriert den Agent in bestehende Prozesse, statt einen parallelen Schattenworkflow zu schaffen, und hält die Qualitätskontrolle dort, wo sie hingehört. #### Governance und Verantwortung Im Business reicht ein guter Workflow ohne Governance nicht. Entscheide, wer Agent-Ergebnisse freigibt, wie sensible Daten behandelt werden und welche Aufgaben immer menschliche Kontrolle verlangen. Dokumentiere diese Regeln, damit sie nicht nur in einzelnen Köpfen leben. Eine einfache Human-Approval-Checkliste für riskante Schritte verhindert, dass Tempo auf Kosten der Nachvollziehbarkeit geht. Governance ist hier keine Bremse; sie ist das, was einem Team erlaubt, dem Agent über die Zeit sicher mehr Verantwortung zu geben. ### Ein KI-Modell wählen: Haiku, Sonnet, Opus, GPT und Gemini im Vergleich - Kanonische URL: https://agenticschool.dev/de/wissen/choosing-an-ai-model Es gibt kein einzelnes bestes KI-Modell, nur das richtige Modell für eine Aufgabe und ein Budget. Jeder Anbieter liefert eine Familie von Modellen in Stufen: klein und schnell, mittel und ausgewogen, gross und schlau. Sobald du die Stufen statt der Markennamen siehst, wird das Wählen einfach. Dieser Leitfaden kartiert die Landschaft 2026, erklärt, wie du Benchmarks liest, ohne dich täuschen zu lassen, und zeigt, wo du starke Modelle günstig oder kostenlos bekommst. #### Denk in Stufen, nicht in Marken Vergiss Markentreue und denk in Stufen. Kleine Modelle sind schnell und günstig, super für Klassifikation, Extraktion, einfache Umschreibungen und Jobs mit hohem Volumen. Mittlere Modelle sind das ausgewogene Arbeitspferd für die meiste echte Programmier- und Schreibarbeit. Grosse Modelle sind langsamer und teurer, denken aber bei wirklich harten Problemen weit besser. Fast jeder Anbieter spiegelt diese Struktur, also kannst du, sobald du sie verinnerlicht hast, jedes neue Modell sofort anhand von Datenblatt und Preis einordnen. #### Wie sich die Familien einordnen Claude bietet Haiku (klein), Sonnet (mittel) und Opus (gross). OpenAI GPT und Google Gemini haben äquivalente kleine, mittlere und grosse Stufen. Die Faustregel ist, eine Stufe tiefer zu starten, als du denkst, und nur höher zu gehen, wenn der Output wirklich nicht gut genug ist. Ein Flaggschiff-Modell zum Umformatieren einer Liste zu nutzen ist, wie eine Chirurgin ein Pflaster aufkleben zu lassen. #### Benchmarks ehrlich lesen Benchmarks sind nützlich und zugleich regelmässig irreführend. Ein Modell kann einen Coding-Benchmark anführen und sich in deinem echten Projekt trotzdem schlechter anfühlen, weil Benchmarks enge Aufgaben unter Idealbedingungen messen, auf die Anbieter hart optimieren. Behandle sie als groben Filter, nicht als Urteil. Der einzige Benchmark, der zählt, ist dein eigener: nimm drei echte Aufgaben aus deiner Arbeit, jage sie durch zwei oder drei Modelle und beurteile den Output selbst, mit Blick auf Konstanz statt auf Spitzenleistung. #### Preise und Routing nach Schwierigkeit Der Preis wird pro Million Input- und Output-Tokens angegeben, und der Abstand zwischen den Stufen ist gross, oft zehnfach oder mehr. Weil Output ein Vielfaches des Inputs kostet, sind wortreiche Modelle und geschwätzige Prompts teurer, als du erwartest. Der praktische Zug ist, nach Schwierigkeit zu routen: ein günstiges Modell für die leichte Mehrheit der Aufrufe, ein teures Modell nur für die harte Minderheit. In einem Workflow im grossen Massstab zählt diese eine Entscheidung oft mehr als die Wahl des Anbieters. #### Starke Modelle günstig oder kostenlos Du musst nicht den vollen Preis zahlen, um zu starten. OpenRouter gibt dir einen Account und Key, um fast jedes Modell über einen Endpoint zu nutzen, mit transparenter Preisgestaltung und einfachem Wechseln, was ideal zum Vergleichen von Modellen ist. Google bietet über sein AI Studio regelmässig grosszügige kostenlose Credits, ein wirklich starker, günstiger Weg zu einem fähigen Modell. Die meisten Anbieter geben dir ausserdem kostenlose Trial-Nutzung, die du gezielt für deinen eigenen Drei-Aufgaben-Benchmark einsetzen kannst. ### Deine erste App mit KI shippen: von der Idee zur Live-Website - Kanonische URL: https://agenticschool.dev/de/wissen/ship-your-first-app Die meisten bleiben zwischen einer Idee und dem Moment stecken, in dem sie live im Internet steht. Der Weg fühlt sich wie eine Wand aus unbekannten Worten an: Scaffolding, Dev Server, Git, DNS, Deployment. Es ist weit einfacher, als es aussieht, sobald du es der Reihe nach machst. Dieser Leitfaden geht die ganze Schleife durch, vom Scaffolden eines Projekts und dem lokalen Ausführen bis zum Unter-Versionskontrolle-Stellen und dem Deploy ins öffentliche Internet mit einer echten Domain. #### Scaffolden und lokal ausführen Statt ein Framework auswendig zu lernen, lass deinen Agent einen modernen Starter scaffolden und jeden Schritt erklären. Der Ablauf ist immer derselbe: Projekt erstellen, Dependencies installieren, Dev Server starten, Browser öffnen. Der Dev Server gibt eine lokale Adresse wie localhost aus, was schlicht "dieser Computer" heisst. Noch ist nichts im öffentlichen Internet, was beim Bauen genau richtig ist. Bearbeite eine Datei, speichere, und der Browser aktualisiert sich sofort, was Webbauen schnell anfühlen lässt. #### Unter Versionskontrolle stellen Git ist Versionskontrolle: es macht Schnappschüsse deines Projekts namens Commits, damit du immer zurück kannst. Stell es dir als unbegrenzte Rückgängig-Historie mit Etiketten vor. Jeder Commit hält fest, was sich geändert hat und warum, sodass eine schlechte Änderung nie eine Katastrophe ist, du kehrst einfach zum letzten guten Commit zurück. Diese eine Gewohnheit nimmt die Angst weg, die Einsteiger vom Experimentieren abhält, weil nichts endgültig ist, bis du es entscheidest. #### Secrets draussen halten, bevor du pushst Bevor du irgendetwas zu GitHub pushst, stell sicher, dass Secrets nicht entkommen können. Eine .gitignore-Datei listet Dinge auf, die Git ignorieren soll, und deine .env-Datei, in der API-Keys leben, gehört dorthin. Die Regel ist absolut: Secrets gehen in .env, .env geht in .gitignore, und der Agent schreibt nie einen Key in committeten Code. Mach das einmal richtig und du veröffentlichst nie versehentlich einen Key. Stell Business-Repositories standardmässig auf privat, damit dein Code und IP dir gehören. #### Auf Vercel deployen Vercel ist eine Hosting-Plattform, die dafür gebaut ist. Verbinde dein GitHub-Repo und Vercel beobachtet es und deployt jedes Mal automatisch neu, wenn du pushst. Importiere dein Repository, akzeptiere die erkannten Build-Einstellungen für ein Standardprojekt und klick auf Deploy. In ein, zwei Minuten bekommst du eine Live-URL, die jeder auf der Welt öffnen kann. Setze deine Secrets als Umgebungsvariablen im Vercel-Dashboard statt im Code, damit sie sicher bleiben und nie dein Repo berühren. #### Eine eigene Domain verbinden DNS ist das Telefonbuch des Internets und übersetzt einen menschlichen Namen wie yoursite.com in die Adresse des Servers, der antworten soll. Um eine Domain zu verbinden, fügst du Records hinzu, meist einen A-Record oder einen CNAME, die deinen Namen auf Vercel zeigen. Vercel sagt dir genau, welche Records du erstellen sollst, du fügst sie bei deinem DNS-Anbieter ein, und nach der Propagation stellt Vercel ein kostenloses HTTPS-Zertifikat aus, sodass deine Seite sicher lädt. Viele Builder verwalten DNS über Cloudflare für kostenloses HTTPS, ein schnelleres globales CDN und grundlegenden Schutz. #### Warum Shippen zählt Ein Projekt auf deinem Laptop verdient nichts. Eine Live-Seite kann Kunden gezeigt, von Google indexiert, von KI empfohlen und mit echtem Feedback verbessert werden. Automatische Deploys heissen, dass eine Verbesserung zu shippen dich einen einzigen Push kostet, sodass die Schleife von Idee zu Live-Update Minuten dauert, nicht Tage. Diese Geschwindigkeit ist der gesamte Wettbewerbsvorteil dieser Bauweise, und sie beginnt erst, wenn du tatsächlich shippst. ### Der moderne App-Stack erklärt: Auth, Daten und Payments - Kanonische URL: https://agenticschool.dev/de/wissen/modern-app-stack-explained Ein echtes Produkt ist mehr als eine Website. Es braucht Nutzer, die sich einloggen können, Daten, die bestehen und sich aktualisieren, und einen Weg, Zahlungen entgegenzunehmen. Die gute Nachricht ist, dass du diese harten Teile nicht mehr von Grund auf baust: dedizierte Dienste handhaben jeden davon sicher. Dieser Leitfaden gibt dir die Landkarte - wie die Teile zusammenpassen, welcher Dienst was tut und in welcher Reihenfolge du sie zusammensetzt - damit du ein produktives SaaS baust, ohne die gefährlichen Teile neu zu erfinden. #### Wie die Teile zusammenpassen Eine moderne App teilt sich in eine schnelle, indexierbare Marketing-Oberfläche und die interaktive App hinter dem Login. Ein Framework wie Next.js, Astro oder TanStack liefert Struktur, Routing und Rendering. Darauf ergänzt du drei Dienste: Authentifizierung, eine Datenbank und Payments. Marketing- und App-Oberfläche sauber zu trennen lässt jede für ihren Zweck optimieren, was sowohl Performance als auch SEO hilft. #### Authentifizierung mit Clerk Passwörter zu speichern, Sessions zu verwalten und Angriffen korrekt zu widerstehen ist ein tiefes Spezialgebiet, also solltest du es nicht selbst basteln. Clerk handhabt Sign-up, Login, Sessions und Social Login wie Google OAuth, was eine ganze Kategorie an Sicherheitsrisiko entfernt. Du integrierst seine Komponenten und lässt es die Identität verwalten, während deine App alles andere verwaltet. Der Wechsel von Entwicklung zu Produktion ist ein sorgfältiger Key-Tausch, kein Neubau. #### Reaktive Daten mit Convex Convex speichert deine Daten und führt deine Backend-Logik als TypeScript-Funktionen aus. Du deklarierst ein Schema, liest mit Queries und änderst mit Mutations, und die UI aktualisiert sich automatisch, wenn sich etwas ändert, von dem sie abhängt. Starke Typisierung fliesst aus der Datenbank in deine Komponenten und entfernt eine ganze Klasse von Bugs. Für echte Produkte bevorzuge Soft Deletes, die eine Zeile als gelöscht markieren, sie aber behalten, sodass Daten wiederherstellbar bleiben und die Historie intakt bleibt. #### Payments mit Stripe Stripe ist der Standard, um Zahlungen entgegenzunehmen, und es heisst, dass du nie rohe Kartendaten anfasst. Checkout hostet eine sichere Zahlungsseite, Subscriptions handhaben wiederkehrende Umsätze, und Webhooks sagen deiner App, was passiert ist, damit sie mit der Abrechnungsrealität synchron bleibt. Eine strikte Trennung von Test- und Produktions-Keys lässt dich alles bauen und prüfen, ohne echtes Geld zu bewegen. Die harten Details - Proration, Gutscheine und Embedded Checkout - bauen auf diesem Fundament auf. #### Secrets halten alles zusammen Jeder Dienst, den du ergänzt, kommt mit geheimen Keys, und einen zu leaken kann katastrophal sein. Halt sie aus dem Code heraus in env-Dateien, die immer gitignored sind, nutze getrennte Keys für Entwicklung und Produktion, damit ein Fehler in Dev keine Live-Daten berühren kann, und verschlüssele sensible Daten im Ruhezustand. Diese Disziplin ist das Bindegewebe des ganzen Stacks, und sie muss mit jeder neuen Integration mitwachsen. #### Live gehen Launch heisst, jeden Dienst von Entwicklungs- auf Produktions-Keys und -Daten umzustellen, einen nach dem anderen, und jeden zu prüfen, bevor der nächste kommt. Mach dann das Live-Produkt auffindbar, indem du dich bei der Search Console registrierst und eine Sitemap einreichst, und schnell, indem du Core Web Vitals als Teil des Launches behandelst. Eine sorgfältige Reihenfolge verhindert das klassische Launch-Tag-Versagen, bei dem ein vergessener Key Logins oder Abrechnung lahmlegt. ### Agent-First-Produkte: Warum KI deine API lieben muss - Kanonische URL: https://agenticschool.dev/de/wissen/agent-first-products Zwei Jahrzehnte lang wurden Produkte für menschliche Augen und menschliche Klicks gestaltet. Das ändert sich. Ein wachsender Anteil von Aktionen wird von KI-Agents im Auftrag von Menschen ausgeführt, und Agents schauen nicht auf deine schöne UI, sie rufen deine API. Ein Produkt, dessen API sauber, dokumentiert und eine Freude in der Nutzung ist, wird von Agents und den Menschen, die sie steuern, übernommen. Dieser Leitfaden erklärt Agent-First-Design und die API-over-UI-Philosophie, die damit kommt. #### Agents sind eine neue Nutzerbasis KI-Agents wählen jetzt, welche Tools und APIs sie aufrufen, um einen Job zu erledigen. Das macht sie zu Nutzern, mit Vorlieben. Ein Produkt, über das ein Agent lesen, das er verstehen und sauber aufrufen kann, wird gewählt; eines, das sich hinter einer UI versteckt, die ein Agent nicht nutzen kann, wird übersprungen, egal wie poliert diese UI ist. Für Agents zu gestalten ist kein Futurismus, es ist das Erkennen einer Nutzerbasis, die bereits existiert und schnell wächst. #### Die API-over-UI-Philosophie Agent-First-Design behandelt die API als primäre Produktoberfläche, nicht als Nachgedanken hinter dem Interface. Saubere Endpoints, ehrliche Dokumentation und maschinenlesbare Auffindbarkeit kommen zuerst, und die UI wird zu einem Client der API statt zum ganzen Produkt. Diese Umkehrung erzwingt Klarheit: wenn ein Agent dein Produkt allein aus den Docs nutzen kann, kann es eine menschliche Entwicklerin sicher auch. #### Wie eine grossartige agentenseitige API aussieht Agents belohnen Vorhersehbarkeit. Klare Schemas, konsistente Antworten, sinnvolle Fehlermeldungen und auffindbare Dokumentation lassen einen Agent dein Produkt beim ersten Versuch selbstbewusst nutzen. Maschinenlesbare Signale wie eine llms.txt-Datei und strukturierte Daten machen deine Fähigkeiten leicht auffindbar und verständlich. Dieselben Qualitäten, die eine API für einen Agent angenehm machen, machen sie für eine menschliche Entwicklerin angenehm. #### Warum das ein Wettbewerbsvorteil ist Je mehr Arbeit durch Agents fliesst, desto mehr wird das Produkt, zu dem ein Agent zuerst greift, zu einem dauerhaften Vorteil. Es ist Distribution, die du dir durch Nutzbarkeit verdienst, nicht durch Anzeigenkauf. Früh Bewegende, die Agent-First gestalten, werden empfohlen und integriert, während Konkurrenten noch Buttons polieren, die kein Agent je klicken wird. Die Verschiebung belohnt Builder, die sie jetzt ernst nehmen. #### Wie du anfängst Du musst nicht alles neu bauen. Beginne damit, deine wertvollste Fähigkeit über eine saubere, dokumentierte API verfügbar zu machen, ergänze maschinenlesbare Auffindbarkeit, damit Agents sie finden, und teste es, indem du einen Agent dein Produkt allein aus den Docs nutzen lässt. Wo der Agent strauchelt, braucht deine API Arbeit. Diese Feedback-Schleife - ein Agent als dein erster Nutzer - ist der schnellste Weg zu einem Agent-First-Produkt. --- ## Projekte ### BizCollect: Ein Business-Daten-Tool API-First bauen - Kanonische URL: https://agenticschool.dev/de/projekte/bizcollect - Stack: TypeScript, Node.js, REST API, OpenAPI, Convex, Claude Code BizCollect sammelt und strukturiert Business-Daten zuerst über eine saubere API, das UI kommt danach. Warum API-First geändert hat, wie ich Produkte baue. #### Das Problem, das ich lösen wollte Ich brauchte einen verlässlichen Weg, Business-Daten aus vielen chaotischen Quellen zu sammeln, zu bereinigen und zu strukturieren und sie anderen Tools in einer vorhersehbaren Form zu übergeben. Mein erster Instinkt war, wie bei den meisten Leuten, ein hübsches Dashboard zu bauen. Ich fing mit den Screens an. Das war der Fehler, der mich am meisten gelehrt hat. #### Warum ich auf API-First umgestellt habe Mittendrin merkte ich, dass jeder Konsument dieser Daten ein Programm war, kein Mensch, der auf Buttons klickt: eine Automation, ein Scraper, ein anderer Agent, ein zukünftiges Ich, das um Mitternacht ein Skript schreibt. Das UI war ein dünner Nachgedanke. Also baute ich das Ganze rund um eine dokumentierte API neu, mit dem Dashboard als nur einem Client dieser API statt als dem Produkt selbst. - Jede Fähigkeit ist ein Endpunkt mit einem stabilen Vertrag, nicht ein Button, vergraben in einem Screen. - Die API kommt mit einer OpenAPI-Spec, damit ein Agent sie entdecken und nutzen kann, ohne dass ich etwas erkläre. - Antworten sind vorhersehbares JSON mit jedes Mal derselben Form, damit Konsumenten nie raten müssen. #### Was sich änderte, als die API zuerst kam In dem Moment, als die API das Produkt war, wurde alles dahinter einfacher. Automationen klinkten sich ein, ohne Screens abzukratzen. Testen wurde trivial, weil ich Endpunkte testete, nicht Klick-Flows. Und als ich einen KI Agent auf die OpenAPI-Spec ansetzte, konnte er BizCollect beim ersten Versuch korrekt nutzen, weil der Vertrag ihm genau sagte, was er senden muss und was er zurückbekommt. Das war der Aha-Moment: Ein Tool, das eine KI verstehen und ohne Händchenhalten bedienen kann, ist 2026 weit mehr wert als ein Tool, durch das sich nur ein Mensch navigieren kann. #### Was ich anders machen würde Ich würde die OpenAPI-Spec schreiben, bevor ich einen einzigen Endpunkt schreibe, und sie als Design-Dokument behandeln. Ich würde die API auch ab Tag eins versionieren, statt Versionierung später dranzuschrauben. Das Dashboard lässt sich immer neu generieren; ein kaputter API-Vertrag bricht jeden, der von dir abhängt, inklusive Agents, die du nie getroffen hast. ### s2p: Jeden Release automatisch auf alle Kanäle posten - Kanonische URL: https://agenticschool.dev/de/projekte/s2p - Stack: GitHub Actions, GitHub API, Node.js, Webhooks, n8n, TypeScript s2p verwandelt ein GitHub-Release automatisch in formatierte Posts über jeden Social-Kanal. Wie ich eine Release-zu-Social-Pipeline baute, die sich selbst betreibt. #### Die Routinearbeit, die ich nicht mehr machen wollte Jedes Mal, wenn ich einen Release auslieferte, kopierte ich den Changelog, formatierte ihn für jede Plattform um, wechselte den Ton und postete ihn von Hand an fünf Orten. Es dauerte zwanzig Minuten, ich machte es uneinheitlich, und meist liess ich aus Faulheit ein oder zwei Kanäle aus. s2p ("ship to posts") war meine Entscheidung, dass ein Computer das jedes Mal gleich erledigen soll. #### Wie die Pipeline funktioniert Der Auslöser ist ein veröffentlichter GitHub-Release. Ein Workflow greift die Release-Notes ab, ein LLM schreibt sie in die richtige Stimme und Länge für jeden Kanal um, und das Ergebnis wird zum Posten in die Warteschlange gestellt. Das Ganze ist eine Kette kleiner, langweiliger Schritte, und genau das macht es verlässlich. - Ein GitHub-Webhook feuert, wenn ich einen Release veröffentliche. - Die Release-Notes werden pro Kanal umformatiert: kurz und knackig für den einen, länger und technisch für den anderen. - Jeder Post wird aus derselben Quelle der Wahrheit erzeugt, damit die Kanäle nie auseinanderdriften. #### Die Lektion in den langweiligen Teilen Der interessante Teil war nicht das LLM, das Text umschreibt, es war die Verkabelung. Verlässliche Automation dreht sich meist um die unglamourösen Edge Cases: Was passiert, wenn ein Kanal down ist, wenn der Release keine Notes hat, wenn ein Post auf halbem Weg scheitert. Ich lernte, jeden Schritt idempotent zu machen und laut zu loggen, damit ein halbfertiger Lauf nie still dasselbe zweimal postet oder einen Kanal stumm fallen lässt. Der KI-Teil waren die einfachen 20 Prozent. Die vertrauenswürdige Verkabelung waren die 80 Prozent, die es zu etwas machten, auf das ich mich wirklich verlasse. ### Favicon Maker: Ein kleines Tool, das sich auszahlte - Kanonische URL: https://agenticschool.dev/de/projekte/favicon-maker - Stack: TypeScript, Canvas, Sharp, React, Vercel Favicon Maker macht aus einem einzigen Logo jede Favicon- und Icon-Grösse, die eine Seite braucht. Ein kleines, scharfes Tool über den Wert, eine Sache gut zu machen. #### Warum ein ganzes Tool für Favicons Jede Seite braucht ein Favicon, und nicht nur eine Datei: Da ist die klassische .ico, ein Haufen PNG-Grössen für verschiedene Geräte, ein apple-touch-icon und ein Manifest-Eintrag. Das von Hand zu machen ist fummelig und leicht subtil falsch zu machen, weshalb so viele Seiten ein verwaschenes Icon ausliefern. Ich wollte ein sauberes Logo reinwerfen und das komplette, korrekte Set herausbekommen. #### Den Scope brutal klein halten Die Versuchung bei so einem Tool ist, immer mehr hinzuzufügen: einen Logo-Editor, Hintergrundentfernung, eine Icon-Bibliothek, Accounts. Ich habe allem widerstanden. Favicon Maker macht genau eine Sache, und diese Einschränkung ist der ganze Grund, warum es gut ist. - Ein Input: dein Logo. Ein Output: jede Favicon- und Icon-Grösse, korrekt benannt. - Keine Accounts, kein Upsell, keine Einstellungen, die niemand versteht. - Weil es eine Sache macht, ist es leicht zu vertrauen und unmöglich, sich davon verwirren zu lassen. #### Was der Favicon-Trick mir über SEO beibrachte Das hier zu bauen schickte mich in ein Kaninchenloch, das sich als wichtig herausstellte: Das Favicon ist das kleine Ding, das neben deinem Ergebnis in der Suche und in Browser-Tabs auftaucht, und ein scharfes, wiedererkennbares verbessert leise, wie vertrauenswürdig dein Link wirkt. Ein winziges Detail, das die meisten ignorieren, ist genau die Art Vorsprung, die sich aufsummiert. Das Tool war klein, die Lektion nicht: scharfe, korrekte Details in jeder Grösse gehören zum professionellen Auftritt, und professionell zu wirken gehört dazu, geklickt zu werden. ### CodeCourier: Fremden Code ausführen, ohne sich zu verbrennen - Kanonische URL: https://agenticschool.dev/de/projekte/codecourier - Stack: Node.js, E2B, Docker, TypeScript, REST API CodeCourier führt KI-generierten Code in isolierten Sandboxes aus, damit ein schlechter Snippet nie den Host berührt. Was ich über sichere Codeausführung lernte. #### Das Problem, Code auszuführen, den eine KI schrieb In dem Moment, in dem du eine KI Code generieren und ihn dann ausführen lässt, hast du ein Sicherheitsproblem. Der Code mag in Ordnung sein, oder er löscht Dateien, leakt Secrets oder hämmert das Netzwerk. CodeCourier war meine Antwort: ein Service, der einen Snippet nimmt, ihn irgendwo ausführt, wo er keinen Schaden anrichten kann, und das Ergebnis zurückgibt. #### Sandboxes sind der ganze Punkt Die Kernidee ist, dass der Code in einer wegwerfbaren, isolierten Umgebung läuft, einer Sandbox, die keinen Zugriff auf irgendetwas hat, das mir wichtig ist. Versucht ein Snippet etwas Böses, ist der schlimmste Fall, dass die Sandbox weggeworfen wird. Ich stützte mich auf bestehende Sandbox-Infrastruktur, statt meine eigene Isolation zu bauen, denn Isolation subtil falsch zu machen ist der Weg, übernommen zu werden. - Jeder Lauf bekommt eine frische, wegwerfbare Umgebung ohne Host-Zugriff und ohne echte Secrets. - Netzwerk und Dateisystem sind standardmässig dicht; du gibst Zugriff bewusst frei, nie versehentlich. - Timeouts und Ressourcen-Limits stoppen einen entlaufenen Snippet, bevor er Geld kostet oder ewig hängt. #### Warum ich meine eigene Isolation nicht baute Mein Instinkt war, mich zu einer selbstgebauten Sandbox zu tricksen. Ich bin froh, dass ich es nicht tat. Isolation ist eine Domäne, in der der Fehlerfall still und katastrophal ist: Du denkst, du bist sicher, bis du es sehr deutlich nicht bist. Speziell gebaute Sandbox-Tools zu nutzen hiess, dass der harte, sicherheitskritische Teil von Leuten erledigt wurde, die sich darauf spezialisieren, und ich mich auf die Orchestrierung drumherum konzentrieren konnte. Das ist derselbe Instinkt wie ein Auth-Provider statt eigenem Login: Manche Probleme sind zu scharf, um sie von Grund auf zu lösen. ### AutoMail: E-Mail-Automation, die wie ein Mensch klingt - Kanonische URL: https://agenticschool.dev/de/projekte/automail - Stack: Node.js, Email API, n8n, LLM, TypeScript AutoMail entwirft, versendet und verfolgt E-Mails automatisch nach, behält aber einen menschlichen Freigabeschritt. Wie ich E-Mail automatisierte, ohne wie ein Bot zu klingen. #### E-Mail ist, wo Automation persönlich wird E-Mail zu automatisieren ist gefährlich, weil der Output direkt zu einem Menschen geht, der dich danach beurteilt. Eine unbeholfene automatisierte E-Mail ist schlimmer als keine E-Mail: Sie sagt dem Empfänger, dass dir nicht genug an ihm lag, um sie zu schreiben. AutoMail war mein Versuch, die repetitiven Teile von E-Mail zu automatisieren, ohne den Teil zu verlieren, der sie menschlich wirken lässt. #### Der Mensch-im-Loop-Schritt, der mich rettete Meine erste Version versendete alles automatisch. Es war ein Fehler. Die Lösung war, ein menschliches Freigabe-Gate für alles zu behalten, bei dem sich das System nicht sicher war, sodass die Automation entwirft und der Mensch nickt. Mit der Zeit wurden die Kategorien, die verlässlich gut waren, zu voller Automatik befördert, und der Rest blieb unter Prüfung. - Das System entwirft; ein Mensch gibt alles ausserhalb der bekannt-sicheren Kategorien frei. - Templates erledigen die langweiligen, identischen Fälle; das LLM erledigt die, die Nuance brauchen. - Jeder Versand wird geloggt, damit ich genau sehe, was rausging und an wen. #### Was ich über Vertrauen und Ton lernte Die grosse Lektion war, dass Automation Vertrauen schrittweise verdient. Du fängst nicht damit an, der Maschine die Schlüssel zu geben; du fängst damit an, dass die Maschine entwirft und du freigibst, und du weitest die Autonomie nur aus, wenn sich jede Kategorie bewährt. Dieser abgestufte Ansatz ist dasselbe Muster hinter jeder sicheren Automation, die ich seither gebaut habe: erst validieren, das Validierte automatisieren und einen Menschen an den Rändern wachen lassen. Auch der Ton zählt. Ein paar menschliche Touches in den Templates hielten die E-Mails davon ab, in dieses flache, generierte Register zu rutschen, das Leute aufhören lässt zu lesen. ### GlowLens: Bilder in nützliche Signale verwandeln - Kanonische URL: https://agenticschool.dev/de/projekte/glowlens - Stack: Gemini Vision, Node.js, TypeScript, REST API, Convex GlowLens nutzt Vision-Modelle, um strukturierte Signale aus Bildern zu ziehen, und meldet, wie sicher es ist. Was mir der Bau eines Vision-Tools beibrachte. #### Was GlowLens macht GlowLens nimmt Bilder und verwandelt sie in strukturierte Signale: was auf dem Bild ist, messbare Attribute und einen Confidence-Score für jede Antwort. Es begann als Experiment, wie weit moderne Vision-Modelle gekommen sind, und wurde zu einem wiederverwendbaren Baustein, zu dem ich greife, wann immer ein Projekt ein Bild verstehen muss. #### Confidence ist Teil der Antwort Die wichtigste Design-Entscheidung war, dass GlowLens nie nur ein Ergebnis nennt, sondern ein Ergebnis plus wie sicher es ist. Ein Vision-Modell, das selbstsicher eine falsche Antwort gibt, ist gefährlich; eines, das sagt "wahrscheinlich das, aber ich bin nur zu 60 Prozent sicher", lässt das System drumherum eine kluge Entscheidung treffen. - Jedes extrahierte Attribut kommt mit einem Confidence-Signal, nicht nur einem Wert. - Ergebnisse mit niedriger Confidence werden zu einem Menschen geleitet, statt blind geglaubt zu werden. - Der Output ist strukturiertes JSON, damit der nächste Pipeline-Schritt auf Confidence verzweigen kann. #### Wo Vision-Modelle noch stolpern Vision ist heute echt beeindruckend, aber es ist keine Magie. Es kämpft mit ungewöhnlichen Winkeln, schlechtem Licht und allem, was es selten gesehen hat, und entscheidend scheitert es auf eine Art, die selbstsicher aussieht. Die Lektion, die ich mitnahm, ist, dass der Wert eines Vision-Tools nicht nur seine Genauigkeit in einfachen Fällen ist, sondern wie elegant es die harten behandelt. Indem ich Confidence zum erstklassigen Output machte und die unsicheren Fälle zu einem Menschen leitete, wurde GlowLens zu etwas, auf dem ich tatsächlich aufbauen konnte, statt zu einem cleveren Demo, das dich unter Druck leise belügt. ### CallAssistant: Ein Telefon-Agent auf Twilio und Realtime-Voice - Kanonische URL: https://agenticschool.dev/de/projekte/callassistant - Stack: Twilio, OpenAI Realtime, Node.js, WebSockets, TypeScript CallAssistant nimmt echte Telefonanrufe an und bearbeitet sie mit Twilio und einem Realtime-Voice-Modell. Was es wirklich braucht, einen sprechenden Telefon-Agent zu bauen. #### Eine Telefonnummer, die sich selbst beantwortet CallAssistant verbindet eine echte Telefonnummer mit einem Voice-Agent: Jemand ruft an, der Agent geht ran, versteht, was die Person will, und erledigt es in einem natürlichen Gespräch. Twilio trägt den Anruf, ein Realtime-Voice-Modell macht das Zuhören und Sprechen, und mein Code ist der Klebstoff und das Hirn, das entscheidet, was tatsächlich zu tun ist. #### Latenz ist das ganze Erlebnis Im Web kommst du mit einem Spinner durch. In einem Telefonanruf fühlt sich eine Sekunde Pause an, als wäre die Leitung tot. Die gesamte technische Herausforderung war, die Round-Trip-Zeit schnell genug zu halten, dass sich das Gespräch lebendig anfühlte, was hiess, Audio in beide Richtungen zu streamen, statt auf komplette Sprecherwechsel zu warten. - Audio streamt in Echtzeit über eine dauerhafte Verbindung, nicht in langsamen Request-Response-Brocken. - Der Agent kann mitten im Satz unterbrochen werden, weil echte Menschen unterbrechen. - Jede Aktion, die der Agent ausführen kann, ist ein klar definiertes Tool, damit er nie etwas Gefährliches improvisiert. #### Was Voice mich lehrte, das Text nicht tat Einen Text-Chatbot zu bauen wiegt dich in dem Glauben, Voice sei einfach dasselbe mit einem Mikrofon. Ist es nicht. Voice ist unerbittlich bei Timing, bei Unterbrechungen, bei der peinlichen Stille, wenn das Modell nachdenkt. Es erhöht auch den Einsatz bei Sicherheit: Ein Voice-Agent, der echte Aktionen in einem echten Anruf ausführt, braucht enge, gut definierte Tools und klare Grenzen, denn es gibt keinen "Bist du sicher?"-Dialog in einem Telefonanruf. Die tiefste Lektion war, dass das Medium das Produkt formt. Dasselbe Modell verhält sich völlig anders, wenn das Interface eine lebendige menschliche Stimme ist statt einer Chatbox. ### B-Rolls Finder: YouTube per Gespräch durchsuchen - Kanonische URL: https://agenticschool.dev/de/projekte/b-rolls-finder - Stack: YouTube Data API, Node.js, React, LLM, TypeScript B-Rolls Finder durchsucht YouTube über ein Chat-Interface, um schnell das richtige B-Roll zu finden. Wie ich das Finden von Videomaterial wie ein Gespräch wirken liess. #### Das Problem, Material zu finden Wenn du ein Video schneidest, ist es eine Plackerei, den richtigen B-Roll-Clip zu finden: Du tippst Keywords in YouTube, scrubbst durch Ergebnisse, verfeinerst und wiederholst. B-Rolls Finder war mein Versuch, das durch ein Gespräch zu ersetzen. Du beschreibst Stimmung und Inhalt, den du willst, und es geht los und findet Kandidaten. #### Chat als Interface, die API als Motor Unter der Haube ist es die YouTube Data API, die sucht, aber das Interface ist eine Chatbox. Das LLM verwandelt eine lose menschliche Anfrage wie "ruhige Luftaufnahmen einer Stadt im Morgengrauen" in präzise Queries, führt sie aus und präsentiert die Ergebnisse im Gespräch, damit du in klarer Sprache verfeinern kannst. - Du beschreibst in Worten, was du willst; das Modell verwandelt das in echte Suchanfragen. - Ergebnisse kommen als kurze, überschaubare Shortlist zurück statt als endloses Scrollen. - Du verfeinerst per Antwort, so wie du einem menschlichen Assistenten sagen würdest "mehr wie das zweite". #### Die Lektion über gute Interfaces Die API war der einfache Teil; der Gewinn war das Interface. Dieselben Daten, dieselbe YouTube-Suche, fühlten sich völlig anders an, wenn sie in ein Gespräch gewickelt waren statt in eine Suchbox. Es erinnerte mich daran, dass viel vom Wert in KI-Produkten gerade keine neue Fähigkeit ist, sondern ein besseres Interface zu Fähigkeit, die schon existiert. Ich stiess auch auf die praktischen Realitäten der Arbeit mit einer Drittanbieter-API: Quotas, Rate Limits und die Notwendigkeit zu cachen, alles, worüber ich abstrakt gelesen hatte und erst wirklich verstand, als es mich biss. Die API eines anderen zu respektieren ist Teil davon, ein guter Mitbürger zu sein, und Teil davon, nicht abgeschnitten zu werden. ### Rechnungs-Automation: Vom Foto zur sauberen Datenbankzeile - Kanonische URL: https://agenticschool.dev/de/projekte/invoice-automation - Stack: Gemini Vision, Node.js, Convex, TypeScript, REST API Dieses Tool liest Rechnungsbilder und schreibt strukturierte Daten in eine Datenbank, samt der chaotischen Edge Cases. Was Bild-zu-Datenbank wirklich bedeutet. #### Die Aufgabe: Foto rein, Daten raus Das Ziel klingt simpel: Nimm ein Foto oder einen Scan einer Rechnung und verwandle es in eine saubere Datenbankzeile mit Lieferant, Betrag, Datum und Positionen. In einem Demo klappt es beim ersten Versuch und fühlt sich wie Magie an. In Wirklichkeit sind Rechnungen genau da, wo Bild-zu-Daten gedemütigt wird, weil keine zwei gleich formatiert sind. #### Die Edge Cases sind das Projekt Der Happy Path dauerte einen Nachmittag. Die Edge Cases dauerten den Rest der Zeit, und da steckt die ganze echte Ingenieursarbeit. Verblasste Scans, fremde Währungen, Summen, die nicht aufgehen, zwei Rechnungen auf einer Seite, Handschrift am Rand. Das Modell las das meiste korrekt und vertat sich dann still bei einer Ziffer, was auf einer Rechnung genau die Art Fehler ist, die man nicht ausliefern kann. - Ich baute einen Stapel Test-Rechnungen, inklusive absichtlich hässlicher, und liess jede Änderung gegen alle laufen. - Extrahierte Zahlen werden gegeneinander validiert, sodass eine Summe, die nicht zu ihren Positionen passt, markiert wird. - Felder mit niedriger Confidence werden einem Menschen zur Bestätigung gezeigt, statt still geschrieben zu werden. #### Testdaten sind der heimliche Held Das wertvollste, das ich baute, war nicht der Extraktions-Prompt, es war die Sammlung echter, chaotischer Test-Rechnungen. Jedes Mal, wenn das Tool an einer neuen Art Dokument scheiterte, wanderte dieses Dokument ins Testset, und von da an konnte ich daran nie wieder regredieren. Das verwandelte ein fragiles Demo in etwas Verlässliches. Die breitere Lektion ist, dass bei Bild-zu-Daten-Arbeit deine Testdaten das Produkt sind. Das Modell ist Massenware; das kuratierte Set harter Beispiele, gegen das du validierst, ist der Burggraben, und es ist, was dich dem Output genug vertrauen lässt, um ihn in die Nähe von jemandes Geld zu bringen. ### Swiss Trading Cards: Vom Bild zu Produktdaten im Massstab - Kanonische URL: https://agenticschool.dev/de/projekte/swiss-trading-cards - Stack: Gemini Vision, Node.js, Convex, TypeScript, Image processing Swiss Trading Cards verwandelt Fotos von Karten in strukturierte Produktspezifikationen, bereit zum Listen. Wie ich eine verlässliche Bild-zu-Produkt-Pipeline baute. #### Von einem Schuhkarton voll Karten zum Katalog Die Idee war, Fotos von Sammelkarten zu nehmen und automatisch die strukturierten Produktdaten zu erzeugen, die man zum Verkaufen braucht: den Namen, das Set, den Zustand, die Attribute, die einem Käufer wichtig sind. Das von Hand für eine grosse Sammlung zu machen ist stumpfsinnig und fehleranfällig, was es zum perfekten Kandidaten für eine Bild-zu-Daten-Pipeline machte. #### Eine Pipeline, kein einzelner Prompt Der Fehler wäre gewesen, das ganze Bild auf ein Modell zu werfen und alles auf einmal zu verlangen. Stattdessen brach ich es in Stufen auf, jede mit einer klaren Aufgabe, sodass ich jede Stufe unabhängig testen und fixen konnte. Eine saubere Pipeline ist weit leichter zu debuggen als ein riesiger Prompt, der entweder richtig oder falsch ist, ohne etwas dazwischen. - Stufe eins identifiziert die Karte; Stufe zwei extrahiert Attribute; Stufe drei normalisiert sie ins Produktschema. - Jede Stufe gibt strukturierte Daten aus, die die nächste konsumiert, sodass Fehler lokalisiert und sichtbar sind. - Mehrdeutige Karten werden zur Prüfung markiert statt geraten, denn ein falsches Listing ist schlimmer als ein fehlendes. #### In der Normalisierung steckt der Wert Eine Karte zu lesen war der schillernde Teil. Der wirklich wertvolle Teil war die Normalisierung: sicherzustellen, dass dasselbe Set immer gleich geschrieben ist, dieselben Zustandsstufen auf dieselben Werte mappen und der Output immer exakt ins Produktschema passt. Käufer und nachgelagerte Systeme kümmert nicht, wie beeindruckend der Vision-Schritt war; sie kümmert, dass die Daten konsistent sind. Ich lernte, dass eine Bild-zu-Produkt-Pipeline an ihrer langweiligen Normalisierungsschicht lebt oder stirbt, und dass das Aufteilen der Arbeit in kleine, testbare Stufen das Ganze vertrauenswürdig genug machte, um daraus wirklich echte Produkte zu listen. ### Sprachlern-App: Bild zu Text zu Audio verketten - Kanonische URL: https://agenticschool.dev/de/projekte/language-learning-app - Stack: Gemini Vision, Translation API, Text-to-Speech, React, Node.js Diese App verkettet Vision, Übersetzung und Sprache, sodass du die Kamera auf ein Objekt richtest und seinen Namen in einer neuen Sprache hörst. Die Lektion über verkettete KI. #### Lernen, indem du deine Kamera richtest Die App lässt dich die Kamera auf etwas in der echten Welt richten, einen Apfel, einen Stuhl, ein Strassenschild, und seinen Namen in der Sprache hören und lesen, die du lernst. Es ist eine kleine Idee mit überraschend motivierendem Effekt, weil sie neue Wörter an echte Dinge vor dir bindet statt an eine Karteikarte. #### Drei KI-Schritte in einer Kette Unter der Haube ist es eine Kette aus drei Modellen, jedes speist das nächste. Vision identifiziert das Objekt, Übersetzung verwandelt das Wort in die Zielsprache, und Text-to-Speech liest es mit einem anständigen Akzent vor. Jeder Schritt ist für sich einfach; das Produkt ist die Kette. - Bild zu Text: ein Vision-Modell benennt, was die Kamera sieht. - Text zu Text: ein Übersetzungsschritt konvertiert das Wort in die Zielsprache. - Text zu Audio: ein Sprachmodell spricht es aus, damit du lernst, wie es tatsächlich klingt. #### Was Ketten dir über Fehler beibringen Die harte Lektion beim Verketten von Modellen ist, dass Fehler sich multiplizieren. Wenn jeder Schritt zu 90 Prozent verlässlich ist, sind drei Schritte hintereinander nicht zu 90 Prozent verlässlich, sie summieren sich, und eine falsche Objekterkennung am Anfang vergiftet alles danach. Also war die eigentliche Arbeit, jeden Schritt elegant und sichtbar scheitern zu lassen: Wenn Vision unsicher ist, was das Objekt ist, sagt die App das, statt dir selbstsicher das falsche Wort beizubringen. Das hier zu bauen änderte, wie ich über mehrstufige KI-Produkte denke. Die Magie steckt in der Kette, aber die Verlässlichkeit steckt darin, wie ehrlich jedes Glied zugibt, wenn es unsicher ist, damit ein kleiner früher Fehler nicht still zu einer selbstsicheren falschen Antwort am Ende wird. ### Maxify Audio: Sound aufräumen ohne Studio - Kanonische URL: https://agenticschool.dev/de/projekte/maxify-audio - Stack: Node.js, FFmpeg, Audio processing, TypeScript, REST API Maxify Audio verbessert raue Aufnahmen über eine automatisierte Kette zu sauberem, hörbarem Sound. Was mir der Bau eines Audio-Enhancement-Tools beibrachte. #### Gut-genug Audio für Leute ohne Studio Maxify Audio nimmt eine raue Aufnahme, die Art, die du von einem Laptop-Mikrofon in einem normalen Raum bekommst, und räumt sie zu etwas auf, das professionell genug klingt, um es zu veröffentlichen. Das Ziel war nie Studio-Perfektion; es war, die meiste Lücke automatisch zu schliessen für Leute, die kein Studio besitzen oder Audio-Engineering kennen. #### Eine Kette von Verarbeitungsschritten Enhancement ist eine Sequenz: das Hintergrundrauschen reduzieren, die Lautstärke ausgleichen, den Ton wärmen und die Pegel normalisieren, damit es bei einer konsistenten Lautheit sitzt. Jeder Schritt ist eine gut verstandene Audio-Operation, und sie in der richtigen Reihenfolge zu verketten erledigt die meiste Arbeit. Die Kunst liegt in der Reihenfolge und der Zurückhaltung. - Rauschreduktion zuerst, damit spätere Schritte kein Zischen verstärken. - Pegel- und Ton-Anpassungen, um Sprache klar und konsistent zu machen. - Ein finaler Normalisierungs-Durchlauf, damit jeder Output bei einer sinnvollen, gleichmässigen Lautheit landet. #### Die Lektion übers Zuviel-Tun Meine frühen Versionen überverarbeiteten alles. Ich drückte die Rauschreduktion und das Enhancement so hart, dass Stimmen unter Wasser und unnatürlich klangen, was schlimmer ist, als sie rau zu lassen. Die Lösung war Zurückhaltung: für den realistischen Fall tunen, nicht den schlimmsten, und akzeptieren, dass gut-genug und natürlich aggressiv und künstlich schlägt. Das ist eine Lektion, die weit über Audio hinaus gilt. Bei jeder automatisierten Verbesserung, ob Sound, Bilder oder Text, ist die Versuchung, jeden Regler aufs Maximum zu drehen, aber das beste Ergebnis kommt meist von einer leichteren Hand, die das Original respektiert. Zu wissen, wann man aufhört, stellte sich als die eigentliche Fähigkeit heraus. --- ## Ressourcen ### Claude Code Setup-Checkliste - Kanonische URL: https://agenticschool.dev/de/ressourcen/claude-code-setup-checklist Claude Code Setup-Checkliste ist ein praxisnahes Arbeitsdokument für das Bauen mit KI-Agents in deinem Business. Es behandelt den Zweck, wann du danach greifst, die konkreten Setup-Schritte, die häufigen Fehler, die du vermeiden solltest, die Sicherheits- und Datenschutzpunkte, die zählen, und den nächsten sinnvollen Schritt. Nutze es als wiederverwendbaren Baustein in Reviews, Briefings, Checklisten und internen Playbooks, damit deine KI-Workflows zu wiederholbaren Systemen werden statt zu einmaligen Tool-Experimenten. ### Codex Workflow-Template - Kanonische URL: https://agenticschool.dev/de/ressourcen/codex-workflow-template Codex Workflow-Template ist ein praxisnahes Arbeitsdokument für das Bauen mit KI-Agents in deinem Business. Es behandelt den Zweck, wann du danach greifst, die konkreten Setup-Schritte, die häufigen Fehler, die du vermeiden solltest, die Sicherheits- und Datenschutzpunkte, die zählen, und den nächsten sinnvollen Schritt. Nutze es als wiederverwendbaren Baustein in Reviews, Briefings, Checklisten und internen Playbooks, damit deine KI-Workflows zu wiederholbaren Systemen werden statt zu einmaligen Tool-Experimenten. ### Agent-Task-Briefing - Kanonische URL: https://agenticschool.dev/de/ressourcen/agent-task-brief Agent-Task-Briefing ist ein praxisnahes Arbeitsdokument für das Bauen mit KI-Agents in deinem Business. Es behandelt den Zweck, wann du danach greifst, die konkreten Setup-Schritte, die häufigen Fehler, die du vermeiden solltest, die Sicherheits- und Datenschutzpunkte, die zählen, und den nächsten sinnvollen Schritt. Nutze es als wiederverwendbaren Baustein in Reviews, Briefings, Checklisten und internen Playbooks, damit deine KI-Workflows zu wiederholbaren Systemen werden statt zu einmaligen Tool-Experimenten. ### Spec-Sheet-Template - Kanonische URL: https://agenticschool.dev/de/ressourcen/spec-sheet-template Spec-Sheet-Template ist ein praxisnahes Arbeitsdokument für das Bauen mit KI-Agents in deinem Business. Es behandelt den Zweck, wann du danach greifst, die konkreten Setup-Schritte, die häufigen Fehler, die du vermeiden solltest, die Sicherheits- und Datenschutzpunkte, die zählen, und den nächsten sinnvollen Schritt. Nutze es als wiederverwendbaren Baustein in Reviews, Briefings, Checklisten und internen Playbooks, damit deine KI-Workflows zu wiederholbaren Systemen werden statt zu einmaligen Tool-Experimenten. ### Spickzettel zur Modellauswahl - Kanonische URL: https://agenticschool.dev/de/ressourcen/model-selection-cheatsheet Spickzettel zur Modellauswahl ist ein praxisnahes Arbeitsdokument für das Bauen mit KI-Agents in deinem Business. Es behandelt den Zweck, wann du danach greifst, die konkreten Setup-Schritte, die häufigen Fehler, die du vermeiden solltest, die Sicherheits- und Datenschutzpunkte, die zählen, und den nächsten sinnvollen Schritt. Nutze es als wiederverwendbaren Baustein in Reviews, Briefings, Checklisten und internen Playbooks, damit deine KI-Workflows zu wiederholbaren Systemen werden statt zu einmaligen Tool-Experimenten. ### OpenRouter Schnellstart - Kanonische URL: https://agenticschool.dev/de/ressourcen/openrouter-quickstart OpenRouter Schnellstart ist ein praxisnahes Arbeitsdokument für das Bauen mit KI-Agents in deinem Business. Es behandelt den Zweck, wann du danach greifst, die konkreten Setup-Schritte, die häufigen Fehler, die du vermeiden solltest, die Sicherheits- und Datenschutzpunkte, die zählen, und den nächsten sinnvollen Schritt. Nutze es als wiederverwendbaren Baustein in Reviews, Briefings, Checklisten und internen Playbooks, damit deine KI-Workflows zu wiederholbaren Systemen werden statt zu einmaligen Tool-Experimenten. ### CLAUDE.md-Starter - Kanonische URL: https://agenticschool.dev/de/ressourcen/claude-md-starter CLAUDE.md-Starter ist ein praxisnahes Arbeitsdokument für das Bauen mit KI-Agents in deinem Business. Es behandelt den Zweck, wann du danach greifst, die konkreten Setup-Schritte, die häufigen Fehler, die du vermeiden solltest, die Sicherheits- und Datenschutzpunkte, die zählen, und den nächsten sinnvollen Schritt. Nutze es als wiederverwendbaren Baustein in Reviews, Briefings, Checklisten und internen Playbooks, damit deine KI-Workflows zu wiederholbaren Systemen werden statt zu einmaligen Tool-Experimenten. ### Checkliste für Secrets und .gitignore - Kanonische URL: https://agenticschool.dev/de/ressourcen/gitignore-secrets-checklist Checkliste für Secrets und .gitignore ist ein praxisnahes Arbeitsdokument für das Bauen mit KI-Agents in deinem Business. Es behandelt den Zweck, wann du danach greifst, die konkreten Setup-Schritte, die häufigen Fehler, die du vermeiden solltest, die Sicherheits- und Datenschutzpunkte, die zählen, und den nächsten sinnvollen Schritt. Nutze es als wiederverwendbaren Baustein in Reviews, Briefings, Checklisten und internen Playbooks, damit deine KI-Workflows zu wiederholbaren Systemen werden statt zu einmaligen Tool-Experimenten. ### Vercel Deploy-Checkliste - Kanonische URL: https://agenticschool.dev/de/ressourcen/vercel-deploy-checklist Vercel Deploy-Checkliste ist ein praxisnahes Arbeitsdokument für das Bauen mit KI-Agents in deinem Business. Es behandelt den Zweck, wann du danach greifst, die konkreten Setup-Schritte, die häufigen Fehler, die du vermeiden solltest, die Sicherheits- und Datenschutzpunkte, die zählen, und den nächsten sinnvollen Schritt. Nutze es als wiederverwendbaren Baustein in Reviews, Briefings, Checklisten und internen Playbooks, damit deine KI-Workflows zu wiederholbaren Systemen werden statt zu einmaligen Tool-Experimenten. ### Leitfaden zur DNS- und Domain-Verbindung - Kanonische URL: https://agenticschool.dev/de/ressourcen/dns-domain-guide Leitfaden zur DNS- und Domain-Verbindung ist ein praxisnahes Arbeitsdokument für das Bauen mit KI-Agents in deinem Business. Es behandelt den Zweck, wann du danach greifst, die konkreten Setup-Schritte, die häufigen Fehler, die du vermeiden solltest, die Sicherheits- und Datenschutzpunkte, die zählen, und den nächsten sinnvollen Schritt. Nutze es als wiederverwendbaren Baustein in Reviews, Briefings, Checklisten und internen Playbooks, damit deine KI-Workflows zu wiederholbaren Systemen werden statt zu einmaligen Tool-Experimenten. ### Clerk Auth-Leitfaden - Kanonische URL: https://agenticschool.dev/de/ressourcen/clerk-auth-guide Clerk Auth-Leitfaden ist ein praxisnahes Arbeitsdokument für das Bauen mit KI-Agents in deinem Business. Es behandelt den Zweck, wann du danach greifst, die konkreten Setup-Schritte, die häufigen Fehler, die du vermeiden solltest, die Sicherheits- und Datenschutzpunkte, die zählen, und den nächsten sinnvollen Schritt. Nutze es als wiederverwendbaren Baustein in Reviews, Briefings, Checklisten und internen Playbooks, damit deine KI-Workflows zu wiederholbaren Systemen werden statt zu einmaligen Tool-Experimenten. ### Convex Backend-Leitfaden - Kanonische URL: https://agenticschool.dev/de/ressourcen/convex-backend-guide Convex Backend-Leitfaden ist ein praxisnahes Arbeitsdokument für das Bauen mit KI-Agents in deinem Business. Es behandelt den Zweck, wann du danach greifst, die konkreten Setup-Schritte, die häufigen Fehler, die du vermeiden solltest, die Sicherheits- und Datenschutzpunkte, die zählen, und den nächsten sinnvollen Schritt. Nutze es als wiederverwendbaren Baustein in Reviews, Briefings, Checklisten und internen Playbooks, damit deine KI-Workflows zu wiederholbaren Systemen werden statt zu einmaligen Tool-Experimenten. ### Stripe Checkout-Checkliste - Kanonische URL: https://agenticschool.dev/de/ressourcen/stripe-checkout-checklist Stripe Checkout-Checkliste ist ein praxisnahes Arbeitsdokument für das Bauen mit KI-Agents in deinem Business. Es behandelt den Zweck, wann du danach greifst, die konkreten Setup-Schritte, die häufigen Fehler, die du vermeiden solltest, die Sicherheits- und Datenschutzpunkte, die zählen, und den nächsten sinnvollen Schritt. Nutze es als wiederverwendbaren Baustein in Reviews, Briefings, Checklisten und internen Playbooks, damit deine KI-Workflows zu wiederholbaren Systemen werden statt zu einmaligen Tool-Experimenten. ### Stripe Webhook-Leitfaden - Kanonische URL: https://agenticschool.dev/de/ressourcen/stripe-webhook-guide Stripe Webhook-Leitfaden ist ein praxisnahes Arbeitsdokument für das Bauen mit KI-Agents in deinem Business. Es behandelt den Zweck, wann du danach greifst, die konkreten Setup-Schritte, die häufigen Fehler, die du vermeiden solltest, die Sicherheits- und Datenschutzpunkte, die zählen, und den nächsten sinnvollen Schritt. Nutze es als wiederverwendbaren Baustein in Reviews, Briefings, Checklisten und internen Playbooks, damit deine KI-Workflows zu wiederholbaren Systemen werden statt zu einmaligen Tool-Experimenten. ### n8n Self-Hosting-Leitfaden - Kanonische URL: https://agenticschool.dev/de/ressourcen/n8n-selfhosting-guide n8n Self-Hosting-Leitfaden ist ein praxisnahes Arbeitsdokument für das Bauen mit KI-Agents in deinem Business. Es behandelt den Zweck, wann du danach greifst, die konkreten Setup-Schritte, die häufigen Fehler, die du vermeiden solltest, die Sicherheits- und Datenschutzpunkte, die zählen, und den nächsten sinnvollen Schritt. Nutze es als wiederverwendbaren Baustein in Reviews, Briefings, Checklisten und internen Playbooks, damit deine KI-Workflows zu wiederholbaren Systemen werden statt zu einmaligen Tool-Experimenten. ### Playwright Scraping-Leitfaden - Kanonische URL: https://agenticschool.dev/de/ressourcen/playwright-scraping-guide Playwright Scraping-Leitfaden ist ein praxisnahes Arbeitsdokument für das Bauen mit KI-Agents in deinem Business. Es behandelt den Zweck, wann du danach greifst, die konkreten Setup-Schritte, die häufigen Fehler, die du vermeiden solltest, die Sicherheits- und Datenschutzpunkte, die zählen, und den nächsten sinnvollen Schritt. Nutze es als wiederverwendbaren Baustein in Reviews, Briefings, Checklisten und internen Playbooks, damit deine KI-Workflows zu wiederholbaren Systemen werden statt zu einmaligen Tool-Experimenten. ### Leitfaden zur Sandbox-Ausführung - Kanonische URL: https://agenticschool.dev/de/ressourcen/sandbox-execution-guide Leitfaden zur Sandbox-Ausführung ist ein praxisnahes Arbeitsdokument für das Bauen mit KI-Agents in deinem Business. Es behandelt den Zweck, wann du danach greifst, die konkreten Setup-Schritte, die häufigen Fehler, die du vermeiden solltest, die Sicherheits- und Datenschutzpunkte, die zählen, und den nächsten sinnvollen Schritt. Nutze es als wiederverwendbaren Baustein in Reviews, Briefings, Checklisten und internen Playbooks, damit deine KI-Workflows zu wiederholbaren Systemen werden statt zu einmaligen Tool-Experimenten. ### Template zum Bauen von API-Tools - Kanonische URL: https://agenticschool.dev/de/ressourcen/api-tool-builder-template Template zum Bauen von API-Tools ist ein praxisnahes Arbeitsdokument für das Bauen mit KI-Agents in deinem Business. Es behandelt den Zweck, wann du danach greifst, die konkreten Setup-Schritte, die häufigen Fehler, die du vermeiden solltest, die Sicherheits- und Datenschutzpunkte, die zählen, und den nächsten sinnvollen Schritt. Nutze es als wiederverwendbaren Baustein in Reviews, Briefings, Checklisten und internen Playbooks, damit deine KI-Workflows zu wiederholbaren Systemen werden statt zu einmaligen Tool-Experimenten. ### Playbook für Lead-Magnete und Funnels - Kanonische URL: https://agenticschool.dev/de/ressourcen/lead-magnet-funnel-playbook Playbook für Lead-Magnete und Funnels ist ein praxisnahes Arbeitsdokument für das Bauen mit KI-Agents in deinem Business. Es behandelt den Zweck, wann du danach greifst, die konkreten Setup-Schritte, die häufigen Fehler, die du vermeiden solltest, die Sicherheits- und Datenschutzpunkte, die zählen, und den nächsten sinnvollen Schritt. Nutze es als wiederverwendbaren Baustein in Reviews, Briefings, Checklisten und internen Playbooks, damit deine KI-Workflows zu wiederholbaren Systemen werden statt zu einmaligen Tool-Experimenten. ### Human-in-the-Loop-Checkliste - Kanonische URL: https://agenticschool.dev/de/ressourcen/human-in-the-loop-checklist Human-in-the-Loop-Checkliste ist ein praxisnahes Arbeitsdokument für das Bauen mit KI-Agents in deinem Business. Es behandelt den Zweck, wann du danach greifst, die konkreten Setup-Schritte, die häufigen Fehler, die du vermeiden solltest, die Sicherheits- und Datenschutzpunkte, die zählen, und den nächsten sinnvollen Schritt. Nutze es als wiederverwendbaren Baustein in Reviews, Briefings, Checklisten und internen Playbooks, damit deine KI-Workflows zu wiederholbaren Systemen werden statt zu einmaligen Tool-Experimenten. ### Test-Stack-Checkliste - Kanonische URL: https://agenticschool.dev/de/ressourcen/test-stack-checklist Test-Stack-Checkliste ist ein praxisnahes Arbeitsdokument für das Bauen mit KI-Agents in deinem Business. Es behandelt den Zweck, wann du danach greifst, die konkreten Setup-Schritte, die häufigen Fehler, die du vermeiden solltest, die Sicherheits- und Datenschutzpunkte, die zählen, und den nächsten sinnvollen Schritt. Nutze es als wiederverwendbaren Baustein in Reviews, Briefings, Checklisten und internen Playbooks, damit deine KI-Workflows zu wiederholbaren Systemen werden statt zu einmaligen Tool-Experimenten. ### Checkliste zur Security-Härtung - Kanonische URL: https://agenticschool.dev/de/ressourcen/security-hardening-checklist Checkliste zur Security-Härtung ist ein praxisnahes Arbeitsdokument für das Bauen mit KI-Agents in deinem Business. Es behandelt den Zweck, wann du danach greifst, die konkreten Setup-Schritte, die häufigen Fehler, die du vermeiden solltest, die Sicherheits- und Datenschutzpunkte, die zählen, und den nächsten sinnvollen Schritt. Nutze es als wiederverwendbaren Baustein in Reviews, Briefings, Checklisten und internen Playbooks, damit deine KI-Workflows zu wiederholbaren Systemen werden statt zu einmaligen Tool-Experimenten. ### DSGVO-Compliance-Checkliste - Kanonische URL: https://agenticschool.dev/de/ressourcen/gdpr-compliance-checklist DSGVO-Compliance-Checkliste ist ein praxisnahes Arbeitsdokument für das Bauen mit KI-Agents in deinem Business. Es behandelt den Zweck, wann du danach greifst, die konkreten Setup-Schritte, die häufigen Fehler, die du vermeiden solltest, die Sicherheits- und Datenschutzpunkte, die zählen, und den nächsten sinnvollen Schritt. Nutze es als wiederverwendbaren Baustein in Reviews, Briefings, Checklisten und internen Playbooks, damit deine KI-Workflows zu wiederholbaren Systemen werden statt zu einmaligen Tool-Experimenten. ### Checkliste für SEO und GEO/AEO - Kanonische URL: https://agenticschool.dev/de/ressourcen/seo-geo-checklist Checkliste für SEO und GEO/AEO ist ein praxisnahes Arbeitsdokument für das Bauen mit KI-Agents in deinem Business. Es behandelt den Zweck, wann du danach greifst, die konkreten Setup-Schritte, die häufigen Fehler, die du vermeiden solltest, die Sicherheits- und Datenschutzpunkte, die zählen, und den nächsten sinnvollen Schritt. Nutze es als wiederverwendbaren Baustein in Reviews, Briefings, Checklisten und internen Playbooks, damit deine KI-Workflows zu wiederholbaren Systemen werden statt zu einmaligen Tool-Experimenten. ### Blueprint für eine Agent-First-API - Kanonische URL: https://agenticschool.dev/de/ressourcen/agent-first-api-blueprint Blueprint für eine Agent-First-API ist ein praxisnahes Arbeitsdokument für das Bauen mit KI-Agents in deinem Business. Es behandelt den Zweck, wann du danach greifst, die konkreten Setup-Schritte, die häufigen Fehler, die du vermeiden solltest, die Sicherheits- und Datenschutzpunkte, die zählen, und den nächsten sinnvollen Schritt. Nutze es als wiederverwendbaren Baustein in Reviews, Briefings, Checklisten und internen Playbooks, damit deine KI-Workflows zu wiederholbaren Systemen werden statt zu einmaligen Tool-Experimenten. --- ## Changelog ### Claude Code Workflow Review, 12. Juni 2026 - Kanonische URL: https://agenticschool.dev/de/changelog/claude-code-workflow-review-2026-06-12 Projektregeln, Tests und Review-Prompts sollten regelmässig aktualisiert werden. Für Teams bedeutet das: Agent-Aufgaben brauchen klare Akzeptanzkriterien, kleine Diffs und eine Review-Schleife, damit Geschwindigkeit nicht auf Kosten von Wartbarkeit, Sicherheit und Nachvollziehbarkeit geht. Behandle CLAUDE.md als lebendes Dokument und mach jede wiederkehrende Korrektur zur festen Regel. ### Codex Business Workflows, 12. Juni 2026 - Kanonische URL: https://agenticschool.dev/de/changelog/codex-business-workflows-2026-06-12 Issue-Templates und Akzeptanzkriterien werden wichtiger denn je. Je klarer ein Business-Problem in erwartete Outputs, Tests und Grenzen übersetzt wird, desto zuverlässiger kann Codex kleine Änderungen, Code-Reviews und Dokumentationsaufgaben in produktive Workflows einbauen. Halte eine AGENTS.md, damit Codex deinen Konventionen automatisch folgt. ### Convex und Clerk Template, 12. Juni 2026 - Kanonische URL: https://agenticschool.dev/de/changelog/convex-clerk-template-2026-06-12 Rollen gehören in Convex, Clerk liefert die Identität. Dadurch bleiben Admin- und Moderationsrechte serverseitig prüfbar, während Login, Session und Profilverwaltung sauber über Clerk laufen. Diese Trennung reduziert Risiko bei späteren Team- und Membership-Funktionen und skaliert mit deinem Produkt. ### Modellpreise und Stufen, 12. Juni 2026 - Kanonische URL: https://agenticschool.dev/de/changelog/model-pricing-shift-2026-06-12 Aufgabenschwierigkeit auf Modellstufe abzustimmen bleibt der klarste Hebel auf deine KI-Rechnung und deine Ergebnisqualität. Die einfachen 80 Prozent der Aufrufe an ein kleines Modell zu leiten und ein grosses Modell nur für wirklich harte Aufgaben zu reservieren, kann Kosten um eine Grössenordnung senken und gleichzeitig die Zuverlässigkeit erhöhen. Halte das Wechseln mit OpenRouter günstig, damit du immer zur besseren Passung wechseln kannst. ### Vercel Speed Insights, 12. Juni 2026 - Kanonische URL: https://agenticschool.dev/de/changelog/vercel-speed-insights-2026-06-12 Schwere Embeds und Admin-Bundles müssen von Public Pages getrennt bleiben. Core Web Vitals bleiben für SEO-lastige Lektionen nur stabil, wenn externe Medien lazy laden, Admin-Code nicht in Public Routes landet und Layout-Boxen feste Dimensionen haben. Behandle Performance als Teil des Veröffentlichens, nicht als Nachgedanken.