Computer haben mich seit jeher fasziniert. Einerseits natürlich die vielen Dinge, die Computern für uns einfacher machen – man denke nur an E‑Mail oder das Internet und wie die Leben davor funktionierte (ich bin tatsächlich alt genug, mich daran zu erinnern). Andererseits und noch viel mehr faszinierten mich aber die Dinge, die ich selbst, mit meiner Vorstellung, meinen Überlegungen, meiner Kreativität damit erschaffen konnte: Softwareentwicklung war und ist für mich eine Möglichkeit, meinen Ideen Ausdruck und Form zu verleihen.
Recht naheliegend habe ich deswegen Informatik studiert. Ebenfalls recht naheliegend und erwartbar, entwickelte sich meine „Karriere“ langsam aber stetig weg von der Software-Entwicklung hin zum Management, zuerst in IT-Projekten, dann als Geschäftsführer einer kleinen, neugegründeten Beratungsfirma, dann in großen Veränderungsprojekten wie der agilen Transformation der BMW Group IT und schließlich als Leiter einer Practice Area in Allianz Inhouse Consulting. Der Trend ist recht eindeutig: Immer weniger eigenhändige Softwareentwicklung, immer mehr Excellisten und PowerPoint-Präsentationen. Meine Kreativität fand derweil ein neues Betätigungsfeld: Ich begann mit dem Schreiben dieses Blogs, das schließlich in mein Buch „Manifest für menschliche Führung“ mündete.
Zurück zu den Wurzeln
Das Bedürfnis wieder selbst in die Tasten zu greifen und Software zu entwickeln verschwand nie vollständig. Je weiter ich mich davon entfernte und je schneller sich die Welt der Softwareentwicklung fortentwickelte (meine letzte aktiv genutzte Programmiersprache war Java mit JEE!), desto größer wurde meine Sehnsucht. Ich wollte zurück zu meinen Wurzeln und – wie es David Heinemeier Hansson so schön formulierte – mit meinen bloßen Händen den Code ziselieren. Ich begann mich zunächst mit Neovim / Lazyvim als Editor und Programmierumgebung zu beschäftigen (eine sehr steile Lernkurve, aber mittlerweile ein Editor den ich auch für alltägliche Aufgaben nicht mehr missen möchte), machte einen Abstecher zu Ruby on Rails und griff dann ein schon gut abgehangenes Projekt wieder auf, aus dem nun ein echtes Produkt wurde: Pulse – Dein Micro-Journal, eine iOS-App zum täglichen Reflektieren.
Genau wie Ruby stellte sich Swift als Programmiersprache als überaus faszinierend heraus auch wenn ich natürlich anerkenne, dass diese Faszination für Nicht-Informatiker eher weniger nachvollziehbar sein dürft. Was früher sauber getrennte Programmierparadigmen waren (objektorientiert, funktional, imperativ und prozedural, usw.), findet sich in Swift in einer einzigen Sprache als Best-of vereint. Das zu lernen, zu verstehen, selbst auszuprobieren – das war mein eigentliches Ziel. Nicht die fertige App.
Der sehr, sehr gute Praktikant
Von AI oder gar Vibe-Coding hielt ich mich bewusst fern. Ich wollte den Code spüren und verstehen, wie die Konzepte ineinander greifen. Mehr als das übliche „Tab-Complete“, also die Autovervollständigung im Editor, die es einem erspart beispielsweise die genaue Signatur von Funktionen nachzuschlagen, ließ ich nicht zu. Nicht, weil ich es besser wusste, sondern gerade weil ich es noch so gut wusste und konnte.
Dann kam Claude oder besser gesagt ich kam mit Claude in Berührung. Und ich erkannte wie recht Kevin Kelly hatte, als er die so angesagten auf Large Language Models basierenden KI-Assistenten sinngemäß als sehr, sehr gute Praktikanten beschrieb. Claude ist da keine Ausnahme und liefert meist solide Arbeit. Manchmal sogar überraschend gute, die mich verblüfft und zum Nachdenken anregt. Erste Entwürfe, die funktionieren. Architekturvorschläge, die durchdacht sind. Code, der kompiliert und das tut, was er soll.
Und trotzdem oder gerade deswegen fühlte ich mich unwohl. Es war als würde ich Bob Ross im Fernsehen bewundern, um dadurch Malen zu lernen. (Für die jüngeren Leser: Bob Ross war ein amerikanischer Maler und TV-Legende, berühmt für Landschaften in unter dreißig Minuten — und dafür, dass Millionen fasziniert zusahen, aber kaum jemand selbst malte.)
Ich habe den von Claude geschriebenen Code gelesen, verstanden (meistens), kopiert, eingefügt oder praktischerweise einfach einfügen lassen. Claude ist nicht nur ein einziger sehr, sehr guter Praktikant, sondern eine gut orchestrierte Armee von sehr guten und hoch-spezialisierten Praktikanten, die den Code so lange kneten, bis alle Fehler beseitigt sind und das Feature funktioniert. Durchaus praktisch und am Ende war es durchaus guter Code. Aber er war nicht meiner. Und der Lerneffekt war in etwa so groß als würde ich eben Bob Ross beim Malen zusehen. Ich hatte ihn nicht gerungen, war nicht an falschen Ansätzen gescheitert, hatte nicht die spezifische Befriedigung gespürt, wenn etwas nach langem Nachdenken und Nachforschen endlich funktionierte. Das Verstehen beim Lesen ist eine andere Kompetenz als das Können beim Schreiben. Die Lücke zwischen beiden ist exakt der Ort, an dem das Lernen passiert. Zugegebenermaßen keine wirklich neue Erkenntnis.
Es gibt Dinge, die wir lernen müssen, bevor wir sie tun können. Und wir lernen sie, indem wir sie tun.
Aristoteles, Nikomachische Ethik
Der IKEA-Effekt
Die Verhaltensökonomen Norton, Mochon und Ariely haben 2011 nachgewiesen, was viele intuitiv kennen: Menschen schätzen Dinge, die sie eigenhändig hergestellt haben, unverhältnismäßig hoch — nicht wegen der objektiven Qualität des Ergebnisses, sondern wegen der investierten Mühe bei der Anfertigung. Der IKEA-Effekt.
Ich spüre ihn an meinem eigenen Code sehr deutlich. Meine Lösungen sind alles andere als perfekt. Es gibt Stellen, die Claude und ich mittlerweile gemeinsam überarbeitet haben und die nun deutlich eleganter sind. Und es gibt sicherlich immer noch Stellen, über die ein erfahrener SwiftUI-Entwickler milde lächelnd den Kopf schütteln würde. Aber es ist mein Code. Ich habe ihn mühsam angefertigt, habe die Dokumentation gelesen, war Dauergast auf Stack Overflow, habe Fehler gemacht, mit dem Debugger Schritt für Schritt die Ursache gesucht und Lösungen gefunden.
Mir geht es mit AI-Assistenten genauso wie es den Hausfrauen in den 1950er Jahren mit fix und fertigen Backmischungen ging. Es ist zu einfach. Erst als die Hersteller das richtige Maß an Eigenleistung einbauten, frische Eier, frische Milch oder Dekoration, wurden die Backmischungen zum Renner.
Beschleunigung des Lernens
Mittlerweile haben Claude und ich aber eine Arbeitsweise gefunden, die meinem Lernziel dient:
Erstens: Wir denken gemeinsam. Bevor ich Code schreibe, plane ich mit Claude das Feature oder das Refactoring. Was ist der beste Ansatz? Welche Patterns gibt es? Was könnte schiefgehen? Claude denkt mit, stellt Fragen, ich stelle Fragen, wir disktuieren Alternativen und einigen uns auf einen Plan.
Zweitens: Ich programmiere. Allein. Mit der besprochenen Richtung im Kopf, aber ohne Claude als Ghostwriter. Das ist der Teil, in dem das Lernen passiert. Denn vieles was vorher ganz einfach aussah, ist es dann im Detail doch nicht und manches war nicht zuende gedacht.
Drittens: Claude macht den Code-Review und ich bekomme Feedback. Was hätte ich eleganter lösen können? Wo gibt es Risiken? Was habe ich übersehen?
Mit diesem Modus komme ich zwar nicht schneller zum fertigen Ergebnis, aber er beschleunigt das Lernen deutlich.
Was das bedeutet
Die eigentliche Frage, die sich aus dieser Erfahrung ergibt, ist keine technische sondern ganz klassisch die Kernfrage nach dem Wozu: Was will ich eigentlich und wie kann mir KI dabei helfen?
Als Werkzeug zur Effizienzsteigerung ist die Praktikantenarmee von Claude oft erstaunlich gut — wenn es das Ziel ist, schnell eine funktionierende App zu bauen, schreibt Claude den Code, braucht aber die führende Hand eines Experten; insbesondere dann, wenn die Software nicht nur ein Wegwerfprodukt sein soll und über Jahre gewartet werden soll.
Als Lernbegleiter funktioniert Claude anders und ebenfalls sehr gut: als Sparringspartner beim Durchdenken, als strenger aber konstruktiver Reviewer, als geduldiger Erklärer. Aber eben nicht als Ghostwriter.
Das Ziel bestimmt den richtigen Einsatz. Pulse entwickelt sich dadurch zwar langsamer, was kein Fehler sein muss wenn man dem Prinzip von Dieter Rams folgt: Weniger, aber besser!. Aber ich komme dennoch schneller an mein eigentliches Ziel: Das nachhaltige Erlernen der Konzepte der iOS-Entwicklung mit SwiftUI.
