In an age of agentic engineering we in the Samman Society continue to find that human engineering expertise is needed to achieve high-quality software.

– Emily Bache, “Samman Society statement on Agentic AI”

Letzte Woche, am 12. Oktober 2026, hat Emily Bache das „Samman Society statement on Agentic AI” veröffentlicht. Du solltest esl lesen: Es ist kurz und interessant. Hier sind noch ein paar zusätzliche Gedanken von mir…

Ich denke immer noch, dass generative KI insgesamt negativ für die Menschheit ist, darüber habe ich bereits geschrieben. Wenn du wissen willst, warum, schau dir Selbst wenn uns die KI nicht umbringt, ist das keine gute Nachricht an

Einiges funktioniert nicht mehr

Die Stellungnahme beschreibt Dinge, die nicht mehr funktionieren, wie zum Beispiel Code Katas, die zu klein sind, wenn Agenten involviert sind.

Das habe ich selbst erlebt: In einem Code Retreat war eine der Einschränkungen „Nutze eine KI und überprüfe dann den Code gründlich”. Wie immer war die Kata „Game of Life”.

Das Problem war: Sie spuckt eine perfekte Lösung aus. Vielleicht, weil das Problem zu klein und zu gut definiert ist, um etwas Interessantes hervorzubringen; oder noch wahrscheinlicher, weil es bereits unzählige gute Lösungen im Trainingsmaterial gibt.

Wir hatten für den Rest der Session nichts zu tun, also haben wir einer anderen Gruppe zugeschaut, die die KI bat, „flauschige Häschen” zu Game of Life hinzuzufügen. Dadurch ist dann einiges an Blödsinn entstanden, was zumindest lustig war.

Training anpassen

Dann geht es in dem KI-Statement darum, dass viele Coaches gearade ihre Methoden anpassen:

Many coaches are now teaching various new technical practices for AI tools based on their own experience and their own beliefs about what works. That is a great starting point since we are all excellent engineers in our own right. In the longer term we expect a body of knowledge to emerge which we will agree on.

– Emily Bache, “Samman Society statement on Agentic AI”

In einem meiner TDD-Trainings haben wir zuerst versucht, testgetriebene Entwicklung von Hand zu betreiben, und dann zugeschaut, wie eine KI es macht. Dabei ist dann kein „echtes” TDD rausgekommen— nicht mit dem einfachen Prompt, den die Gruppe sich ausgedacht hat. Aber wir hatten trotzdem ein gutes Ergebnis und einen guten Test. Wir waren uns nicht sicher, ob das daran lag, dass die Lösungen in den Trainingsdaten waren, also haben wir versucht, uns ein Problem auszudenken, bei dem es hoffentlich nur wenige Java-Lösungen gibt, wenn überhaupt.

Gemeinsam haben wir die Aufgabe definiert als: „Schreibe ein Programm, das eine Uhrzeit auf der Erde als Eingabe bekommt und ausgibt, ob es Nacht, Morgendämmerung, Tag oder Abenddämmerung am Olympus Mons auf dem Mars ist, mit TDD”.

Das war lustig anzusehen! Wir haben immer noch einige Probleme mit der TDD-Vorgehensweise der KI festgestellt, aber wieder waren der Code und die Tests ziemlich gut.

Und die Lösung war nur ein paar Zeilen lang, also habe ich die Übung für einen Konferenz-Workshop auf den Kopf gestellt: Du schreibst den Code, die KI darf nur beraten. Ich fand das noch lustiger und habe auch tolles Feedback von den Teilnehmern bekommen. Du kannst es hier selbst ausprobieren: Sunlight on Olympus Mons: an AI-Mentored Kata.

Vorher nicht möglich

Und KI ermöglicht es uns, neue Dinge zu schaffen, die vorher nicht möglich waren. Ich wollte schon immer eine Legacy-Code-Übung, die größer ist als eine “normale” Kata, um Dinge zu trainieren wie:

  • Ein Refactoring durchführen, ohne das ganze System zu kennen
  • Die Diskrepanzen zwischen der Dokumentation und dem Code finden
  • Einen Bug fixen, ohne Nebenwirkungen in einem verwickelten System zu verursachen
  • Mindestens N Design-Probleme finden, die Refactoring verhindern
  • Einen neuen Bounded Context entwerfen, der mit dem bestehenden System interagiert
  • …

Ich hatte nie Zeit, das von Hand zu machen, aber ich bin ziemlich weit gekommen, indem ich es mit KI gemacht habe: Legacy Code Exercise: DragonKeep. Es hat alle oben genannten Design-Probleme (und mehr) und ein Lizenz-Statement, das ich liebe, im first-implementation branch. (*)

Wohin führt uns das?

Vielleicht ist es jetzt schwerer, Fähigkeiten zu vermitteln / zu coachen: Wir wissen nicht wirklich, welche Fähigkeiten gebraucht werden, und wenn wir während des Coachings / Trainings eine KI nutzen, funktionieren einige der Techniken, die wir früher verwendet haben, nicht mehr.

Aber ich denke immer noch, dass es im Moment (Oktober 2026) unsere beste Chance ist, (die meisten) unserer technischen Fähigkeiten am Laufenden zu halten und gleichzeitig möglichst viel über die Arbeit mit KI zu lernen. Aber für mich bedeutet das auch, Code von Hand zu schreiben und die KI von Zeit zu Zeit auszuschalten. Oder zumindest sie nur als Guide und Mentor zu nutzen, wie in der Mars-Time-Kata.

(*) Ich sollte das Projekt wahrscheinlich irgendwann von Codeberg wegbewegen.

Lies / sieh dir alle Teile dieser Serie hier an: