KI im Programmieren: Mein Ping-Pong-Prinzip
Die Antwort von Claude hat mich letzte Woche wirklich zum Nachdenken gebracht: „Ich kann dir den Code schreiben, aber verstehst du auch, was er macht?" Diese simple Frage trifft den Kern einer Herausforderung, mit der viele beim Programmieren lernen kämpfen – besonders jetzt, wo KI-Tools uns in Sekunden funktionierenden Code liefern können.
Warum sich Programmieren mit KI manchmal falsch anfühlt
Der Cursor blinkt.
Du hast ein Problem.
Früher hättest du Stack Overflow durchforstet, Dokumentationen gelesen, vielleicht ein Tutorial angeschaut.
Heute?
Ein Prompt in ChatGPT oder Claude, und drei Sekunden später: 47 Zeilen perfekt formatierter Code (“meistens😂”).
Genial, oder?
Und gleichzeitig fühlt es sich irgendwie... leer an. Als hättest du beim Marathon ein Taxi genommen.
Dieses Gefühl ist real und berechtigt. Unser Gehirn ist darauf programmiert, Kompetenz durch Anstrengung zu messen. Wenn die Lösung zu leicht kommt, zweifeln wir: „Habe ich wirklich etwas geleistet? Bin ich überhaupt ein richtiger Entwickler?"
Das Imposter-Syndrom bekommt neue Nahrung: „Die KI kann das besser als ich." Stimmt technisch gesehen sogar – sie tippt schneller, kennt mehr Syntax, macht weniger Tippfehler. Aber sie versteht dein Problem nicht wirklich. Sie weiß nicht, warum du diese Funktion brauchst, welche Constraints dein Projekt hat, oder was in drei Monaten passiert, wenn sich die Anforderungen ändern.
Die Angst, ersetzbar zu sein, ist nachvollziehbar. Aber sie basiert auf einem Missverständnis: KI ersetzt nicht Entwickler – sie verschiebt nur, welche Skills wichtig sind. Vom reinen Code-Tipper zum Problem-Löser und Architekten. Vom Syntax-Auswendiglerner zum kritischen Reviewer.
Der Schlüssel liegt darin, KI nicht als Maßstab für deinen Selbstwert zu nehmen, sondern als Werkzeug zu begreifen. Ein Zimmermann misst seinen Wert auch nicht daran, ob seine Säge gerader schneidet als er selbst – sondern daran, was er damit baut.
Bevor wir tiefer einsteigen, möchte ich etwas offen sagen: Das Imposter-Syndrom begleitet mich ziemlich oft. Ich komme ursprünglich aus dem Handwerk und habe keine formale Ausbildung im IT-Bereich. Alles, was ich heute kann, habe ich mir selbst beigebracht – genau in der Zeit, als KI gerade ihren Durchbruch hatte.
Am Anfang habe ich über Videos und Online-Kurse gelernt und wirklich jede einzelne Zeile Code selbst geschrieben. Ich wollte verstehen, was ich tue – nicht nur kopieren.
Mit der Zeit wurde KI jedoch immer leistungsfähiger. Ich habe begonnen, mehr Aufgaben auszulagern, um schneller voranzukommen. Das Problem dabei: Ich habe gemerkt, dass ich dadurch weniger gelernt habe. Ich war zwar produktiver, aber mein eigenes Verständnis ist nicht im gleichen Maß gewachsen.
Deshalb musste ich für mich ein System entwickeln – eines, das es mir ermöglicht, nach meinem Hauptjob kontinuierlich Fortschritte im Code zu machen und gleichzeitig fachlich besser zu werden. Ein System, das Produktivität und echtes Lernen miteinander verbindet.
OK und jetz gehts rein 🚀
Hier kommt der Perspektivwechsel, der alles ändert: Du bist nicht der Code-Schreiber, der von KI überholt wird. Du bist der Dirigent eines Orchesters, in dem KI ein (sehr fähiges) Instrument spielt.
Wie ich bereits in meinem Artikel über KI in der Webentwicklung – Bedrohung oder Chance für Entwickler? erklärt habe, liegt die wahre Kompetenz nicht mehr im Auswendiglernen von Syntax, sondern im Verstehen von Zusammenhängen und im strategischen Einsatz der richtigen Tools.
Ein Orchestrator denkt in Systemen, nicht in Zeilen:
Was ist das eigentliche Problem? Nicht „Ich brauche eine Funktion", sondern „Nutzer sollen ihre Daten exportieren können, ohne dass der Server abstürzt."
Welche Constraints gibt es? Performance? Sicherheit? Kompatibilität? Budget für API-Calls?
Wie fügt sich die Lösung ins Gesamtsystem? Wird der Code wartbar sein? Versteht ihn mein Team in sechs Monaten noch?
Welche Qualitätskriterien gelten? Tests? Error Handling? Logging?
Diese Fragen kann die KI nicht für dich beantworten. Sie braucht dich, um zu wissen, in welche Richtung sie spielen soll.
Der Vergleich mit einem Senior Developer hilft: Du würdest einem Senior auch nicht blind vertrauen. Du würdest seine Vorschläge hinterfragen, Alternativen diskutieren, seine Entscheidungen verstehen wollen. Genau so solltest du mit KI arbeiten.
Die Zusammenarbeit funktioniert am besten, wenn du klare Rollen definierst:
Du übernimmst: Problemdefinition, Architekturentscheidungen, Qualitätskontrolle, finale Verantwortung.
KI übernimmt: Boilerplate-Code, Syntax-Details, erste Implementierungsvorschläge, Erklärungen komplexer Konzepte.
Diese Arbeitsteilung ist nicht Schwäche – sie ist smart. 🎯
Die goldene Regel: Nichts mergen, was du nicht erklären kannst
Hier wird es konkret: Die wichtigste Regel im Umgang mit KI-generiertem Code ist radikal simpel und radikal schwer durchzuhalten.
Merge keinen Code, den du nicht Zeile für Zeile erklären kannst.
Nicht „ungefähr verstehe". Nicht „wird schon stimmen". Sondern wirklich verstehen: Was macht diese Zeile? Warum ist sie nötig? Welche Alternativen gäbe es? Was passiert, wenn hier ein Edge Case auftritt?
Das fühlt sich am Anfang langsam an. Unbequem. Die KI hat dir doch schon die Lösung gegeben – warum jetzt noch alles durchkauen?
Weil genau hier das Lernen passiert.
Lass dir den Code erklären. Nicht nur „was macht er", sondern „warum so und nicht anders". Frag nach dem Datenfluss, nach möglichen Problemen, nach Best Practices. Moderne KI-Tools sind erstaunlich gute Tutoren – wenn du die richtigen Fragen stellst.
Stelle Rückfragen. „Warum verwendest du hier async/await statt Promises?" „Gibt es eine performantere Lösung?" „Was sind die Trade-offs?"
Baue Mini-Versionen nach. Nimm eine komplexe Funktion und implementiere eine vereinfachte Version selbst, ohne KI. Dann vergleiche: Was hast du anders gemacht? Was ist besser? Was schlechter?
Führe ein Lernlog. Notiere neue Konzepte, die dir begegnen. „Heute gelernt: Debouncing bei Input-Feldern verhindert unnötige API-Calls." Diese Notizen sind Gold wert.
Der Prozess ist nicht „KI generiert, du kopierst". Sondern: „KI schlägt vor, du verstehst, du entscheidest, du verantwortest."
Das ist der Unterschied zwischen einem Copy-Paste-Developer und einem Entwickler, der KI als Lernbeschleuniger nutzt.
Ping-Pong statt Copy-Paste: Ein gesunder Workflow
Der Workflow macht den Unterschied zwischen „KI macht alles" und „Ich entwickle mit KI-Unterstützung". Hier ein Ansatz, der für viele gut funktioniert:
Phase 1: Planung (du führst)
Bevor ein Prompt geschrieben wird, kläre:
- Was genau soll das Feature können?
- Welche Eingaben, welche Ausgaben?
- Welche Randbedingungen gibt es?
- Wie testest du, ob es funktioniert?
Schreibe das auf. In natürlicher Sprache, als wäre es ein Briefing an einen Kollegen.
Phase 2: Erste Implementierung (KI schlägt vor)
Jetzt kommt die KI ins Spiel. Aber nicht mit „Schreib mir eine Login-Funktion", sondern mit deinem durchdachten Briefing.
„Ich brauche eine Login-Funktion für eine Express-API. Sie soll Email und Passwort entgegennehmen, gegen eine PostgreSQL-Datenbank prüfen (mit bcrypt), bei Erfolg ein JWT zurückgeben (mit 24h Gültigkeit), und bei Fehlern entsprechende HTTP-Status-Codes verwenden. Schreibe auch einen Unit-Test dafür."
Siehst du den Unterschied? Du gibst Kontext, Constraints, Qualitätskriterien. Die KI kann jetzt eine Lösung vorschlagen, die wirklich passt.
Phase 3: Review und Verstehen (du prüfst)
Der Code ist da. Jetzt beginnt deine Arbeit:
- Lies ihn komplett durch
- Markiere alles, was du nicht verstehst
- Lass dir diese Teile erklären
- Prüfe auf Sicherheitslücken (Input Validation? SQL Injection?)
- Teste Edge Cases (leere Strings? Null-Werte? Sonderzeichen?)
Wenn etwas unklar bleibt: Nicht weitermachen. Fragen.
Phase 4: Iteration (Ping-Pong)
Jetzt wird's interessant. Du findest Probleme oder hast Verbesserungsideen:
„Der Error-Handling-Code ist zu generisch. Ich möchte spezifische Fehlermeldungen für ‚Email nicht gefunden' vs. ‚Passwort falsch' – aber ohne Angreifern zu verraten, welche Emails existieren."
Die KI schlägt eine Lösung vor. Du prüfst wieder. Vielleicht noch eine Runde:
„Kannst du den Code so refactoren, dass die Datenbanklogik in einem separaten Service liegt? Ich möchte später zwischen PostgreSQL und MongoDB wechseln können."
Dieser Ping-Pong-Prozess – kleine Schritte, schnelle Feedbackschleifen – ist der Sweet Spot. Du lernst durch jede Iteration, behältst die Kontrolle, aber sparst Zeit bei repetitiven Aufgaben.
Review und Verantwortung: Deine Aufgabe bleibt deine Aufgabe
Hier wird's ernst: KI-generierter Code kann Bugs haben. Er kann Sicherheitslücken enthalten. Er kann ineffizient sein. Und manchmal – das nennt man Halluzination – erfindet die KI einfach Funktionen, die gar nicht existieren.
Die Verantwortung dafür trägst am Ende du. Nicht die KI. Nicht der Tool-Anbieter. Du.
Das klingt hart, ist aber eigentlich befreiend: Es bedeutet, dass deine Rolle als Entwickler nicht verschwindet, sondern sich verlagert. Vom Code-Schreiber zum Code-Reviewer und Qualitätswächter.
Korrektheit prüfen: Funktioniert der Code wie erwartet? Teste nicht nur den Happy Path, sondern auch Edge Cases. Was passiert bei leeren Inputs? Bei sehr großen Zahlen? Bei unerwarteten Datentypen?
Lesbarkeit sicherstellen: Wird ein anderer Entwickler (oder du in drei Monaten) den Code verstehen? Sind Variablennamen aussagekräftig? Ist die Logik nachvollziehbar?
Security-Basics checken: Input Validation? Keine hardcodierten Secrets? Dependencies aktuell und ohne bekannte Vulnerabilities? XSS-Schutz? CSRF-Schutz bei Forms?
Performance im Blick: Macht der Code unnötige Datenbankabfragen? Gibt es N+1-Probleme? Werden große Datenmengen effizient verarbeitet?
Testing nicht vergessen: KI kann Tests vorschlagen, aber du musst entscheiden, ob sie sinnvoll sind. Decken sie die wichtigen Szenarien ab? Oder testen sie nur, dass 1+1=2 ist?
Ein einfacher Review-Workflow hilft:
1. Code durchlesen (verstehe ich jeden Teil?) 2. Lokal ausführen (funktioniert es?) 3. Tests schreiben/prüfen (sind Szenarien abgedeckt?) 4. Security-Check (wo könnten Probleme entstehen?) 5. Dokumentation (warum diese Lösung?)
Punkt 5 wird oft vergessen, ist aber Gold wert: Dokumentiere nicht was der Code macht (das sieht man), sondern warum du dich für diese Lösung entschieden hast. Welche Alternativen gab es? Welche Trade-offs hast du gemacht?
Diese Notizen helfen dir später – und jedem, der den Code anfasst.
Skills, die jetzt wirklich zählen
Die Frage „Was muss ich noch lernen, wenn KI Code schreiben kann?" ist berechtigt. Die Antwort überrascht vielleicht: Mehr als je zuvor – nur andere Dinge.
Problemlösung und Abstraktion: Die Fähigkeit, ein vages Business-Problem in technische Requirements zu übersetzen, wird wichtiger. „Kunden beschweren sich über langsame Ladezeiten" muss zu „Wir brauchen Lazy Loading für Bilder, Code-Splitting für JS und Caching-Strategien für API-Calls" werden.
Architektur und System-Design: Wie baue ich ein System, das skaliert? Wie trenne ich Concerns sauber? Welche Design Patterns passen? KI kann dir helfen, Patterns zu implementieren – aber du musst wissen, welches passt.
Kommunikation: Prompting ist im Kern Kommunikation. Je klarer du Anforderungen formulieren kannst, desto besser die Ergebnisse. Diese Fähigkeit hilft dir auch im Team, bei Kunden, in Code-Reviews.
Debugging und Fehlersuche: Wenn etwas nicht funktioniert, musst du systematisch eingrenzen können: Liegt's am Frontend? Backend? Datenbank? Network? KI kann Vorschläge machen, aber du musst den Prozess steuern.
Domain-Wissen: Je besser du die fachliche Domäne verstehst (E-Commerce, Fintech, Gesundheitswesen...), desto bessere Lösungen kannst du bauen. Dieses Wissen hat keine KI.
Mehr Details dazu findest du in meinem Beitrag zu 7 Strategien, um im KI-Zeitalter fokussiert zu bleiben & nicht den Anschluss zu verlieren, wo ich auch auf mentale Routinen und nachhaltiges Lernen eingehe.
Soft Skills: Code-Reviews geben, Feedback annehmen, im Team arbeiten, Prioritäten setzen – all das wird wichtiger, nicht unwichtiger.
Der Skill-Stack verschiebt sich von „Syntax auswendig können" zu „Probleme verstehen und Lösungen orchestrieren". Das ist eigentlich eine gute Nachricht: Die interessanten Teile der Entwicklung bleiben bei dir. 💡
Ein praktischer Tipp für Portfolio-Projekte: Baue bewusst Projekte, bei denen du KI als Beschleuniger nutzt, aber das Lernen im Fokus behältst. Dokumentiere deinen Prozess: Was hast du die KI machen lassen? Wo hast du selbst gedacht? Welche Entscheidungen hast du getroffen?
Das zeigt potenziellen Arbeitgebern oder Kunden nicht nur, dass du coden kannst – sondern dass du verstehst, wie moderne Entwicklung funktioniert.
Fazit
Programmieren lernen mit KI fühlt sich manchmal an wie Fahrradfahren mit Stützrädern: Praktisch, aber irgendwie „nicht echt". Die gute Nachricht: Du musst nicht zwischen „alles selbst machen" und „alles von KI machen lassen" wählen.
Der Schlüssel liegt im Orchestrator-Mindset: Du führst, KI unterstützt. Du definierst Ziele und Qualität, KI liefert Vorschläge und Erklärungen. Der Ping-Pong-Workflow – kleine Schritte, schnelles Feedback, ständiges Hinterfragen – macht dich schneller besser, ohne dass du die Kontrolle verlierst.
Die goldene Regel bleibt: Merge nichts, was du nicht erklären kannst. Nicht weil du dich selbst quälen sollst, sondern weil genau hier das Lernen passiert. Jede Zeile Code, die du wirklich verstehst, baut deine Kompetenz auf – auch wenn eine KI sie geschrieben hat.
Die Skills, die jetzt zählen, sind vielleicht sogar spannender als früher: Problemlösung statt Syntax-Memorieren. Architektur statt Boilerplate. Kommunikation statt Copy-Paste.
Und mental? Gib dir selbst die Erlaubnis, KI als Werkzeug zu nutzen, ohne dich dadurch weniger kompetent zu fühlen. Ein Tischler ist nicht weniger Handwerker, weil er eine Oberfräse statt eines Stechbeitels nutzt. 🛠️
Bei BlackForest-WebCraft nutze ich genau diese Prinzipien, wenn ich Websites für Kunden aus dem Schwarzwald entwickle: KI beschleunigt repetitive Aufgaben, aber die Architektur, das Design-Thinking und die Qualitätskontrolle bleiben menschlich. Das Ergebnis: Schnellere Projekte ohne Qualitätsverlust.
Falls du selbst eine professionelle Website brauchst oder Fragen zum Thema Webentwicklung hast – ich freue mich auf ein unverbindliches Gespräch.
Demfall, have a nice day und mach dich nicht verrückt 😉
