Sprachmodelle und Java-Code

Sprachmodelle und Java-Code

0:00 Über künstliche Intelligenz in der Softwareentwicklung ist inzwischen viel gesagt worden — meistens allgemein und selten sprachbezogen. Genau da setzt dieses Modul an. Denn ein Sprachmodell verhält sich bei Java anders als bei Python oder JavaScript, und die Gründe dafür sind sehr konkret: die Trainingsdaten, die Bauzeiten, die Größe typischer Codebasen.

0:20 Wer diese Eigenheiten kennt, arbeitet nicht nur sicherer, sondern auch schneller. Wer sie nicht kennt, wundert sich, warum das Werkzeug bei Kollegen wunderbar funktioniert und im eigenen Projekt seltsam altmodische Vorschläge macht.

Sprachmodelle und Java-Code

0:33 Dieses Modul ist der Grund, warum ein Java-Seminar zu diesem Thema anders aussieht als ein allgemeines KI-Seminar. Wir klären, woher die Java-Kenntnisse eines Modells stammen, welche typischen Fehlerbilder daraus folgen, und wie Sie den Compiler und die Testausführung zu Ihrer billigsten Prüfinstanz machen. Am Ende steht eine Arbeitsweise, die sich durch den Rest des Seminars zieht.

0:55 Vier Punkte. Erstens: verstehen, woher das Wissen eines Modells über Java kommt — das erklärt die Stärken und macht die Schwächen vorhersagbar. Zweitens: die typischen Fehlerbilder bei Java-Code sicher erkennen, damit Sie sie im Vorbeigehen sehen statt im Debugger. Drittens: Compiler und Tests als Prüfinstanz einsetzen, statt selbst zu bewerten. Und viertens: Kontext und Bauzyklen so führen, dass die Arbeit bezahlbar bleibt.

1:20 Der letzte Punkt klingt nach Buchhaltung, ist aber in der Praxis oft der Unterschied zwischen Begeisterung und Ernüchterung.

Was ein Sprachmodell über Java weiß

1:29 Beginnen wir mit den Grundlagen, und zwar bewusst knapp. Wir brauchen kein Verständnis davon, wie ein Sprachmodell intern arbeitet. Wir brauchen nur eine Antwort auf die Frage, woher sein Java-Wissen stammt — denn daraus lässt sich alles Weitere ableiten. Das ist eine der wenigen Stellen, an denen ein bisschen Theorie sich unmittelbar in Praxis auszahlt.

1:50 Ein Sprachmodell lernt aus öffentlich verfügbarem Code, aus Dokumentation und aus Forenbeiträgen. Der entscheidende Satz steht in der Mitte: Es kennt kein „richtig", es kennt „häufig". Das ist keine Abwertung, sondern eine Beschreibung. Stellen Sie sich jemanden vor, der sehr viel gelesen hat und ein hervorragendes Gedächtnis für Muster besitzt — aber nie in Ihrem Haus gearbeitet hat.

2:13 Bei allem, was verbreitet ist, ist diese Person brillant. Bei allem, was speziell ist oder neu, rät sie sehr überzeugend. Der Nutzen dieser Einordnung ist Vorhersagbarkeit. Wenn Sie wissen, dass die Stärke aus Häufigkeit entsteht, können Sie im Voraus sagen, wo es gut gehen wird und wo nicht. Spring wird gut bedient, Ihre hauseigene Abrechnungsbibliothek nicht. Ein Muster aus tausend Projekten sitzt, das Sprachfeature vom letzten Jahr wackelt.

2:41 Und der letzte Punkt ist der wichtigste für den Rest des Seminars: Firmeninterner Code kommt in keinem Training vor. Was das Modell darüber weiß, haben Sie ihm gegeben — sonst nichts. Die Logik dieser Tabelle ist eine einzige Frage: Wie oft kam das im öffentlichen Code vor? Links steht, was millionenfach geschrieben wurde.

3:01 Rechts steht, was selten oder gar nicht vorkommt. Und jetzt kommt die eigentliche Pointe, sie steht in der Fußzeile: Die rechte Spalte ist keine Warnliste, sondern eine Aufgabenliste. Alles, was ein Modell nicht wissen kann, müssen wir ihm mitgeben — als Kontext, als Regel, als Beispiel. Genau das bauen wir im fünften Modul.

3:21 Diese Tabelle ist also der Bauplan dafür. Der erste Punkt ist der wichtigste des ganzen Kapitels: Sicheres Auftreten mit falschem Inhalt. Sprachmodelle formulieren gleich souverän, ob sie recht haben oder nicht — es gibt kein Zögern, kein „ich bin mir unsicher" in der Stimmlage. Wir Menschen sind aber darauf trainiert, Sicherheit im Ton als Kompetenzsignal zu lesen. Machen Sie sich das bewusst, es ist die häufigste Falle überhaupt.

3:47 Und der letzte Punkt: Beispiele aus dem Netz sind oft veraltet, aber sprachlich überzeugend. Alt und gut geschrieben ist eine gefährliche Kombination.

Der Java-8-Bias der Trainingsdaten

3:57 Und damit zu dem Kapitel, das ich für das wichtigste dieses Moduls halte. Wenn Sie heute nur eine Sache mitnehmen, dann diese. Es geht um einen Effekt, der nichts kaputtmacht, nirgends auffällt und trotzdem über Jahre die Qualität einer Codebasis bestimmt. Er hat keine Fehlermeldung, keinen Alarm und keinen Zeitpunkt, an dem er sichtbar wird. Und er lässt sich, wenn man ihn einmal kennt, mit sehr wenig Aufwand abstellen.

4:22 Java 8 kam 2014 und war jahrelang der Standard. Entsprechend stammt ein Großteil des öffentlich verfügbaren Java-Codes aus dieser Zeit — Tutorials, Antworten in Foren, Beispielprojekte. Ein Modell, das daraus lernt, hält Java 8 für den Normalfall. Es ist wie ein Kollege, der 2015 in Rente gegangen ist und dessen Rat immer noch richtig ist, nur eben von damals.

4:45 Er schreibt Ihnen funktionierenden Code. Und ohne dass Sie etwas dagegen tun, wächst Ihr Altbestand weiter — nur eben schneller als früher. Gehen wir die Logik dieser Tabelle durch, statt sie abzulesen. Links steht jeweils, was millionenfach im Netz steht. Rechts, was heute üblich wäre. Und in der Fußzeile steht der Satz, auf den es ankommt: Das ist kein Fehler im engeren Sinn. Der Code läuft.

5:11 Er übersetzt, die Tests sind grün, das Review findet nichts zu beanstanden — denn nichts ist kaputt. Er altert nur bereits beim Entstehen. Deshalb ist dieser Effekt so hartnäckig: Es gibt keinen Moment, in dem er auffällt. Sie müssen aktiv danach schauen. Der dritte Punkt ist der unangenehme: Ein Code-Review bemerkt es selten. Das liegt nicht an der Sorgfalt der Reviewer.

5:35 Es liegt daran, dass ein Review auf Fehler schaut, und hier ist nichts falsch. Wer nicht ausdrücklich nach Zeitgemäßheit fragt, findet auch nichts. Der letzte Punkt ist aber die gute Nachricht — und der Grund, warum ich hier so viel Zeit investiere: Die Gegenmaßnahme ist billig. Ein Satz im Projektkontext, der den Zielstand nennt, verändert die Vorschläge sofort. Das kostet Sie fünf Minuten.

5:59 Der letzte Punkt begegnet mir am häufigsten: die Annahme, ein neueres Modell habe das Problem automatisch nicht. Das ist verständlich und trifft nicht zu, denn die Ursache liegt in der Verteilung der Trainingsdaten, nicht in der Modellgröße. Solange im Netz mehr Java-8-Code steht als moderner, bleibt der Effekt bestehen.

6:18 Und der erste Punkt ist die eigentliche Lösung: Den Zielstand nirgends festzuhalten heißt, das Modell raten zu lassen. Und es rät nach Häufigkeit. Also nach Java 8. Diese Übung ist bewusst klein, weil ihr Wert im Aha-Effekt liegt. Erzeugen Sie drei Vorschläge zu Lagerwerk — ganz normal, ohne besondere Vorgaben. Und dann gehen Sie jeden durch und markieren, was davon Java 8 ist. Sie werden überrascht sein, wie viel es ist, gerade weil der Code völlig in Ordnung aussieht.

6:47 Notieren Sie zu jedem Fund die moderne Entsprechung. Diese Liste ist mehr als eine Übung: Sie ist der Rohstoff für die Regeln, die wir morgen aufschreiben.

Erfundene APIs und Annotationen erkennen

6:57 Vom stillen Problem zum lauten: Im dritten Kapitel geht es um Vorschläge, die schlicht nicht existieren. Das klingt zunächst harmlos, weil so etwas ja auffallen müsste — spätestens beim Übersetzen. In einer großen Spring-Codebasis fällt es aber überraschend oft nicht auf, und zwar aus einem sehr menschlichen Grund. Diesen Mechanismus schauen wir uns an, denn wer ihn versteht, erkennt die Fälle künftig im Vorbeigehen.

7:22 Ein Sprachmodell erzeugt Text, der zu dem passt, was es gelernt hat. Wenn es hundert ähnliche Annotationen kennt, kann es eine hunderteinste bilden, die genauso aussieht — und die es nicht gibt. Das ist wie ein Wort, das perfekt deutsch klingt und trotzdem in keinem Wörterbuch steht. In einem Framework mit vielen ähnlich benannten Bestandteilen wirkt das vollkommen plausibel.

7:43 Und weil Sie den Namen nicht auswendig kennen, prüfen Sie ihn nicht — Sie erkennen ihn wieder, obwohl Sie ihn noch nie gesehen haben. Vier Zeilen, zwei Erfindungen. Und das Bemerkenswerte ist: Sie müssen genau hinsehen, um sie zu finden. Die Annotation existiert. Das eine Attribut existiert. Das andere klingt, als müsste es existieren — es wäre schließlich praktisch. Und der Methodenname folgt exakt dem Namensschema, das das Framework verwendet.

8:11 Genau darin liegt die Falle. Es ist kein Unsinn, es ist eine plausible Fortsetzung des Musters. Die gute Nachricht steht auf der nächsten Folie: Bei einer dieser beiden Erfindungen hilft Ihnen der Compiler sofort. Der zweite Punkt ist der, den Sie sich merken sollten: Konfigurationsschlüssel scheitern erst zur Laufzeit, oft still.

8:33 Ein erfundener Methodenname übersetzt nicht — das merken Sie in Sekunden. Ein erfundener Konfigurationsschlüssel wird dagegen einfach ignoriert. Kein Fehler, keine Warnung, die Einstellung ist nur wirkungslos. Sie glauben also, Sie hätten eine Zeitüberschreitung gesetzt, und haben es nicht. Solche Fehler findet man erst unter Last. Deshalb gilt: Bei allem, was Konfiguration ist, lohnt sich der Blick in die Dokumentation immer.

9:00 Der erste Punkt ist der, der am schwersten zu entdecken ist: Attribute an bekannten Annotationen. Die Annotation kennen Sie, sie steht überall im Projekt — also lesen Sie darüber hinweg und übersehen, dass ein Attribut darin erfunden ist. Der letzte Punkt ist der versionsabhängige Fall: Ein Vorschlag kann völlig korrekt sein, nur eben für eine andere Version des Frameworks als die, die Sie einsetzen.

9:23 Beides hat dieselbe Gegenmaßnahme, und sie ist unspektakulär: Bei allem, was Sie nicht sicher kennen, kurz in die Dokumentation sehen. Das dauert dreißig Sekunden und spart im Zweifel eine Stunde.

Der Compiler als Wahrheitsprüfer

9:35 Nach zwei Kapiteln über Schwächen kommt jetzt der Vorteil — und Java hat hier tatsächlich einen, den dynamische Sprachen nicht haben. Wir sehen uns an, wie sich dieser Vorteil zu einer Arbeitsweise ausbauen lässt. Sie ist unspektakulär und wirkt sofort. Und sie zieht sich durch den Rest des Seminars, deshalb lohnt es sich, sie hier einmal bewusst zu üben, statt sie nur zur Kenntnis zu nehmen.

9:58 Statische Typisierung galt lange als Umstand: mehr schreiben, mehr Zeremonie. Im Umgang mit Sprachmodellen kehrt sich das um. Ein erheblicher Teil erfundener Vorschläge scheitert bereits an der Übersetzung — der Compiler ist ein Prüfer, der nichts übersieht, nichts vergisst und nichts kostet. Stellen Sie sich einen Lektor vor, der jeden Text in Sekunden auf erfundene Wörter prüft. Sie müssen ihn nur fragen.

10:22 Und genau das ist der Punkt: Der Vorteil entsteht nicht durch die Typisierung allein, sondern dadurch, dass Sie früh und oft übersetzen. Der rote Faden dieser fünf Schritte ist Disziplin bei der Schrittgröße. Kleine Änderung, sofort übersetzen, erst dann weiter. Besonders hinweisen möchte ich auf Schritt drei: Fehler ungefiltert zurückgeben, statt sie selbst zu deuten.

10:45 Der Impuls ist, den Fehler zu lesen und in eigenen Worten zu beschreiben — dabei geht Information verloren. Der Compiler formuliert bereits präzise, inklusive Zeile und Typ. Diese Formulierung ist die beste Anweisung, die Sie geben können. Und die Fußzeile bringt es auf den Punkt: Wer fünf Änderungen sammelt, sucht danach in fünf Änderungen.

11:06 Der erste Punkt ist der unmittelbare Gewinn: Erfundene Namen fallen in Sekunden auf. Der dritte ist der wirtschaftliche: Kurze Zyklen halten den Kontext klein und damit die Kosten niedrig. Denn jede Runde, in der Sie fünfhundert Zeilen mitschicken, kostet — und wenn der Fehler dann in Zeile drei lag, war der Rest umsonst.

11:25 Der vierte Punkt ist der, den ich Ihnen als Gewohnheit ans Herz lege: Der Fehlertext ist die beste Formulierung der nächsten Anweisung. Kopieren statt umschreiben. Der erste Punkt ist die notwendige Einschränkung: Der Compiler prüft Typen, nicht Fachlichkeit. Grün heißt, dass es übersetzt — nicht, dass es stimmt. Ein Vorschlag kann formal einwandfrei sein und fachlich das Gegenteil dessen tun, was Sie wollten. Der Compiler ist also die erste Instanz, nicht die einzige.

11:54 Und der zweite Punkt markiert die Lücke: Reflexion und Konfiguration entziehen sich der Prüfung vollständig. Alles, was erst zur Laufzeit aufgelöst wird, ist blinder Fleck. Dort müssen Tests einspringen — und die bauen wir im achten Modul.

Der Maven-Feedback-Loop und seine Kosten

12:09 Im fünften Kapitel wird es unromantisch: Wir reden über Wartezeit. In Java-Projekten ist das kein Randthema, sondern der Faktor, der bestimmt, wie oft Sie überhaupt prüfen — und wie oft Sie prüfen, bestimmt am Ende die Qualität. Der Zusammenhang ist indirekt und deshalb leicht zu übersehen. Wir messen die Zeiten hier tatsächlich, statt über sie zu reden, denn die Zahlen überzeugen besser als jedes Argument.

12:33 In manchen Sprachen dauert die Rückmeldung Sekunden. In einem Java-Projekt mit mehreren Modulen dauert ein vollständiger Bau Minuten. Das klingt nach einem technischen Detail und ist in Wahrheit eine Verhaltensfrage. Wer drei Minuten auf jede Antwort wartet, prüft seltener, sammelt Änderungen und verliert die Zuordnung zwischen Fehler und Ursache.

12:54 Die Antwort darauf ist nicht Geduld, sondern Zielgenauigkeit: nicht alles bauen, sondern das, worum es geht. Genau darum geht es auf der nächsten Folie. Zwei Kommandos, und der Unterschied ist nicht kosmetisch. Oben steht der vollständige Lauf über alle Module — richtig vor einem Auslieferungsschritt, verschwenderisch in einer Arbeitsschleife.

13:14 Unten steht das, was Sie fünfzigmal am Tag brauchen: ein Modul, ein Test. Der Unterschied sind mehrere Minuten pro Runde, und bei zwanzig Runden ist das ein halber Vormittag. Und beachten Sie die Fußzeile: Dieses gezielte Kommando gehört in die Projektanweisung. Denn wenn Sie es nicht aufschreiben, probiert ein Agent — und probiert im Zweifel den vollständigen Lauf.

13:37 Der erste Punkt ist die Kernaussage: Die Zykluszeit bestimmt, wie oft geprüft wird, und damit die Qualität. Das ist ein indirekter Zusammenhang, den man leicht übersieht — niemand entscheidet bewusst, seltener zu prüfen. Man tut es einfach, weil Warten unangenehm ist. Der zweite Punkt betrifft direkt unser Thema: Ein Agent, der raten muss, baut im Zweifel den gesamten Reaktor.

14:00 Er hat keinen Grund, sparsam zu sein, wenn ihm niemand sagt, was reicht. Sparsamkeit ist hier also keine Tugend, sondern eine Konfiguration. Der erste Punkt ist die naheliegendste und schlechteste Abkürzung: Tests überspringen, um schneller zu sein. Das löst das Zeitproblem und schafft ein größeres — dann prüft nämlich niemand mehr, und wir sind wieder bei der Hoffnung als Strategie.

14:24 Der zweite Punkt ist die subtile Falle: modulübergreifende Änderungen mit einem Einzelmodul-Bau absichern. Das ist grün und sagt nichts. Wenn Sie an einer Schnittstelle arbeiten, die andere Module nutzen, brauchen Sie den größeren Lauf. Zielgenauigkeit heißt nicht, immer das Kleinste zu bauen, sondern das Passende.

Kontextfenster gegen reale Java-Codebasen

14:42 Im letzten Kapitel dieses Moduls kommen wir zu dem Punkt, an dem Java-Projekte sich am deutlichsten von anderen unterscheiden — und an dem in der Praxis die meisten Enttäuschungen entstehen. Es geht um die schlichte Frage, was ein Werkzeug überhaupt sehen kann. Und um die weniger schlichte, was es sehen sollte. Die zweite Frage ist die eigentliche Arbeit, und sie lässt sich nicht automatisieren.

15:05 Ein Kontextfenster ist begrenzt — das ist bekannt. Weniger bekannt ist, wie schnell Java-Projekte es mit Material füllen, das nichts aussagt: tiefe Klassenhierarchien, Interfaces ohne sichtbare Implementierung, generierter Code, Lombok. Stellen Sie sich einen Schreibtisch vor, auf dem nur begrenzt Platz ist. Sie können ihn mit vierzig Ordnern belegen, von denen dreißig Formulare enthalten, die jemand automatisch erzeugt hat. Oder mit fünf, die die Entscheidungen enthalten.

15:33 Auswahl schlägt Menge — und Auswahl ist eine fachliche Entscheidung, keine technische. Diese Tabelle folgt einem einzigen Prinzip: Hat hier ein Mensch eine Entscheidung getroffen? Links steht, was Entscheidungen enthält — die Klasse, um die es geht, ihr Test, die fachliche Schnittstelle. Rechts steht, was automatisch entstanden ist oder vorsichtshalber mitgenommen wurde. Interessant ist die letzte Zeile links: die Projektanweisung.

15:59 Sie ist die einzige Datei, in der jemand ausdrücklich aufgeschrieben hat, wie in diesem Haus gearbeitet wird — und deshalb gehört sie immer dazu. Wir bauen sie im fünften Modul. Der erste Punkt ist der, der oft überrascht: Weniger Kontext heißt genauere Antworten, nicht nur billigere. Man würde intuitiv das Gegenteil annehmen — mehr Information, bessere Antwort.

16:21 In der Praxis verdrängt zu viel Material genau die Datei, auf die es ankam, und das Modell orientiert sich am Rauschen. Der zweite Punkt ist eine gute Faustregel für Java: Generierter Code beschreibt nichts, was ein Mensch entschieden hat. Er ist damit die erste Kategorie, die Sie ausschließen können — ohne Verlust. Der zweite Punkt ist der java-spezifischste dieses ganzen Moduls: Lombok.

16:46 Wenn Sie eine Lombok-Klasse mitgeben, sieht das Werkzeug Felder und Annotationen — aber keine Getter, keine Setter, keinen Builder. Die existieren erst nach dem Übersetzen. Das Ergebnis ist absehbar: Es hält vorhandene Methoden für fehlend und schlägt vor, sie zu ergänzen. Deshalb reicht es nicht, Lombok auszuschließen — Sie müssen es erklären.

17:07 Wie das aussieht, sehen wir im fünften Modul. Und der letzte Punkt bleibt der Kern: Kontext füllen ersetzt keine klare Frage. Fassen wir zusammen, was Sie in den Rest des Seminars mitnehmen. Der Java-8-Bias ist die wichtigste Eigenheit im Umgang mit KI und Java, und er lässt sich mit einem Satz Kontext abstellen. Erfundene Annotationen und Methodennamen haben erkennbare Muster — und der Compiler findet die meisten davon geschenkt.

17:34 Gezielte Testkommandos entscheiden über Ihre Zykluszeit und damit über die Qualität. Und Kontext wird ausgewählt, nicht gefüllt. Genau davon handelt das fünfte Modul: Wir schreiben all das auf, damit ein Agent es lesen kann.