Der mythische Bot-Monat – Teil 2

This transcript was generated automatically and has not been manually reviewed. It may therefore contain errors. The spoken word in the recording is always authoritative.

Sven Johann Herzlich willkommen zu einer neuen Folge vom INNOQ Podcast. Heute mal wieder mit Daniel Westheide und Gerrit Beine. Wir quatschen über den zweiten Teil vom mythischen Botmonat. Moin, moin. Wie geht’s euch?

Daniel Westheide Guten Morgen.

Gerrit Beine Sehr gut.

Daniel Westheide Guten Morgen. Ja, wäre ich Anwalt, ich könnte gar nicht genug sagen.

Sven Johann Sehr gut, sehr gut, sehr gut. Genau, wir hatten uns vor geraumer Zeit, also ist schon eine Weile her, ich glaube, das ist schon zwei, drei Monate her, hatten wir schon eine Folge zum mythischen Botmonat gemacht. Hintergrund vielleicht noch mal für die, die den ersten Teil nicht gehört haben, hört noch mal rein. Aber der Hintergrund ist, vor 51 Jahren, ganz schön lange her, hat Fred Brooks ein Buch geschrieben, der mythische Mann-monat, mit so ein paar Wahrheiten aus der Softwareentwicklung. Damals, als die IBM Z 360 Series entwickelt hat, also Betriebssystem, wahrscheinlich habe ich jetzt den Namen falsch gesagt. Und dann gab es irgendwie 20 oder 25 Jahre später hat er noch mal so eine Neuauflage gemacht und hat geguckt, was hat sich geändert. Und da kam raus, im Grunde genommen hat sich an seinen Thesen gar nichts geändert. Also es gibt schon so kleinere Änderungen, aber grundsätzlich hat sich nichts geändert. Und wir wollen jetzt noch mal fast 25 Jahre später oder nee, mehr als 25 Jahre später, wollen wir auch noch mal drauf gucken und überlegen, na ja, jetzt mit Agentic AI, was steht denn noch von den Thesen? Und beim letzten Mal sind wir eigentlich auch so darauf gekommen, viele Sachen sind immer noch wahr. Make or buy gibt es auf jeden Fall so einen kleinen Shift. Also das hat sich ein bisschen geändert und ja, jetzt wollen wir heute noch mal auf ein paar weitere Thesen drauf schauen. Gut, legen wir doch direkt mal los mit einer meiner Lieblingsthesen und zwar die konzeptionelle Integrität. Man muss dazu sagen, der Fred Brooks, der hat auch mal ein zweites Buch geschrieben, The Design of Designs. Und da sagt er in dem Buch verkürzt: Alle erfolgreichen Produkte, nicht nur auf Software gemünzt, die haben eine gewisse konzeptionelle Integrität, wo sozusagen ein Mastermind dahinter sagt, so machen wir es, ne? Es gibt keine Abweichung, es gibt eine Person, die sich halt daran hält. Das ist wichtig für das Design oder den Erfolg von vielen Systemen. Gut, ich lese mal kurz vor und dann könnt ihr noch mal kommentieren. Also er sagt: Voraussetzung für ein benutzerfreundliches System ist die Integrität seines Konzepts, die nur durch eine Trennung von Architektur und Implementierung erreicht werden kann. Im Namen und Auftrag des Nutzers entscheidet ein Chefarchitekt oder eine kleine Anzahl von Architekten, was in das System eingeht und was draußen bleibt. Der Chefarchitekt sollte eine Idee entwickeln, was das System leisten soll und sicherstellen, dass diese Vision vom Rest des Entwicklungsteams verstanden wird. Jetzt ein interessanter Satz: Etwaige neue Vorschläge einzelner werden nicht mit einbezogen, wenn sie sich nicht nahtlos in das Gesamtdesign einfügen. Weiterer interessanter Punkt, da kann, glaube ich, Daniel, glaube ich, schon so ein paar Artikel zu geschrieben haben, behaupte ich mal: Um ein benutzerfreundliches System zu gewährleisten, kann ein System absichtlich weniger Funktionen aufweisen, als möglich wäre. Wenn es nämlich zu kompliziert zu benutzen ist, werden viele seiner Funktionen ungenutzt bleiben, weil niemand die Zeit hat, ihre Bedienung zu erlernen. All right. Genau, wie sieht es da heute aus? Was wird ihr oder zukünftig, was passiert da?

Daniel Westheide Möchtest du zuerst, Gerrit, oder?

Gerrit Beine Gerne du, wenn du da schon was geschrieben hast. Geschrieben, weiß nicht. Also ich habe.

Sven Johann Also ich referenziere mich.

Gerrit Beine Ja.

Sven Johann Ja, ich wollte nur sagen, worauf ich mich referenziere bei dir war, du hast ja mal so Artikel geschrieben, wir brauchen, also wenn ich mich richtig erinnere, schnellere Feedback Loops.

Gerrit Beine Mhm.

Sven Johann Und es nutzt nichts, jetzt irgendwie ganz viele neue Features rauszuhauen, man muss auch validieren, ob das jetzt irgendeiner überhaupt will oder ob die Leute das nutzen. Das war so mein Anker dafür.

Daniel Westheide Genau. Also damit hat der Brooks natürlich recht, das war schon immer so. Aber das war auch schon vor Jahrzehnten nicht beachtet worden. Ich glaube, in meinem Studium hat mir unser Usability Professor in der Usability Vorlesung mal einen Screenshot von Microsoft Word gezeigt, wenn man alle Icons in dieser Icon Liste oben mal anzeigen lässt. Dann hatte man, glaube ich, keinen Platz mehr zum Editieren. Und von daher ist das jetzt nichts Neues, dass man das nicht beachtet hat. Und mit agentischer Entwicklung ist es wahrscheinlich noch einfacher, noch mehr Features rauszuhauen. Also der Aspekt, der würde ich mal sagen, da hat der Brooks auf jeden Fall recht und das gilt auch weiterhin. Was jetzt diesen Chefarchitekten angeht oder den kleinen Kreis, das ist ja im Grunde dieses Architecture Review Board, das wurde ja eigentlich schon vor einiger Zeit in den meisten Unternehmen, die ich kenne, so nicht mehr praktiziert, ne? Ich meine, von Harmel-Law, der Architecture Advice Process zum Beispiel, ist ja gerade eigentlich ein Versuch, Architekturverantwortung auf die Teams zu verteilen. Das also alle Architektur Entscheidungen treffen können. Und natürlich diejenigen, die was dazu zu sagen haben, auch einbeziehen. Aber dass man eben nicht mehr diese strikte Trennung hat zwischen Architekt und den Leuten, die das implementieren. Und vielleicht ist es mit Agenten aber tatsächlich so, dass das in der Form nicht funktioniert. Weil Agenten kommunizieren eben nicht untereinander. Und fragen sich gegenseitig, ob man vielleicht noch was Wichtiges zu dem Thema zu sagen hat. Und ich glaube, Gerrit nickt gerade und möchte was dazu sagen.

Gerrit Beine Ich möchte zu zwei Dingen etwas sagen. Also zum einen, glaube ich, möchte ich der Word-These widersprechen. Ich glaube, dass gerade die Icon-Leiste von Word architektonisch genau dieses Prinzip unterstützt, dass ich Funktionen in einer Architektur integrieren kann und die Nutzenden immer nur die Funktionen sehen, die sie brauchen, weil sie den Rest ausblenden können. Damit kriege ich genauso eine architektonische Balance hin zwischen, ich kann möglichst viele Funktionen für viele verschiedene Situationen, in denen sich Nutzende befinden, unterstützen und habe gleichzeitig nicht eine Überlastung der Nutzenden, indem ich ihnen alles auf einmal präsentieren muss. Also ich glaube, das ist eigentlich genau diese Art zu denken, wo man sagt, man könnte jetzt an der Stelle Word als, also ich bin jetzt kein Fan von Word, aber diesen Aspekt, ne, diese könnte man durchaus als ein geschicktes Usability-Konzept verstehen und sagen, das löst eigentlich architektonisch genau das Problem. Ob man jetzt alle Funktionen braucht, kann ich weder beurteilen, noch ist es aber an sich, dass es passt, ich glaube, das ist gar nicht so dumm gedacht. Und geht eigentlich genau in die richtige Richtung. Und man hat es ja auch in vielen anderen Softwaresystemen, dass ich halt Funktionen ausblenden kann, einblenden kann und sowas. Also, das ist was, das finde ich eigentlich gar nicht so verkehrt.

Sven Johann Also Niklaus Wirth hat da so ein Paper oder ein Buch geschrieben, würden wir noch mal in die Shownotes reinpacken dann, ja. Okay.

Gerrit Beine Ja, und das andere ist natürlich, wenn es um die Frage nach der Rolle Architekt/Architektin geht, da scheiden sich ja die Geister. Also, ich habe ja relativ lange Product Owner Trainings gemacht und in der Product Owner Community gab es immer so diese Aussage, da gilt das Highlander-Prinzip, es kann nur einen geben. Weil wenn es zu viele, aber anders als bei den Highlandern, das ist bei Product Ownern so, wenn es zu viele gibt, sind die alle kopflos. Und das ist so ein bisschen eine paradoxe Situation, weil wenn es am Ende nicht eine Person gibt oder ja, ich bleib mal bei der Person, wenn es nicht eine Person gibt, die am Ende Decider of the last Resort ist, die also Entscheidungskonflikte dadurch lösen kann, dass sie qua Autorität einfach eine Entscheidung trifft. Dann kommen wir nicht zu einem Ende. Also dann können wir endlos verhandeln, ob jetzt die Architektur in die linke und die rechte Richtung entwickelt werden soll, oder nach oben oder nach unten oder vorwärts und rückwärts. Also da haben wir halt alle Dimensionen und wir kommen aber nicht vorwärts. Und gerade Sprache ist dafür ja ein super Mittel, wo man sagen kann, solange Leute miteinander reden, ist alles gut. Aber es gibt halt auch Situationen, wo man dann mal handeln muss. Und da muss aus der Sprache eine Entscheidung folgen. Und an der Stelle, ich bin ein großer Freund, bei sowas dann zu sagen, okay, ich habe irgendwie eine Systematik, wie Communities of Practice oder Decision Boards oder sowas, wo ich versuche, die Perspektive derer, die die Konsequenzen der Entscheidung tragen müssen, in die Entscheidung zu integrieren. Aber es gibt am Ende trotzdem eine Autorität, ob das jetzt eine Person ist oder ein Board ist, völlig egal, aber es gibt eine Autorität, die am Ende die Entscheidung treffen kann. Und genau das ist eigentlich so genau dieser Spagat, wo glaube ich auch bestimmte Aspekte, die dann so in der Agile Community vor 20 Jahren rumgegeistert sind, so ein bisschen missverstanden wurden, glaube ich. Also, das ist so mein Gedanke zu dieser Architekturrolle und ich halte die, wenn wir jetzt noch mehr mit Sprache arbeiten, bei den Agents, bei der Koordination von Agents für existenziell. Also ich glaube, da sind viel mehr Management als Engineering Skills notwendig.

Sven Johann Mhm. Ja, also fand ich jetzt so, weil ich ganz interessant gefunden habe, weil du gesagt hast, die Leute, die Betroffenen, ne? Das ist ja genau der Andrew-Harmel-Law-Spruch, ne? Also du willst eine Entscheidung treffen, aber du musst halt die Betroffenen, also Experten, die dir helfen können und Betroffene einladen, aber du kannst halt ein Arschloch sein, du kannst nach Rat fragen, aber kannst ignorieren.

Gerrit Beine Genau.

Sven Johann Aber da würden wir bei, wenn wir konzeptionelle Integrität haben wollen, dann gibt es gewisse, ich sag mal, wir würden sagen Makro-Entscheidungen. Da musst du als Team, da musst du dich dran halten, ja.

Gerrit Beine Genau an dieser Stelle kommen wir zu einer ganz wichtigen Unterscheidung zwischen der Welt, in der wir mit Teams arbeiten, wo Menschen involviert sind, und der Welt, in der wir mit Agents arbeiten. Du hast gerade eine wichtige Unterscheidung gemacht, Sven, indem du Experten und Betroffene genannt hast. Das müssen nicht unbedingt die gleichen Leute sein. In Softwareentwicklungsteams sind das oft die gleichen Leute, nämlich diejenigen, die entwickeln und auch die Konsequenzen ihrer Architektur-Entscheidungen tragen müssen. Gleichzeitig sind sie diejenigen, die sich inhaltlich auskennen, die Technologien und die Fachlichkeit beherrschen. Wenn wir jetzt über AI-Coding nachdenken, ist mein Coding Agent, der den Code generiert, der Betroffene. Diesen kann ich aber nicht nach Expertise fragen. Er wird mir immer irgendwelche Sachen erzählen und mich in meiner Meinung bestätigen, so ist er nun mal gestrickt. Das heißt, plötzlich rücken Expertise und Betroffenheit in der Softwareentwicklung wieder auseinander. Ich brauche wieder Leute, die Experten darin sind, wie man guten Code gestaltet, wie man Fachlichkeit über den Zwischenschritt von Prompts in Code überführt und vor allem, wie Technik funktioniert. Das trennt sich jetzt wieder. Ich glaube, da wird es in den nächsten Jahren wieder einige Reibereien geben, weil wir jahrelang in die eine Richtung gegangen sind und gesagt haben, Experten und Betroffene sind die gleichen, nämlich meine Entwicklungsteams. Jetzt stellen wir fest, wenn der Code nicht mehr von den Leuten, sondern vom Agent geschrieben wird, trennt sich das wieder, und wir haben wieder zwei verschiedene Gruppen. Das finde ich eine interessante Überlegung, darüber habe ich noch nicht nachgedacht, aber wo du diese Unterscheidung aufgemacht hast, könnte man bestimmt auch etwas dazu schreiben.

Sven Johann Ja, also da ich ja immer so, ich sag mal, Plattform- oder zentralistische Themen immer so schlecht finde, sind bei mir ganz oft die Betroffenen ganz andere als die Experten. Aber okay, ja. Gut. Vielleicht noch mal ganz kurz zurück zu den zu vielen Features. Daniel hat ja gesagt, das war schon vor 50 Jahren so und wurde seit 50 Jahren ignoriert. Jetzt wird es, ich meine, wenn man ganz normal linear nach vorne denkt, was man natürlich nie tun sollte, aber wenn wir das tun würden, würden wir sagen, jetzt wird eigentlich alles noch viel schlimmer, weil wir noch viel mehr Features viel schneller bekommen, die die Software noch unbenutzbarer machen. Oder wie würdet ihr das sehen, oder seht ihr Hoffnung, dass dann trotzdem noch etwas anderes passiert?

Gerrit Beine Ja, es kommt halt darauf an, was man mit der gewonnenen Zeit und den gewonnenen Ressourcen macht, dadurch, dass man Features schneller umsetzen kann. In einem meiner Blogposts hatte ich auf jeden Fall auf eine Studie verwiesen, dass ein super hoher Anteil von Features in den meisten Anwendungen ungenutzt ist, oder sehr selten genutzt. Das ist schon sehr spannend. Ich habe ja die Hoffnung, dass man, wenn man schneller umsetzen kann, mehr Zeit in Discovery-Arbeit steckt, also herauszufinden, was man überhaupt bauen sollte.

Daniel Westheide Wobei.

Sven Johann Entschuldigung.

Gerrit Beine Ja, ich meine, wenn man immer mehr Features baut, ich glaube, den Punkt hat Sven kurz im Vorgespräch eben auch erwähnt, das muss ja nachher auch alles gewartet werden, der Code. Man muss in der Lage sein, irgendwie den zu pflegen und zu betreiben, alles. Von daher, einfach immer noch mehr zu bauen, ist vielleicht während des Bauens günstig, aber man muss sich auch über die langfristigen Konsequenzen bewusst sein.

Daniel Westheide Ja, also, was ich an der Stelle immer sehe, ist, ich kann, also ich glaube, in dieser häufig zitierten Aussage, wo es auch ganz viele Untersuchungen dazu gibt, dass es viele Funktionen in Software gibt, die nur wenig genutzt werden, rauszuschließen, dass die unnötig sind, halte ich für einen Trugschluss. Weil wenn ich mir Steuererklärungssoftware angucke, benutze ich die einmal im Jahr. Und die Funktion, die Steuererklärung abzugeben, benutze ich dann ein einziges Mal in diesem einen Jahr. Ganz viele andere Funktionen der Software benutze ich häufiger. Und daraus jetzt zu schließen, diese Funktion ist unnötig, ist aus meiner Sicht ein struktureller Denkfehler. Also, ich würde das nicht unbedingt gegeneinander ausspielen, weil diese zwei Dinge, dass wir ganz oft goldene Wasserhähne in der Software haben, das ist unbenommen. Also, das würde ich auch unterschreiben, aber ich glaube nicht, dass Nutzungshäufigkeit uns dahin führt, ob es goldene Wasserhähne sind. Ich glaube sogar, dass Menschen dazu neigen, wenn so ein goldener Wasserhahn da ist, den oft zu benutzen, auch in Situationen, wo er eigentlich unnötig ist und man das gar nicht bräuchte. Also, wie viele Leute hatten im Hintergrund bei Windows 3.1 damals Solitär offen? Das hat jetzt zur eigentlichen Arbeit wenig beigetragen. Aber Spaß beiseite. Wie gesagt, das ist so eine Perspektive, die ich da noch aufmachen würde, und wenn es um diese Menge der Features geht, das ist das, worum ich mir tatsächlich ein bisschen Sorgen mache, weil Coding war ja nie der Engpass. Also Coding hat lange gedauert, aber weil Coding lange gedauert hat, waren wir überhaupt noch handlungsfähig. Und das, was wir jetzt erleben werden, ist ein Feature Overload. Das heißt, was uns bisher daran gehindert hat, gute Software zu bauen, war unsere Fähigkeit, bei der Menge an Features, die produziert worden sind, zu entscheiden, welche Features relevant sind und welche nicht. So, und jetzt haben wir es noch leichter zu produzieren. Und wenn man sich mal Industriegeschichte anguckt, ich nehme als Beispiel Plastikflaschen. Die bräuchte eigentlich kein Mensch. Trotzdem sind die millionenfach im Ozean. Wir könnten auch andere Flaschen benutzen. Und das, was uns jetzt mit Features passieren wird, ist, dass die so werden wie Plastikflaschen. Wir entwickeln die, weil es schnell geht, trinken sie leer, benutzen sie einmal und schmeißen sie weg, weil niemand mehr in der Lage ist, zu entscheiden, ob ein Feature gut ist oder nicht. Also holen wir uns einfach das nächste, wenn wir es brauchen. Und die Codegeneratoren, die jetzt die Hürde von Softwareerstellung senken, die führen genau zu so einem Plastikflascheneffekt, dass wir ganz, ganz viel Software sehen werden, die genau eine Person einmal benutzt, und dann wird die einfach weggeworfen und nie wieder verwendet. Und das größte Problem, was ich darin sehe, das schließt auch an die konzeptionelle Integrität an, ist Anschlussfähigkeit. Wenn wir Millionen von Softwareprodukten finden werden, die alle ähnliche Probleme auf ähnliche Weise lösen und unsere Querschnittskonzepte wegfallen, die die konzeptionelle Integrität sicherstellen, dann werden wir jede Menge inkompatible Softwarefragmente haben, die einfach nicht zusammenpassen. Und das wird uns, was die Handlungsfähigkeit angeht, ungeheuer ausbremsen. Also in der Menge von Features, die wir produzieren können und die wir auch untersuchen können und so weiter und so fort. Da sehe ich die größte Gefahr, dass uns das wirklich in Hinsicht auf Handlungsfähigkeit noch langsamer macht. Das sind übrigens auch so Effekte, die kann man so aus den Lean-Methodiken herleiten und sagen, das ist eigentlich genau die kausale Kette, die sich da bilden wird. Und das ist das, darum mache ich mir tatsächlich ein bisschen Sorgen an der Stelle.

Gerrit Beine Es wäre super, wenn wir besser in Discovery wären, wie du das gesagt hast, Daniel. Ich glaube das aber nicht. Ich befürchte es nicht, dass das so kommen wird, sondern dass wir mit Software überschwemmt werden, weil es so einfach ist und wir dann nicht nur einen Ozean voller Plastikflaschen haben, sondern auch einen Ozean voller toter Apps.

Sven Johann Ja, ich bin auf jeden Fall gespannt. Ich muss an ein früheres Projekt von mir denken, da haben wir ziemlich viel gemessen, wie die Software genutzt wird. Also eigentlich alles, ich würde mal sagen, in Anführungszeichen, hat der Produktmanager alles richtig gemacht. Es gab nie großartig upfront eine Definition, was das Ding machen soll, gab einen Haufen Ideen, die dann, wo wir iteriert haben und geguckt haben, wie nutzen die Leute das überhaupt. Da ist halt sehr viel Zeit reingegangen, zu gucken, also zu messen, wie die Leute das nutzen und dann noch diese Messungen auszuwerten. Und dann kamen zum Beispiel so Sachen raus, wie: Wir haben jetzt alles links und rechts rum gedreht. Dieses Feature interessiert keine Sau, egal, wo wir das platzieren, egal, was wir machen, es interessiert niemanden. Aber es kostet aus Operations-Sicht ziemlich viel Kohle. Also werfen wir es einfach weg. Und dann hatten wir zum Beispiel in so einem Review gesagt: Ja, was wir übrigens auch noch gemacht haben, wir haben die, also hieß irgendwie Peer Groups, wir haben die Peer Groups rausgeworfen. Aufschrei! Also Leute sind ausgeflippt, wütend, dass wir doch nicht einfach Features löschen können. Dafür hat doch jemand bezahlt, dass dieses Feature da ist. Ja, aber keiner nutzt es, es kostet ein Haufen Geld. Ja, aber wir haben doch dafür bezahlt. In dem Moment habe ich gedacht, oh Gott, jetzt kann man die Hoffnung aufgeben. Also wenn das die Denke ist: Ich habe für irgendwas bezahlt, was keine Sau will und was eigentlich totaler Schwachsinn ist, aber ich will es nicht wegwerfen, weil ich ja dafür bezahlt habe.

Daniel Westheide Klassische Sunk Cost Fallacy.

Sven Johann Ah.

Gerrit Beine Ja, aber das übersieht ja die laufenden Kosten des Betriebs, was Sven gerade meinte, nicht wahr?

Daniel Westheide Ja, ja.

Gerrit Beine Aber diese Argumentation ist halt genau diese Sunk Cost Fallacy und es ist völlig egal, wenn wir dem ganzen schlechten Geld noch jede Menge gutes Geld hinterherwerfen, weil ich ja schon mal dafür bezahlt habe. Der Film ist so schlecht, ich gehe im Kino nicht, auch wenn der Film so schlecht ist, weil ich dafür bezahlt habe.

Sven Johann Genau.

Daniel Westheide Das ist es leider.

Gerrit Beine Ja, so geht’s mir jedes Mal, wenn ich Filme im Kino sehe. Ich gehe nach 20 Minuten, weil die nicht zu ertragen sind.

Daniel Westheide Das ist.

Gerrit Beine Probier’s aber mal mit.

Daniel Westheide Das soll ja gut sein.

Sven Johann Machen wir mal einen kleinen Cut, weil sonst kriegen wir die anderen Themen nicht mehr durch. Oh, jetzt, also den finde ich ziemlich interessant, und zwar, also eigentlich ist wahrscheinlich alles interessant, aber machen wir den noch mal. Spezialwerkzeuge. Brooks sagt, statt dass jeder einzelne Programmierer seinen eigenen Satz an Spezialwerkzeugen nutzt, sollte jedem Team ein benannter Werkzeugmacher angehören, der solche Werkzeuge erstellt, die den Aufgaben des Teams genau angepasst sind. Also ich muss sagen, ich habe jetzt die letzten sechs Monate auf jeden Fall eine ziemliche Werkzeugflut erlebt, die uns das Leben einfacher machen, also das müssen wir bei mir im Projekt, weil es so einfach ist, Werkzeuge zu bauen, die uns irgendwann weg automatisieren, was man früher nie gemacht hätte.

Daniel Westheide Geht mir auch so.

Sven Johann Aber gibt es bei euch diesen einen Werkzeugmacher oder?

Gerrit Beine Nee. Also der eine Werkzeugmacher, das ist halt der Coding Agent, nicht wahr? Aber es ist nicht eine menschliche Person im Team, die all die Werkzeuge bei uns macht. Im Grunde auf Teamebene hast du das ja mit Plattformteams im Grunde.

Sven Johann Auf Multiteam-Ebene.

Gerrit Beine Ja, genau, die dann für alle anderen Teams Werkzeuge bereitstellen. Was aber auch spannend ist, wenn man jetzt mehr Werkzeuge hat, die machen ja nicht nur uns menschlichen Entwicklern im Team das Leben einfacher, sondern die kannst du ja dann auch wieder nutzen, wenn du mit Agents zum Beispiel Features umsetzt, als Tools für diese Agenten, um ein bisschen mehr Determinismus reinzubringen. Je mehr Tools du denen bereitstellst, was Bestimmtes tun können und sollen, dann sind halt weniger Freiheitsgrade da, wo man falsch abbiegen kann. Was ich mir da immer wünsche, ist, dass in dieser Agenten-Szene, Community, in diesem Entwicklungsansatz, dass man da mal anfängt, sich auf dieses Unix-Prinzip zu beziehen und sagt: Ich habe genau ein Tool für einen Zweck. Das hat ein paar Optionen, aber das kann ich halt immer wieder verwenden. Das ist ja so etwas, was teilweise so ein bisschen mit den Skills versucht wird, die man dann den Agents beibringt. Da fehlt mir aber genau wieder der Determinismus, weil der ganze Spaß ist halt nur eingeschränkt deterministisch. Und das ist, also da fehlt mir tatsächlich noch so ein bisschen Konsolidierung, aber ich denke, die wird auch kommen. Wenn das eine gewisse Verbreitung gefunden hat, werden sich da bestimmte Standards etablieren. Ich hoffe bloß immer, dass die Leute sich die nicht von LinkedIn holen, sondern tatsächlich aus der Praxis, aus dem konkreten Doing, sich das Zeug entwickelt.

Sven Johann Also ich meinte tatsächlich, als Werkzeug hatte ich jetzt gar nicht so an Skills gedacht, sondern an Tools, die wirklich Constraints Enforcer sind. Ich weiß nicht, ob das der richtige Begriff ist, aber OpenAI hat da so einen ziemlich schönen Artikel in ihrem Engineering Blog, wie die Software entwickeln. Klar, die haben halt Context Engineering als eine Säule, aber die haben halt, sie nennen das Architecture Constraints, wo die halt im Grunde genommen Tools haben, die die praktisch die Agents aufrufen oder die gewisse Vorgaben erzwingen. Du kannst, also der Agent hat einen relativ kleinen Spielraum, was er machen kann. Ein banales Beispiel ist, die haben ArchUnit-Tests, also haben sie nicht, aber so in unserer Welt würde man sagen, es gibt ArchUnit-Tests, die die so eine strukturelle, also die Struktur sicherstellen. Oder die haben Custom Linter, das ist bei uns zum Beispiel jetzt auch interessant, die halt querschnittliche Konzepte überprüfen, ob die wirklich so eingehalten wurden. Genau, also tatsächlich Tools war so meine Sicht darauf.

Gerrit Beine Nee, ich hätte jetzt bei Tools an Dinge wie Make, Set, AWK gedacht.

Sven Johann Hm.

Gerrit Beine Also das ist so die Ebene, wo ich über Tools nachdenke, die auch in ganz vielen Situationen adaptiert werden und die auch immer noch ständig benutzt werden. Also, wenn ich mir angucke, wenn ich hier Claude irgendwas an meinem Code machen lasse, wie oft das auf diese Tools zurückgreift in der Entwicklung, das ist erstaunlich. Man muss diesen Determinismus an irgendeiner Stelle in das System reinbringen, ansonsten funktioniert es halt nicht. Das war ja auch die wesentliche Erkenntnis, als sie sich diesen Code von Claude angeguckt haben, dass das meiste dieser Codegenerierung eigentlich auf regulären Ausdrücken basiert und nicht auf LLMs. Fand ich bemerkenswert.

Sven Johann Ja.

Daniel Westheide Ja.

Sven Johann Gut, haben wir noch was zum Thema Spezialwerkzeuge? Bisherige, ja?

Gerrit Beine Ich sehe da das gleiche Problem wie vorhin bei den Features. Es ist jetzt unglaublich leicht, Werkzeuge zum Wegwerfen zu produzieren. Und das Blöde ist, wenn man dann Prozesse aufbaut, die an diesen Werkzeugen hängen und diese Werkzeuge keiner mehr versteht, keiner mehr warten kann oder was noch schlimmer ist, diese Werkzeuge tatsächlich zu irgendeinem Zeitpunkt mal einen Prompt involvieren, was ein LLM triggert, etwas zu tun, was nicht dauerhaft zuverlässig ist. Weil das LLM irgendwann wegfällt, weil es eine neue Version gibt. Da gab es ja genug Experimente dazu, die gezeigt haben, ein Versionssprung funktioniert deine ganzen Prompts nicht mehr. Und das ist etwas, was ich in der Hinsicht für kritisch halte, aber da gilt halt auch wieder: Es wird sehr leicht, neue Dinge zu bauen. Die Frage ist, ob es wirklich trägt, ob es ein Fundament tragen kann. Und ich denke da manchmal, wenn ich das so mit Leuten diskutiere, vielleicht sollten wir langsam anfangen, für so etwas auch Engineering Practices nicht nur in Form von Büchern zu veröffentlichen, sondern tatsächlich auch in Form von Industriestandards festzuschreiben, wo man sagt, an die muss man sich halten, sonst darf diese Software beispielsweise nicht eingesetzt werden. Ja?

Sven Johann Ja. Also ab und zu habe ich ja schon Sorgen, weil ich habe neulich so eine Bücherbestellung für das nächste Schuljahr gemacht und die Software, es war halt so ein kleiner Schulbuchverlag, da habe ich gedacht, oh Mann, ey, also wenn du siehst, wie das funktioniert, habe ich mich tierisch aufgeregt und habe gesagt, wir reden hier darüber, was AI machen kann, aber selbst die einfachsten Dinge kriegen die Leute nicht hin. Und dann habe ich daran gedacht, was passiert eigentlich, wenn viele Leute jetzt AI in die Hand bekommen und du hast eben irgendwie Steuererklärung und so gesagt. Also Sachen, wo du wirklich, wo die aber da werde ich eigentlich relativ, also ich bin tatsächlich relativ entspannt, weil diese Standards gibt es ja jetzt schon, oder? Also ich meine, wenn du einen Extremfall, wenn du ein Safety Critical System baust, dann, also jetzt ohne dass ich da Einblicke habe, du weißt das wahrscheinlich besser, Gerrit, als ich, aber beim ISAQB, unser ehemaliger Kollege Lars Supe [unklar: Schreibweise des Namens im Audio prüfen], der hat ja mit so ein paar Leuten dieses, hat ja so formale Methoden als Modul eingebracht, und so im Sinne von, wir brauchen eigentlich, wenn Codegenerierung einfach ist, braucht, also vielleicht brauchen wir auch noch ein bisschen was anderes als Tests, sondern wir brauchen noch formale Methoden, die sagen, was tatsächlich sein soll. Mhm.

Gerrit Beine Genau. Ich kenne tatsächlich auch niemanden aus der Ecke, der irgendwie ein Fan von dieser Codegenerierung ist, aber das ist noch mal eine andere Diskussion, aber es ist genau das. Und wenn du das anguckst, Medizintechnikbereich, überall dort, wo Menschenleben gefährdet sind, hast du solche Standards. Das Problem ist, dass wir ganz viele Anwendungen für Bereiche entwickeln, in denen es solche Standards nicht gibt, wo es jetzt aber noch leichter wird, Fehler zu machen. Und meine Referenz für so etwas ist immer Cathy O’Neil, die hat vor, es kann 10 Jahre mittlerweile her sein, ein Buch geschrieben, Weapons of Math Destruction, also MATH, Mathematik, wo sie Beispiele zeigt, wo Softwareentwicklung auf Basis von Big Data, war damals das große Thema, komplett in die falsche Richtung läuft, wo Entscheidungen getroffen werden, die einfach nur Käse sind, Quatsch sind und so weiter und so fort, wo aber auch jetzt nicht Menschenleben gefährdet sind im Sinne von, da kann jemand sterben, aber wo Menschenleben gefährdet sind im Sinne von, da kann ich Existenzen vernichten. Und wenn ich jetzt anfange, so etwas mit AI zu entwickeln und da irgendwelche Modelle mir von einem Agent generieren lasse, die Risikobewertung oder irgendwelche anderen Geschichten machen, da ist halt ganz viel Fantasie drin, das war damals viel Fantasie drin, da ist heute viel Fantasie drin und ich meine, die schönste Story aus dem letzten Jahr in dem Bereich war ja diese Starbucks Geschichte, die führen irgendeine Software ein, die die Logistik für die Milch macht und nachdem die Software eingeführt worden ist, mussten, was weiß ich, 50.000 Starbucks Filialen weltweit, die Milch wieder mit der Hand abwiegen, weil die Software halt eine Genauigkeit von 99 % hatte, was erstmal gut klingt, was aber für den Arbeitsalltag völlig untauglich ist. Und das sind Dinge, die haben halt Leute, die das nicht gelernt haben, also das Denken in Konsequenzen nicht gelernt haben, haben die halt nicht auf dem Schirm. Die sagen halt, ja, super, wir haben damit Software generiert, die hat 99 % Treffsicherheit, total genial, klingt ja gut, raus damit und dann gibt es auch noch Leute, die kaufen den Kram.

Daniel Westheide Um mal auf einen anderen Blogpost von mir einzugehen, die hätten vorher, glaube ich, einen Monat bei Starbucks in der Filiale arbeiten müssen, die das entwickelt haben.

Gerrit Beine Genau. Genau. Das ist genau der Punkt. Aber es wird halt unglaublich leicht, Lösungen für Probleme zu produzieren, die es gar nicht gibt. Und du wirst immer jemanden finden, der den Arabern Ölheizungen verkauft, weil das ist halt was Großartiges, wenn es mal kalt wird. So eine Ölheizung. Und dann kaufen die Leute das.

Sven Johann Ach ja.

Gerrit Beine Da werden lustige Dinge, also lustige in Anführungszeichen, in großen Anführungszeichen lustige Dinge.

Sven Johann Ja, also ich gucke auf jeden Fall mal in, packen wir nicht schon Weapons of Math Destruction, weil ich muss automatisch an diese, weil du sagst, da werden Existenzen zerstört, da muss ich automatisch an diese Story vom UK Parcel Service oder Post Office denken, wo es halt auch irgendein Software-Bug gab, der zu Problemen in der Kasse führte, also da war die Abrechnung nicht korrekt. Und dann haben die halt gesagt, die Software macht keine Fehler, das müssen die Clerks in den Postal Offices sein. Und dann wurde geklagt und hin und her und manche Leute haben sich umgebracht, aus Verzweiflung, weil denen da irgendwie, was weiß ich, was angeklagt wurde, weil denen die Existenz weggeklagt wurde und dann waren schon ein Haufen tot. Und dann kam raus, ja, ups.

Gerrit Beine Ja.

Sven Johann War doch die Software. Und so, also vor so Sachen habe ich tatsächlich ein bisschen Schiss, weil diese Sachen, die jetzt nicht ganz so kritisch sind, aber halt wo du mit, wo man dann aber trotzdem sicherstellen, also wo es, wo es heute schon ein bisschen schiefgeht, dass halt, na ja, wir triften ein bisschen ab von Spezialwerkzeugen.

Gerrit Beine Nee, das ist gar nicht so sehr das Abdriften, weil das ist ja eine, das ist durchaus eine Kette, die sich so fortsetzt. Cathy O’Neil hat an einer Stelle einen Fall zitiert, ich glaube, das war in den Niederlanden, wo die Arbeitsämter eine Software eingeführt haben, die auf Grundlage deiner Unterlagen anhand von einem statistischen Modell bewertet hat, ob es sich lohnt, dir irgendwie eine Weiterqualifikation zu geben, wenn du arbeitslos wirst oder nicht. Und wenn die Software halt entschieden hat, nö, dann bist du halt aus dem kompletten System rausgefallen.

Sven Johann Computer says no.

Gerrit Beine Computer says no, genau, das ist das Prinzip. So, und jetzt haben wir aber ein LLM, das nicht nur einfach „no“ sagt, sondern das uns auch noch eloquent erklären kann, warum es „no“ sagt. Wenn wir jetzt Leute haben, die keine Ahnung von Softwareentwicklung haben, die also nicht wissen, wie Entscheidungen im Prozessor zustande kommen, dass es immer irgendwie auf Register und If-Anweisungen und irgendwelche Jumps zurückzuführen ist, was da technisch passiert. Wenn wir dann solche Leute haben, die jetzt für genau diese Branchen günstige Lösungen anbieten, und gerade der deutsche öffentliche Dienst ist ja angehalten, die wirtschaftlichste Lösung einzukaufen, dann werden wir unter Umständen – das ist jetzt keine Prophezeiung, aber man kann ja aus der Vergangenheit ein paar Muster erkennen, die sich fatalerweise nicht bewährt haben, aber trotzdem beibehalten werden – dann kann es durchaus dazu führen, dass wir anfangen, Software zu kaufen und Softwaresysteme zu nutzen, die zu teilweise fatalen Konsequenzen führen können. Und die halt auch in die Lebenswirklichkeit von Leuten auf eine Weise eingreifen, wo man Leute hat, die Experten sind, wo man Leute hat, die Benutzer sind, und Leute hat, die Betroffene sind, und dann plötzlich noch eine dritte Kategorie eingeführt wird, weil die Betroffenen ganz, ganz weit weg sind. Und das sind so die Stellen, wo ich mir wirklich Gedanken mache, ob wir nicht für solche Bereiche auch Engineering Standards brauchen.

Sven Johann Ja, ja, ja, ja, ja, ja.

Gerrit Beine Ich glaube, der Bereich, in dem wir bisher Engineering Standards haben, muss, wenn wir KI benutzen, viel, viel größer werden, weil wir mehr Probleme mit Software lösen können und das auch getan werden wird. Das ist jetzt kein Argument gegen AI-Based Coding oder so etwas, das ist nur ein Argument dafür, dass wir eine Strategie brauchen, um damit umzugehen.

Sven Johann Mhm.

Gerrit Beine Das braucht es halt, ne? Also, ich würde auch nicht auf Code verzichten wollen, weil mir das an ganz vielen Stellen hilft in meiner Entwicklungsumgebung und JUnit und wie sie alle heißen, die da im Hintergrund wirken. Das ist völlig okay, aber es ist trotzdem die Frage, wo sind meine Engineering Standards und ist das, was da an Resultat rauskommt, angemessen für das Problem?

Sven Johann Ja, also ich hatte neulich mit einem ehemaligen Kollegen von mir geredet. Der hat sich, also der war nie Softwareentwickler, aber der war in der Softwarebranche, war halt Testmanager und solche Dinge. Und der hat jetzt seinen Vice President Job bei einer Bank aufgegeben, um sein eigenes Software-Startup zu gründen. Er hat jetzt so ein Tool entwickelt und meinte, ja, Entwicklung ist demokratisiert und so, und jetzt habe ich hier mein Startup und hier ist meine Software. Und dann hat er so erzählt, was er macht, und ich habe gesagt, oh Mann, ey, ich würde das Ding nie kaufen, weil ich habe einfach Angst. Du weißt ja nicht genau, wie Software funktioniert. Also, ich meine, du bietest da so ein SaaS-Ding an und du hast keine Ahnung, was dieses SaaS-Ding macht, und dir soll ich irgendwie Geld geben? Nee, sorry. Also, das ist wahrscheinlich die Sache, dass es einen Haufen Systeme gibt, wo Leute, die keine Ahnung von Entwicklung haben, jetzt Produkte anbieten.

Gerrit Beine Ja.

Sven Johann Na ja. Ja, auf jeden Fall ein interessanter Gedanke. Also, das ist ein interessanter Gedanke. Ich würde sagen, diese Sorge teile ich, dass Dinge auf den Markt kommen, denen man nicht vertrauen kann, und woher weißt du das? Du weißt es ja initial nicht.

Gerrit Beine Genau, das ist genau der Punkt.

Sven Johann Okay, ich mache mal weiter, wir haben schon 40 Minuten. Ich gehe mal zum nächsten Ding, und zwar das Ärzteteam. Auch wieder super interessant, passt eigentlich zu unserer Diskussion, die wir eben hatten, finde ich. Ärzteteam, sagt er, ähnlich wie ein Ärzteteam von einem Chefarzt geleitet wird, der selbst operiert und von seinem Team bestmögliche Hilfestellung erhält, erscheint es vernünftig, kritische Systemkomponenten von einem guten Programmierer entwickeln zu lassen, während der Rest des Teams nach Bedarf zuliefert. Brooks sinniert weiter, dass gute Programmierer meist – na ja gut, jetzt lese ich nicht mehr weiter, weil es wehtut, weil meist fünf bis, ah nee, fünf bis zehnmal so produktiv. Ah, nein, sag es nicht. Wie mittelmäßige, ich kann jetzt nicht mehr weitermachen. Okay. Jetzt hat es sogar. Aber okay, also, aber ich glaube, das Ding ist klar, ne? Also, wenn es irgendwas Kritisches gibt, den kritischen Code, also ich sag mal, wir haben ein Billing System oder wahrscheinlich beim Post Office (UK), die Abrechnung hat vielleicht nicht der gute Programmierer gemacht, sondern der Praktikant oder so. Da würde ich sagen, das war schon lange richtig so, dass die kritischen Sachen die sehr, sehr, sehr, sehr, sehr seniorigen Leute machen sollten. Und wie ist das zukünftig, wie seht ihr das? Also, kritische Komponenten, wie entwickelt man die jetzt, werden die anders entwickelt? Ich meine, die Antwort haben wir schon gegeben, ne? Sollte man kritische Komponenten anders entwickeln als andere, wenn man so einen Agent zur Hand hat?

Gerrit Beine Also Glue Code kann ich problemlos von Claude entwickeln lassen. Aber das, wo die Intelligenz reingehört, das ist etwas, da würde ich auf jeden Fall die Menschen draufsetzen. Ich muss aber auch wieder sagen, ich würde die – also das, was Brooks da als Produktivität von Programmierern referenziert, würde ich nicht mit Seniorität gleichsetzen, weil ich schon ein paar Leute kennengelernt habe, die in sehr, sehr jungen Jahren unglaublich genial waren, was Coding angeht, und ich gleichzeitig sehr seniore Menschen kennengelernt habe, denen es auch gegen Ende ihrer Karriere immer noch schwergefallen ist, bestimmte Dinge – also die haben ihren Job gemacht und es war auch immer okay – aber denen es auch bis zum Ende ihrer Karriere schwergefallen ist, bestimmte Problemstellungen nachzuvollziehen und eine sinnvolle Software zu diesen. Also, ich würde nicht Seniorität da als das Kriterium nehmen, sondern eher wirklich, was für einen Fabel, was für ein Talent haben die Leute für Problemlösung.

Sven Johann Hm.

Gerrit Beine Daniel, was sagst du dazu?

Daniel Westheide Hm. Ja, also ich finde diese Analogie mit dem Chefarzt und dem OP-Team drumherum eigentlich grundsätzlich, auch schon abseits von agentischer Entwicklung, ein bisschen problematisch. Ich weiß nicht, ob ihr das Buch Impact Players kennt von Liz Wiseman. Da muss ich dran denken, weil da auch über einen OP-Assistenten so eine Anekdote drinsteht, der heißt Jojo. Und das ist ganz interessant, der hat dann halt mit Assistenzärzten natürlich zusammengearbeitet im OP-Saal, die natürlich formal in der Hierarchie irgendwie höher gestellt waren. Und wenn so ein Arzt dann ein Instrument anfordert, dann reicht Jojo aber eben nicht das verlangte, sondern das, was der Chirurg hätte verlangen sollen. Weil Jojo so viel Erfahrung hat, dass er eigentlich schon antizipiert, was jetzt hier wirklich gebraucht wird. Und wer jetzt hier vielleicht die meiste Expertise hat, ist dann oft auch kontextabhängig, ne? Und ich glaube, ja, also, ja. Eigentlich ist das, was da im OP-Saal dann passiert, mehr Ensemble Programming als das, was Brooks sich da gedacht hat, dass der Chefarzt halt die Anweisung gibt und die anderen nur zuliefern. Die müssen halt auch viel mitdenken. Und oft denken sie Dinge mit, die der Chefarzt vielleicht gar nicht bedacht hat. Oder das ist ja auch nicht immer ein erfahrener Chefarzt, wie gesagt, so ein vielleicht auch jemand mit weniger Berufserfahrung. Ja.

Sven Johann Also, ich hätte es jetzt für mich ein bisschen anders interpretiert. Für mich war das eher so, der Agent ist sozusagen mein oder meine Agents sind mein Team und ich bin der Chefarzt, ja? Und zum Beispiel unser Kollege, also Jochen Christ, der ja mit Simon Harrer Entropy Data gegründet hat, der hat ja neulich erzählt, na ja, so banale Features, die macht der Agent, also da rührt er gar nicht mehr. Der Code wird generiert, da gibt es Tests, das Ding geht live, fertig ist die Laube. Aber bei kritischen, also alles, was kritische Systemkomponenten sind, ja, da sind die natürlich dann wieder anders drauf. Da gucken die dem Ding auf die Finger, also mehr auf die Finger, da gibt es mehr Anweisungen, da wird mehr selbst gemacht, und ich wollte eigentlich in diese Richtung hin, dass so, also Gerrit hat ja irgendwie gesagt, so irgendwann, also jetzt neulich vor ein paar Minuten, so banale Codegenerierung kann man einfach machen lassen, aber es gibt halt, also je kritischer es wird, desto weniger, also desto mehr sollte man selbst machen, ja? Wäre so meine, wäre so meine Interpretation gewesen. Desto mehr muss ich drauf gucken.

Gerrit Beine Das ist quasi auch das, was ich häufig in Trainings mit Leuten diskutiere im Kontext mit Domain Driven Design. Das Domain Model, das schreiben wir schön von Hand, weil da steckt die Intelligenz drin, die Fachlichkeit, das ist quasi unser Asset. Das müssen wir auch bis ins letzte Detail verstanden haben, aber wenn wir nach draußen gehen, haben wir irgendwann mal so an beginnend so Mappings, wo wir so DTOs in JSON verwandeln oder aus irgendeinem Fremd-DTO, was kommt, eine Transformation in unseres machen müssen und so etwas. Das sind Bereiche, da würde ich wirklich sagen, also das kann ich einen Agent machen lassen, weil A ist es sehr, sehr einfach dort zu erkennen, dass etwas schiefgeht. Also die Möglichkeit, den Fehler zu sehen, ist bei solchen Situationen sehr, sehr groß. Gleichzeitig ist das etwas, was leicht austauschbar ist, wo ich wenig Implikationen auf Fachlichkeit habe, wo ich keine Abstimmung mit Domain Expertinnen brauche, um eine Entscheidung zu treffen, und da halte ich es für vollkommen unkritisch – vollkommen unkritisch in Anführungszeichen, ne, aber für durchaus vertretbar, sage ich, es kriegt besser – für durchaus vertretbar dort Agent Based Coding und so etwas einzusetzen und dann auch zu sagen, das reviewe ich nicht mehr, weil ich habe zwei Enden, wo ich jeweils ein fertiges Modell habe, und wenn da was schiefgeht bei der Transformation, das kracht halt, das sehe ich. Ja, also würde ich halt sagen, okay, das war jetzt auch nicht unbedingt den Code reviewen, sondern dann sage ich halt, wenn es gekracht hat, Code Agent bitte noch mal, ne? Aber beim Domain Model, das wäre zum Beispiel was, wo ich da möchte ich jede Zeile per Code persönlich kennen. Das ist.

Sven Johann Mhm.

Daniel Westheide Ja, ich hatte mir das Kapitel ja auch dann noch mal genauer durchgelesen zum Ärzteteam. Was ich ziemlich lustig fand, war, dass da auch dieser Begriff des Copilot auftauchte. Ich weiß nicht, ob ihr das auch noch mal gelesen hattet. Der Copilot, da schreibt er, his main function is to share in the design as a thinker, discussant and evaluator. He researches alternative design strategies, he may even write code, but he is not responsible for any part of the code.

Sven Johann What?

Daniel Westheide Und ist ja vielleicht kein Zufall, dass wir so ein paar AI-Produkte namens Copilot haben, habe ich dann gedacht. Und vor allem der Teil, dass sie nicht Verantwortung übernehmen, das ist nun mal auch so. Sie treffen aber ganz viele Entscheidungen, während sie umsetzen, und wir müssen dann am Ende die Verantwortung übernehmen als Menschen.

Sven Johann Am Anfang musste ich ein bisschen lachen, aber der letzte Teil ist eine Diskussion, die ich öfter höre: Der Entwickler ist dafür verantwortlich, obwohl jemand anderes es macht. Du kannst sagen, der Agent hat es gemacht, aber du bist derjenige, der die Entscheidungen trifft. Die Ausführung macht vielleicht jemand anderes, aber du bist letztendlich die Person, die die Verantwortung übernimmt.

Daniel Westheide Genau. Aber diese Rolle des Copiloten wird ja oft auch mittlerweile von AI übernommen, dieses ‘Share in the Design as a Thinker, Discussant and Evaluator’. Ich erwische mich ja auch immer wieder dabei, wie man seine Designüberlegungen mit dem AI-Assistenten diskutiert, statt mit dem eigenen Team.

Sven Johann Ich finde, bevor man zum Team geht, ist das völlig in Ordnung.

Daniel Westheide Ja, aber das ist, glaube ich, dann auch schon so, wie Gerrit gesagt hat, dass auch wenn man versucht gegenzusteuern, oft die eigene Richtung einfach nur bestätigt wird. Zumindest auf einer höheren Ebene. Vielleicht wenn man die Details kritisiert, aber es sagt ja halt selten, dass du komplett in die falsche Richtung abgewogen bist.

Sven Johann Letzten Endes würde ich nie sagen: „Hier ist mein Entwurf, mach mal eine Designkritik.“ Sondern ich müsste eigentlich immer sagen: „Hier sind die Optionen, die ich habe, hier ist der Kontext und hier sind die Kriterien. Was denkst du?“ Dann kann er eigentlich gar nicht so genau, also dann kriegst du eine Meinung, aber meiner Meinung nach auch nur dann, wenn das klassische Probleme sind. Wenn es wirklich ein extrem kontextspezifisches Problem ist, dann würde ich sagen, das kann man komplett vergessen, ist eigentlich immer Schrott. Aber neulich, also ist ja auch schon wieder ein bisschen länger her, so nach dem Motto: „Wir machen Canary Releases, wir haben folgende Optionen, hier ist ein bisschen Kontext.“ Ich meine, es war immer noch eine schlechte Entscheidung, weil der Kontext sehr entscheidend war, aber du kannst zumindest mal sagen: „Hier sind die Optionen, kannst du dann noch mal ein paar, kannst du mal gucken, welche Vor- und Nachteile da vielleicht fehlen oder die falsch sind.“

Daniel Westheide Ja. Man könnte sagen, das, was er als Copilot beschreibt, sollten weiterhin Menschen sein. Und eigentlich sind das in meiner Erfahrung auch meistens nicht nur einzelne Personen, sondern das gesamte Team.

Sven Johann Hm.

Daniel Westheide Mit dem man sich austauscht.

Sven Johann Ja, ich meine, das lese ich übrigens jetzt auch häufiger. Daniel und ich hatten ja mal vor Ewigkeiten einen Podcast gemacht, der hieß, der Titel war etwas unsexy, ‘Was ist Programmieren?’, aber eigentlich ging es da um ‘Theory as Model’, nee, ‘Model Build Theory of Model Building’.

Daniel Westheide Programming as Theory Building.

Sven Johann Programming as Theory Building, genau. Und ich meine, da war ja damals, also vor, wie alt ist dieses Paper, bestimmt auch schon 50 Jahre alt.

Daniel Westheide Mitte der 80er, glaube ich.

Sven Johann Oder okay, ja, da war ja auch schon die Sache, also Softwareentwicklung ist nicht das Tippen von Text, sondern wir haben alle ein gemeinsames Modell im Kopf, um was es geht, und das muss irgendwie passieren. Und das ist ja hier genau das Gleiche. Du musst die wichtigen Sachen mit allen besprechen, damit alle dieselbe Vorstellung haben, um was es geht.

Daniel Westheide Ja.

Sven Johann Alright, ich gucke auf die Uhr. Ich würde vielleicht noch mal einen haben wir noch, wir hätten noch zwei, aber ich glaube, die schaffen wir nicht mehr. Und zwar geht es in diese Richtung, die wir jetzt auch schon wieder hatten, die wir die letzte Zeit, die letzten Minuten hier verfolgt haben, und zwar hat Fred Brooks 1975 gesagt: „Build one to throw away.“ Also, was er damit meinte, war, ja, wir müssen erstmal ein System bauen, dann wissen wir, wie es geht, und dann werfen wir das Ding weg, und dann das zweite System, das wird dann das wirkliche System, ja? Und da hat er ja 25 Jahre später gesagt, na ja, das war eigentlich eine scheiß Idee, weil das Wasserfallmodell ist doof. Und besser ist doch iterative Entwicklung, ne? Wobei man sagen muss, also 1976 hat Winston Royce schon gesagt, das Wasserfallmodell ist doof. Wir machen besser iterative Entwicklung. Aber okay, die nächsten 25 Jahre hat sich eh keiner dran gehalten und die nächsten 30 Jahre. Aber da kam mir so in den Sinn, so Iteration im Agentic AI Zeitalter, ja? Also da man liest irgendwie bei LinkedIn, ja, ich habe hier heute noch mal 75.000 Zeilen Code geschrieben und so weiter, ne, und dann denkt man so, oh, Wahnsinn, ne, was machen die Leute? Und auf der Gegenseite, also da denke ich immer, ich komme da gar nicht mehr hinterher, ne? Und zum Beispiel Kent Beck sagt, wir müssen immer noch, also wir müssen immer noch höchst iterativ arbeiten, weil wir dieser Software auch irgendwie geistig folgen können. Na? Also du kannst eigentlich gar nicht mehr, also wir haben ja immer so gelacht, ne, der Wasserfall kommt zurück. Wir müssen jetzt mit Spec Driven nur noch sagen, was wir wollen, und dann wird das in einem rausgehauen. Also das macht mich wahnsinnig, ja. Aber okay, ist natürlich eine Option. Wie seht ihr das?

Daniel Westheide Also erstmal finde ich wegwerfen tatsächlich gar nicht so blöd. Muss ja nicht gleich ein ganzes System sein, aber ich glaube, die Praxis, einen Spike zu entwickeln in einer beschränkten Zeit, das verträgt sich ja auch mit iterativer Entwicklung. Ja. Aber ich glaube, das ist jetzt wichtig, wenn man jetzt agentisch entwickelt, hilft es, glaube ich, wenig, einfach den Agenten den Spike entwickeln zu lassen, weil es ja hauptsächlich ums Lernen und Verstehen geht. Meistens macht man das ja, wenn man was Neues ausprobiert, wo man sich noch unsicher ist, wie es funktioniert und ob es funktioniert.

Sven Johann Ja, und wie es sich anfühlt, ne? Also so ein bisschen, ja, ja, ja.

Daniel Westheide Und jetzt könnte man natürlich schön sagen, das ist ja jetzt noch viel billiger, den Spike zu entwickeln. Dauert irgendwie nur 5 Minuten oder 10, der Agent macht das schon. Aber dann ist das, glaube ich, irgendwie an dem Punkt vorbei, worum man das macht. Das erstmal ein Punkt dazu. Vielleicht hat Gerrit ja noch andere Aspekte.

Gerrit Beine Ja und nein, also ich stimme dir zu und widerspreche dir. Die Frage ist tatsächlich, in welche Richtung zielt der Spike? Geht es darum, Know-how aufzubauen, wie ich das technisch realisiere? Dann hast du absolut recht, dann bringt es nichts, das den Agenten machen zu lassen. Wenn es darum geht, einen Spike zu bauen, im Sinne von, ich will mal gucken, ob dieses Feature funktioniert, ob Leute das benutzen wollen, wie das zum Rest der Software passt, dann ist es vollkommen egal, ob ich das programmiere oder der Agent, weil dann ist das Lernen in einem anderen Bereich. Ich würde tatsächlich an der Stelle immer die Frage stellen, in welcher Domäne will ich was lernen? Im technischen Realisieren oder in der fachlichen Nützlichkeit? Und dann kann ich diese Entscheidung auch treffen, und da, wie gesagt, wenn es um die Fachlichkeit geht, kann es problemlos auch der Agent machen, wenn ich weiß, wie es technisch geht.

Daniel Westheide Ja, ja, das auf jeden Fall.

Gerrit Beine Genau, das würde ich wieder differenzieren. An sich hast du aber recht, ne? Also beim Spike geht es darum, etwas zu lernen, und das darf ich nicht aus den Augen verlieren. Spikes sind in der agilen Softwareentwicklung etwas völlig Normales. Es wird nur ungern von den Menschen dann weggeworfen. Das ist immer so das Problem. Wenn ich vor 15, 16 Jahren als Scrum Master unterwegs war, war immer eine meiner größten Schwierigkeiten, meine Entwicklungsteams dazu zu bringen, mal geschriebenen Code wirklich wegzuwerfen, weil den hat man ja geschrieben. Den könnte man ja noch gebrauchen. Und da ist irgendwie so ein Punkt, das macht man nicht gern. Und das kann man einfacher machen.

Daniel Westheide Das ist natürlich was.

Gerrit Beine Bitte?

Daniel Westheide Jetzt geht es halt einfacher, glaube ich, auch mental zu sagen, das werfe ich weg.

Gerrit Beine Genau, was der Agent hat, ist nicht mehr der eigene Code. Das könnte so sein, ich weiß es nicht. Es ist zu kurz, um da zu sagen, das ist irgendwie die eine oder die andere, aber das könnte eine Möglichkeit sein, sich davon leichter zu trennen. Aber ja, wir werden sehen, was da passiert. Aber grundsätzlich würde ich mir das auch wünschen, mehr in Prototypen zu denken und zu sagen, ich schmeiße den Code weg. Bin ich ein großer Fan davon, Dinge wegzuwerfen. Also Code wegzuwerfen. Auch wenn ich vor und gegen dieses Meer aus Plastikflaschen Code argumentiert habe, das ist nicht unbedingt, wie soll ich sagen, konsistent meine Argumentation an der Stelle, aber wir reden ja an der Stelle über konzeptionelle Artefakte, von daher hing vielleicht auch der Vergleich mit diesem Plastikflaschen.

Sven Johann Ja, ich habe mir gerade noch mal notiert, auch für die Shownotes, was vielleicht sehr gut reinpasst, ist dieses Big Ball of Mud Paper, das ja auch schon wieder 35 Jahre alt ist oder so. Und die sagen ja, die Metapher ist eigentlich der Carport. Also da sagt jemand, ah, wir machen das mal schnell, wir probieren das mal aus, oder wir bauen es schnell und dann machen wir es richtig, und dann wird es nie richtig gemacht. Nichts hält länger als das Provisorium, weil halt niemand etwas wegwerfen will. Ja. Ich bin auf jeden Fall auch gespannt. Aber noch mal vielleicht ganz kurz zurück zu diesem Kent-Beck-Ding, dass wir geistig folgen müssen. Das beschäftigt mich tatsächlich immer noch ziemlich, was so iterative Entwicklung angeht, Sachen machen und dann wieder Ideen wegwerfen, weil man plötzlich sieht, es geht ja nicht nur um die Codequalität an sich oder Daniel hat gesagt, wir wollen was lernen. Aber ich meine, auch während dem Entwickeln, das ist Kent Becks Argument, du kriegst eine Anforderung und dann fängst du an, also früher sozusagen, dann fängst du halt an zu entwickeln und während dem Entwickeln fällt dir auf, hm. Also eigentlich haben wir dieses und jenes nicht bedacht. Dann müssen wir noch mal zurück, die Anforderung machen, ne?

Gerrit Beine Ja, bitte?

Sven Johann Fachlich, genau.

Gerrit Beine Fachlich, genau.

Sven Johann Genau, dass man sagt, irgendwie passt das nicht. Wenn du jetzt, wie läuft das? Muss man das nicht beibehalten? Das ist das eine, dass du merkst, da passt fachlich etwas nicht. Zum anderen ist der zweite Punkt, wir müssen geistig hinterherkommen. Wenn du jetzt in großen Chunks Code raushämmerst, dann verlierst du dieses geistige Modell der Software. Vielleicht braucht man das auch gar nicht mehr, vielleicht gibt es andere Möglichkeiten, aber keine Ahnung. Ich bin auf jeden Fall gespannt. Meine Meinung ist, ich programmiere ja gar nicht mehr so viel, aber wenn, dann versuche ich immer in möglichst kleinen Iterationen zu arbeiten. Die gehen jetzt viel schneller, aber ich will trotzdem, meine Iterationsgröße bleibt gleich. Der Code, der erzeugt wird, die Zeit für die Codeerzeugung ist viel kürzer, aber ich kann gar nicht schneller gehen, weil ich einfach nicht mehr hinterherkomme. Ich verstehe gar nicht mehr, worum es geht. Ich sehe Nicken.

Gerrit Beine Ja.

Sven Johann Es gibt Zustimmung.

Gerrit Beine Mir geht es ähnlich. Ich habe auch das Problem, dass ich durch den Job nicht mehr so viel zum Programmieren komme. Wenn ich etwas mache, dann in kleinen Schritten. Aber der Inhalt, das, was ich in so einem kleinen Schritt heute schaffe, mit Unterstützung von Junie, Claude und Co, ist mehr als das, was ich vor vier, fünf Jahren in so einem Schritt geschafft habe. Aber es bleibt ein kleiner Schritt. Ich probiere es auch manchmal aus, dass ich sage: „Hier, ich gebe dir mal eine komplette Spezifikation, mach mir mal die komplette Lösung.“ Die taugt dann meistens nicht. Das ist der Punkt, dass das kleine, schnelle Iterieren etwas ist, das funktioniert immer noch gut.

Sven Johann Ich muss gerade noch an Kent Beck denken, der irgendwann mal diese Metapher hatte, wo Steine im Wasser liegen. Am besten und sichersten springt man von Stein zu Stein. Aber irgendwann wird man risikofreudiger und überspringt mal einen Stein, weil die Steine so eng beieinander liegen, dann denkt man, das ist irgendwie doof. Und dann überspringst du so einen Stein und schwupp, liegst du im Wasser, weil man besser kleine Schritte macht. Daran muss ich gerade noch mal denken. Dann denkt man so, ja, jetzt könnte ich vielleicht noch mal einen größeren Chunk generieren lassen und schon liegst du auf der Nase. Dann musst du auch wieder zurück. Okay. Ich glaube, ich muss irgendwann noch mal Adrian Cockcroft für so einen Podcast einladen, weil Adrian Cockcroft ist offensichtlich kein Blöder, aber der ist ja eigentlich der, der ständig bei LinkedIn schreibt: „Oh, heute noch mal 50.000 Zeilen Code generiert für meine Software.“ Aber das ist halt alles nur, die Software hat halt immer nur einen Nutzer, er selbst. Das ist vielleicht dann auch noch mal so ein Unterschied.

Gerrit Beine Ja.

Sven Johann Okay.

Gerrit Beine Der darf das dann auch. Der kennt die Teergrube.

Sven Johann Ja, genau. Es ist ja auch kein Produkt. Es ist keine Software für eine Person, die er da macht.

Gerrit Beine Ja.

Sven Johann Alright, wir sind etwa 5 Minuten über der angepeilten Zeit. Ich weiß nicht, ob ihr noch letzte Worte habt.

Gerrit Beine Es bleibt spannend.

Daniel Westheide Ja.

Sven Johann Ja, das denke ich auch. Ich frage mich halt, ob es in einem Jahr oder so noch mal so einen entscheidenden Moment gibt, wo die Modelle so viel besser sind, dass das vielleicht.

Gerrit Beine Ja.

Sven Johann Dass die Aussagen dann noch mal revidiert werden müssen, aber.

Gerrit Beine Ja, vielleicht müssen wir in einem Jahr eine dritte Folge machen, wo wir uns dann darüber lustig machen, wie falsch wir lagen oder so.

Daniel Westheide Das finde ich cool. Ich frage mich aber die ganze Zeit, was kommt nach den Agents?

Sven Johann Wir hatten, also der Podcast „Jung und Naiv“ macht ja immer seine Politik-Predictions. Ein Jahr später machen sie neue Politik-Predictions, aber schauen noch mal darauf, welche falsch waren. Das wäre vielleicht auch noch mal so eine Sache, in einem Jahr noch mal oder überhaupt mal so AI Software Engineering Predictions zu machen und dann ein Jahr später noch mal drauf zu gucken, wie ist es denn eigentlich gelaufen?

Gerrit Beine Ja.

Sven Johann Ja, es bleibt spannend. Es gibt einen Haufen spannender Themen, weil ich sage, die Modelle werden besser. Wahrscheinlich werden sie besser, vielleicht werden sie auch schlechter, da bin ich auch noch gespannt, wäre vielleicht auch noch mal so ein Thema. In den USA bekomme ich jetzt mit, dass viele Empfehlungen sind, nichts mehr öffentlich zu machen. Alles, was ihr früher vielleicht in einem Engineering Blog veröffentlicht habt, macht es einfach nicht mehr. Alles bleibt intern, weil der Engineering Blog im Prinzip nur Lernmaterial für LLMs ist. Wir bekommen das jetzt auch mit, Johannes Link, der, glaube ich, bei J Unit 5 dabei war und ein Property Based Testing Framework für Java entwickelt, sagt, dass es eine Anti-Gen-AI-Bewegung gibt, wie man Lernergebnisse verschlechtern kann, indem man Anweisungen in den Code schreibt, sodass das Lernen schlechter wird. Ich könnte mir vorstellen, dass das viel mehr wird.

Gerrit Beine Ja.

Sven Johann Und die Modelle vielleicht sogar schlechter werden.

Gerrit Beine Die Frage ist, ob das etwas bringt, weil wenn ich Text schreibe, der dazu führt, dass die LLMs schlechter lernen, werden die LLM-Leute nachziehen und ihren LLMs beibringen, beim Training genau solche Textfragmente zu ignorieren. Das sind ja immer so Schnellschüsse, das trägt halt nicht. Ich halte mehr davon, dass man Differenzierung macht, dass man auch nicht ausweist, was AI-generiert ist, sondern dass man eher ausweist, was von Menschen gemacht ist. Dass man sagt, ich honoriere das mit einem entsprechenden Wert, den Unterschied zwischen meinem italienischen Restaurant, wo ich gerne hingehe, versus McDonald’s. Da honoriere ich halt, dass die Pizza von Hand gemacht wird und ich sehe, dass die entsteht und so. Da kannst du ja durchaus so Differenzierungen reinbringen. Aber ich meine, ich habe auf meinen Servern auch die kompletten IP-Ranges von Meta geblockt, weil die mir einfach zu viel Last produzieren, wenn die da meinen kompletten Server abscannen, mein Portfolio. Das ist mir zu viel, aber prinzipiell ist das etwas, das können wir im Internet nicht verhindern, dass das passiert. Und dann ist die Frage, ob wir aufhören zu publizieren oder nicht. Zu schweigen kann an der Stelle halt keine Option sein und irgendwelchen Fake da reinzumachen, macht mir persönlich viel zu viel Arbeit.

Sven Johann Ja, ich hatte neulich in einem US-Podcast gehört, da ging es darum, dass OpenAI oder Anthropic versucht hat, Deep Seek zu verklagen, weil Deep Seek eine Model Distillation gemacht hat und sie meinten, die hätten von ihnen geklaut. Die Gegenaussage war: „Ihr habt von der gesamten Menschheit geklaut. Das ist Quatsch.“ In diesem Zusammenhang kam heraus, dass sie von der gesamten Menschheit geklaut haben und das jetzt verkaufen. „The biggest theft of all time.“ In den USA gibt es anscheinend eine Bewegung, dass sogar viele republikanische Senatoren darauf schauen, dass die LLMs als Public Good verstaatlicht werden müssen, weil die Daten Public Good waren. Da bin ich auf jeden Fall gespannt, was sich in der Richtung tut, weil das ist schon ein riesen Ding. Man will eigentlich publizieren, aber das ist halt so schwierig.

Gerrit Beine Hm.

Daniel Westheide Ich würde sagen, wir publizieren unseren INNOQ Podcast trotzdem.

Sven Johann Wir publizieren den trotzdem und wir publizieren auch – ich publiziere ja keine Artikel, aber Gerrit und Daniel publizieren weiterhin schöne Artikel. Machen wir. Die übrigens natürlich auch etwas können, was die AI nicht kann: Original Thought. Ich weiß gar nicht, wie man das auf Deutsch sagen würde.

Gerrit Beine Ja, muss man die AI fragen.

Sven Johann Ja.

Daniel Westheide Originelles Denken?

Gerrit Beine Kreatives Denken?

Sven Johann Ja, kreatives Denken, vielleicht ist das richtiger.

Gerrit Beine Ja.

Sven Johann Okay, jetzt aber, für alle, die es bis hierhin geschafft haben, vielen Dank. Und vielen Dank an euch und bis zum nächsten Mal.

Gerrit Beine Sehr gerne.

Daniel Westheide Bis dann.

Sven Johann Ciao, ciao.

Gerrit Beine Tschüss.

Daniel Westheide Ciao.

This summary was generated automatically and has not been manually reviewed. It may therefore contain errors. The spoken word in the recording is always authoritative.

Was bleibt von Fred Brooks' 50 Jahre alten Thesen zum mythischen Mann-monat, wenn nicht mehr Menschen, sondern Agenten den Code schreiben?

Konzeptionelle Integrität: Der Chefarchitekt im Zeitalter der Agenten

Sven Johann eröffnet mit Brooks' These der konzeptionellen Integrität – ein Chefarchitekt sorgt für ein stimmiges Gesamtkonzept, ohne das viele Systeme scheitern. Daniel Westheide ordnet ein, dass diese strikte Trennung von Architektur und Implementierung in vielen Unternehmen längst durch geteilte Architekturverantwortung abgelöst wurde. Gerrit Beine hält bei der Koordination von Agenten eine letztentscheidende Autorität trotzdem für unverzichtbar, weil sonst endlos verhandelt würde, ohne zu einem Ergebnis zu kommen.

„Wenn es am Ende nicht eine Person gibt, die Entscheidungskonflikte dadurch lösen kann, dass sie qua Autorität einfach eine Entscheidung trifft, dann kommen wir nicht zu einem Ende.“

Feature-Flut: Der Plastikflaschen-Effekt

Gerrit Beine bringt die Sorge ein, dass agentisches Coding die Feature-Produktion beschleunigt, ohne dass der Bedarf wirklich validiert wird. Daniel Westheide widerspricht der verbreiteten These, seltene Nutzung bedeute automatisch Überflüssigkeit, sieht die eigentliche Gefahr aber im „Feature Overload“: Codegeneratoren senken die Hürde so stark, dass massenhaft inkompatible, kaum genutzte Software entsteht – und mit ihr die konzeptionelle Integrität verloren geht.

„Wir entwickeln Features, weil es schnell geht, benutzen sie einmal und schmeißen sie weg, weil niemand mehr in der Lage ist, zu entscheiden, ob ein Feature gut ist oder nicht.“

Spezialwerkzeuge: Wo bleibt der Determinismus?

Sven Johann fragt nach Brooks' Idee eines dedizierten Werkzeugmachers pro Team. Gerrit Beine erklärt, dass diese Rolle heute faktisch der Coding Agent übernimmt, plädiert aber dafür, sich stärker am Unix-Prinzip zu orientieren – ein Werkzeug für einen Zweck. Beide sind sich einig, dass feste Tools, Linter oder Architektur-Tests den nötigen Determinismus liefern müssen, damit Agenten nicht beliebig abweichen.

„Man muss diesen Determinismus an irgendeiner Stelle in das System reinbringen, ansonsten funktioniert es nicht.“

Kritische Komponenten und die Rolle des Copiloten

Anhand von Brooks' Ärzteteam-Analogie diskutieren die drei, wie kritische Systemteile heute entstehen sollten. Gerrit Beine zieht die Grenze bei der Fachlichkeit: Glue-Code und Transformationen kann der Agent übernehmen, das Domain Model mit der eigentlichen Intelligenz bleibt Handarbeit. Daniel Westheide entdeckt in Brooks' Beschreibung des „Copiloten“ – der mitdenkt, aber keine Verantwortung trägt – eine frühe Beschreibung heutiger KI-Assistenten.

„Sie treffen aber ganz viele Entscheidungen, während sie umsetzen, und wir müssen dann am Ende die Verantwortung übernehmen als Menschen.“

Build one to throw away: Iteration im Agentic-Zeitalter

Zum Abschluss geht es um Brooks' „Build one to throw away“ und die Frage, ob Agentic AI eine Rückkehr zu großen, spec-getriebenen Entwürfen bedeutet. Sven Johann bringt Kent Becks Mahnung ein, dass Menschen der Software weiterhin geistig folgen müssen. Gerrit Beine berichtet, dass sich die Menge an Code pro Schritt vergrößert hat, die Schrittgröße selbst aber gleich geblieben ist.

„Der Inhalt, den ich in einem kleinen Schritt heute schaffe, ist mehr als das, was ich vor vier, fünf Jahren geschafft habe. Aber es bleibt ein kleiner Schritt.“