
Programmieren lernen, während die KI schon programmiert
Die Frage, die diese Woche im Büro stand
Diese Woche hat eine Praktikantin bei uns gearbeitet, die programmieren lernen will. Irgendwann kam die Frage, die gerade fast jeder stellt, der über diesen Beruf nachdenkt: Lohnt sich das noch, wo die KI den Code doch selbst schreibt?
Ja, und zwar nicht als Trostpflaster.
Ich arbeite täglich mit Sprachmodellen, und sie schreiben mir jeden Tag Code. Was sie mir nicht abnehmen, ist die Entscheidung, ob das Ergebnis taugt. Genau dort liegt der Beruf inzwischen. Wer beurteilen kann, was ein Modell ausgibt, wird damit sehr schnell. Wer es nicht beurteilen kann, produziert etwas, das aussieht wie Können, und merkt den Unterschied erst, wenn nachts um drei etwas kaputtgeht.
Eine Zahl kann stark aussehen, ohne stark zu sein
P@ssw0rt! hat neun Zeichen aus allen vier Zeichenklassen. Setzt man das in die übliche Entropieformel ein, kommen 59 Bit heraus, und 59 Bit gelten als ordentlich.
In Wahrheit fällt dieses Passwort nach ein paar hundert Rateversuchen. Es ist kein Zufall, sondern ein Wörterbuchwort mit Ersetzungen, die jeder Angreifer kennt. Die Formel hat nichts falsch gerechnet, sie wurde nur auf etwas angewendet, für das sie nicht gilt. Ansehen kann man dem Ergebnis das nicht.
So liest sich auch generierter Code. Sauber formatiert, mit Typannotationen, freundlich kommentiert. Ob er stimmt, entscheidet nicht sein Aussehen, sondern ob du die Stelle erkennst, an der er nicht stimmt. In Python gibt es dafür ein Lehrstück: [[0]*10]*10 erzeugt kein Zehn-mal-zehn-Brett, sondern zehnmal dieselbe Zeile. Änderst du ein Feld, ändern sich zehn auf einmal. Ein gutes Modell schreibt das meistens korrekt. Wenn es das einmal nicht tut, findest du den Fehler nur, wenn du weißt, dass es ihn gibt.
Das zweite Beispiel erlebt jeder Anfänger einmal. Du fragst ein Modell, wie man eine Bibliothek installiert, bekommst pip install pygame, tippst es ein, und beim Start erscheint trotzdem ModuleNotFoundError: No module named 'pygame'. Die Antwort war nicht falsch. Sie passte nur nicht zu deinem Rechner, weil dort mehrere Python-Installationen nebeneinander liegen und das Paket in der falschen gelandet ist. Ein Modell kann das nicht wissen, denn es sieht deinen Rechner nicht. Du weißt es, sobald dir jemand einmal erklärt hat, was eine Projektumgebung ist. Ohne diese Erklärung fragst du dreimal nach, bekommst dreimal eine plausible Antwort und kommst keinen Schritt weiter.
Das ist mein ganzes Argument. KI verschiebt die Arbeit vom Tippen zum Beurteilen, und beurteilen kann nur, wer die Grundlagen einmal selbst durchgearbeitet hat. Ohne Fleiß kein Preis, das gilt hier ziemlich wörtlich.
Was an drei Tagen entsteht
Der Kurs besteht aus drei Dokumenten. Eines richtet den Rechner ein, zwei sind Tageskurse mit festem Fahrplan, Meilensteinen und Prüffragen nach jedem Abschnitt.
| Dokument | Dauer | Was am Ende läuft |
|---|---|---|
| Python, uv und einen Editor einrichten | 20 bis 30 Minuten | Ein Rechner, auf dem Python startet |
| Schiffe versenken mit Python und Pygame | ein Arbeitstag | Ein grafisches Spiel mit Gegner-KI |
| Crack Me, das Passwort-Kraftwerk | ein Arbeitstag | Ein Programm, das Passwörter durch drei Angriffsstufen jagt |
Beide Tageskurse sind Spiele, und das ist kein Zufall. Ein Spiel gibt sofort Rückmeldung. Ein Fenster geht auf oder eben nicht. Der Klick landet im richtigen Kästchen oder zwei Felder daneben. Diese Rückkopplung ersetzt den Dozenten, der über die Schulter schaut.
Beide Kurse teilen dieselbe Hausregel: Die Spiellogik kennt die Grafik nicht. Am Vormittag entsteht ein Programm, das im Terminal komplett spielbar ist, und erst danach kommt die Oberfläche dazu. Wer das einmal gebaut hat, versteht den Rest seines Berufslebens, warum Fachlogik und Darstellung getrennt gehören.
Im Schiffe-Kurs steigert sich der Gegner über drei Stufen. Die erste würfelt und braucht im Schnitt 96 Schüsse für 100 Felder. Die dritte rechnet für jedes Feld aus, auf wie vielen möglichen Schiffspositionen es liegt, und kommt mit 45 aus. Der Unterschied ist keine Programmiertechnik, sondern Stochastik. Genau das ist der Moment, an dem es bei den meisten klickt.
Für wen das gedacht ist
Du solltest Python-Grundlagen mitbringen: Variablen, Schleifen, Listen, einfache Funktionen. Alles Weitere steht in den Dokumenten. Ein Terminal musst du noch nie geöffnet haben, dafür gibt es die Systemeinrichtung, und die erklärt auch den Unterschied zwischen Terminal, Python-Konsole und Datei. Das klingt trivial und ist die häufigste Ursache für rätselhafte Fehlermeldungen in der ersten Woche.
Die Kurse sind für einen Tag mit Begleitung geschrieben, funktionieren aber allein. Die Lösungen stehen nicht drin, nur Gerüste mit TODO-Markierungen und die Prüffragen dazu. Das ist Absicht: Ein Gerüst, das man selbst füllt, bleibt hängen. Eine fertige Lösung, die man abtippt, nicht.
Was hier nicht steht, sage ich auch: Das ist keine Ausbildung. Zwei Tage machen niemanden zum Entwickler. Sie reichen für den Punkt, an dem du merkst, ob dir die Sache liegt, und genau dafür sind sie gebaut.
Entstanden sind die Unterlagen für genau eine Praktikantin. Dass sie hier stehen, hat einen einfachen Grund: Wer selbst einen Tag mit jemandem verbringt, der programmieren lernen will, kann sie nehmen und benutzen. Die Prüffragen nach jedem Meilenstein sind für die begleitende Person geschrieben, nicht für die lernende, und die Hilfeleiter im Anhang sagt ausdrücklich, wann man noch nicht helfen soll.
Wo du anfängst
Mit der Systemeinrichtung, egal welchen der beiden Kurse du danach nimmst. Sie dauert eine halbe Stunde, läuft auf Windows, macOS und Linux, und danach ist der Rechner fertig für alles, was noch kommt.
Und falls du nach dem Passwort-Kurs wissen willst, welche anderen Dinge in der IT nur aussehen, als wären sie sicher: Das ist die richtige Frage. Sie ist der Grund, warum es diesen Beruf noch gibt.