Ein paar hundert Zeilen plausibler Code entstehen heute schneller, als ein Mensch sie lesen kann. Das verschiebt eine Zuständigkeit. Das Vorschlagen wird billig, das Beurteilen bleibt teuer. In einem Beitrag mit dem Titel „Code you didn’t write“ beschreibt Jared Palmer diesen Umbruch und kommt zu einer Schlussfolgerung, die harmlos klingt und weit reicht: Wer KI beim Programmieren einsetzt, braucht nicht weniger Urteilsvermögen als früher, sondern mehr – nur an anderer Stelle.
Paradox klingt das nur auf den ersten Blick. Wenn ein Werkzeug die meiste Tipparbeit übernimmt, sollte der Mensch entlastet werden. Meist passiert das Gegenteil. Der Grund liegt darin, wie gute Entscheidungen beim Programmieren entstehen. Palmer beschreibt das mit einem Wort, das in der Softwareentwicklung selten fällt und trotzdem ständig wirkt: Geschmack. Um zu verstehen, was gemeint ist, hilft ein Blick in die Küche.
Warum langsames Tippen ein eingebauter Schutz war
Beim Kochen entscheiden sich die wichtigen Dinge beiläufig, während die Hände arbeiten. Wer eine Soße abschmeckt, merkt, dass sie zu salzig ist. Wer Gemüse schneidet, sieht, dass die Stücke zu groß geraten. Solche Korrekturen kosten keine eigene Denkpause. Sie fallen nebenbei an, und genau deshalb werden sie gemacht. Palmer überträgt das aufs Programmieren: Wer Code von Hand schreibt, benennt eine Variable, merkt, dass eine Funktion zu lang wird, sieht plötzlich, dass zwei Fallunterscheidungen in Wahrheit ein einziger Fall sind.
All das passiert im Tempo des Tippens. Und dieses Tempo ist langsam. Das ist der Punkt. Wer einen schlechten Geschmack hat, trifft schlechte Entscheidungen langsam, und die Langsamkeit begrenzt den Schaden. Nicht aus Tugend, sondern aus Physik: Die Hände kommen nicht schneller voran als der Gedanke. Was wie eine Einschränkung wirkt, war eine eingebaute Bremse, die niemand bewusst eingebaut hatte.
KI-Coding-Tools nehmen diese Bremse heraus. Plausibler Code entsteht in Sekunden, in Mengen, die niemand in derselben Zeit lesen kann. Die Verlangsamung fällt weg. Was passiert dann mit dem Geschmack? Palmer skizziert zwei Antworten, eine naheliegende und eine, die weiter reicht.
Vom Schreiber zum Prüfer: Code Review von KI-generiertem Code
Die naheliegende Antwort: Geschmack wird zum Filter. Das Modell schlägt vor, der Mensch urteilt. Das stimmt, und schon dieser Teil macht den Geschmack wichtiger als früher, weil man plötzlich viel mehr Code beurteilt, als man selbst je geschrieben hätte. Beurteilen ist schwerer als Schreiben, und das ist keine Bescheidenheitsfloskel, sondern eine strukturelle Tatsache. Wer eine Funktion selbst geschrieben hat, weiß, warum jede Zeile dort steht. Wer sie liest, muss diese Begründung erst rekonstruieren.
Dabei gibt es eine unangenehme Feinheit. KI-Code und Code-Qualität verhalten sich fast gegenläufig: Je ordentlicher der Vorschlag aussieht, desto schwerer fällt das Review, weil nichts zum Anhalten zwingt. Fehler in hässlichem Code springen ins Auge. Fehler in sauber formatiertem, idiomatischem Code bleiben unsichtbar, solange man nicht gezielt nach ihnen sucht. Palmer nennt das die härteste Sorte Code, die man prüfen kann.
Wer KI beim Programmieren richtig einsetzen will, muss deshalb mehr Zeit in die Prüfung stecken, nicht weniger. Viele Teams stellen ihre Rechnung hier falsch auf. Sie erwarten, dass die Kontrolle wegfällt, weil die Erstellung schneller wird. In Wahrheit verschiebt sich nur, wo die Arbeit liegt.
Die wichtigen Weichen fallen vor der ersten Zeile
So weit die naheliegende Antwort. Palmer hält sie für unvollständig, und dieser Einwand ist der interessanteste Teil seines Beitrags. Wer vor dem fertigen Ergebnis sitzt, hat die entscheidenden Entscheidungen längst hinter sich: was überhaupt gebaut werden soll, wie es aufgeteilt wird, was bewusst wegfällt. Wer das Falsche verlangt, bekommt das Falsche gut gebaut. Guter Geschmack beim Prüfen kann dann nur noch feststellen, dass sauber gearbeitet wurde.
Das Beispiel, das Palmer anführt, ist einfach. Jemand wünscht sich eine Cache-Schicht. Das Modell liefert einen ordentlichen Cache. Das eigentliche Problem war aber, dass dieselben Daten an drei Stellen im System abgerufen werden. Gebraucht hätte man keinen Cache, sondern das Löschen von zwei dieser drei Abrufe. Der Cache ist die Antwort auf die falsche Frage – sauber umgesetzt, korrekt getestet und trotzdem am Problem vorbei.
Dieser Fehler fällt durch noch so sorgfältiges Review nicht auf. Er ist im Code nicht sichtbar, weil der Code in Ordnung ist. Er steckt in der Aufgabenstellung, und die entsteht, bevor jemand eine Zeile schreibt. Genau hier liegt für den Autor der Teil des Geschmacks, der am meisten bewirkt: die richtige Form eines Programms zu erkennen, bevor es sie hat.
Wo Modelle gut werden und wo sie es nicht werden
Man könnte einwenden, dass die Modelle den Geschmack selbst entwickeln. Palmer rechnet damit, dass sie in bestimmter Hinsicht sehr gut werden. Die Idiome der meisten Programmiersprachen beherrschen sie schon heute besser als die Mehrheit der Entwickler. Lokale Urteile über Code – diese Schleife sollte eine Map sein, dieser Name führt in die Irre – lassen sich aus vielen Beispielen lernen, und genau das tun diese Systeme im großen Stil.
Schwerer aus Beispielen zu lernen ist etwas anderes: welcher Teil der Komplexität notwendig ist und welcher selbstgemacht, was Nutzer tatsächlich tun werden, welcher Teil des Systems sich nächstes Jahr ändert. Das hängt vom Zweck eines Programms ab, und dieses Wissen liegt fast nur bei den Menschen, denen das Programm gehört. Palmer sagt es nüchtern: Dieser Geschmack lässt sich nicht aus Mustern ableiten, weil er nicht in den Mustern steckt.
In der Praxis heißt das: Der Teil des Programmiergeschmacks, der sich in Regeln fassen lässt, wandert zu den Werkzeugen. Der Teil, der an einem konkreten Problem, einem konkreten Team und einem konkreten Markt hängt, bleibt beim Menschen. Wer KI-Coding-Tools einsetzt, sollte sich also nicht fragen, ob sie den eigenen Geschmack ersetzen, sondern welcher Teil davon überhaupt ersetzbar ist.
Weniger Prompting, mehr Nachdenken über das Problem
Daraus folgt etwas leicht Absurdes. Wenn die Maschine den Großteil des Codes schreibt, wird man besser, indem man weniger über Prompting nachdenkt und mehr über Probleme. Palmer ist sich nicht sicher, wie weit diese Verschiebung trägt, und diese Vorsicht ist angebracht. Er hält es für die vernünftigste Wette: Am meisten aus diesen Werkzeugen holen die heraus, die ohnehin wussten, was sie wollten.
Das verändert auch den Blick auf die eigene Weiterbildung. Sauberen von unsauberem Code zu unterscheiden bleibt nützlich, keine Frage. Aber dieser Teil wird zunehmend zur Aufgabe, bei der die Werkzeuge helfen können. Die Form eines Programms zu bestimmen, bevor jemand es schreibt, ist der Teil, den sie einem noch nicht abnehmen. Und er hat die größte Wirkung, weil jede Zeile, die das Modell später schreibt, diese Form erbt.
Softwareentwicklung mit KI-Unterstützung ist damit kein kürzerer Weg, sondern ein anders verteilter. Die Tipparbeit verschwindet, die Denkarbeit an den Rändern nimmt zu – vorne bei der Frage, was gebaut werden soll, hinten bei der Frage, ob das Gebaute wirklich das Gemeinte trifft.
Was das konkret bedeutet
Die praktische Konsequenz ist unspektakulär und deshalb leicht zu übersehen. Wer heute Code prüft, den er nicht selbst geschrieben hat, sollte mehr Zeit einplanen, als die Menge des Codes nahelegt. Wer Anforderungen formuliert, sollte genauer sein als früher, weil ein präziser Auftrag an ein unpräzises Problem nur schneller am Ziel vorbeiführt. Und wer sich fragt, worin er besser werden sollte, findet die Antwort eher im Verständnis des Problems als in der Beherrschung der Werkzeuge.
Palmer endet mit einer Wette, nicht mit einer Gewissheit, und das passt zu einem Thema, das sich schneller bewegt als die Erfahrung, die man darüber sammeln kann. Seine Beobachtung lässt sich aber schon heute überprüfen. Wenn ein Vorschlag des Modells in Sekunden entsteht und man zehn Minuten braucht, um ihn zu beurteilen, dann war Geschwindigkeit nie das Ziel. Der Geschmack ist nicht verschwunden. Er ist nur an die Stelle gerückt, an der er ohnehin am meisten bewirkt hat – vor die erste Zeile.
Quelle: jaredpalmer.com
