Für die Foundations-Prüfung musst du nicht nur wissen, dass Claude Code produktiv arbeiten kann, sondern warum bestimmte Setup-Entscheidungen zu stabileren Ergebnissen führen. Drei Begriffe sind hier zentral: Repo Hygiene, Prompt-Struktur und Reproducibility. Zusammen bilden sie die Basis für verlässliche Agenten-Workflows.
Repo Hygiene bedeutet: Das Modell arbeitet in einem klaren, gut strukturierten Code-Kontext. Wenn ein Repository veraltete Build-Dateien, tote Skripte, doppelte Docs oder unklare Ordnernamen enthält, erhöht sich die Fehlerrate. Claude Code kann zwar viel inferieren, aber schlechte Signalqualität im Kontext führt zu schlechten Entscheidungen. Praktisch heißt Hygiene: eindeutige README, konsistente Ordnerstruktur, klare Entry Points, aktuelle Dependency-Dateien und keine unnötigen Artefakte im Arbeitsbaum. Für Prüfungsfragen ist wichtig: Repo Hygiene ist kein „Nice to have“, sondern ein Risikokontroll-Mechanismus gegen Halluzination, falsche Imports und fehlerhafte Refactors.
Der zweite Hebel ist die Prompt-Strategie. In Claude-Code-Workflows sind gute Prompts keine Romane, sondern präzise Aufträge mit Ziel, Constraints und Definition of Done. Ein robustes Muster ist: (1) Zielzustand, (2) betroffene Dateien/Module, (3) harte Grenzen (keine API-Änderung, keine DB-Migration etc.), (4) Validierungsschritte. Beispiel: „Refactore Modul X für bessere Lesbarkeit, keine Public-API-Änderung, alle Tests müssen grün bleiben, liefere kurze Änderungszusammenfassung.“ Solche Prompts reduzieren den Suchraum und damit Kosten, Laufzeit und Fehlentscheidungen. In der Prüfung wird oft indirekt gefragt, welche Prompt-Merkmale die Zuverlässigkeit erhöhen: Kontextabgrenzung + überprüfbare Akzeptanzkriterien ist meist die richtige Richtung.
Dritter Baustein: Reproducibility. Ein Ergebnis ist nur dann produktionsreif, wenn es reproduzierbar ist – also bei gleichem Input unter gleichen Bedingungen konsistent entsteht. Dazu gehören festgelegte Tool-Versionen, dokumentierte Startbefehle, deterministische Testschritte und ein stabiler Ablauf wie „triage → execute → validate → summarize“. Wenn ein Agent heute funktioniert und morgen nicht, liegt das häufig an impliziten Annahmen: andere Environment-Variablen, geänderte Abhängigkeiten, fehlende Pre-Checks. Ein gutes Setup macht diese Annahmen explizit. In Exam-Szenarien ist „funktioniert einmal lokal“ fast immer die falsche Qualitätsmetrik; „wiederholbar im Team- und CI-Kontext“ ist die richtige.
Praktisch solltest du Claude Code daher wie ein Engineering-System behandeln, nicht wie einen Chat. Definiere den Arbeitsrahmen vorab: Welche Branch-Strategie? Welche Tests sind Pflicht? Welche Dateien sind tabu? Wie wird bei Unsicherheit eskaliert (z. B. menschliche Freigabe bei sicherheitsrelevanten Änderungen)? Dadurch verschiebst du den Agenten von opportunistischem Probieren zu kontrollierter Ausführung. Genau das honoriert die Foundations-Prüfung: strukturiertes Denken über Zuverlässigkeit, Nachvollziehbarkeit und Risiko.
Eine gute Merkhilfe: Sauberer Kontext erzeugt bessere Entscheidungen, gute Prompts erzeugen bessere Aktionen, reproduzierbare Abläufe erzeugen Vertrauen. Wenn eines davon fehlt, steigt die Failure-Surface deutlich.
1. Repo Hygiene reduziert Fehlverhalten: klare Struktur und aktuelle Doku senken Halluzinations- und Integrationsrisiken.
2. Prompts brauchen prüfbare Constraints: Ziel + Grenzen + DoD schlagen vage „mach mal besser“-Anweisungen.
3. Reproduzierbarkeit ist Qualitätskriterium: stabile Versionen, feste Validierung und dokumentierter Workflow sind prüfungsrelevant.
Du übernimmst ein Projekt mit unaufgeräumtem Repo. Claude Code soll ein Modul refactoren, aber letzte Runs waren inkonsistent (einmal grün, einmal kaputt). Welche zwei Maßnahmen erhöhen mit der größten Wirkung die Zuverlässigkeit für den nächsten Run?
Erstens: Repo-Hygiene vorziehen (klare betroffene Dateien, veraltete Artefakte entfernen, Einstiegspunkte dokumentieren), damit der Modellkontext sauber ist. Zweitens: einen präzisen Prompt mit harten Constraints und validierbarer Definition of Done verwenden (z. B. keine API-Änderung, Tests grün, kurze Diff-Zusammenfassung). So sinken Interpretationsspielraum und nicht-deterministische Ergebnisse deutlich.