Wie man die eigenen Programmierfähigkeiten mit AI verbessert

• Mit AI-Coding-Tools sollen Transformationsaufgaben, die für Menschen 1–2 Stunden dauern, auf ein Review von 15–20 Minuten reduziert werden.
• Allerdings liegt die Qualität des von AI erzeugten Codes derzeit nicht einmal bei 90 % von handgeschriebenem Code, sodass sie praktisch wenig hilfreich zu sein scheint.
• Deshalb stellt sich die Frage, wie man AI so einsetzen sollte, dass sich Produktivität und Codequalität gleichzeitig steigern lassen.

Praktische Tipps, um mit AI Effizienz und Qualität beim Programmieren zu steigern

1. AI nur auf wiederholbare Aufgaben konzentrieren

• AI erzielt den größten Effekt, wenn ähnlich geformte Aufgaben mehrfach wiederholt werden.
• Einmal setzt ein Mensch die bestmögliche Lösung direkt in hoher Qualität um und nutzt sie als Referenzbeispiel.
• Danach werden Aufgaben mit demselben Muster der AI zur Massenverarbeitung übergeben.
• Bei Aufgaben, die Denken und Urteilsvermögen erfordern, sinkt die erwartbare Effizienz stark.

2. Vor dem Coden unbedingt zuerst einen Plan erstellen

• Nicht sofort Code generieren, sondern zuerst einen Lösungsplan aufschreiben.
• In der Planungsphase sollen alle Unklarheiten und Fragen sichtbar gemacht werden.
• Wenn der Plan nicht zufriedenstellend ist, nicht in die Umsetzungsphase wechseln.
• Die Qualität des Ergebnisses hängt stärker von der Klarheit des Planungsdokuments ab als vom Prompt.

3. Aufgaben in extrem kleine Einheiten zerlegen

• In Einheiten wie eine Datei, eine Komponente oder einige wenige Funktionen anfragen.
• Anfragen wie „gesamtes Refactoring“ oder „idiomatisch verbessern“ haben eine hohe Fehlerrate.
• Die Struktur entwirft der Mensch, die wiederholte Implementierung übernimmt die AI.

4. Keinen Kontext anhäufen, sondern häufig zurücksetzen

• Je länger ein Gespräch wird, desto stärker fallen Regelkonformität und Qualität ab.
• Eine Session sollte nur eine Aufgabe behandeln.
• Wenn sich die Richtung ändert, in einer neuen Session neu beginnen.
• Bei langfristigen Aufgaben den Status in Dokumenten (plan.md usw.) festhalten und erneut einspeisen.

5. Regeldokumente kurz und mechanisch halten

• CLAUDE.md / AGENTS.md sollten innerhalb von 500–1000 Tokens bleiben.
• Statt deklarativer Anweisungen vor allem konkrete und überprüfbare Regeln formulieren.
• Nur das Nötigste zu häufigen Fehlern festhalten.
• Alles andere über Code und automatische Prüfungen erzwingen.

6. Tests, Linter und Builds als Feedback-Loop nutzen

• Statt „mach es gut“ lieber klare Erfolgskriterien vorgeben.
• Als Ziel Tests bestanden, Build erfolgreich und 0 Linter-Fehler setzen.
• Nur mit einem Feedback-Loop kann sich die AI selbstständig annähern.
• Tests, die bestehendes Verhalten absichern, senken die Schwierigkeit von Refactorings erheblich.

7. Nicht während der Ausführung nachbessern, sondern den Plan korrigieren und neu ausführen

• Wenn das Ergebnis nicht gefällt, nicht wiederholt Änderungen am Code anfordern.
• Stattdessen das Planungsdokument anpassen und in einer neuen Session erneut ausführen.
• Wenn die Richtung erst in der Umsetzungsphase geändert wird, bricht die Qualität schnell ein.

8. Stil anhand von Beispielen vermitteln

• Abstrakte Anweisungen wie „guter Code“ haben fast keine Wirkung.
• Before-/After-Beispiele zusammen bereitstellen.
• Gute und schlechte Beispiele klar voneinander trennen.
• Regeln rund um die Beispiele erweitern.

9. Das Verstehen nicht aufgeben und Verantwortungsgrenzen klar ziehen

• Von AI erzeugter Code muss immer von Menschen verstanden und geprüft werden.
• Außer bei Prototypen und risikoarmem Code ist eine Nutzung ohne Review tabu.
• Bei sicherheitskritischem, betrieblichem oder langfristig zu wartendem Code ist Verständnis die Voraussetzung für Qualität.

10. Zuerst prüfen, ob die Aufgabe überhaupt für AI geeignet ist

• Aufgaben ohne eindeutige richtige Antwort und mit starkem ästhetischem oder strukturellem Urteil sind für AI ungeeignet.
• Besonders schwierig sind UI-Refactorings, bei denen sich visuelle Ergebnisse schwer automatisch verifizieren lassen.
• Falls nötig:
  • Schritt 1: mechanische Transformation mit dem Ziel, das Verhalten beizubehalten
  • Schritt 2: Qualitäts-Refactoring durch Menschen

11. Mit der Erwartung „10 % Verbesserung“ starten

• Nicht von Anfang an 10x erwarten.
• Eine Strategie, kleine Verbesserungen zu kumulieren, ist langfristig wirksamer.
• Entscheidend ist, die Maßstäbe für Design und Qualität nicht aufzugeben

[GN⁺]

Hacker-News-Kommentare

• Hier ist Boris aus dem Claude-Code-Team. Ich teile ein paar Tipps.

  1. Dinge, bei denen Claude häufig falsch liegt oder sie nicht versteht, sollte man in CLAUDE.md festhalten. Claude liest diese Datei automatisch.
  2. Den Plan-Modus (zweimal Shift+Tab) aktiv zu nutzen, zuerst einen Plan aufzustellen und dann ausführen zu lassen, kann bei schwierigen Aufgaben 2- bis 3-mal bessere Ergebnisse bringen.
  3. Es ist hilfreich, eine Methode zur Validierung der Arbeit bereitzustellen. In Svelte kann man zum Beispiel den Puppeteer-MCP-Server verwenden, damit die Ergebnisse im Browser geprüft werden.
  4. Als Modell empfehle ich Opus 4.5. Es fühlt sich gegenüber Sonnet 4.5 ganz klar wie ein Upgrade um eine Stufe an.
     Hoffe, das hilft.
  • Ich habe dank des Plan-Modus ebenfalls einen großen Produktivitätsschub erlebt. Aber in der neuesten Version gibt es einen Bug, bei dem der Plan-Modus immer nur auf den ersten Plan der Sitzung verweist, wodurch mein Workflow kaputtgeht. Ich frage mich, ob ich ihn auf ungewöhnliche Weise nutze.
  • Nachdem man Claude während der Arbeit korrigiert hat, ist es sinnvoll, einen Self-Reflection-Prompt auszuführen. Dadurch werden manuell zusammengetragene Inhalte automatisch in CLAUDE.md übernommen.
  • Ich stimme den obigen Ratschlägen zu. Vor allem die Feedback-Schleife in Punkt (3) ist entscheidend. Das Modell muss selbst Änderungen vornehmen und die Ergebnisse überprüfen können. Wenn man es Log-Dateien schreiben lässt oder einen Pseudocode-Plan erstellen lässt, werden auch komplexe Probleme schnell gelöst.
  • Opus 4.5 ist wirklich ein Gamechanger. Beim Refactoring eines älteren React-Projekts hat es mir enorm geholfen. Wenn man den Prompt präzise formuliert und CLAUDE.md gut einrichtet, ist der Effekt groß.
  • CLAUDE.md funktioniert nur etwa 4- bis 5-mal gut, danach vergisst es die Anweisungen. Selbst wenn man etwa sagt, es solle mich „Mr. bcherny“ nennen, vergisst es das schnell wieder.
  • Im Vergleich zu Google Jules fühlte sich Claude Code viel stärker wie ein professioneller Entwickler an. Allerdings hat Claude Code Web keine Projektfunktion, und mir wurde geantwortet, ich solle eine .clinerules-Datei verwenden. Ich würde gern den Unterschied zu CLAUDE.md kennen.
  • Eine nützliche Funktion in CLAUDE.md ist @import. Wenn man vor einen Dateinamen ein @ setzt, kann man ihn zwangsweise in den Kontext aufnehmen. Wenn man das aber zu oft nutzt, wird es ineffizient.

• Wenn man Spracheingabe nutzt, versteht das Modell die Absicht genauer. Ich spreche Prompts mit etwa 500 Wörtern ein. Beim Sprechen fließen die Gedanken natürlicher als beim Tippen.
  Wenn man sagt: „Mach einen Plan und frag nach, wenn du Fragen hast“, dann stellt Claude tatsächlich Fragen. Es ist auch effektiv, Claude anzuweisen, den bisherigen Code-Stil nachzuahmen.

  • Ich habe laboratory.love auch fast vollständig per Sprache gebaut. Per Tastenkürzel nutze ich oft den Satz: „Analysiere vor dem Schreiben von Code das Problem und die Anforderungen und frage bei Unklarheiten nach.“
  • Nur weil jemand schnell spricht, heißt das nicht, dass er gedankenlos spricht. Eher kann es ein Problem sein, mit zu wenig Nachdenken zu sprechen.
  • Mit einer KI zu sprechen, während jemand zuhört, ist etwas seltsam, aber lange Sätze spreche ich ebenfalls ein.
  • Ich würde gern wissen, welchen Spracherkennungsdienst du verwendest.

• Man sollte im Prompt eine Loop-Bedingung aufnehmen. Zum Beispiel: „Wiederhole, bis yarn test erfolgreich durchläuft.“
  Ein LLM ist letztlich ein Agent, der Werkzeuge wiederholt ausführt, also sollte man es auch so behandeln.
  Siehe auch: Prompting the Agent Loop

• Ich empfehle meine nori-profiles-Konfiguration.
  Nach vier Monaten Experimenten hat sich die Leistung von Claude Code spürbar verbessert.
  Verwandter Artikel: Averaging 10 PRs a Day with Claude

  • Mich würde interessieren, worin der Unterschied zu den skills von Claude Code liegt.

• Bei uns im Unternehmen arbeiten wir mit einer großen Golang-Codebasis. Ich habe viele Tools ausprobiert, darunter Cursor, Claude Code und Gemini CLI, aber die meisten werden von der Menge an Code überwältigt.
  aider ließ sich dagegen viel leichter kontrollieren und war genauer. Dateien hinzuzufügen ist zwar manuell, aber dafür ist es fast zu 100 % korrekt.
  Zusammen mit aktuellem Claude Sonnet oder Gemini 2.5 Pro ist es am präzisesten.

  • Der Vorteil von aider ist, dass es kein vollständig agentisches Tool ist. Man verwaltet den Kontext manuell, wodurch keine falschen Dateien geändert werden. Auch bei Token-Ersparnis und Geschwindigkeit ist das ein Vorteil.

• Wenn ich mit Cursor arbeite, lasse ich zuerst beim Refactoring einer Route eine Regeldatei erzeugen. Bei den anderen Routen reicht danach einfach „refactor“.

  • Hab keine Angst vor langen Prompts. Das ist genau Context Engineering. Schon der Gesprächsverlauf selbst macht den Kontext reichhaltiger.
    Man sollte die verbleibende Kontextkapazität immer im Blick behalten und bei Bedarf frühzeitig den Kontext leeren.

• Wichtig ist die Sichtweise, den Agenten wie ein Teammitglied zu behandeln. Man sollte die jeweiligen Stärken und Schwächen beobachten und die Zusammenarbeit entsprechend anpassen.
  Ich konzentriere die Stärke des Agenten auf verifizierbare Probleme oder experimentellen Code.
  Ich kenne mich mit Svelte nicht gut aus, aber es scheint sinnvoll, ein Rewrite über disposable Tests im TDD-Stil zu steuern.
  Manchmal ist es am besten, den bisherigen falschen Kontext zu verwerfen und in einem neuen Workspace neu zu beginnen.

  • Es wäre schön, wenn du eine Zusammenfassung dieses Textes über „kognitiven Stil und Teamarbeit“ teilen könntest.

• Ich sehe LLMs als Sucher (searcher). Wenn man Fragen klein und konkret hält, wird die Suche einfacher, und je weiter man sich von den Trainingsdaten entfernt, desto höher ist die Fehlerwahrscheinlichkeit.

  1. Projekt in Zed öffnen
  2. Gemini CLI, Qwen code oder Claude verbinden
  3. Um Dateibearbeitung bitten und testen
  4. Wenn es nicht klappt, Grok oder Gemini 3 Chat versuchen
  5. Wenn es immer noch nicht klappt, manuell lösen
     Bei neuen Projekten reicht oft schon ein One-Shot-Prompt.
  • Zu kleine Prompts können jedoch zu Underspecification führen. Sie senken zwar die Rechenkosten, sind aber in Bezug auf die Qualität nachteilig.

• Mein bevorzugtes Claude-Code-Toolset ist superpowers.

  1. Zuerst erkläre ich die Funktion in einer Brainstorming-Session.
  2. Claude schreibt ein Design-Dokument und einen Implementierungsplan und speichert beides auf der Festplatte.
  3. In einem neuen Claude-Fenster wird mit dem Befehl Execute Plan Schritt für Schritt ausgeführt und committet.
  4. Alle drei Schritte lasse ich eine Selbstprüfung durchführen, um die Codequalität zu erhöhen.
     Ich nutze das jetzt seit zwei Wochen und es ist fast nie fehlgeschlagen.

• Meine Prinzipien für AI-Programmierung sind einfach.

  1. One Shot scheitert.
  2. Teile Aufgaben in verifizierbare Einheiten auf.
  3. Halte den Gesamtplan in einer Markdown-Datei fest.
  4. Führe jeden Schritt in einer neuen Sitzung aus, prüfe ihn und committe dann.
     Der Kern ist „Less is more“. Je frischer das Kontextfenster, desto besser, und etwa 500 bis 750 Wörter sind ideal. Jeder Schritt muss überprüfbar sein.

• Bei Java-bezogenen Aufgaben wechselt Claude ständig die Richtung oder macht widersprüchliche Vorschläge. Ich habe das Gefühl, dass ChatGPT deutlich besser ist.

  • Mit konkreteren Anweisungen im Prompt könnte es besser werden.
  • Mich würde interessieren, ob du schon die Claude-Code-Version ausprobiert hast.

• Wenn man „idiomatischen Code“ möchte, muss man zunächst den eigenen Stil sehr genau definieren. Gute und schlechte Beispiele sollte man in kleine Teile aufteilen, in den Plan-Modus von Opus 4.5 geben, einen Plan erstellen lassen und dann ausführen. Wenn es nicht auf Anhieb perfekt ist, überarbeitet man das Planungsdokument und versucht es erneut. Wenn man versucht, es wie einen Junior-Entwickler bis ins Detail anzuleiten, wird es eher ineffizient.

  • Jemand anderes teilte die Erfahrung, dass man „bei den aktuellen Modellen nicht unbedingt jedes Mal eine neue Sitzung beginnen muss“ und dass Inline-Refactoring ebenfalls ausreichend stabil sein kann.