In der sich schnell entwickelnden Welt des KI-gestützten Codings hat sich ein GitHub-Repo als das populärste Set an Verhaltensrichtlinien für AI-Coding-Agents herauskristallisiert: forrestchang/andrej-karpathy-skills. Erstellt vom Entwickler Forrest Chang, destilliert es Andrej Karpathys virale Beobachtungen über LLM-Coding-Fallstricke in eine einzige, praxisnahe CLAUDE.md Datei. Wir haben sie auf GitHub, Twitter/X, Reddit, Web-Artikeln und dem Quellcode selbst recherchiert — hier ist der ultimative Guide.
Get the latest on AI, LLMs & developer tools
New MCP servers, model updates, and guides like this one — delivered weekly.
🎬 Sieh dir die Video-Analyse an
Lieber lesen? Scrolle weiter für den vollständigen schriftlichen Guide mit Code-Beispielen.
1. Warum es viral ging
Beginnen wir damit, warum dieses Repo wichtig ist. Es wurde zu einem der am schnellsten wachsenden Repositories auf GitHub — zehntausende Sterne in den ersten Wochen — für ein Repo, das im Wesentlichen eine einzige Datei.
Kein Framework. Keine Library. Keine App. Ein einziger Satz an Verhaltensrichtlinien für AI-Coding-Agents. Erstellt am 27. Januar 2026, veröffentlicht unter der MIT-Lizenz, und es wächst weiter. Das sagt einiges darüber aus, wohin sich die Branche entwickelt.
Warum das wichtig ist
Viele beliebte Open-Source-Tools mit Tausenden von Mitwirkenden und jahrelanger Entwicklung haben weniger Sterne. Dieses Repo ging viral mit einer Handvoll Commits und null Laufzeitabhängigkeiten. Der Wert liegt nicht im Code — er liegt in den Ideen.
2. Die Entstehungsgeschichte
Das Repo lässt sich direkt auf einen viralen Tweet zurückführen von Andrej Karpathy — Mitbegründer von OpenAI, ehemaliger KI-Leiter bei Tesla und die Person, die den Begriff “vibe coding” geprägt hat. In seinem Post teilte Karpathy kein Tool oder Repo. Er teilte Beobachtungen — eine Liste von Frustrationen darüber, wie sich LLMs beim Schreiben von Code verhalten.
Ein paar zufällige Notizen vom Programmieren mit Claude in den letzten Wochen.
— Andrej Karpathy (@karpathy) 26. Januar 2026
Coding-Workflow. Angesichts der jüngsten Fortschritte bei den LLM-Coding-Fähigkeiten bin ich, wie viele andere auch, schnell von etwa 80 % manuellem + Autocomplete-Coding und 20 % Agents im November zu 80 % Agent-Coding und 20 % Edits + Touchups übergegangen in…
Entwickler Forrest Chang las diese Beobachtungen und tat etwas Praktisches: Er wandelte sie in eine strukturierte, maschinenlesbare CLAUDE.md Datei. Kein vager Blogpost. Kein Twitter-Thread. Eine Konfigurationsdatei die KI-Agenten tatsächlich lesen und befolgen.
Die entscheidende Erkenntnis war: Karpathy identifizierte Probleme. Forrest Chang kodifizierte Lösungen. Die Community validierte beides — was es zu einem der meist-gesternten AI-Workflow-Repos auf GitHub machte.
3. Die Probleme, die Karpathy identifizierte
Karpathys Beobachtungen waren keine vagen Beschwerden. Es waren spezifische, reproduzierbare Muster, die jeder Entwickler, der KI-Coding-Agenten nutzt, schon erlebt hat. Hier sind seine exakten Worte:
Problem 1: Versteckte Annahmen
“Die Modelle treffen in Ihrem Namen falsche Annahmen und arbeiten einfach damit weiter, ohne sie zu prüfen. Sie managen ihre eigene Verwirrung nicht, bitten nicht um Klärung, zeigen Inkonsistenzen nicht auf, präsentieren keine Abwägungen und widersprechen nicht, wenn sie es eigentlich sollten.”
Problem 2: Over-Engineering
“Sie neigen dazu, Code und APIs unnötig zu verkomplizieren, Abstraktionen aufzublähen, toten Code nicht zu entfernen... sie implementieren ein aufgeblähtes Konstrukt über 1000 Zeilen, wo 100 ausreichen würden.”
Problem 3: Unbeabsichtigte Nebenwirkungen
“Sie ändern oder entfernen manchmal immer noch Kommentare und Code, den sie nicht ausreichend verstehen, als Nebenwirkung, selbst wenn dies orthogonal zur eigentlichen Aufgabe ist.”
Wenn Sie Claude Code, Copilot, Cursor oder einen anderen KI-Coding-Agenten verwendet haben, kennen Sie das. Sie bitten den Agenten, einen Bug zu beheben, und er schreibt die halbe Datei um. Sie bitten ihn, ein Feature hinzuzufügen, und er baut eine komplette Abstraktionsschicht auf. Sie bitten ihn um Hilfe, und er prescht mit falschen Annahmen selbstbewusst voran.
Die Reddit-Community (insbesondere r/ClaudeAI und r/ClaudeCode) hat einen weit verbreiteten Begriff für dieses Verhalten: “der selbstbewusste Junior-Entwickler.” Die KI ist schnell, kenntnisreich und neigt zu naiven Fehlern, wenn sie unbeaufsichtigt bleibt. Sie ist brillant, aber unzuverlässig — genau die Art von Ingenieur, die klare Leitplanken benötigt.
4. Die vier Prinzipien
Forrest Chang destillierte Karpathys Beobachtungen in vier Prinzipien. Jedes davon adressiert direkt eine spezifische Klasse von LLM-Fehlern:
| Prinzip | Adressiert |
|---|---|
| Erst denken, dann coden | Falsche Annahmen, versteckte Unklarheiten, fehlende Abwägungen |
| Einfachheit an erster Stelle | Überkomplizierung, aufgeblähte Abstraktionen, spekulative Features |
| Präzise Änderungen | Orthogonale Änderungen, Bearbeitung von unbeteiligtem Code, Abweichungen vom Coding-Style |
| Zielorientierte Ausführung | Vage Implementierung, keine Verifizierung, schwache Erfolgskriterien |
Schauen wir uns die einzelnen Punkte genauer an.
Prinzip 1: Erst denken, dann coden
“Keine Annahmen treffen. Unklarheiten nicht verstecken. Abwägungen offenlegen.”
Dies ist das grundlegendste Prinzip. LLMs neigen dazu, stillschweigend eine Interpretation zu wählen und diese umzusetzen. Dieses Prinzip erzwingt explizites Denken:
- Annahmen explizit benennen — Bei Unsicherheit nachfragen statt raten
- Mehrere Interpretationsmöglichkeiten aufzeigen — Bei Unklarheiten nicht stillschweigend eine Option wählen
- Kritisch hinterfragen, wenn angebracht — Wenn ein einfacherer Ansatz existiert, weise darauf hin
- Bei Unklarheiten stoppen — Benenne, was unklar ist, und bitte um Klärung
Beispiel: Die Falle der versteckten Annahmen
Benutzeranfrage: “Add a feature to export user data”
def export_users(format='json'):
users = User.query.all()
# Annahme: ALLE Benutzer, Speicherort, Felder,
# CSV-Feldnamen — ohne Rückfragen
Vor der Implementierung muss ich Folgendes klären:
1. Umfang: Alle Benutzer exportieren oder eine gefilterte Teilmenge?
(Datenschutzrelevanz)
2. Format: Datei-Download? Hintergrund-Job?
API-Endpunkt?
3. Felder: Welche Benutzerfelder?
(einige könnten sensibel sein)
4. Volumen: Wie viele Benutzer normalerweise?
Einfachster Ansatz: Füge einen API-Endpunkt hinzu, der
paginiertes JSON zurückgibt. Was ist deine Präferenz?
Prinzip 2: Einfachheit zuerst
“Minimaler Code, der das Problem löst. Nichts Spekulatives.”
Dies wirkt der Tendenz von LLMs zum Over-Engineering entgegen. Die Regeln sind streng:
- Keine Features über das Geforderte hinaus
- Keine Abstraktionen für Code, der nur einmal verwendet wird
- Keine “Flexibilität” oder “Konfigurierbarkeit”, die nicht angefordert wurde
- Keine Fehlerbehandlung für unmögliche Szenarien
- Wenn 200 Zeilen auch 50 sein könnten, schreibe ihn neu
Der Test: Würde ein Senior Engineer sagen, dass dies überkompliziert ist? Wenn ja, vereinfachen.
Beispiel: Die Überabstraktions-Falle
Benutzeranfrage: “Füge eine Funktion zur Rabattberechnung hinzu”
class DiscountStrategy(ABC):
@abstractmethod
def calculate(self, amount): ...
class PercentageDiscount(DiscountStrategy): ...
class FixedDiscount(DiscountStrategy): ...
class DiscountConfig: ...
class DiscountCalculator: ...
# 50+ Zeilen für eine einzelne Berechnung
# Die Verwendung erfordert 30+ Zeilen Setup
def calculate_discount(amount, percent):
"""Berechne den Rabatt. percent ist 0-100."""
return amount * (percent / 100)
# Verwendung
discount = calculate_discount(100.0, 10.0) # $10 Rabatt
Zentrale Erkenntnis aus dem Repo
„Die ‚überkomplizierten‘ Beispiele sind nicht offensichtlich falsch — sie folgen Entwurfsmustern und Best Practices. Das Problem ist Timing: sie fügen Komplexität hinzu, bevor sie benötigt wird.” Guter Code löst das heutige Problem einfach, nicht das Problem von morgen vorzeitig.
Prinzip 3: Chirurgische Änderungen
“Rühre nur an, was du musst. Räume nur dein eigenes Chaos auf.”
Dies ist das Prinzip, das Karpathy's Frustration über LLMs, die orthogonale Änderungen vornehmen, am direktesten anspricht. Beim Bearbeiten von vorhandenem Code:
- “Verbessere” keinen benachbarten Code, Kommentare oder Formatierungen
- Refactore keine Dinge, die nicht kaputt sind
- Passe dich dem bestehenden Stil an, auch wenn du es anders machen würdest
- Wenn dir nicht zusammenhängender toter Code auffällt, erwähne ihn — lösche ihn nicht
Wenn deine Änderungen Orphans erzeugen:
- Entferne Imports/Variablen/Funktionen, die DEINE Änderungen ungenutzt gemacht haben
- Entferne keinen bereits vorhandenen toten Code, außer du wirst dazu aufgefordert
Der Test: Jede geänderte Zeile sollte sich direkt auf die Anfrage des Benutzers' zurückführen lassen.
Beispiel: Die Drive-By-Refactoring-Falle
Benutzeranfrage: “Behebe den Bug, bei dem leere E-Mails den Validator zum Absturz bringen”
15 Zeilen geändert:
- Docstring hinzugefügt (nicht angefordert)
- Validierung für Benutzernamen hinzugefügt (nicht angefordert)
- Kommentare geändert (nicht angefordert)
- “Verbesserte” E-Mail-Validierungslogik (nicht angefordert)
- .strip()-Aufrufe überall hinzugefügt (nicht angefordert)
3 Zeilen geändert:
- Leerstring-Guard für E-Mail hinzugefügt
- Variablenreferenz geändert, um Absturz zu vermeiden
- Nichts weiter verändert.
Beispiel: Die Style-Drift-Falle
Benutzeranfrage: “Logging zur Upload-Funktion hinzufügen”
The LLM adds logging — but also changes single quotes to double quotes, adds type hints nobody asked for, adds a docstring, reformats whitespace, and restructures the boolean return logic. The correct approach: add nur die Logging-Zeilen unter Verwendung des bestehenden Stils (single quotes, no type hints, same spacing).
Prinzip 4: Zielorientierte Ausführung
“Erfolgskriterien definieren. Wiederholen, bis verifiziert.”
Dieses Prinzip fasst zusammen, was Karpathy für die wertvollste Erkenntnis bei der Arbeit mit LLMs hält:
Karpathy's zentrale Erkenntnis
“LLMs sind außergewöhnlich gut darin, Iterationen zu durchlaufen, bis sie bestimmte Ziele erreichen... Sag ihnen nicht, was sie tun sollen, sondern gib ihnen Erfolgskriterien vor und schau ihnen dabei zu.”
Das Prinzip verwandelt imperative Aufgaben in deklarative Ziele:
| Anstatt... | Umwandeln in... |
|---|---|
| “Validierung hinzufügen” | “Schreibe Tests für ungültige Eingaben und sorge dann dafür, dass sie bestanden werden” |
| “Behebe den Bug” | “Schreibe einen Test, der den Fehler reproduziert, und sorge dann dafür, dass er bestanden wird” |
| “Refactor X” | “Stelle sicher, dass die Tests vorher und nachher bestanden werden” |
Bei mehrstufigen Aufgaben sollte das Modell einen kurzen Plan formulieren:
1. [Schritt] → verify: [Prüfung]
2. [Schritt] → verify: [Prüfung]
3. [Schritt] → verify: [Prüfung]
Strong success criteria let the LLM loop
unabhängig. Schwache Kriterien (“mach, dass es funktioniert”)
erfordern ständige Klärung.
5. Die eigentliche CLAUDE.md-Datei
Hier ist die vollständige, ungekürzte CLAUDE.md Datei aus dem Repo. Sie ist bewusst kurz gehalten — unter 70 Zeilen. Diese Kürze ist ein Feature, keine Einschränkung:
Verhaltensrichtlinien zur Reduzierung gängiger LLM-Coding-
Fehler. Bei Bedarf mit projektspezifischen Anweisungen
zusammenführen.
Abwägung: Diese Richtlinien tendieren eher zur Vorsicht
als zur Geschwindigkeit. Bei trivialen Aufgaben nach eigenem Ermessen handeln.
## 1. Erst denken, dann coden
Keine Annahmen treffen. Unklarheiten nicht verbergen. Abwägungen offenlegen.
Vor der Implementierung:
- Annahmen explizit formulieren. Bei Unsicherheit nachfragen.
- Wenn mehrere Interpretationen existieren, diese präsentieren.
- Wenn es einen einfacheren Ansatz gibt, darauf hinweisen.
- Wenn etwas unklar ist, anhalten. Benennen, was verwirrend ist.
## 2. Einfachheit zuerst
Minimaler Code, der das Problem löst. Nichts Spekulatives.
- Keine Features über das Geforderte hinaus.
- Keine Abstraktionen für Einweg-Code.
- Keine “Flexibilität”, die nicht angefordert wurde.
- Keine Fehlerbehandlung für unmögliche Szenarien.
- Wenn 200 Zeilen auch 50 sein könnten, schreibe sie neu.
## 3. Chirurgische Änderungen
Ändere nur das Nötigste. Beseitige nur deine eigenen Altlasten.
- “Verbessere” keinen angrenzenden Code oder Formatierungen.
- Refactore nichts, was nicht kaputt ist.
- Passe dich dem bestehenden Stil an, auch wenn du es anders machen würdest.
- Wenn dir toter Code auffällt, erwähne ihn — lösche ihn nicht.
## 4. Zielorientierte Ausführung
Definiere Erfolgskriterien. Wiederhole den Vorgang bis zur Verifizierung.
Wandle Aufgaben in verifizierbare Ziele um:
- “Validierung hinzufügen” → “Tests schreiben, dann bestehen lassen”
- “Bug fixen” → “In einem Test reproduzieren, dann beheben”
- “X refactoren” → “Sicherstellen, dass Tests vorher und nachher bestehen”
Das ist alles. Die gesamte Datei. Ihre Stärke liegt in ihrer Kürze — kurz genug, um in das Kontextfenster des Agents zu passen, ohne projektspezifische Anweisungen zu verdrängen, und lang genug, um die entscheidenden Verhaltensleitplanken festzulegen.
6. Praxisbeispiele
Das Repo enthält eine EXAMPLES.md Datei mit detaillierten Vorher-Nachher-Vergleichen. Hier ist die wichtigste “Zusammenfassung der Anti-Patterns” aus der Datei:
| Prinzip | Anti-Pattern | Lösung |
|---|---|---|
| Erst denken, dann coden | Setzt stillschweigend Dateiformat, Felder und Scope voraus | Annahmen explizit auflisten, um Klärung bitten |
| Einfachheit zuerst | Strategy-Pattern für eine einzelne Rabattberechnung | Eine einzige Funktion, bis Komplexität tatsächlich erforderlich ist |
| Gezielte Änderungen | Reformats quotes, adds type hints while fixing a bug | Nur Zeilen ändern, die das gemeldete Problem beheben |
| Zielorientiert | “Ich werde den Code überprüfen und verbessern” | “Test für Bug X schreiben → Test bestehen lassen → sicherstellen, dass keine Regressionen auftreten” |
7. Installation
Das Repo bietet zwei Installationsmethoden an:
Option A: Claude Code Plugin (Empfohlen)
Dies installiert die Richtlinien als Claude Code Plugin und macht den Skill verfügbar für alle Ihre Projekte:
/plugin marketplace add forrestchang/andrej-karpathy-skills
# Dann das Plugin installieren
/plugin install andrej-karpathy-skills@karpathy-skills
Option B: CLAUDE.md (Pro Projekt)
Für ein einzelnes Projekt:
curl -o CLAUDE.md https://raw.githubusercontent.com/
forrestchang/andrej-karpathy-skills/main/CLAUDE.md
echo "" >> CLAUDE.md
curl https://raw.githubusercontent.com/forrestchang/
andrej-karpathy-skills/main/CLAUDE.md >> CLAUDE.md
Anpassung
Diese Richtlinien sind darauf ausgelegt, mit projektspezifischen Anweisungen zusammengeführt zu werden. Fügen Sie eigene Abschnitte für TypeScript-Konfigurationen, API-Standards, Testkonventionen oder was auch immer Ihr Projekt benötigt, hinzu. Die vier Prinzipien bilden die Verhaltensgrundlage; Ihre Projektregeln bauen darauf auf.
8. Was ist CLAUDE.md?
Für diejenigen, die mit dem Konzept nicht vertraut sind: CLAUDE.md ist ein Projekt-Memory-Card für KI-Coding-Agents. Sie wird zu Beginn jeder Sitzung automatisch von Claude Code gelesen und bietet so einen persistenten Kontext über verschiedene Konversationen hinweg.
Betrachten Sie es als das KI-Äquivalent einer Onboarding-Dokumentation für neue Entwickler — mit dem Unterschied, dass die KI sie liest jedes einzelne Mal, wenn sie die Arbeit an Ihrem Projekt aufnimmt.
Best Practices für CLAUDE.md (2026)
| Abschnitt | Inhalt |
|---|---|
| Projektübersicht | Zusammenfassung in 2-3 Sätzen, was das Projekt macht |
| Tech Stack | Sprachen, Frameworks, wichtige Bibliotheken |
| Architektur | Codebase-Map (Source, Komponenten, Config) |
| Befehle | dev, build, test, lint Befehle |
| Coding-Standards | Namenskonventionen, Patterns, Style-Regeln |
| Sicherheitsregeln | “Niemals API-Keys hardcoden,” “Nicht /config bearbeiten” |
Die Hierarchie
CLAUDE.md(Projekt-Root) — Gemeinsamer Kontext, in Git committetCLAUDE.local.md(Projekt-Root) — Private, entwicklerspezifische Notizen (zu .gitignore hinzufügen)~/.claude/CLAUDE.md— Globale Einstellungen für alle Projekte- Unterverzeichnis
CLAUDE.mdDateien — Kontext wird nur beim Arbeiten in diesem Verzeichnis geladen
Die Faustregel: Wenn du eine Anweisung im Chat mehr als zweimal wiederholen musst, überführe sie in deine CLAUDE.md.
9. Community-Reaktionen
Wir haben Diskussionen auf Reddit (r/ClaudeAI, r/ClaudeCode), Twitter/X und technischen Blogs recherchiert. Das denkt die Community:
Der “Selbstbewusste Junior-Entwickler”-Konsens
Die Reddit-Community beschreibt Claude Code häufig als brillanten, aber manchmal unzuverlässigen “Junior-Entwickler.” Es ist schnell und kompetent, neigt aber dazu, gefährliche Abkürzungen zu nehmen, zu halluzinieren oder naive Fehler zu machen, wenn es unbeaufsichtigt bleibt. Die Karpathy-Skills-Datei adressiert dies direkt, indem sie die Guardrails hinzufügt, die ein Junior-Entwickler benötigt.
Das “Skill Issue”-Argument
Eine vorherrschende Meinung auf Reddit: Die Qualität von KI-generiertem Code ist direkt proportional zum eigenen technischen Urteilsvermögen des Nutzers und den “Context Engineering”-Fähigkeiten. Fortgeschrittene Nutzer, die Prompt-Struktur, Kontext-Management und Verifizierungsschleifen beherrschen, berichten von drastisch höheren Erfolgsquoten. Die Karpathy-Skills-Datei ist eines der beliebtesten “Context Engineering”-Tools.
Die “KI-Psychose”-Debatte
Karpathys Beschreibung der “permanenten KI-Psychose” — ein ständiger Zustand hyperproduktiver, aber zehrender Agenten-Steuerung — stieß auf große Resonanz. Einige sehen KI-Agenten als Wettbewerbsvorteil, den man nicht ignorieren darf. Andere nennen es “Produktivitätstheater” — man fühlt sich schnell, während man unwartbaren Code produziert. Die Skills-Datei steht in der Mitte: Sie erkennt an, dass KI-Agenten mächtig sind, argumentiert aber, dass sie disziplinierte Einschränkungen.
Die Verschiebung des menschlichen Flaschenhalses
Der Konsens in der Community: KI hat die Hürde für das Schreiben von Code gesenkt. Aber der eigentliche Flaschenhals hat sich von der Implementierung hin zu Architektur und Evaluierungverschoben. Die Herausforderung ist nicht mehr “Wie schreibe ich das?”, sondern “Verstehe ich das, was der Agent gerade gebaut hat, gut genug, um es zu warten?”
10. Das Gesamtbild
Von “Vibe Coding” zu “Agentic Engineering”
Als Karpathy Anfang 2025 den Begriff “Vibe Coding” prägte, beschrieb er eine lockere, dialogorientierte Art des Promptings. Bis 2026 hat die Community dies zu “Agentic Engineering” weiterentwickelt. — eine Disziplin, in der Entwickler KI als Partner betrachten, der klare Ziele, definierte Grenzen und rigoroses Testen erfordert.
Das andrej-karpathy-skills Repo repräsentiert diese Evolution. Es geht nicht darum, einzuschränken, was KI tun kann. Es geht darum, ihre Fähigkeiten zu kanalisieren durch Prinzipien, die bessere Ergebnisse erzielen.
Das “Idea File”-Pattern
Dieses Repo verdeutlicht auch das, was Karpathy das “idea file” Pattern nennt — das Teilen von Ideen anstelle von Implementierungen. Die CLAUDE.md Datei ist keine Library, die jemand importiert. Es ist ein Set von Prinzipien, die jeder anpassen kann. Der Agent des Empfängers passt sie an seine spezifischen Bedürfnisse an. Dies ist eine neue Art von Open Source: kein offener Code, sondern offene Ideen.
Woran man erkennt, dass es funktioniert
Laut der README des Repos funktionieren diese Richtlinien, wenn man Folgendes sieht:
- Weniger unnötige Änderungen in Diffs — Nur angeforderte Änderungen erscheinen
- Weniger Rewrites aufgrund von Überkomplizierung — Der Code ist direkt beim ersten Mal einfach
- Klärende Fragen erfolgen vor der Implementierung — Nicht erst nach Fehlern
- Saubere, minimale PRs — Keine Drive-by-Refactorings oder “Verbesserungen”
Der Tradeoff-Hinweis
Das Repo geht offen mit seinen Tradeoffs um: “Diese Richtlinien setzen eher auf Vorsicht als auf Geschwindigkeit.” Bei trivialen Aufgaben (einfache Tippfehler, offensichtliche Einzeiler) ist gesundes Urteilsvermögen gefragt — nicht jede Änderung erfordert die volle Strenge. Ziel ist es, kostspielige Fehler bei komplexeren Arbeiten zu vermeiden, ohne einfache Aufgaben auszubremsen.
11. Alle Quellen & Links
Dieser Artikel wurde recherchiert unter Verwendung von Multi-Quellen-Recherche auf GitHub, Twitter/X, Reddit, in Webartikeln und im Quellcode selbst. Hier sind alle Primärquellen:
Primärquellen
- GitHub: forrestchang/andrej-karpathy-skills — Das Repo selbst
- CLAUDE.md — Die eigentliche Richtliniendatei
- EXAMPLES.md — Praxisnahe Vorher-Nachher-Beispiele
- Karpathy's Original-Tweet — Der virale Post über LLM-Coding-Fallstricke
Community-Diskussionen
- Reddit r/ClaudeAI — Community-Diskussionen über Claude Code-Workflows und den Konsens zum “confident junior dev”
- Reddit r/ClaudeCode — Threads zu CLAUDE.md Best Practices und Spec-Systemen
- Twitter/X — Reaktionen von Entwicklern, Teilen von Workflows und Berichte zur Adoption
Web-Quellen
- Medium — Technische Reviews und Implementierungsleitfäden
- dev.to — Tutorials aus der Developer-Community
- Forbes — Berichterstattung über die Entwicklung von “vibe coding” hin zu “agentic engineering”
- VentureBeat — Analyse von Karpathys “Compiler”-Analogie für das Kontextmanagement
- Analytics Vidhya — Technische Analyse des Ansatzes der Skills-Datei
Dokumentation
- Claude Code Dokumentation — Offizielle CLAUDE.md Referenz
- HumanLayer.dev — Best Practices für die CLAUDE.md Konfiguration
Verwandte Artikel auf dieser Seite
- Karpathys LLM-Wissensdatenbanken: Der Original-Tweet erklärt
- Karpathys LLM-Wiki: Der vollständige Leitfaden zu seinem Idea File
- So richten Sie Skills in Ihrer AI IDE ein
- Der vollständige Leitfaden für System Prompts für AI Agents
Get the Ultimate Antigravity Cheat Sheet
Join 5,000+ developers and get our exclusive PDF guide to mastering Gemini 3 shortcuts and agent workflows.