KI ist bequem. Sehr bequem sogar. Du beschreibst ein Problem, bekommst eine Antwort, kopierst vielleicht noch ein Code-Beispiel und bist erst einmal weiter. Gerade beim Einstieg in Java fühlt sich das oft wie eine Abkürzung an. Und ja, manchmal ist es auch eine. Wenn du gerade nicht weisst, wie eine for-Schleife aufgebaut ist, was eine NullPointerException bedeutet oder warum Maven eine Dependency nicht findet, kann dir KI schnell eine erste Richtung geben.

Das Problem beginnt dort, wo diese Richtung zur einzigen Quelle wird.

Programmieren besteht nicht nur daraus, Code zu schreiben. Ein grosser Teil der Arbeit besteht darin, Fehlermeldungen zu lesen, Zusammenhänge zu verstehen, Begriffe einzuordnen und gezielt nach Informationen zu suchen. Genau diese Fähigkeit geht schnell verloren, wenn jede Frage direkt an eine KI gestellt wird. Nicht, weil KI grundsätzlich schlecht ist. Sondern weil sie dir oft das Denken zwischen Problem und Lösung abnimmt.

Früher war der Weg etwas unbequemer. Du hattest eine Fehlermeldung, hast sie kopiert, bei Google gesucht, drei Treffer geöffnet, eine Stack Overflow Diskussion gelesen, danach in die offizielle Dokumentation geschaut und irgendwann verstanden, was wirklich los ist. Das war nicht immer schön und manchmal war es nervig. Aber genau dabei hast du gelernt, wie Probleme aussehen, wie andere Entwickler denken und welche Quellen belastbar sind.

Heute bekommst du oft sofort eine glatt formulierte Antwort. Sie klingt plausibel, ist sauber strukturiert und manchmal trotzdem falsch. Das ist für Anfänger besonders gefährlich, weil falsche Antworten nicht unbedingt falsch aussehen. Eine KI kann dir selbstbewusst erklären, warum eine Lösung richtig ist, obwohl sie in deinem Projekt mit deiner Java-Version, deinem WildFly, deiner Maven-Konfiguration oder deinem konkreten Fehlerbild nicht passt.

 

Warum gutes Suchen eine Entwicklerfähigkeit ist

Gutes Suchen ist keine Nebensache. Es ist eine Kernfähigkeit. Du brauchst sie, wenn dein Build fehlschlägt, wenn IntelliJ dir einen roten Fehler zeigt, wenn eine REST-Schnittstelle nicht antwortet oder wenn eine Exception im Log steht, die du noch nie gesehen hast. In solchen Momenten hilft es wenig, nur nach einer fertigen Lösung zu fragen. Du musst lernen, das Problem so zu zerlegen, dass du überhaupt sinnvoll suchen kannst.

Nimm eine typische Fehlermeldung aus Java:

Exception in thread "main" java.lang.NullPointerException

Damit allein kommst du nicht weit. Diese Meldung sagt nur, dass irgendwo auf null zugegriffen wurde. Interessant wird es erst mit Kontext. Welche Klasse? Welche Zeile? Welche Variable? Passiert es beim Start der Anwendung, beim Klick auf einen Button oder beim Aufruf einer Methode? Ein guter Suchbegriff ist deshalb selten nur die komplette Fehlermeldung. Oft ist er eine Mischung aus Fehlertyp, Framework, Version und konkretem Verhalten.

Statt einfach nach der gesamten Log-Ausgabe zu suchen, kannst du gezielter suchen nach java NullPointerException object is null, wildfly deployment failed maven dependency oder intellij cannot resolve symbol maven reload. Das wirkt banal, macht aber einen grossen Unterschied. Du lernst dabei, die wichtigen Teile aus dem Rauschen herauszufiltern.

Genau das kann KI verdecken. Sie gibt dir direkt eine mögliche Ursache. Dadurch musst du weniger genau hinschauen. Auf Dauer gewöhnst du dir ab, Fehlermeldungen sauber zu lesen. Du erkennst weniger Muster. Du fragst schneller nach einer Lösung, statt zuerst zu prüfen, was dein Programm eigentlich tut.

Ein Senior Developer sucht nicht besser, weil er jede Antwort kennt. Er sucht besser, weil er schneller erkennt, wonach er suchen muss. Er weiss, wann eine Fehlermeldung wichtig ist, wann ein Stacktrace nur Folgefehler zeigt, wann die offizielle Doku reicht und wann ein alter Forenbeitrag wahrscheinlich nicht mehr passt.

 

KI-Antworten sind nicht dasselbe wie Quellen

Die Suche im Internet hat sich verändert. Google zeigt nicht mehr nur Trefferlisten. Mit AI Overviews und ähnlichen Funktionen erscheinen KI-generierte Zusammenfassungen direkt über oder zwischen den klassischen Suchergebnissen. Google hat AI Overviews 2024 zuerst breit in den USA ausgerollt und danach auf weitere Länder und Sprachen erweitert. Aus Sicht der Nutzer mag das bequem sein, weil die Antwort sofort sichtbar ist. Aus Sicht des Lernens ist es problematisch, weil die eigentliche Quelle weiter nach hinten rückt.

Eine KI-Antwort ist eine Zusammenfassung. Sie kann auf guten Quellen basieren, sie kann Quellen vermischen und sie kann Details auslassen. Gerade technische Details sind aber oft entscheidend. Bei Java macht es einen Unterschied, ob du mit Java 8, 17 oder 21 arbeitest. Bei Jakarta EE macht es einen Unterschied, ob du noch javax.* oder schon jakarta.* verwendest. Bei WildFly macht es einen Unterschied, welche Server-Version läuft. Bei Maven macht es einen Unterschied, ob ein Problem aus deiner pom.xml, aus dem lokalen Repository oder aus einer transitive Dependency kommt.

Wenn du nur die KI-Zusammenfassung liest, bekommst du häufig eine glatte Antwort ohne die Details, die eigentlich wichtig wären. Du siehst nicht, ob die Information aus der offiziellen Dokumentation stammt, aus einem alten Blogartikel, aus einer Diskussion mit veraltetem Code oder aus mehreren Quellen, die nicht zusammenpassen.

Bei Java solltest du dir angewöhnen, echte Quellen bewusst zu öffnen. Dazu gehören die offizielle Java-Dokumentation, die Dokumentation deines Frameworks, die Maven-Dokumentation, die WildFly-Dokumentation, seriöse Issue-Tracker, Release Notes und gut nachvollziehbare Diskussionen auf Plattformen wie Stack Overflow. Nicht jeder Treffer ist gleich gut. Ein Treffer von 2012 kann hilfreich sein, aber bei modernen Java-Versionen auch komplett in die falsche Richtung führen.

 

Wie du heute sinnvoll recherchierst

Sinnvolle Recherche beginnt nicht mit der Suchmaschine, sondern mit deiner Beobachtung. Was ist passiert? Was hast du erwartet? Was ist stattdessen passiert? Welche Änderung hast du zuletzt gemacht? Welche Fehlermeldung steht wirklich im Log? Diese Fragen verhindern, dass du planlos suchst.

Wenn dein Code nicht kompiliert, suchst du anders als bei einem Laufzeitfehler. Wenn Maven keine Dependency findet, ist Google nicht immer der erste Ort. Dann prüfst du zuerst die pom.xml, danach dein Maven-Fenster in IntelliJ, danach das lokale Repository und dann Maven Central. Wenn WildFly beim Deployment scheitert, liest du den Server-Log von oben nach unten und suchst nicht nur nach der letzten roten Zeile. Die letzte Fehlermeldung ist oft nur das Ergebnis eines Problems, das vorher im Log steht.

Gute Suchanfragen sind konkret, aber nicht zu lang. Du musst nicht deinen kompletten Stacktrace in Google werfen. Oft reicht eine präzise Kombination aus den wichtigsten Begriffen. Zum Beispiel WildFly deployment failed ClassNotFoundException, Maven dependency not found local repository, Java stream filter null values oder IntelliJ Maven reimport dependencies.

Hilfreich sind auch Suchoperatoren. Mit site: kannst du gezielt auf einer bestimmten Webseite suchen, zum Beispiel in der offiziellen Dokumentation oder auf Stack Overflow. Mit Anführungszeichen suchst du nach einer exakten Formulierung. Mit einem Minus kannst du Begriffe ausschliessen, die dich ständig auf falsche Treffer bringen. Google selbst dokumentiert solche Operatoren, und sie sind immer noch nützlich, auch wenn die Suche heute stärker von KI-Zusammenfassungen geprägt ist.

Du kannst auch bewusst andere Wege nutzen. Manchmal ist die Suche direkt in der Dokumentation besser als Google. Manchmal hilft GitHub, weil du dort echte Projekte findest, die ein ähnliches Problem gelöst haben. Manchmal ist die Issue-Suche eines Frameworks sinnvoller als ein Blogartikel. Manchmal bringt dich Maven Central schneller zur richtigen Version als irgendein Tutorial. Und manchmal ist eine lokale Suche in deinem eigenen Projekt der wichtigste Schritt, weil der Fehler gar nicht im Internet liegt, sondern in deinem Code.

Wichtig ist dabei: Suche nicht nur nach Lösungen. Suche nach Begriffen. Wenn du nicht verstehst, was eine Exception bedeutet, recherchiere zuerst die Exception. Wenn du nicht verstehst, was eine Annotation macht, lies nach, wofür sie gedacht ist. Wenn du nicht verstehst, warum eine Dependency gebraucht wird, schau dir an, wer sie einbindet und wofür sie verwendet wird.

KI kann dich dabei unterstützen. Du kannst sie bitten, eine Fehlermeldung zu erklären, Suchbegriffe vorzuschlagen oder Unterschiede zwischen zwei Begriffen zu beschreiben. Aber die eigentliche Prüfung bleibt bei dir. Öffne die Quellen. Vergleiche Aussagen. Achte auf Versionen. Teste kleine Änderungen bewusst. Und schreibe dir auf, was du herausgefunden hast.

 

Fazit

Eine Generation, die das Programmieren mit KI lernt, steht nicht automatisch schlechter da. Sie hat starke Werkzeuge, schnellen Zugriff auf Erklärungen und kann viele Einstiegshürden leichter überwinden. Aber sie läuft Gefahr, eine grundlegende Fähigkeit zu überspringen: selbstständig Informationen finden, prüfen und einordnen.

Beim Programmieren reicht es nicht, eine Antwort zu bekommen. Du musst verstehen, warum sie passt. Du musst erkennen, wann sie nicht passt. Und du musst lernen, wo du nachsehen kannst, wenn die Antwort zu glatt klingt.

Gutes Suchen ist langsam am Anfang und schnell mit Erfahrung. Es trainiert dein technisches Denken. Es zwingt dich, Fehler genauer zu lesen. Es zeigt dir, welche Quellen zuverlässig sind. Und es macht dich unabhängiger von Tools, die manchmal richtig liegen und manchmal nur überzeugend klingen.

KI darf Teil deines Werkzeugkastens sein. Aber sie sollte nicht dein einziger Weg zur Lösung werden. Wer programmieren lernt, sollte auch suchen lernen. Nicht aus Nostalgie, sondern weil gute Recherche direkt zu besserem Code führt.

Du kannst dich bei deiner Recherche auch bewusst gegen KI entscheiden. Suchmaschienen wie duckduckgo.com, startpage.com oder qwant.com arbeiten ähnlich und zum aktuellen Zeitpunkt ohne KI Antworten.