Programmieren mit KI ist wie Sucht mit Heroin

Vorab: Nein, ich habe keine eigenen Erfahrungen mit Sucht. Aber durch meine berufliche Vergangenheit weiß ich einiges darüber.

Mehr Erfahrung habe ich dagegen mit dem Programmieren. Das mache ich nun seit 25 Jahren. Vornehmlich Datenbanken mit T-SQL aber auch VB.Net, C#.Net, Node, etc. und verschiedene andere Programmiersprachen.

Nach ersten sehr vielversprechenden Versuchen bei Nutzen von KI (chatGPT) als Assistent zum Programmieren bin ich nun ein umfangreicheres Thema angegangen, bei dem ich mich auf volle KI-Unterstützung einlassen wollte.

Bisher lief die Unterstützung so, dass ich chatGPT einzelne Funktionen schreiben ließ. Dabei behielt ich die Kontrolle über den gesamten Programmaufbau. Die Architektur blieb mein Hoheitsgebiet.

Das Ergebnis war umwerfend. Programmierung in Groovy für OpenText OBM – kein Problem. SQL, .Net, PowerShell – nichts leichter als das.
Ein beträchtlich höheres Tempo bei der Bearbeitung von Einzelthemen war das Ergebnis.

Naheliegend, dieses Vorgehen weiter auszureizen.

Nächste Aufgabe: ein Commandline Tool (CLI), mit dessen Hilfe SQL-Statements analysiert werden können. Das Schlüsselwort lautet hier „Data Lineage“. Dabei geht es darum, verfolgen zu können, welche einzelnen Datenbankelemente (Spalten) auf welchen Quellen in der Datenbank aufsetzen.
(Beispiel: „INSERT tUser (nachname,vorname) select nn,vn from tUser_Base where Town=‘Bremen‘“. Hier sollte festgestellt werden, dass tUser.nachname von tUser_BASE.nn abhängt)

Dafür gibt es bereits einen sehr guten Parser. Damit ist eine wesentliche Voraussetzung gegeben. Denn ein Parser ist eine „Maschine“, die einen Satz in einer bestimmten Sprache in seine Bestandteile zerlegen kann. SPO – Subjekt, Prädikat, Objekt. In diesem Fall „Aktion, Objekt, Filter, …“ Und das ist Voraussetzung für die Bewertung der einzelnen Elemente.

Bald stellte ich fest, dass die Komplexität der Aufgabe den vorab grob geschätzten Aufwand bei weitem übersteigen würde. An dieser Stelle übergab ich die Kontrolle über das eigentliche Coden im Wesentlichen an chatGPT.
Pause – nach einigen Tagen, in denen das Programmieren mehr und mehr zum Copy/Paste wurde.
Eine ehrliche Ansage meinerseits an chatGPT: „Ich habe den Überblick verloren. Erkläre mir den Programmablauf, die einzelnen Klassen und deren Hauptfunktionen.“ Das beschäftigte mich einen halben Tag, danach hatte ich eine grobe Vorstellung davon, was in „meinem“ Programm so abging.
Trotzdem war ich nicht mehr in der Lage, dieses Wissen jemand anderem zu vermitteln. Es reichte gerade mal für ein „So ziemlich verstanden.“
Eine Premiere für mich: das erste von mir erstellte Programm, dessen Code ich nicht mehr unter voller Kontrolle hatte.
Wie in der Vergangenheit, ließ ich den Code in kleinen, leicht verdaulichen Portionen erstellen, jeweils mit einem compilierbaren Ergebnis. Nach thematischen Abschnitten führte ich einzelne Tests durch; keine Regressionstest, das war noch nicht nötig.

Im weiteren Verlauf stellte ich immer häufiger die Frage, die mich eigentlich disqualifizierte und die hier aufzuschreiben mir, zugegeben, etwas peinlich ist: „Was kommt als nächstes?“ chatGPT antwortete stets souverän. Schön, wenn wenigstens einer einen Plan hat.

Resultat: ich habe in einer Woche so viel Code erstellt, wie sonst in drei bis sechs Monaten. Das ist unglaublich, es beflügelt mich und macht Angst.

Heute nun ließ ich Mechanismen für Regressionstests einbauen (man beachte: ich „baue“ nicht mehr, ich „lasse bauen“). Mittlerweile hat chatGPT die volle Kontrolle über den Code. Die Details verstehe ich nicht mehr.
Ich sehe mich in der Rolle eines detailverliebten Product Owners in einem SCRUM-Kontext. Ich beschreibe die User Stories (WAS ich haben möchte), das Entwickler-Team (chatGPT) setzt um, WIE es will.
Wichtiger Unterschied: ich interessiere mich für den generierten Code und ich drücke CTRL-B für „Build“.

Zwischenstand:
Was sind die Ergebnisse, was habe ich gelernt, was werde ich anders machen?

Tempo: in dem die Lösung wächst, ist atemberaubend. Ich kann hier keinen Faktor angeben. Wenn ich’s müsste, läge der auf jeden Fall über 10, könnte je nach Thema auch mal bei 50 liegen, aber das sind nur subjektive Schätzungen, da darf jeder eine Zahl sagen.
Qualität: des Codes ist großartig. So sauber strukturiert hätte ich das nie programmiert. Die Klassen sind sauber geschnitten, manchmal ein bisschen viel Code.
Kontrolle: die ist weg. Ich kann nicht einschätzen, ob ein genialer Programmierer mit wesentlich weniger Code die gleiche Aufgabe zehnmal schneller bewältigen würde. Ich vermute und hoffe: nein.
Aber dafür verbürgen möchte ich mich nicht.
Spaß: an der Arbeit geht weitgehend verloren. Ich gebe die Kontrolle aus der Hand. Programmierer können nichtdeterministisches Verhalten überhaupt nicht leiden, es sei denn, sie haben es selbst programmiert. Copy/Paste mit Drüberschauen. Das ist eine echte Spaßbremse für jemanden, der aus Leidenschaft programmiert.

„Lessons learned“
Wie komme ich auf den aberwitzigen Vergleich „Programmieren mit KI sei wie Sucht mit Heroin“?

Hätte nicht eine Nummer kleiner genügt, zum Beispiel: „Auf Speed“? Ich habe den Vergleich bewusst gewählt. Denn ich rede nicht von einem leichten Rausch, der Flügel verleiht und am nächsten Tag vielleicht einen Kater.
Ich empfinde die Disruption, die von der KI gestützten Programmierung ausgeht, als brutal. Die Auswirkungen sind immens, sofort wirkend und nicht mehr umkehrbar.

  1. Ich habe in unglaublich kurzer Zeit ein unglaubliches Pensum in einer sehr hohen Qualität zu Wege gebracht (ok, chatGPT hat).
    Resultat: ich kann aus Gründen der Effizienz nie wieder ernsthaft ohne KI programmieren.
    Und auch: ich bin vordergründig sehr stolz darauf, was ich in so kurzer Zeit hingekriegt habe. (In Wirklichkeit war es nicht ich, aber ich kann für den Moment so tun, als ob.)
  2. Die Geschwindigkeit, in der chatGPT das Programmierzepter in die Hand nimmt, ist beängstigend. Ein paar Tripps und es geht nicht mehr ohne.
  3. Mein komplettes zukünftiges Dasein als Programmierer wird von chatGPT bestimmt werden.
    Programmieren ohne KI käme mir in Zukunft albern, gekünstelt, kurz: sinnlos vor.
  4. Es hat mir viel vom Spaß am Programmieren genommen. Copy/Paste ist sehr, sehr langweilig.
  5. Ich gaukle mir vor, ich hätte die Kontrolle über mein Programmiererleben. Aber nachdem ich die Spezifikation, die „Vision“, um im SCRUM-Kontext zu bleiben, hinreichend genau dargelegt habe, sind meine Einwürfe und Verbesserungsvorschläge selten etwas, auf das chatGPT nicht selbst so oder in ähnlicher Form gekommen wäre.

Disruption, brutal – bedeutet das schlecht? Hier kommt der Vergleich in’s Straucheln. Diese Veränderung wird eintreten, so oder so. Es ist an den Programmierern, sich nach ihrem Platz in dieser veränderten Welt umzuschauen. Es müssen nicht alle gleich das Prompt-Bauen lernen. Denn auch das, tut mir leid, das sagen zu müssen, kann die KI ebenfalls besser.

Was dann?

Als ich vor über dreißig Jahren begann, mit dem Auto durch Berlin zu fahren, gab es keine Navi’s, Handys o.ä. wegweisende Devices. Es gab Stadtpläne. Der Falk-Faltstadtplan konnte so gefaltet werden, dass man nur einen handlichen DIN-A4 Ausschnitt auf dem Schoß zu balancieren hatte, genial.
Und ich kannte mich in den für mich wichtigen Gegenden aus. Ich hatte für mich wichtige Teile des Planes im Kopf und ich hatte eine Vorstellung von meiner Umgebung.
Seit ein paar Jahren wohne ich in der Nähe einer anderen Stadt und ohne Navigation bin ich aufgeschmissen, kaum in der Lage, mich gewaltfrei von A nach B zu bewegen. Da ist mir eine Fähigkeit, die ich beständig trainiert hatte, abhandengekommen.

Und das ist der wesentliche Punkt:
überlässt man der KI frühzeitig die Kontrolle über den Code, wird man nie lernen, in den Strukturen zu denken, die für die Bewältigung komplexer Programmieraufgaben notwendig sind.

Bei einer gegebenen Aufgabenstellung gilt es, vor dem Coden einige Fragen zu beantworten.

  • Verstehe ich die Erwartungen des Beauftragenden (egal ob inhouse oder Kunde)?
  • Habe ich eine Vision davon, wie das Produkt am Ende aussehen, was es leisten wird?
  • Kenne ich alle wesentlichen Randbedingungen, die gelten? (Zeit, Geld, Beteiligte, Innovationsfähigkeit oder -unfähigkeit, Starrsinn auf verschiedenen Ebenen,
    „hidden agendas“)
  • Kann oder muss ich einzelne Faktoren als „out of scope“ einstufen?
  • Etwas später, aber noch vor „Main()“:
    die Frage nach der Problemklasse. Muss ich ein spezifisches Problem lösen, das nur einmalig und in diesem betrieblichen Kontext auftritt? Oder kann ich damit rechnen, dass andere Anforderungen eingehen werden, die sich bei einem generischeren Ansatz durch eine Konfigurationsänderung und minimale Erweiterungen lösen ließen? (Aus XML wird JSON)

Die meisten dieser Fragen lassen sich schwer durch KI beantworten. Und der Prompt, in dem man den Mikrokosmos einer Abteilung als Kontext einfließen lässt, dürfte schwierig zu erstellen sein.
Es geht wieder einmal um das Menschsein. Und darin liegt die große Chance.

Fazit

Für angehende Programmierer:
Es ist wichtig, das Programmieren von Hand zu lernen. Ohne KI. Das ist grausam langsam gegenüber einen Copy/Paste-Programmieren. Aber es übt ungemein. Und es macht Spaß. Das ist eigentlich das Tollste an diesem Job: aus Fehler zu lernen. Aber die muss man erst einmal machen.

Für Programmierer, die um ihren Job fürchten:
Die Angst ist berechtigt. Die Zeiten, in denen eine Handvoll Syntax und Compilerbefehle den „Guru“ ausmachten (ein Begriff, der viel zu häufig in diesem Umfeld verwendet wird), sind vorbei. Kann heute jeder.
Aber komplexe Systeme verstehen, Abhängigkeiten nachvollziehen, Probleme bei vor der Nase liegenden Abkürzungen frühzeitig erkennen, verallgemeinern, Klassifizieren, das sind die Qualifikationen, die der Job – ohne KI-Einsatz – vermittelt haben sollte. Ohne die wäre man längst durch Makros o.ä. selbst „wegprogrammiert“ worden.