Entwicklerinnen und Entwickler, die Testfälle für Systeme schreiben, die sie nur oberflächlich verstehen, produzieren Testfälle, die nur die Oberfläche treffen. Sich in eine Fachdomäne einzuarbeiten ist daher ebenso erforderlich wie Kenntnisse von Äquivalenzklassen, Grenzwertanalyse und risikobasierter Priorisierung. Einarbeitung in neue Themen steht auch an, wenn etwa ein neues Testautomatisierungstool eingeführt wird, für das Bestehen einer Zertifikatsprüfung oder die Vorbereitung für eine neue Rolle, beispielsweise wenn eine Testerin Testmanagerin werden möchte.

Eine KI-gestützte Lernumgebung kann bei all diesen Themen helfen, aber nur mit dem richtigen Prozess und einem technischen Rahmen. Dieser Artikel zeigt den Lernprozess sowie den Aufbau der Lernumgebung mit Claude Code, Zettelkasten und Skills. Am Ende beschreibt er drei Lernprojekte aus der Praxis. Der gezeigte Aufbau ist eine Idee des Autors und wird in dessen Firma bereits von Kolleginnen und Kollegen genutzt. Die vorgestellte Umgebung kann in regulierten Umgebungen laufen, dient aber nicht dazu, Lernthemen zu bearbeiten, die interne Dokumente erfordern.

Der Prozess: agiles Lernen mit KI

Der klassische Lernweg ist, ein Buch von der ersten bis zur letzten Seite zu lesen oder einen Onlinekurs Lektion für Lektion durchzuarbeiten. Das kostet aber viel Zeit und liefert oft breites Wissen, von dem für das konkrete Projekt nur ein kleiner Teil benötigt wird. Entwicklerinnen und Entwickler, die ein 100-seitiges Anforderungsdokument in zwei Wochen so weit verstehen müssen, um sinnvolle Testfälle erstellen zu können, können sich diesen Weg nicht leisten.

Agiles Lernen geht anders vor und stellt dazu sechs Fragen. Am Anfang steht folgende: Was muss der Testende am Ende können, und bis wann? Ein Ziel wie „Ich möchte die Domäne Wetter besser verstehen“ ist zu beliebig, um damit zu arbeiten. Ein Ziel wie „einzelne Wetter-Begriffe wie Hoch und Tief einordnen“ gibt dem Lernpfad eine Richtung. Daraus entsteht ein Lernpfad aus kurzen Sprints, kein fertiger Lernplan. Nach jedem Sprint folgt ein Review. Dort klären die Lernenden, ob das Gelernte schon für den nächsten Schritt reicht oder ob eine weitere Runde benötigt wird. Am Ende benutzt die Lernende das Wissen direkt in ihrer täglichen Arbeit.

Die zweite Frage ist die nach der Zeit. Ein Zeithorizont zwingt zur Priorität. Wer drei Wochen Zeit zum Lernen hat, lernt anders als der, dem dafür drei Monate zur Verfügung stehen.

Die dritte Frage betrifft die Länge eines Sprints. Eine Woche ist ein guter Standardwert. Zwei Wochen können sinnvoll sein, wenn sich der Stoff schwer portionieren lässt. Dazu kommt die Zeit, die pro Sprint wirklich zur Verfügung steht, in jedem Sprint zum Beispiel zwei Stunden. Diese Stunden addieren sich nicht wie auf einem Konto. Acht Wochen mit je einer Stunde ergeben eben keinen Achtstundentag, und das ist ein Vorteil. In den Pausen zwischen den Einheiten arbeitet der Kopf am Stoff weiter, ganz nebenbei, sodass er beim nächsten Sprint fester sitzt als nach einem einzigen langen Block.

Die vierte Frage ist die nach Ort und Zeitpunkt. Gelernt wird im Zug, am Schreibtisch, in Blöcken von einer Stunde oder in kurzen Einheiten am Morgen. Dazu gehört auch, ob es feste Termine gibt oder ob die Sprints nach Bedarf laufen.

Die fünfte Frage betrifft die Lernform. Manche Themen erschließen sich über eine angeleitete Schulung schneller. Andere erarbeitet der Lernende im Selbststudium, mithilfe der KI und den ausgewählten Quellen. Auch eine Mischform ist möglich. Die Entscheidung fällt am besten früh, weil sie den Zuschnitt der Sprints prägt.

Die sechste Frage betrifft die Ressourcen. Handbücher, Fachbücher und Videos gehören dazu, ebenso die Menschen, die beim Lernen helfen können.

Beteiligte Rollen: Welche Rollen treiben den Prozess? Die Lernende selbst steuert den Lernpfad, kennt den eigenen Bedarf und trägt die Verantwortung dafür, dass das Gelernte am Ende sitzt.

Die KI übernimmt zwei Aufgaben, die in einem Lernteam sonst zwei Personen ausfüllen. Als Lernarchitektin strukturiert sie den Stoff, erklärt Zusammenhänge, schlägt Quellen vor und formuliert Übungen. Im Prompting-Dialog stellt sie als Lernbegleiterin Rückfragen und prüft das Verständnis, unter anderem auch mit sokratischen Fragen.

Vertrauenswürdig macht den Prozess erst eine Fachexpertin aus der Domäne. Sie checkt den Lernpfad zu Beginn gegen und bleibt ansprechbar, wenn zwischendurch etwas nicht stimmt. Die Domäne muss dabei nicht die Fachwelt des Kunden sein. Beim Einstieg in Python übernimmt eine erfahrene Entwicklerin diesen Part, sie kennt die Idiome der Sprache und die Besonderheiten beim Testen in Python. Bei der Wetter-App ist es der Meteorologe aus der Fachabteilung. Und wer von der Testerin zur Testmanagerin wächst, holt sich einen Testmanager als Lerncoach, der die Rolle schon ausfüllt. Diese Rolle überspringen viele, weil sie Aufwand bedeutet und man ja die KI hat. Beim Lernen mit der KI ist sie die wichtigste von allen.

Je nach Kontext kommt eine vierte Rolle hinzu. Vorgesetzte ermöglichen Lernzeit, gleichen die Lernziele mit der Projektrealität ab und schaffen Gelegenheiten, das Gelernte anzuwenden. Wer allein und ohne Rückendeckung lernt, kann diesen Part weglassen. Dann fehlt allerdings oft genau die Anwendungsgelegenheit, die aus Wissen echtes Können macht.

Was die KI kann und was nicht

Die KI liegt gelegentlich falsch, ohne dass man es ihr anmerkt. Genau dafür sind die drei folgenden Sicherungen da, und jede fängt eine andere Fehlerquelle ab.

Das Was sichert der gemeinsame Lernpfad. Er entsteht im Dialog zwischen KI und Lernenden, durchläuft anschließend ein Review der Fachexpertin und ist damit menschlich qualitätsgesichert.

Das Woher sichern die gebundenen Quellen. Was die KI sagt, lässt sich zurückverfolgen, weil sie die Fundstelle angibt und die Lernende nachschlagen kann. In den KI-Quellen steht nur öffentlich zugängliches Material. Das Handbuch des Geräteherstellers darf hinein. Das interne Anforderungsdokument des Projekts bleibt draußen. Warum diese Grenze so wichtig ist, zeigt der Abschnitt zum sicheren Aufbau der Umgebung.

Die dritte Sicherung bleibt beim Menschen. Bei ihm bleibt die grundsätzliche Skepsis gegenüber jeder Ausgabe. Das ist keine Haltung, die man einmal annimmt und dann vergisst. Die Testerin fragt die KI nach der Fundstelle, lässt sich die Seitenzahl nennen und schlägt nach. Fällt etwas auf, geht sie damit zur Fachexpertin.

Der Sprint: Nach einem Kickoff läuft der Lernprozess in einer Schleife. Ein Lernsprint bringt ein Stück Stoff, danach folgt das Review zum Sprint. Dort stellt sich die Lernende, im einfachsten Fall nur zusammen mit der KI, bei einem holprigen Sprint zusätzlich mit dem menschlichen Lerncoach eine Frage: Ist das Ziel dieses Sprints erreicht? Bei negativer Antwort folgt eine weitere Runde zum selben Thema, bevor es dann im übernächsten Sprint mit neuen Themen weitergeht. Das Review sitzt damit in jedem Durchlauf und entscheidet jedes Mal neu, ob es weitergeht.

Die Retro: Die Retro folgt erst, wenn alle Sprints durch sind. Sie fragt danach, was und was nicht funktioniert hat und was der nächste Lernzyklus anders machen sollte. Das geht meistens recht schnell und dauert in der Praxis ungefähr zwanzig Minuten. Ihr größter Wert entsteht für andere. Wer später dasselbe oder etwas Ähnliches lernen will, findet in den festgehaltenen Ergebnissen, welcher Kurs nichts taugte und welches Buch getragen hat. Deshalb gehören die Retro-Ergebnisse dokumentiert, in Confluence oder einer anderen Wissensdatenbank, wo das nächste Testteam sie findet.

Sprint, Review und Retro geben den Rahmen vor. Wie er sich füllt, entscheiden die Lernenden selbst (Abb. 1).

Lernumgebung sicher aufbauen: VM statt Container

Manche Tester bauen die Lernumgebung auf dem Firmenrechner nach, andere auf einem Fremdrechner beim Kunden. Damit die KI dort keinen Schaden anrichten kann, läuft sie in einer virtuellen Maschine (VM) auf dem Host. Der Schutz endet allerdings am Netzwerk. Die Lernumgebung hängt bewusst an der API der KI und an der Websuche, denn ohne Internet kann die KI weder recherchieren noch antworten. Was in die VM wandert und die KI erreicht, kann diesen Weg nach außen nehmen. Firmeninternes Wissen hat in dieser Umgebung deshalb nichts verloren, jedenfalls nicht, wenn sie LLMs aus der Cloud nutzt. Wer vertraulich arbeiten muss, für den ist die Lernumgebung nicht gebaut.

Host und VM teilen sich einen Ordner, die einzige Nahtstelle zwischen beiden. Was dort liegt, sieht die KI, alles andere auf dem Host bleibt unerreichbar. Der eigentliche Wert dieser Bauweise liegt in der Frage, die sie jedes Mal aufwirft. Wer eine Datei in den geteilten Ordner legt, entscheidet damit aktiv, dass die KI und über sie die Cloud sie sehen dürfen. Achtung: Das ist kein echter Sicherheitsmechanismus. Das Design unterstützt, dass Lernende hier keine Fehler machen.

Öffentliches Material darf in die Cloud, Vertrauliches bleibt draußen (Abb. 2).

Die VM ist nur eine Möglichkeit von mehreren. Die Auswahl an Isolationswerkzeugen ist groß und fällt individuell aus, ähnlich wie beim Lernen selbst. Container wie Podman im rootless-Modus sind schlanker und starten in Sekunden, teilen sich aber den Kernel mit dem Host. Bubblewrap packt einzelne Prozesse feingranular in eine Sandbox. Auch der Sandbox-Modus von Claude Code unter Linux arbeitet damit.

Welche Lösung am sichersten ist, hängt vom Blickwinkel ab. Ein Container spart Aufwand und Startzeit, teilt sich aber den Kernel mit dem Host. Eine VM zieht dagegen die härtere Grenze, mit eigenem Kernel. Sicherheit ist nicht das einzige Kriterium, Bedienbarkeit und Wartung zählen auch. Dieser Artikel zeigt die Lösung mit VirtualBox, weil ein eigener Kernel die härteste der klassischen Grenzen zieht und ein Snapshot die ganze VM nach einem Experiment auf Knopfdruck zurücksetzt. Aufsetzen und Konfiguration kosten allerdings Zeit.

Ordnung schaffen: Wissen und Anweisungen

Dieser Abschnitt zeigt das konkrete Vorgehen beim Aufbau einer Lernumgebung mit Claude Code. Andere KI-Anbieter dürften ähnliche Mechanismen kennen, Namen und Details bleiben aber Sache des jeweiligen Herstellers.

Auf dem geteilten Ordner wächst mit jedem Lernthema ein kleines Archiv heran. Handbücher der Gerätehersteller als PDF, Exporte und Konfigurationen als XML, eigene Aufzeichnungen und Rechercheergebnisse als Markdown. Ohne Ordnung wird dieser Bestand für beide Seiten unbrauchbar, sowohl für den Menschen, der etwas wiederfinden will, als auch für ein KI-Modell wie Claude Code, das beim Lesen das Passende treffen soll. Die Wissensarchitektur gibt den Rahmen vor, in dem Mensch und Maschine sich gleichermaßen zurechtfinden. Sie beantwortet drei Fragen: Wo liegen die Daten, wie hängen sie zusammen, und woher weiß Claude Code, wie es damit umgehen soll?

Zwei Ebenen auf dem geteilten Ordner: Die Ordnerstruktur bleibt leichtgewichtig, nach dem KISS-Prinzip (Keep It Simple, Stupid). Der geteilte Ordner besitzt deshalb nur zwei Ebenen. Die erste Ebene ist die Wissensbasis, nach Themen sortiert. Ein Ordner beispielsweise für die Wetter-App, einer für Python, einer für die ISTQB-Vorbereitung. Ein Thema überlebt viele Projekte, deshalb entscheidet das Thema über die Ablage. Eine Notiz zur Wetter-App taugt in zwei Jahren für einen ganz anderen Zweck. Die zweite Ebene sind die Projekte, die aus dieser Basis schöpfen, zum Beispiel das Lernen für ein Zertifikat. Das trennt das Material von den Werkstücken. Für ein neues Lernthema entsteht einfach ein neuer Ordner, ohne dass die Struktur umgebaut werden muss.

Der geteilte Ordner trägt zwei Ebenen: die nach Themen sortierte Wissensbasis und die Projekte, die aus ihr schöpfen (Abb. 3).

Die Terminal-Ausgabe des Befehls tree. zeigt die Ordnerstruktur eines echten Verzeichnisses (Abb. 4).

Zettelkasten und Verknüpfungsskript: Die Wissensbasis besteht aus vielen kleinen Notizen (Zetteln), die aufeinander verweisen. Das Vorbild ist der Zettelkasten des Soziologen Niklas Luhmann, der sein Wissen in tausenden kurzen Zetteln mit Querverweisen ablegte, aus denen sich später größere Gedanken zusammensetzen ließen. Auf der Konsole führt dasselbe Prinzip zu kurzen Markdown-Dateien, die über Verweise zusammenhängen.

Diese Verweise stellt ein kleines Bash-Skript her, etwa append_path.sh. Es nimmt zwei Dateien, ermittelt den absoluten Pfad der ersten und hängt ihn ans Ende der zweiten. Welche zwei Notizen zueinander gehören, entscheidet die Testerin, das Skript stellt nur die technische Verknüpfung her. Aus einer Notiz über Fehlerbilder wird so ein Zeiger auf die Notiz über die Wetter-App, ganz ohne Datenbank oder Wiki.

Das Bash-Skript append_path.sh ermittelt den absoluten Pfad einer Datei und hängt ihn ans Ende einer zweiten Datei (Abb. 5).

Das Skript stößt an eine Grenze, da es nur an Textdateien oder eine Markdown-Datei anhängen kann. An das Ende einer PDF- oder einer XML-Datei schreibt es nichts. Für jedes solcher Fremdformate entsteht deshalb eine eigene kleine Begleitnotiz, etwa handbuch_zettel.md neben handbuch.pdf, und dieser Zettel nimmt den Verweis auf. Angelegt wird er in der Beispiel-Lernumgebung derzeit von Hand, eine Automatisierung dafür steht noch aus.

Findet Claude Code beim Lesen einer Notiz am Ende einen solchen Pfad, folgt es ihm und schlägt in der verknüpften Datei nach. Dass das Modell das tun soll, muss allerdings irgendwo stehen, und dieser Ort ist die Projektanweisung.

Skills, Projektanweisung und Prompt: Drei Bausteine bestimmen, wie Claude Code arbeitet, und jeder hat seine eigene Rolle. Im Prompt steht die aktuelle Aufgabe, das, was die Lernende gerade eintippt. Anders die Projektanweisung: Sie hält den dauerhaften Kontext bereit, der in jeder Sitzung gilt, unabhängig von der Tagesaufgabe. Die Skills wiederum kommen nur bei Bedarf zum Zug und bringen dann die wiederverwendbaren Prozeduren mit. Wer diese drei durcheinander wirft, schreibt entweder ständig dasselbe in jeden Prompt oder überlädt die Projektanweisung mit Dingen, die dort nicht hingehören.

Die Projektanweisung heißt in Claude Code CLAUDE.md. Diese Markdown-Datei liest das Werkzeug zu Beginn jeder Sitzung automatisch. Solche Anweisungsdateien lassen sich stapeln. Eine liegt auf Höhe des geteilten Ordners und gilt für alles darunter. Eine zweite kommt im Wetter-App-Ordner hinzu, sobald Claude Code dort arbeitet, und trägt das bei, was nur dieses Thema angeht. Beide gelten dann gemeinsam. Über den Projektbaum hinaus gibt es weitere Ablageorte, eine persönliche Datei im Heimatverzeichnis für alle Projekte und eine von der IT verwaltete für unternehmensweite Vorgaben.

Wichtig für jedes Lernprojekt wichtig: Diese Dateien liefern Kontext. Was am Ende gilt, wenn sich zwei Ebenen widersprechen, entscheidet die KI. Das Ergebnis ist nicht garantiert.

Ein Skill ist ein Ordner mit einer SKILL.md-Datei, dazu bei Bedarf Skripte oder weitere Ressourcen. Die Projektanweisung liest Claude Code immer. Einen Skill zieht es nur heran, wenn dessen Beschreibung zur aktuellen Aufgabe passt. Beim Start einer Sitzung scannt das Werkzeug die Beschreibungen aller Skills und legt sich daraus eine kompakte Übersicht an, aus der es bei passender Aufgabe den ganzen Skill nachlädt. Skills liegen an einem von zwei Orten, persönlich unter ~/.claude/skills oder projektgebunden unter .claude/skills im Projektordner. Kollidieren zwei Skills im Namen, einer persönlich, einer projektgebunden, hat der projektgebundene das letzte Wort. So lässt sich für ein einzelnes Projekt eine abweichende Fassung hinterlegen, während die persönliche in allen anderen Projekten unangetastet bleibt.

Skills über die Themenordner zu verteilen, ergibt dagegen keinen Sinn. Claude Code findet einen Skill über seine Beschreibung, egal wo er im Baum liegt. Faustregel: Was über mehrere Projekte hinweg wiederkehrt, gehört in einen Skill; was nur ein einzelnes Thema betrifft, gehört in die Projektanweisung. Ein Skill für ein wiederkehrendes Rollenspiel wandert an den zentralen Ort. Das Fachwissen über die Wetter-App steht in der CLAUDE.md des Themenordners.

Ein Ordner, zwei Architekturen: Der geteilte Ordner verklammert die beiden Architekturen dieses Artikels. Die Sicherheitsarchitektur aus dem vorangegangenen Abschnitt sagt, was überhaupt auf den Share darf. Die Wissensarchitektur beschreibt, wie das Erlaubte dort geordnet ist. Es ist derselbe Ordner, aus zwei Blickwinkeln betrachtet.

Ganz sauber liegt allerdings nicht alles auf dem Share. Die projektgebundenen Bausteine tun es, die Notizen, die projektbezogene CLAUDE.md und die Skills unter .claude/skills im Projektbaum. Die persönlichen Varianten dagegen liegen unter ~/.claude im Home-Verzeichnis der VM, und damit außerhalb des geteilten Ordners. Daraus folgt eine bewusste Entscheidung. Wer seine Skills und Anweisungen zusammen mit dem Wissen auf dem Share halten will, damit sie vom Host aus bearbeitbar bleiben und mit der VM wandern, legt sie projektgebunden an. Wer sie über alle Umgebungen hinweg teilen will, nimmt die persönliche Variante im Home in Kauf.