Warum die Grundlagen das Wichtigste sind

Du kennst das bestimmt: Die Übungsaufgabe steht, die Motivation hält sich in Grenzen, und die KI liefert dir in drei Sekunden eine Lösung, die sogar auf Anhieb kompiliert. Haken dran, nächste Aufgabe. Das fühlt sich effizient an doch genau da liegt das Problem. Übungsaufgaben gibt es nicht, damit am Ende ein lauffähiges Programm herauskommt. Das Programm ist tatsächlich nur das Abfallprodukt. Das eigentliche Produkt bist du, genauer gesagt das, was sich beim Lösen in deinem Kopf verändert.

Stell dir jemanden vor, der im Fitnessstudio Hanteln hebt. Die Hantel von unten nach oben zu bewegen, hat für sich genommen keinen besonderen Wert. Am Ende liegt sie schließlich wieder genau da, wo sie vorher lag. Der Sinn liegt in dem, was dabei mit deinem Körper passiert. Würdest du einen Roboter die Hanteln für dich heben lassen, hättest du ein beeindruckendes Trainingsprotokoll, aber keinen einzigen Muskel mehr als vorher. Mit Übungsaufgaben ist es genauso. Entscheidend ist nicht die fertige Lösung, sondern der Weg dorthin. Du rätselst, probierst etwas aus, scheiterst und verstehst irgendwann, warum etwas funktioniert. Genau dabei lernst du. Wenn du diesen Teil überspringst, sammelst du fertige Programme und wunderst dich irgendwann, warum du bei der nächsten Aufgabe wieder völlig planlos bist.

Verstehen skaliert, Kopieren nicht

Bei kleinen Aufgaben fällt es kaum auf, wenn du dir helfen lässt, ohne wirklich zu verstehen, was du da machst. Das Problem zeigt sich später, vorzugsweise dann, wenn du es überhaupt nicht gebrauchen kannst. Sobald du in einem echten Projekt arbeitest, beispielsweise in einer gewachsenen JavaEE-Anwendung auf einem WildFly, die über Maven gebaut wird, bekommst du Fehlermeldungen, für die es keine fertige Musterlösung gibt. Dann musst du einen Stacktrace lesen, Vermutungen aufstellen und systematisch eingrenzen, wo das Problem sitzt. Die KI kannst du natürlich fragen. Aber wenn du selbst nicht ungefähr weißt, was schiefgelaufen sein könnte, wird das Gespräch schnell zum Ratespiel. Und der Compiler ist bekanntlich kein besonders geduldiger Gesprächspartner.

Dazu kommt, dass auch eine KI nur so gut ist wie die Frage, die du ihr stellst. Wer das Problem nicht versteht, kann es kaum präzise beschreiben und die Antwort anschließend noch schlechter beurteilen. Dabei liefert KI durchaus Code, der hervorragend aussieht und trotzdem Unsinn macht. Manchmal sogar mit so überzeugenden Kommentaren, dass man fast ein schlechtes Gewissen bekommt, wenn man daran zweifelt. Wer die Grundlagen nicht kennt, übernimmt diesen Code einfach. Du wirst dann irgendwann zu einer Art Paketdienst für fremde Lösungen: Du transportierst Code von der KI in dein Projekt und hoffst, dass unterwegs nichts kaputtgeht. Spätestens beim nächsten Code-Review kann das unangenehm werden. Verstehen funktioniert dagegen wie Zinseszins. Jedes Konzept, das du wirklich begriffen hast, macht das nächste leichter. Wer Variablen, Typen und Kontrollfluss beherrscht, versteht Methoden schneller. Darauf bauen Klassen, Streams und später ganze Frameworks auf.

Kleine Details, große Wirkung

Gerade die vermeintlichen Kleinigkeiten kosten später oft Stunden. Ein Klassiker ist der Unterschied zwischen i++ und ++i. Beide erhöhen den Wert um eins, liefern aber unterschiedliche Ergebnisse zurück. Bei i++ bekommst du den alten Wert, bei ++i den neuen.

int i = 5;
int a = i++; // a ist 5, i ist danach 6
int b = ++i; // i ist 7, b ist 7

Im Aktualisierungsteil einer gewöhnlichen for-Schleife spielt das kaum eine Rolle, weil der Rückgabewert nicht verwendet wird. Sobald du ihn aber weiterverarbeitest, sieht die Sache anders aus. Ähnlich ist es beim Vergleich von Strings. == prüft, ob zwei Referenzen auf dasselbe Objekt zeigen, während equals den Inhalt vergleicht. Oder die Ganzzahldivision: 1 / 2 ergibt in Java 0, nicht 0.5. Java diskutiert darüber auch nicht mit dir. Solche Details sind keine akademischen Spitzfindigkeiten, sondern können in Preisberechnungen oder Geschäftslogik echte Probleme verursachen. Entscheidend ist nicht, dass du jede Besonderheit auswendig kennst. Du musst verstehen, dass Java nach festen Regeln arbeitet und sich das Verhalten daraus ableiten lässt. Dann hörst du auf zu raten und fängst an, systematisch zu denken. Im Fitnessstudio wäre das der Unterschied zwischen jemandem, der wild mit Gewichten herumwedelt, und jemandem, der weiß, welche Bewegung welchen Muskel trainiert.

Objektorientierung und Clean Code sind Denkweisen

Bei der Objektorientierung entsteht schnell der Eindruck, es ginge vor allem um Theorie. Klassen, Kapselung, Vererbung, Interfaces: Warum nicht einfach alles in eine lange Methode schreiben, wenn es doch funktioniert? Weil das nur so lange gut geht, wie du das gesamte Programm im Kopf behalten kannst. Und bei einer Methode mit 400 Zeilen, sechs verschachtelten Bedingungen und Variablen namens tmp1, tmp2 und x wird das irgendwann schwierig. Objektorientierung hilft dir, Komplexität in überschaubare Teile zu zerlegen. Kapselung hält Regeln an einer definierten Stelle, Interfaces ermöglichen austauschbare Implementierungen. Wer die Ideen dahinter verstanden hat, erkennt ihren Nutzen spätestens dann, wenn ein Projekt wächst und mehrere Entwickler daran arbeiten.

Mit Clean Code ist es ähnlich. Dahinter steckt eine einfache Erkenntnis: Code wird häufiger gelesen als geschrieben. Du schreibst eine Methode einmal, aber du und deine Kollegen lesen sie möglicherweise noch fünfzig Mal. Vergleiche diese beiden Varianten:

double calc(double a, int b) {
    return a - a * b / 100;
}

double berechnePreisMitRabatt(double preis, int rabattInProzent) {
    return preis - preis * rabattInProzent / 100;
}

Die Logik ist identisch, aber bei der zweiten Variante erkennst du sofort, was die Methode tun soll. Bei der ersten darfst du Detektiv spielen. Und niemand möchte montagmorgens um acht einen Kriminalfall lösen, nur um eine Rabattberechnung anzupassen. Gute Namen, überschaubare Methoden und klare Verantwortlichkeiten sind keine reine Schönheitspflege. Sie sorgen dafür, dass du Code später noch verstehen und verändern kannst. Wer gelernt hat, sauber zu denken, stellt übrigens auch bessere Fragen, egal ob bei Kollegen oder einer KI.

Fazit

Du musst KI nicht meiden, ganz im Gegenteil. Als Erklärhilfe, Sparringspartner oder zur Überprüfung deiner eigenen Lösung ist sie ein hervorragendes Werkzeug. Entscheidend ist die Reihenfolge: Erst du, dann die Hilfe. Probiere eine Aufgabe zunächst selbst, auch wenn es holprig wird, du dreimal am Compiler scheiterst und IntelliJ den halben Bildschirm rot markiert. Überlege, warum etwas nicht funktioniert, stelle Vermutungen auf und überprüfe sie. Wenn du wirklich feststeckst, lass dir einen Hinweis geben, statt sofort die vollständige Lösung zu übernehmen. Die Grundlagen sind schließlich nicht das langweilige Pflichtprogramm vor dem eigentlichen Programmieren. Sie sind das Fundament, auf dem alles Weitere aufbaut.

Und damit sind wir wieder im Fitnessstudio. Du kannst natürlich jemanden bitten, deine Hanteln zu heben, danebenstehen und stolz die Wiederholungen zählen. Auf dem Papier sieht das großartig aus, nur stärker wirst du dadurch nicht. Genauso wenig wirst du zum besseren Entwickler, indem du möglichst viele KI-Lösungen in deine IDE kopierst. Die KI darf dir die richtige Technik zeigen, Fehler erklären und dir helfen, wenn du nicht weiterkommst. Aber die eigentlichen Wiederholungen solltest du selbst machen. Denn irgendwann stehst du vor einem Problem, für das es keine fertige Lösung gibt. Dann zählt nicht, wie viele Aufgaben du abgehakt hast, sondern was du dabei tatsächlich gelernt hast.

Also heb deine Hanteln selbst! Die KI darf danebenstehen und Tipps geben, aber schwitzen musst du schon noch selbst.