TL;DR: KI kann inzwischen erstaunlich schnell Code erzeugen, aber sie nimmt uns nicht die Aufgabe ab, guten von schlechtem Code zu unterscheiden. Genau deshalb sind Code Dojos weiterhin sinnvoll. Der Schwerpunkt verschiebt sich vom reinen Schreiben hin zum Verstehen, Bewerten, Testen und Verbessern von Code. KI sollte dabei nicht draußen bleiben, sondern Teil des Dojos sein. Denn in Zukunft wird vermutlich weniger entscheidend sein, wer am schnellsten Code schreiben kann, sondern wer beurteilen kann, ob der erzeugte Code wirklich gut ist.
Code Dojos hatten bisher eine ziemlich einleuchtende Idee: Wir nehmen uns eine überschaubare Programmieraufgabe, setzen uns gemeinsam hin und üben Dinge, für die im normalen Projektalltag meistens keine Zeit ist. Test Driven Development, Refactoring, Clean Code, Pair Programming oder einfach den bewussten Umgang mit der eigenen Programmiersprache.
Das funktionierte gut, solange eine Annahme einigermaßen selbstverständlich war: Wenn wir besseren Code haben wollen, müssen wir lernen, besseren Code zu schreiben.
Und dann kam KI.
Heute kann ich einer KI eine Aufgabe beschreiben und bekomme wenige Sekunden später eine Implementierung. Ich kann sie auffordern, Tests zu schreiben, Methoden zu extrahieren, Namen zu verbessern, eine Klasse aufzuteilen oder mir drei alternative Lösungen vorzuschlagen. Wenn mir das Ergebnis nicht gefällt, muss ich nicht einmal selbst Hand anlegen. Ich sage einfach, was mich stört.
Da liegt die Frage ziemlich nahe: Warum sollte ich mich noch zwei Stunden mit anderen Entwicklern in einen Raum setzen und mühsam eine Bowling Kata programmieren?
Vielleicht ist die Antwort überraschenderweise: gerade deshalb.
Wenn Tippen nicht mehr die eigentliche Arbeit ist
Viele Code Dojos konzentrieren sich stark auf das eigentliche Programmieren. Jemand sitzt an der Tastatur, die anderen schauen zu, dann wird gewechselt. Man diskutiert darüber, ob eine Methode zu lang ist, ob der Name einer Variable verständlich ist und wann der nächste Test geschrieben werden sollte.
Ein Teil davon verliert durch KI tatsächlich an Bedeutung.
Es wäre Unsinn, so zu tun, als hätte sich nichts verändert. Wer heute Software entwickelt, sollte lernen, KI sinnvoll einzusetzen. Ein Code Dojo, das KI grundsätzlich verbietet, weil man schließlich „richtig programmieren“ lernen möchte, kann interessant sein. Als alleinige Übungsform wirkt es aber zunehmend künstlich.
Im echten Projekt werde ich schließlich auch nicht freiwillig auf Werkzeuge verzichten, die mir Arbeit abnehmen.
Das bedeutet allerdings nicht, dass weniger gelernt werden muss. Es verschiebt sich nur, was wir lernen müssen.
Die KI liefert Code. Aber ist es guter Code?
Das Faszinierende an generiertem Code ist, wie überzeugend er auf den ersten Blick aussehen kann.
Saubere Methodennamen, Kommentare an den richtigen Stellen, ein paar Tests dazu und vielleicht sogar ein hübsches Pattern. Fertig ist die Lösung.
Nur leider ist „sieht vernünftig aus“ keine besonders gute Qualitätsmetrik für Software.
Passt die Lösung wirklich zur Anforderung? Sind die Tests sinnvoll oder bestätigen sie lediglich das Verhalten der eigenen Implementierung? Ist die Abstraktion hilfreich oder hat die KI nur ein bekanntes Pattern eingebaut, weil es statistisch gut zur Aufgabenstellung passte? Was passiert bei Randfällen? Welche Annahmen stecken im Code?
Und vor allem: Würde ich diesen Code morgen in Produktion nehmen?
Um diese Fragen beantworten zu können, muss ich Code verstehen und beurteilen können. Genau diese Fähigkeit wird durch KI nicht weniger wichtig. Sie wird wichtiger.
Früher war die Geschwindigkeit, mit der schlechter Code entstehen konnte, zumindest durch unsere Tippgeschwindigkeit begrenzt. Diese natürliche Bremse ist inzwischen weggefallen.
Vielleicht haben wir im Code Dojo bisher das Falsche trainiert
Eine klassische Kata beginnt häufig mit einer Aufgabe und einem leeren Editor.
Das könnte man heute einfach einmal umdrehen.
Die Aufgabe bleibt gleich, aber die KI liefert die erste Implementierung.
Jetzt beginnt das eigentliche Dojo.
Welche Stellen gefallen uns nicht? Welche Annahmen hat die KI getroffen? Welche Tests fehlen? Können wir die Implementierung vereinfachen? Was passiert, wenn wir eine Anforderung verändern? Wie erklären wir der KI, was sie verbessern soll, ohne ihr bereits die komplette Lösung vorzugeben?
Plötzlich geht es nicht mehr darum, möglichst schnell Code zu produzieren. Davon haben wir ohnehin mehr als genug.
Es geht darum, Code zu beurteilen.
Das halte ich für eine der wichtigsten Fähigkeiten, die Entwickler in den nächsten Jahren brauchen werden.
Ein Prompt ist noch keine Architektur
Natürlich kann ich die KI auch fragen, ob sie ihren eigenen Code verbessern kann.
Das funktioniert teilweise erstaunlich gut.
Ich kann sagen: „Refactore diese Klasse nach Clean Code Prinzipien.“ Danach bekomme ich eine neue Version, die wahrscheinlich ordentlicher aussieht als vorher.
Damit ist das Problem aber nur verschoben.
Denn jetzt muss jemand entscheiden, ob das Refactoring tatsächlich besser ist.
Vielleicht hat die KI aus einer übersichtlichen Klasse fünf Interfaces, drei Factories und einen Strategy Context gebaut. Vielleicht hat sie eine sinnvolle Abhängigkeit entfernt. Vielleicht sind die Tests jetzt eleganter, prüfen aber nicht mehr das Entscheidende.
Die Fähigkeit, Code zu erzeugen, wird billiger.
Die Fähigkeit, gute Entscheidungen über Code zu treffen, wird dadurch nicht automatisch billiger.
Und genau hier wird das gemeinsame Üben interessant
Ein Code Dojo war für mich nie besonders spannend, weil dort am Ende eine funktionierende Lösung herauskam. Die Aufgabe selbst ist meistens absichtlich banal.
Interessant sind die Diskussionen auf dem Weg dorthin.
Warum würdest du das so machen?
Brauchen wir diese Abstraktion wirklich?
Ist dieser Test nicht eigentlich überflüssig?
Warum stört dich diese Methode?
Was passiert, wenn sich die Anforderung ändert?
Bei solchen Fragen gibt es häufig keine eindeutige Antwort. Zwei erfahrene Entwickler können denselben Code anschauen und zu unterschiedlichen Einschätzungen kommen. Genau aus dieser Reibung entsteht Lernen.
Eine KI kann mir zehn Refactoringvorschläge machen. Sie ersetzt aber nicht automatisch die Diskussion darüber, welcher davon in unserem konkreten Kontext sinnvoll ist.
Vielleicht sollte deshalb auch die KI im Dojo nicht der Lehrer sein.
Sie sollte Teilnehmer sein.
Ein KI Code Dojo könnte sogar spannender sein
Man könnte beispielsweise allen Gruppen dieselbe Aufgabe geben und ausdrücklich erlauben, beliebige KI Werkzeuge zu verwenden.
Die Aufgabe lautet dann nicht mehr nur: Implementiert diese Kata.
Stattdessen könnte sie lauten: Liefert nach 45 Minuten eine Lösung, die ihr guten Gewissens warten würdet. Ihr dürft die KI alles machen lassen. Ihr müsst anschließend aber jede Entscheidung erklären können.
Das verändert die Dynamik erheblich.
Welche Prompts funktionieren gut? Wann übernimmt man einen Vorschlag und wann nicht? Wann ist es schneller, selbst etwas zu ändern? Erkennt jemand einen Fehler, den die KI mehrfach reproduziert? Kommen unterschiedliche Gruppen trotz identischer Aufgabe zu völlig unterschiedlichen Architekturen?
Und eine besonders interessante Regel wäre:
Niemand darf Code übernehmen, den er nicht erklären kann.
Damit wäre ziemlich schnell sichtbar, ob KI gerade als Werkzeug verwendet wird oder als sehr schneller Lieferant von Dingen, die niemand mehr richtig versteht.
TDD wird dadurch ebenfalls nicht überflüssig
Gerade bei Test Driven Development könnte man argumentieren, dass KI das Thema erledigt hat. Schließlich kann sie Tests gleich mitgenerieren.
Das Problem ist nur: Ein generierter Test ist noch lange kein guter Test.
Wenn dieselbe KI Implementierung und Tests erzeugt, besteht sogar die Gefahr, dass beide dieselben falschen Annahmen enthalten. Der Test bestätigt dann wunderbar eine Lösung, die an der eigentlichen Anforderung vorbeigeht.
Im Dojo lässt sich genau das hervorragend untersuchen.
Man könnte beispielsweise zuerst gemeinsam Testfälle und Randbedingungen diskutieren und erst danach die KI implementieren lassen. Oder eine Gruppe lässt Tests und Implementierung komplett generieren, während eine andere Gruppe die Tests selbst entwirft.
Anschließend schaut man sich an, was dabei herauskommt.
Das dürfte lehrreicher sein als die hundertste Diskussion darüber, ob man bei einer Kata zuerst FizzBuzz oder zuerst den Modulo Operator hinschreibt.
Was bleibt vom Handwerk?
Trotzdem würde ich das klassische Programmieren im Dojo nicht komplett abschaffen.
Wer Code beurteilen möchte, braucht ein Gefühl dafür, wie Code funktioniert. Das ist ähnlich wie beim Taschenrechner. Dass wir nicht mehr jede Division schriftlich ausrechnen, bedeutet nicht, dass mathematisches Verständnis überflüssig geworden ist.
Nur das Verhältnis verändert sich.
Wir müssen wahrscheinlich weniger Zeit darauf verwenden, Syntax auswendig zu lernen oder immer wieder dieselben technischen Routinen zu trainieren. Dafür können wir mehr Zeit in Entwurf, Tests, Verständlichkeit, Fehlersuche und Bewertung investieren.
Das sind ohnehin die Teile der Softwareentwicklung, bei denen es interessant wird.
Vielleicht brauchen wir Code Dojos heute mehr als vorher
KI macht Programmieren schneller. Sie macht gute Softwareentwicklung aber nicht automatisch einfacher.
Im Gegenteil: Wenn innerhalb weniger Minuten hunderte Zeilen plausibel aussehender Code entstehen können, brauchen wir Menschen, die erkennen, welche davon sinnvoll sind.
Ein Code Dojo ist deshalb nicht überholt.
Aber vielleicht ist das klassische Bild vom Code Dojo überholt.
Wir müssen nicht mehr so tun, als säßen wir mit einem leeren Editor auf einer einsamen Insel ohne Copilot, ChatGPT und Coding Agents. Wir können die Werkzeuge benutzen, die wir auch im Alltag benutzen werden.
Dann trainieren wir nicht mehr hauptsächlich, Code zu produzieren.
Wir trainieren, Verantwortung für Code zu übernehmen, den wir möglicherweise gar nicht selbst geschrieben haben.
Und das könnte ziemlich genau die Übung sein, die wir gerade brauchen.
