KI Programmieren 2026: Meine Erfahrung mit Claude Code
Ich werde oft gefragt, welche KI-Tools ich nutze. Die ehrliche Antwort: nach zwei Jahren Experimentieren mit allem was es gibt, bin ich bei einem einzigen Tool gelandet. Claude Code.
Nicht weil ich faul bin. Nicht weil ich nicht mehrere Tools bedienen könnte. Sondern weil ich festgestellt habe: Ein Tool, das ich wirklich verstehe, bringt mir mehr als fünf Tools, zwischen denen ich ständig wechsle.
Die “10x Produktivität”-Versprechen von 2023? Marketing. Was geblieben ist: ein Werkzeug, das mir bei den richtigen Aufgaben hilft - und bei dem ich gelernt habe, wann ich besser selbst nachdenke.
In diesem Artikel teile ich, was nach zwei Jahren übrig geblieben ist. Kein Tool-Vergleich, keine Empfehlungsliste. Einfach das, was für mich funktioniert.
Die Realität nach dem Hype
Die “10x Developer”-Versprechen? Waren Marketing. Die tatsächlichen Produktivitätssteigerungen liegen bei 20-30% - was immer noch ordentlich ist.
Eine McKinsey-Studie aus 2025 zeigt: Entwickler mit KI-Tools erledigen dieselben Aufgaben im Durchschnitt 25% schneller. Bei repetitiven Tasks wie Boilerplate-Code oder Test-Generierung steigt das auf bis zu 50%. Bei komplexen Architektur-Entscheidungen? Nahezu null.
Wenn du 40 Stunden pro Woche codest und 25% effizienter wirst, sparst du 10 Stunden. Das sind nicht “10x mehr Features” - aber es sind 10 Stunden mehr für Code-Reviews, Architektur oder pünktlich Feierabend.
Der Hype kam von Demos mit perfekt vorbereiteten Prompts in kontrollierten Umgebungen. Die Realität ist unordentlicher - Legacy-Code, gewachsene Architekturen, vage Requirements. Hier zeigt sich, was ein Tool wirklich kann.
Warum Claude Code
Ich hab alles ausprobiert. Copilot, Cursor, ChatGPT, diverse andere Tools. Am Ende bin ich bei Claude Code hängengeblieben - dem CLI-Tool, nicht dem Chat-Interface.
Warum? Nicht weil es bei allem das Beste ist. Sondern weil es bei den Dingen hilft, die mich am meisten Zeit kosten:
- Komplexe Probleme verstehen: Wenn ich einen Bug nicht finde, wenn die Architektur nicht aufgeht, wenn der Legacy-Code keinen Sinn ergibt
- Erklären, nicht nur generieren: Claude Code sagt mir nicht nur “hier ist die Lösung”, sondern erklärt warum
- Projekt-Kontext: Das Tool versteht mein Projekt, meine Patterns, meine Constraints
Für schnelle Completions? Dafür brauche ich kein externes Tool - meine IDE macht das gut genug. Aber für die schwierigen Fragen, die mich früher Stunden gekostet haben? Da macht Claude Code den Unterschied.
Der Moment, der mich überzeugt hat
Wir betreuen seit Jahren ein Typo3-System für mehrere Kunden. Über die Zeit ist es gewachsen - eigene Extensions, Anpassungen, Workarounds für ältere Typo3-Versionen. Irgendwann hatten selbst wir Probleme, neue Features sauber einzubauen. Und jedes Major Release von Typo3 wurde zum Abenteuer: Welche unserer Extensions brechen? Welche APIs haben sich geändert? Wo lauern die versteckten Abhängigkeiten?
Beim letzten großen Upgrade haben wir Claude Code das Projekt gegeben und gefragt: “Analysiere unsere Extensions und zeig uns, welche Typo3-APIs wir nutzen, die sich in der neuen Version geändert haben.”
Was zurückkam, war keine oberflächliche Liste. Es war eine systematische Analyse: Welche unserer Extensions welche deprecated APIs nutzen, wo die Breaking Changes lauern, und konkrete Vorschläge für die Migration. Inklusive Stellen, die wir selbst übersehen hätten - weil das Projekt einfach schon so gigantisch gewachsen war.
In einem Tag hatte ich einen Migrationsplan, für den ich sonst eine Woche gebraucht hätte. Nicht weil Claude Code schlauer ist - sondern weil es systematisch durch hunderte Dateien arbeiten kann, ohne den Faden zu verlieren.
Das war der Moment, ab dem ich aufgehört habe, zwischen Tools zu wechseln. Für diese Art von Problem - Legacy verstehen, Abhängigkeiten aufdecken, Migrationen planen - ist Claude Code das Werkzeug, das funktioniert.
Wann ich dem Output vertraue - und wann nicht
Nach zwei Jahren hab ich ein Gefühl dafür entwickelt, wann ich KI-Code einfach übernehmen kann und wann ich genauer hinschaue.
Bei Standard-Sachen - CRUD-Operationen, API-Calls, React-Components nach bekannten Patterns - übernehme ich den Code meist direkt. Diese Aufgaben haben etablierte Lösungen, die KI wurde auf Millionen ähnlicher Beispiele trainiert. Ein kurzer Blick schadet nie, aber ich muss nicht jede Zeile hinterfragen.
Anders sieht es bei allem aus, was mit Security zu tun hat. Authentication, Authorization, Input-Validation - hier reviewe ich jede Zeile wie einen Junior-PR. KI macht bei Security subtile Fehler, die erst in Production auffallen. Ein vergessener Null-Check, eine falsche Verschlüsselung, eine Race-Condition. Das gleiche gilt für Business-kritische Logik: Berechnungen, Zahlungs-Flows, alles wo ein Fehler richtig wehtut.
Und dann gibt es Dinge, die ich bewusst selbst mache. Architektur-Entscheidungen für mein spezifisches Problem. Tech-Stack-Entscheidungen. Alles, was wirklich neu sein muss und nicht nur eine Rekombination von existierenden Patterns. KI ist gut darin, bekanntes Wissen zusammenzusetzen. Für wirklich neue Lösungen brauchst du menschliche Kreativität - und bei kritischen Komponenten willst du 100% Verständnis, nicht “es funktioniert irgendwie”.
Die häufigsten Fehler
Nach zwei Jahren KI-Nutzung sehe ich diese Fehler immer wieder - bei mir selbst und bei anderen.
1. Copy-Paste ohne Verständnis
Der klassische Anfängerfehler: KI-Code übernehmen, ohne zu verstehen was er macht. Wenn dann etwas schiefgeht, stehst du hilflos da. Debugging wird zum Ratespiel.
Besser: Bevor du Code übernimmst, erkläre dir selbst was jede Zeile macht. Wenn du es nicht erklären kannst, verstehst du es nicht. Claude Code ist gut darin, dir genau das zu erklären - nutze das.
2. Blindes Vertrauen bei Security
KI schreibt dir einen Login-Flow mit Klartext-Passwörtern. Oder SQL-Queries ohne Sanitization. Oder JWT-Handling ohne Expiry.
// ❌ KI-generierter Code - NIEMALS so verwenden
const user = await db.query(`SELECT * FROM users WHERE email = '${email}'`);// ✅ Korrekt: Parametrisierte Queries
const user = await db.query("SELECT * FROM users WHERE email = $1", [email]);Besser: Security-Code braucht immer kritisches Review. Jede Zeile prüfen, keine Ausnahmen.
3. Kein eigenes Lernen mehr
Die gefährlichste Falle: Du lässt alles von KI schreiben und hörst auf zu lernen.
Kurzfristig? Schneller Output. Langfristig? Du wirst ersetzbar - nicht durch KI, sondern durch Entwickler, die KI UND eigene Skills haben.
Besser: Nutze KI als Lernwerkzeug. Lass dir erklären, warum der Code so aussieht. Implementiere wichtige Patterns einmal selbst, bevor du sie generieren lässt.
Prompt-Tipps aus dem Alltag
Ein guter Prompt macht den Unterschied zwischen “das ist Müll” und “genau was ich brauchte”. Vier Dinge, die helfen:
- Kontext liefern: Was ist die Situation? Welches Framework, welche bestehenden Patterns?
- Konkret werden: “Schreib Tests” ist vage. “Schreib Unit-Tests für die validateUser-Funktion mit Edge Cases für leere Strings und ungültige E-Mail-Formate” ist konkret.
- Constraints nennen: Keine externen Dependencies? Deutsche Fehlermeldungen? TypeScript strict mode?
- Nachfragen lassen: “Wenn dir Informationen fehlen, frag nach bevor du anfängst.”
Ein Beispiel:
Statt:
Schreib mir eine Funktion für User-Validierung.Besser:
Kontext: TypeScript/Express Backend, wir nutzen Zod für Validierung.
Bestehende Patterns: src/validators/ enthält ähnliche Schemas.
Task: Erstelle ein Zod-Schema für User-Registration mit:
- Email (valid format, required)
- Password (min 8 chars, 1 Großbuchstabe, 1 Zahl, required)
- Username (3-20 chars, alphanumeric + underscore, required)
Constraints: Deutsche Fehlermeldungen, keine Dependencies außer Zod.Der zweite Prompt gibt dir in 90% der Fälle brauchbaren Code. Der erste? Glückssache.
Workflow-Tipps für Claude Code
Erst verstehen, dann coden
Am Anfang hab ich Claude Code einfach losgeschickt: “Implementiere Feature X”. Das Ergebnis? Code der technisch funktionierte, aber nicht zu meinem Projekt passte. Falsche Patterns, falsche Ordnerstruktur, falsche Annahmen.
Was funktioniert: Aufgaben in Phasen aufteilen. Erst “Schau dir an, wie wir Authentication in diesem Projekt gelöst haben” - und warten bis Claude Code die bestehenden Patterns verstanden hat. Dann “Erstell einen Plan für das neue Feature, ohne Code zu schreiben”. Und erst wenn der Plan stimmt: “Jetzt implementieren.”
Das klingt langsamer, ist es aber nicht. Weil ich nicht mehr Code wegwerfe, der am Projekt vorbei geschrieben wurde. Die zehn Sekunden für “verstehe erst das Projekt” sparen mir zehn Minuten Debugging später.
CLAUDE.md: Projekt-Wissen dauerhaft speichern
Claude Code liest automatisch eine CLAUDE.md im Projektroot. Am Anfang hatte ich keine - und hab bei jeder Session die gleichen Sachen erklärt. “Wir nutzen pnpm, nicht npm.” “Die Tests brauchen Docker.” “In diesem Projekt sind deutsche Variablennamen okay.”
Jetzt steht das alles in der CLAUDE.md. Drin stehen bei mir:
- Welcher Package Manager (pnpm)
- Wie die Tests laufen (Docker muss laufen, dann
pnpm test) - Projekt-Konventionen (Branch-Naming, wo neue Components hin)
- Bekannte Workarounds (“Der Build braucht Node 20, nicht 22”)
Spart mir bei jeder neuen Session fünf Minuten Erklärung. Und Claude Code macht weniger Fehler, weil es die Constraints von Anfang an kennt.
Kontext sauber halten
Nach zwei Stunden in einer Session merke ich manchmal: Claude Code verwechselt Sachen. Mischt Code aus Feature A in Feature B. Oder erinnert sich an einen Lösungsansatz, den ich längst verworfen habe.
/clear ist dein Freund. Nach jedem abgeschlossenen Task einmal alles zurücksetzen. Die CLAUDE.md wird neu geladen, der Rest ist weg. Klingt brutal, aber ein frischer Start mit klarem Kontext ist besser als ein verworrener alter Kontext.
Bei wirklich großen Tasks - Security-Review einer ganzen Codebase, oder Refactoring über viele Dateien - lass ich Claude Code Sub-Agents starten. “Analysiere alle API-Endpoints auf SQL-Injection-Risiken. Nutze einen eigenen Agent dafür.” Der Agent arbeitet isoliert, berichtet zurück, und mein Hauptkontext bleibt sauber.
Zusammenfassung
Was ich aus zwei Jahren KI-Nutzung mitnehme:
- 20-30% Produktivitätsgewinn sind realistisch, nicht 10x
- Ein Tool verstehen bringt mehr als zwischen fünf zu wechseln
- Gute Prompts mit Kontext und Constraints machen den Unterschied
- Workflow mit Phasen: Verstehen → Planen → Coden (nicht umgekehrt)
- CLAUDE.md spart bei jeder Session Zeit durch persistenten Projekt-Kontext
- Kontext-Hygiene:
/clearzwischen Tasks, Sub-Agents für große Analysen - Weiter lernen bleibt wichtig - KI verstärkt deine Skills, ersetzt sie nicht
Das Wichtigste: Finde heraus, was für dich funktioniert. Für mich ist es Claude Code. Für dich könnte es etwas anderes sein. Es gibt kein universell “bestes Tool” - nur das, das zu deinem Workflow passt.
Die Themen aus diesem Artikel – Mindset, Prompting und die häufigsten Fehler – gehe ich im kostenlosen 5-Tage-Kurs KI Coding Partner noch tiefer durch. Mit konkreten Übungen und der kompletten 3-Schritt-Prompting-Methode.
Zum Thema “Ersetzt KI meinen Job?”: Ich habe dazu einen separaten Artikel geschrieben. Kurzfassung: Es ist komplizierter als die Schlagzeilen vermuten lassen.
Was sind deine Erfahrungen mit KI-Tools? Und wo ziehst du die Grenze zwischen Vertrauen und Hinterfragen?
