# AI Coding Risks and Product Discipline

**Podcast:** INNOQ Podcast
**Published:** 2026-08-17

## Transcript

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 Bot-Monat.
Moin, moin.
Wie geht's euch?
Guten Morgen.
Sehr gut.
Guten Morgen, ja.
Wäre ich Anwalt, ich könnte gar nicht genug klagen.
Sehr gut, sehr gut, sehr gut.
Wir hatten uns vor geraumer Zeit, also ist schon irgendwie eine Weile, ich glaube das ist schon zwei, drei Monate her, hatten wir schon eine Folge zum mythischen Bot-Monat gemacht.
Also Hintergrund vielleicht nochmal für die, die den ersten Teil nicht gehört haben, hört nochmal 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 er die IBM, jetzt bin ich dünn, Z360 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 nochmal so eine Neuauflage gemacht und hat er 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 Ändungen, aber grundsätzlich hat sich nichts geändert.
Und wir wollen jetzt nochmal fast 25 Jahre später oder mehr als 25 Jahre später, wollen wir auch nochmal drauf gucken und überlegen, naja, jetzt mit Agentic AI, was steht denn noch von den Thesen?
Und beim letzten Mal sind wir eigentlich auch so da drauf 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 draufschauen.
Gut, legen wir doch direkt mal los mit einem 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.
In dem Buch verkürzt sagt er, alle erfolgreichen Produkte sogar, werden nur auf Software gemünzt, die haben eine gewisse konzeptionelle Integrität, wo sozusagen ein Mastermind dahinter sagt, so machen wir es.
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 nochmal kommentieren.
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 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 hat Daniel, glaube ich, schon so ein paar Artikel zugeschrieben, 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.
Alright.
Genau.
Wie sieht es da heute aus?
Oder zukünftig?
Was passiert da?
Möchtest du zuerst, Gerrit?
Gerne du.
Wenn du dazu schon was geschrieben hast.
Gerne du.
Also ich referenziele mich.
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.
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.
Und das war so mein Anker dafür.
Genau.
Also damit hat der Brooks natürlich recht.
Das war schon immer so.
Aber das war auch schon ver...
vor Jahrzehnten nicht beachtet worden.
Ich glaube, in meinem Studium hat mir unser Usability, in der Usability-Ford, also der Professor mal einen Screenshot von Microsoft Word gezeigt.
Wenn man alle Icons in dieser Icon-Liste oben mal anzeigen lässt, dann hat man, glaube ich, keinen Platz mehr zum Editieren gehabt.
Und von daher ist das jetzt nichts Neues, dass man das nicht beachtet hat.
Mit agentischer Entwicklung ist es wahrscheinlich noch einfacher, noch mehr Features rauszuhauen.
Also der Aspekt, würde ich mal sagen, da hat ja 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, wird das ja so nicht mehr praktiziert.
Ich meine, von Hamelor, der Architecture Advice Process zum Beispiel, ist ja gerade eigentlich ein Versuch, Architekturverantwortung auf die Teams zu verteilen, dass also alle Architekturentscheidungen 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.
Ich möchte zu zweit Dingen was sagen.
Also zum einen, glaube ich, möchte ich, der Wirt...
These widersprechen.
Ich glaube, dass gerade die Icon-Leiste von Wirt 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 genau so 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, also ich bin jetzt kein Fan von Wirt, aber diesen Aspekt, 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, 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 Software-Systemen, dass ich halt Funktionen ausblenden kann, einblenden kann und sowas.
Also das ist was, das finde ich eigentlich gar nicht so verkehrt.
Also Niklaus Wirth hat da so ein Paper oder ein Buch geschrieben.
Würden wir nochmal in die Shownotes reinpacken.
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 auch 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 ist es bei Product Owners 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 bleibe mal bei der Person, wenn es nicht eine Person gibt, die am Ende die Sider 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 Architekturen, die linke und die rechte Richtung entwickelt werden sollen 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 und 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.
Ja, also...
Fand ich jetzt so, was ich ganz interessant gefunden habe, weil du gesagt hast, die Leute, die Betroffenen, das ist ja genau der Andrew Hamel Law Spruch, 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 Ask-Call sein und du kannst nach Rat fragen, aber kannst ihn ignorieren.
Genau.
Aber wenn wir konzeptionelle Integrität haben wollen, dann es gibt gewisse, ich sag mal, wir würden sagen Makroentscheidungen.
Da musst du als Team, da musst du dich dran halten.
Und da kommt genau an der Stelle eine ganz, ganz wichtige Unterscheidung zwischen der Welt, in der wir mit Teams arbeiten, wo Menschen drin arbeiten und wo wir mit Agents arbeiten.
Du hast gerade eine wichtige Unterscheidung gemacht, Sven.
Du hast gesagt, Experten und Betroffene, das müssen nicht unbedingt die gleichen Leute sein.
In den Softwareentwicklungsteams sind das ganz oft die gleichen Leute.
Das sind nämlich die Leute, die entwickeln auch diejenigen, die die Konsequenzen meiner Architekturentscheidung tragen müssen.
Das sind aber auch gleichzeitig die, die sich inhaltlich auskennen, die die Technologien kennen, die die Fachlichkeit kennen und so weiter und so fort.
Wenn wir jetzt über das AI-Coding denken, ist betroffen mein Claude-Coding-Agent, der den Code generiert.
Den kann ich auch nicht nach Expertise fragen.
Der wird mir...
immer irgendwelche Sachen erzählen, der wird mich auch immer in meiner Meinung bestätigen.
So ist der halt gestrickt.
Das heißt, plötzlich rückt Expertise und Betroffenheit im Softwareentwickeln wieder auseinander und ich brauche wieder Leute, die ExpertInnen sind, im wie gestalte ich guten Code, wie überführe ich meinetwegen über den Zwischenschritt von Prompts, wie gestalte ich aus Fachlichkeit Code und vor allem, wie funktioniert Technik.
Und das driftet jetzt wieder auseinander.
Und ich glaube, da wird es jetzt wieder so ein paar Reibereien geben in den nächsten Jahren, weil wir halt jetzt jahrelang in die eine Richtung gegangen sind und gesagt haben, Experten und Betroffene sind die gleichen, meine Entwicklungsteams.
Und jetzt stellen wir fest, wenn der Code aber nicht mehr von den Leuten geschrieben wird, sondern vom Agent, driftet das wieder auseinander.
Und wir haben wieder zwei verschiedene.
Das finde ich eine interessante Überlegung.
Da habe ich noch nicht drüber nachgedacht.
Aber wo du es jetzt dieser Unterscheidung aufgemacht hast, könnte man bestimmt auch was dazu schreiben.
Ja, also da ich ja immer so Plattformen oder irgendwas zentralistisch, also zentralistisch hört sich immer so schlecht an.
Aber bei mir sind ganz oft die Betroffenen immer ganz andere als die Experten.
Aber okay.
Gut.
Vielleicht nochmal ganz kurz zurück mit den zu vielen Featuren.
Weil Daniel hat ja gesagt, das war schon vor 50 Jahren so und man hat das seit 50 Jahren ignoriert.
Also ich meine, wenn wir ganz normal linear nach vorne denken, was man natürlich nie tun sollte.
Aber wenn wir das tun würden, würde man sagen, jetzt wird eigentlich alles noch viel schlimmer.
Weil wir bekommen noch viel mehr Features viel schneller.
die Software noch unbenutzbarer machen?
Oder wie würdet ihr das sehen?
Oder seht ihr Hoffnung, dass dann trotzdem noch irgendwas anderes passiert?
Ja, kommt halt darauf an, was man mit der gewonnenen Zeit und mit den gewonnenen Ressourcen macht.
Dadurch, dass man Features schneller umsetzen kann.
In einem meiner Blogposts hatte ich auf jeden Fall auf so eine Studie verwiesen, dass irgendwie ein super hoher Anteil von Features in den meisten Anwendungen ungenutzt ist.
Oder ungenutzt oder sehr selten genutzt.
Das ist schon sehr spannend.
Und 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.
Wobei?
Entschuldigung.
Ja.
Ich meine, wenn man immer mehr Features baut, ich glaube, den Punkt hatte Sven.
Kurz im Vorgespräch, glaube ich, 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, ist das jetzt günstig, aber man muss sich auch über die Konsequenzen bewusst sein, langfristig.
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 und Software gibt, die nur wenig genutzt werden, war es zu schließen, dass die unnötig sind, halte ich für einen Trugschluss.
Weil wenn ich mir angucke, Steuererklärungssoftware benutze ich 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 struktureller Denkfehler.
Also ich würde das nicht unbedingt gegeneinander ausspielen, diese zwei Dinge.
Dass wir ganz oft goldene Wasserhähne in der Software haben, das ist ungenommen.
Also das würde ich auch unterschreiben.
Aber ich glaube nicht, dass Nutzungshäufigkeit uns dahin führt, ob es goldene Wasserhähne sind.
glaube sogar, dass Menschen dazu neigen, wenn so ein goldener Wasserhahn da ist, den oft zu benutzen.
Und auch zu Situationen, wo er eigentlich unnötig ist und man es gar nicht bräuchte.
Also wie viele Leute haben im Hintergrund bei Windows 3.1 damals solitär offen gehabt.
Das hat jetzt zur eigentlichen Arbeit wenig dazu 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.
Und jetzt haben wir es noch leichter zu produzieren.
Und wenn man sich mal anguckt, Industriegeschichte, 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 Code-Generatoren, die jetzt die Hürde von Software-Erstellung senken, die führen genau zu so einem Plastikflaschen-Effekt.
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 in die konzeptionelle Integrität an, ist Anschlussfähigkeit.
Wenn wir Millionen von Softwareprodukten finden werden, die alle ähnliche Probleme auf die ähnliche Weise oder sowas 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 darum mache ich mir tatsächlich ein bisschen Sorgen an der Stelle.
Es wäre super, wenn wir besser im Discovery wären, wie du das gesagt hast, Daniel.
Ich glaube das aber nicht.
Also ich befürchte es nicht, dass das so kommen wird.
mit Software überschwemmt werden, weil es zu einfach ist und wir dann nicht nur einen Ozean voll Plastikflaschen haben, sondern auch einen Ozean voll toter Apps.
Ich bin auf jeden Fall gespannt.
Ich muss an so 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.
Es gab einen Haufen Ideen, wo wir iteriert haben und geguckt haben, wie nutzen die Leute das überhaupt.
Da ist halt sehr viel Zeit reingegangen zu messen, wie die Leute das nutzen und dann noch diese Messungen auszuwerten.
Und da 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, das 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, hatten wir halt gesagt, was wir übrigens auch noch gemacht haben, wir haben die Peergroups rausgeworfen.
Aufschrei!
Also Leute sind ausgeflippt.
Also wütend.
Wir können doch nicht einfach Features löschen.
Dafür hat doch jemand bezahlt, dass dieses Feature da ist.
Ja, aber keiner nutzt, kostet einen Haufen Geld.
Ja, aber wir haben doch dafür bezahlt.
Und dann ab dem Moment, oh Gott, jetzt kann man die Hoffnung aufgeben.
Also wenn das die Denke ist, ich habe für irgendetwas bezahlt, was keine Sau will und was eigentlich totaler Schwachsinn ist.
Aber ich will es nicht wegwerfen, weil ich habe ja dafür bezahlt.
Klassische Sanktkost-Falicy.
Ja, aber das übersieht ja die laufenden Kosten des Betriebs, was Sven gerade meinte.
Ja, ja.
Aber diese Argumentation ist halt, dass genau diese Sanktkost-Falicy, und es ist völlig egal, wenn ich jetzt noch jede Menge, ich schmeiße dem ganzen schlechten Geld noch jede Menge gutes Geld hinterher, weil ich habe ja schon mal dafür bezahlt.
Der Film ist so schlecht.
Ich gehe im Kino nicht, auch wenn der Film so schlecht ist, weil ich dafür bezahlt habe.
Genau.
Das ist es leider.
Ja, so geht es mir jedes Mal, wenn ich Will-Neuf-Filme im Kino sehe.
Ich gehe nach 20 Minuten, weil die nicht zu ertragen sind.
Das ist...
Probier's aber.
Das soll ja gut sein.
Machen wir mal einen kleinen...
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 nochmal.
Spezialwerkzeuge.
Rooks 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, als bei mir im Projekt, weil es so einfach ist, Werkzeuge zu bauen, die uns irgendwann wegautomatisieren, was man früher nie gemacht hätte.
Geht mir auch so.
Aber bei euch gibt es diesen einen Werkzeugmacher oder?
Nee.
Also der eine Werkzeugmacher, das ist halt der Coding-Agent.
Aber es ist nicht eine menschliche Person im Team, die all die Werkzeuge macht bei uns.
Im Grunde auf Team-Ebene hast du das ja mit Platform-Teams.
Auf Multi-Team-Ebene.
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 Entwicklers 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.
Also je mehr Tools du denen bereitstellst, was Bestimmtes tun können und sollen, dann sind halt weniger Freiheitsgrade da, wo man irgendwie falsch abbiegen kann.
Das, was ich mir da immer wünsche, ist, dass in dieser Agent, wie soll ich sagen, Szene, Community, in diesem Entwicklungsansatz, dass man dann 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, 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 inhärent.
wie soll ich sagen, 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.
Also ich meinte tatsächlich, also als Werkzeug hatte ich das gar nicht so an, ich sag mal, an Skills gedacht, sondern an Tools, die wirklich, also sozusagen Constraints Enforcer.
Also ich weiß nicht, ob das der richtige Begriff ist, aber also OpenAI hat da so ein, die haben in ihrem Engineering Blog, die haben den ziemlich schönen Artikel.
Wo ist das OpenAI, dass die auch mal, dass die für irgendwas gut sind.
Aber die haben wirklich schönen Artikel, wie die Software entwickeln.
Und klar, die haben halt sozusagen Context Engineering als eine Säule.
Aber die haben halt, sie nennen das Architecture Constraints, wo die halt im Grunde genommen, also Tools haben, die praktisch die Agents aufrufen oder die gewisse Vorgaben.
erzwingen.
Also du kannst, also der Agent hat einen relativ kleinen Spielraum, was er da machen kann.
Also ich meine, so ein banales Beispiel ist, die haben ArcUnit-Tests, also haben sie nicht, aber so in unserer Welt würde man sagen, es gibt ArcUnit-Tests, die so eine Struktur, 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.
Also tatsächlich Tools war so meine Sicht darauf.
Bei Tools denke ich an Dinge wie Make, Set, AWK.
Also das ist so die Ebene, wo ich über Tools nachdenke, die ja auch in ganz, ganz vielen Situationen adaptiert werden und die auch immer noch ständig benutzt werden.
Also wenn ich mir angucke, wenn ich hier Claude irgendwas machen lasse an meinem Code, wie oft das auf diese Tools zurückgreift in der Entwicklung.
Das ist erstaunlich.
Man muss diesen Determinismus an irgendeiner Stelle reinbringen in das System.
Ansonsten funktioniert es halt nicht.
Das war ja auch die wesentliche Erkenntnis, als ich diesen Code von Claude sich angeguckt habe.
das meiste dieser Code-Generierung eigentlich auf regulären Ausdrücken basiert und nicht auf LLMs.
Fand ich bemerkenswert.
Ja, gut.
Haben wir noch was zum Thema Spezialwerkzeuge?
Also bisherige...
Also ich sehe da das gleiche Problem wie vorhin bei den Features.
Also 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 irgendwie zu irgendeinem Zeitpunkt mal einen Prompt involvieren, was ein LLM triggert, etwas zu tun, was nicht zuverlässig ist dauerhaft.
weil das LLM irgendwann wegfällt, weil es eine neue Version gibt.
Da gab es ja genug Experimente dazu, die gesagt haben, ein Versionssprung funktionieren deine ganzen Prompts nicht mehr.
Und das ist was, was ich in der Hinsicht für kritisch halte.
Aber das gilt halt auch wieder.
Es wird sehr, 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 da so mit Leuten diskutiere, Vielleicht sollten wir langsam anfangen, für sowas auch Engineering Practices nicht nur in Form von Büchern zu veröffentlichen, sondern tatsächlich auch in Form von Standards festzuschreiben, Industriestandards, wo man sagt, an die muss man sich halten, sonst darf diese Software beispielsweise nicht eingesetzt werden für.
Also die...
Also ich meine, so ab und zu habe ich ja schon so Sorgen, weil ich hatte neulich so eine Bücherbestellung gemacht für das nächste Schuljahr und die Software, also 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, also 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, naja, was passiert eigentlich, wenn viele Leute jetzt AI in die Hand bekommen und...
Du hast eben irgendwie Steuererklärungen und so gesagt.
Also Sachen, wo du wirklich...
Aber ich werde eigentlich...
Tatsächlich bin ich relativ entspannt, weil diese Standards gibt es ja jetzt schon, oder?
Also ich meine, wenn du...
Extremfall, wenn du ein Safety-Critical-System baust, dann...
Jetzt, ohne dass ich da Einblicke habe, du weißt das wahrscheinlich besser, Gerrit, als ich, aber beim ISAQB unser ehemaliger Kollege Lars Huppel, 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 Code-Generierung einfach ist, Vielleicht brauchen wir auch noch ein bisschen was anderes als Tests, sondern wir brauchen noch formale Methoden, die sagen, was tatsächlich sein soll.
Genau.
Ich kenne tatsächlich auch niemanden aus der Ecke, der irgendwie ein Fan von dieser Code-Generierung ist.
Aber das ist nochmal eine andere Diskussion.
Aber es ist genau das.
Und wenn du dir das anguckst im Medizintechnik-Bereich, überall dort, wo Menschenleben gefährdet sind, hast du solche Standards.
Das Problem ist, dass wir ganz, ganz viele Anwendungen für Bereiche entwickeln, in denen...
solche Standards nicht gibt, wo es jetzt aber noch leichter wird, Fehler zu machen.
Und meine Referenz für sowas ist immer Casey O'Neill, die hat vor, das kann auch zehn Jahre mittlerweile her sein, ein Buch geschrieben, Weapons of Math Destruction, also M-A-T-H, 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, sowas 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 mit, 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 Prozent hatte.
Was erst mal gut klingt, was aber für den...
Arbeitsalltag völlig untäglich 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 klorten Software generiert, die hat 99% Treffsicherheit, total genial, klingt ja gut, raus damit.
Und dann gibt es auch noch Leute, die kaufen den Trend.
Wollen wir mal auf einen anderen Blogpost von mir einzugehen.
Die hätten vorher, glaube ich, einen Monat bei Starbucks in einer Filiale arbeiten müssen, die das entwickelt haben.
Genau.
Genau.
Das ist genau der Punkt.
Aber das, wie gesagt, 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.
Dann kaufen die Leute das.
Ach ja.
Da werden wir lustige Dinge, also lustige in Anführungszeichen, in großen Anführungszeichen lustige Dinge auf jeden Fall.
Ja, also ich gucke auf jeden Fall mal in, packen wir auch in die Show Notes, Weapons of Math Destruction, weil ich musste automatisch an dieses, weil du sagst, da werden Existenzen zerstört, da musste ich automatisch an diese Storyform vom UK Parcel Service oder Post Office denken, wo es halt auch irgendein Software-Bug hat zu Problemen in der Kasse.
Also die Abrechnung war nicht korrekt.
Und dann haben die halt gesagt, die Software macht keine Fehler.
Das müssen die Clarks in den Postal Offices sein.
Und dann wurde geklagt und hin und her und manche Leute haben sich umgebracht.
Also aus Verzweiflung, weil denen die Existenz weggeklagt wurde und dann waren schon ein Haufen tot.
Und dann kam raus, ups, war doch die Software.
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...
wo man dann aber trotzdem sicherstellt, also wo es heute schon ein bisschen schief geht, dass halt, naja, wir driften ein bisschen ab von Spezialwerkzeugen.
Das ist gar nicht so sehr das Abdriften, weil das ist durchaus eine Kette, die sich so fortsetzt.
Casey O'Neill hat an einer Stelle einen Fall zitiert, ich glaube, das war an 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.
Computer says no.
Computer says no, genau das ist das Prinzip.
Und jetzt haben wir aber so ein LLM, was nicht nur einfach no sagt, sondern was dir das auch noch eloquent erklären kann, warum das no sagt.
Und wenn wir jetzt Leute haben, die keine Ahnung von Softwareentwicklung haben, die also nicht wissen, wie Entscheidungen...
im Prozessor zustande kommt, dass es immer irgendwie auf Register 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, also das ist jetzt keine...
ich kann nicht die Zukunft sehen, aber man kann ja aus der Vergangenheit ein paar Muster durchaus immer wieder 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 Software-Systeme zu nutzen, die zu teilweise fatalen Konsequenzen führen können.
Und die halt auch in die Lebenswirklichkeit von Leuten auf eine Weise eingreift, 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, weil die Betroffenen 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.
Ja.
Also ich glaube, der Bereich, in dem wir bisher Engineering Standards haben, muss, wenn wir AI 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 sowas.
Das ist nur ein Argument dafür, dass wir eine Strategie brauchen, um damit umzugehen.
Das braucht es halt.
Also ich würde auch länger auf Code verzichten wollen, weil das an ganz vielen Stellen hilft in meiner Entwicklungsumgebung und Juni und wie sie alle heißen, die da im Hintergrund werkeln.
Das ist völlig okay.
Es ist trotzdem die Frage, was sind meine Engineering-Standards?
Und ist das, was da an Resultat rauskommt, angemessen fürs Problem?
Ja, also ich hatte neulich mit einem ehemaligen Kollegen von mir geredet.
Der hat sich...
Der war nie Softwareentwickler, aber der war in der Softwarebranche, war halt Testmanager und solche Dinge.
Und der hat 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 dann habe ich gedacht, oh Mann, ey, ich würde das Ding nie kaufen.
Weil ich habe einfach Angst, also schon Angst.
Du weißt ja nicht genau, wie Software funktioniert.
Also ich meine, du bietest da so ein SARS-Ding an und du hast keine Ahnung, was dieses SARS-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, dass die jetzt Produkte anbieten.
Ja.
Naja.
Ja, auf jeden Fall interessanter Gedanke.
Also das ist interessanter Gedanke.
Also ich würde sagen, dass diese Sorge teile ich, dass Dinge auf den Markt kommen, denen man nicht vertrauen kann.
Und woher weißt du das?
Genau.
Das ist genau der Punkt.
Okay, ich springe 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.
Das Ärzteteam, da 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.
Proog siniert weiter, dass gute Programmierer meist, oh naja gut, jetzt lese ich nicht mehr weiter, weil es weh tut, weil meist fünf bis zehnmal so produktiv, ah nein, sagst du nicht, ah, wie mittelmäßige, ah, ich kann jetzt nicht mehr weitermachen, okay.
Jetzt hat es sogar...
Aber okay, also ich glaube, das Ding ist klar, also wenn es irgendwas Kritisches gibt, den kritischen Code, also ich sage mal, wir haben ein Billingsystem oder wahrscheinlich bei British Postal Office, die Abrechnung hat vielleicht nicht der gute Programmierer gemacht, sondern der Praktikant oder so.
Da würde ich sagen, das war...
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.
Sollte man kritische Komponenten anders entwickeln als andere, wenn man so einen Agent zur Hand hat?
Also BlueCode kann ich problemlos von Claude entwickeln lassen.
Aber das, wo die Intelligenz reingehört, das ist was, da würde ich auf jeden Fall die Menschen draufsetzen.
Ich muss aber auch wieder sagen, ich würde das, was BlueCode 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 schwer gefallen ist, bestimmte Dinge, also die haben ihren Job gemacht und war auch immer okay, aber denen ist auch bis zum Ende ihrer Karriere schwer gefallen, dass bestimmte Problemstellungen nachzuvollziehen und eine sinnvolle Software zu gießen.
Also ich würde nicht Seniorität da als das Kriterium nehmen, sondern eher wirklich Was für ein Faible, was für ein Talent haben die Leute für Problemlösungen?
Daniel, was sagst du dazu?
Ja, also ich finde diese Analogie mit dem Chefarzt und dem OP-Team drumherum eigentlich grundsätzlich, also auch schon abseits von agentischer Entwicklung, ein bisschen problematisch.
Ich weiß nicht, ob ihr das Buch Impact Players kennt von Liz Wiseman.
Da musste 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.
Und ich glaube, eigentlich ist das, was da im OP-Saal...
dann passiert näher am Ensemble-Programming als an dem, was Brook 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 es ist ja auch nicht immer ein erfahrener Chefarzt, wie gesagt, sondern vielleicht auch jemand mit weniger Berufserfahrung.
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.
Und zum Beispiel unser Kollege Jochen Christ, der ja mit Simon Harrer Entropy Data gegründet hat, der hat ja neulich erzählt, naja, so banale.
banale Features, die macht der Agent, also da wird, da revieert er gar nicht mehr.
Also 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 vor ein paar Minuten so banale Code-Generierung kann man einfach machen lassen.
Aber es gibt halt, also je kritischer es wird, desto weniger, also desto mehr sollte man selbst machen.
Wäre so meine Interpretation gewesen.
Desto mehr muss ich drauf gucken.
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, beginnen so Mappings, wo wir so DTUs in JSON verwandeln oder aus irgendeinem Fremd DTO, was kommt, eine Transformation in unseres machen müssen und sowas.
Das sind Bereiche, da würde ich wirklich sagen, das kann ich ein Agent machen lassen, weil es sehr, sehr einfach dort zu erkennen, dass etwas schief geht.
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 keine Abstimmung mit Domänexpertinnen brauche, um eine Entscheidung zu treffen.
Und da halte ich es für vollkommen unkritisch, also vollkommen unkritisch in Anführungszeichen, aber für durchaus vertretbar, sage ich, das kriegt besser, für durchaus vertretbar, dort Agent-based Coding und sowas einzusetzen und dann auch zu sagen, das review ich nicht mehr, weil ich habe zwei Enden, wo ich jeweils ein fertiges Modell habe und wenn da was schief geht bei der Transformation, das kracht halt, das sehe ich.
Da würde ich halt sagen, okay, das war jetzt auch nicht unbedingt ein Code-Review, sondern dann sage ich halt, wenn es gekrackt hat, Code-Agent bitte nochmal.
Aber beim Domain-Sell, das wäre zum Beispiel was, wo ich, da möchte ich jede Zeit der Code persönlich kennen.
Ja, ich hatte mir das Kapitel ja auch dann nochmal genauer durchgelesen zum Ärzteteam.
Was ich ziemlich lustig fand, war, dass da auch dieser Begriff des Co-Pilot auftauchte.
Ich weiß nicht, ob ihr das auch nochmal gelesen hattet.
Der Co-Pilot, 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.
What?
Und es ist ja vielleicht kein Zufall, dass wir so ein paar AI-Produkte namens Co-Pilot 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.
Ja, also ich meine, am Anfang musste ich so ein bisschen lachen, aber der letzte Teil, das ist ja auch so eine Diskussion, die ich öfter höre.
Der Entwickler, also wir.
Wir sind halt dafür verantwortlich, obwohl jemand anderes das macht.
Du kannst jetzt sagen, das hat halt der Agent gemacht.
Ja, ist schön, aber du bist der, der die Verantwortung, also du machst die Entscheidungen und du bist aber auch, die Ausführung macht vielleicht jemand anderes.
Aber du bist also ein Nichtmensch, aber du bist letztendlich.
Die Verantwortungsübernahme kommt, da ist immer noch eine Person dahinter.
Ja, genau.
Aber diese Rolle des Co-Pilots, die wird ja oft auch mittlerweile eben von AI übernommen.
Hier dieses Share in the Design, es ist Thinker, Discussing and Evaluator.
Also ich erwische mich ja auch immer wieder mal dabei, wie man seine Design-Überlegung mit dem AI-Assistenten diskutiert, statt mit dem eigenen Team.
Ja, also ich meine so, bevor man zum Team geht, da ist es ja völlig in Ordnung.
Ja, aber das ist glaube ich dann auch schon so, wie Jared gesagt hat, dass auch wenn man versucht gegenzusteuern, dass oft ja die eigene Richtung einfach nur bestätigt wird.
Zumindest auf so einer höheren Ebene.
Vielleicht werden mal Details kritisiert, aber das sagt ja halt selten, dass du komplett in eine falsche Richtung abgewogen bist.
Ja, ich meine, letzten Endes, ich würde ja nie sagen, hier ist mein Entwurf, mach mal eine Designkritik.
Ich müsste eigentlich immer sagen, also man müsste, ich mache.
Hier sind, also eigentlich klassisch ADR, also hier sind die Optionen, die ich habe.
Und hier ist der Kontext und hier sind die Kriterien.
Was denkst du?
Und dann kann er eigentlich gar nicht so genau, also dann kriegst du ja, kriegst du eine Meinung, aber auch meiner Meinung nach auch nur dann, wenn das irgendwie so klassische Probleme sind.
Also wenn wirklich so ein extrem kontextspezifisches Problem ist, dann würde ich mal sagen, das kann man komplett vergessen, das ist eigentlich immer Schrott.
Aber ich sage mal neulich.
also neulich ist 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, war immer noch eine ganz schlechte Entscheidung, weil der Kontext halt sehr entscheidend war.
Aber du kannst zumindest mal sagen, hier sind die Optionen, kannst du nochmal gucken, welche Vor- und Nachteile da vielleicht fehlen oder die falsch sind.
Ja, man könnte sagen, das, was er als Co-Pilot beschreibt, sollten weiterhin Menschen sein.
Und eigentlich, in meiner Erfahrung sind das ja auch meistens nicht nur einzelne Personen, sondern das ist ja meistens das gesamte Team eigentlich, mit dem man sich austauscht.
Ja, ich meine, da, das lese ich übrigens jetzt auch häufiger, also Daniel und ich, wir hatten ja mal vor Ewigkeiten so einen Podcast gemacht, der hieß, also der Titel war etwas unsexy, was ist Programmieren?
Aber eigentlich ging es da um...
um Theory as Model, nee, Theory of Model Building.
Programming as Theory Building.
Programming as, ja genau.
Und ich meine, da war ja, da ist ja damals, also vor, wie alt ist dieses Paper?
Bestimmt auch schon 50 Jahre alt.
Mitte der 80er, glaube ich.
Oder okay, ja.
Da war ja auch schon die Sache.
Also hier Programm, also Softwareentwicklung ist nicht Typing of Text.
sondern ist, 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.
Die wichtigen Sachen, die muss man halt mit allen bequatschen, damit alle dieselbe Vorstellung haben, um was es geht.
Alright, ich gucke auf die Uhr.
Ich würde vielleicht nochmal einen haben wir noch.
Wir hinten haben noch zwei, aber ich glaube, die schaffen wir nicht mehr.
Und zwar geht er so in diese Richtung, die wir jetzt auch schon wieder haben, die wir jetzt die letzte Zeit, die letzten Minuten hier verfolgt haben.
Und zwar der Fred Brooks hat 75 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.
Und da hat er ja 25 Jahre später gesagt, naja, das war eigentlich eine Scheißidee.
weil das Wasserfallmodell ist doof und besser ist doch iterative Entwicklung.
Wobei man sagen muss, also 1976 hat Walker-Royce schon gesagt, das Wassermodell ist doof, wir machen besser iterative Entwicklung.
Aber okay, die nächsten 25 Jahre hat sich eh keiner dran gehalten oder die nächsten 30 Jahre.
Aber da kam mir so in den Sinn, so Iteration im...
Im Agentic AI Zeitalter.
Also man liest irgendwie bei LinkedIn, ja ich habe hier heute noch mal 75.000 Zeilen Code geschrieben und so weiter.
Und dann denkt man so, oh Wahnsinn, was machen die Leute?
Und auf der Gegenseite, also da denke ich immer, ich komme da gar nicht mehr hinterher.
Und zum Beispiel Kent Beck sagt, wir müssen immer noch, also wir müssen immer noch höchst iterativ arbeiten, weil wir müssen dieser Software auch irgendwie geistig folgen können.
Also du kannst eigentlich gar nicht mehr, wir haben ja immer so gelacht, 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.
Aber okay, ist natürlich eine Option.
Wie seht ihr das?
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.
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.
Ja, und wie es sich anfühlt.
Und jetzt könnte man natürlich schön sagen, das ist ja jetzt noch viel billiger, den Spike zu entwickeln.
Dauert irgendwie nur fünf Minuten oder zehn.
Der Agent macht das schon.
Aber dann ist das, glaube ich, irgendwie an dem Punkt vorbei, warum man das macht.
So, das ist erstmal ein Punkt dazu.
Vielleicht hat Gerrit ja noch andere Aspekte.
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, dass den Agent machen wir lassen.
Wenn es darum geht, ein 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...
dann ist das vollkommen egal, ob ich das programmiere oder der Agent, weil dann ist das Stern in einem anderen Bereich.
Ich würde tatsächlich an der Stelle erstmal 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.
Wie gesagt, wenn es um die Fachlichkeit geht, kann es problemlos auch der Agent machen.
Wenn ich weiß, wie es technisch geht.
Ja, das auf jeden Fall.
Das würde ich wieder differenzieren.
An sich hast du aber recht.
Beim Spike geht es darum, was zu lernen und das muss irgendwie, das darf ich nicht aus den Augen verlieren.
Spikes sind in der agilen Softwareentwicklung völlig normal.
Es wird nur ungern von den Menschen dann weggeworfen.
Das ist immer so das Problem.
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.
Jetzt kann man es einfacher machen.
Bitte?
Jetzt geht es halt einfacher, glaube ich, auch mental, zu sagen, das werfe ich weg.
Genau, weil es der Agent-Code hat, es ist nicht mehr der eigene Code.
Das könnte so sein, ich weiß es nicht.
Tatsächlich ist es 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 prinzipiell würde ich mir das auch wünschen, mehr an Prototypen zu denken und zu sagen, ich schmeiß den Krempe weg.
bin ich ein großer Fan davon, Dinge wegzuwerfen.
Also Code wegzuwerfen.
Auch wenn ich vor und gegen dieses mehr 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 hinkt vielleicht auch der Vergleich mit diesen Plastikflaschen.
Ja, ich habe mir gerade nochmal notiert, auch für die Shownotes, was vielleicht da gut reinpasst ist, es gibt doch dieses Big Ball of Mudpaper, was ja auch schon irgendwie wieder 35 Jahre alt ist oder so.
Und die sagen ja, die Metapher ist eigentlich der Carport.
Also da sagt jemand, wir machen das mal schnell, also 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 und dann bei, weil halt niemand was wegwerfen will.
Ich bin auf jeden Fall auch gespannt.
Aber nochmal vielleicht ganz kurz zurück zu diesem Kent-Back-Ding, dass wir geistig folgen müssen.
Das beschäftigt mich tatsächlich immer noch ziemlich, also was so iterative Entwicklungen angeht, Sachen.
Also Sachen machen und dann Ideen wegwerfen, weil man plötzlich sieht, es geht ja nicht nur um die Code-Qualität an sich.
Also Daniel hat gesagt, wir wollen was lernen.
Aber auch während dem Entwickeln, das ist so 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, also eigentlich haben wir dieses und jenes nicht bedacht.
Da müssen wir nochmal zurück die Anforderungen machen.
Fachlich meistens.
Bitte?
Fachlich, genau.
Genau, dass man sagt, oh irgendwie, das passt irgendwie nicht.
Und wenn du jetzt, wie läuft das, also muss man das nicht beibehalten.
Das ist so das eine, dass du merkst, da passt was fachlich nicht.
Und zum anderen, der zweite Punkt ist halt, wir müssen noch irgendwie geistig hinterher kommen.
Also wenn du jetzt irgendwie so einen Haufen Wenn du in großen Chunks Code raushämmerst, dann verlierst du dieses geistige Modell der Software.
Vielleicht braucht man noch gar nicht mehr.
Vielleicht gibt es andere Möglichkeiten, aber keine Ahnung.
Also da bin ich auf jeden Fall noch, also ich bin auf jeden Fall gespannt.
Meine Meinung ist, also ich versuche, ich programmiere ja gar nicht mehr so viel, aber wenn, dann versuche ich immer in möglichst kleinen Iterationen zu arbeiten.
Die gehen halt jetzt viel schneller.
Aber ich will halt trotzdem, also ich sage mal, meine Iterationsgröße bleibt gleich.
Also von dem Code, der erzeugt wird, nur die Zeit für die Code erzeugt ist halt viel kürzer.
Aber ich kann gar nicht schneller gehen, weil ich komme einfach da nicht mehr hinterher.
Ich verstehe gar nicht mehr, um was es geht.
Ich sehe nicken.
Es gibt Zustimmung, keine.
Also geht mir ähnlich.
Ich habe auch das Problem.
durch den Job, ich komme nicht mehr so viel zum Programmieren.
Wenn ich was mache, dann mit kleinen Schritten.
Aber der Inhalt, das, was ich in so einem kleinen Schritt heute schaffe, mit Unterstützung von Juni, 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 und ich probiere es auch manchmal aus, dass ich sage, hier, gib dir mal so eine komplette Speck, mach mir mal eine komplette Lösung.
Die taugt dann meistens nicht.
Und das ist halt der Punkt.
Das kleine, schnelle Iterieren ist was, das funktioniert immer noch gut.
Kent Beck hat ja irgendwann mal diese Metapher gehabt, wo so Steine im Wasser liegen und am sichersten springst du von Stein zu Stein.
Aber irgendwann wird man ein bisschen risikofreudiger und dann überspringt man mal so einen Stein, weil die Steine so eng beieinander liegen und man denkt, das ist irgendwie doof.
Und dann überspringst du so einen Stein und schwupp, liegst du im Wasser, weil du irgendwie besser kleine Schritte machen.
So musste ich gerade nochmal dran denken.
Dann denkt man so, ja, jetzt könnte ich vielleicht noch einen größeren Chunk generieren lassen und bumm, liegst du auf der Nase, musst du auch wieder zurück.
Okay.
Ja, aber ich glaube, ich muss irgendwann nochmal Adrian Cockroft für so einen Case-Podcast einladen, weil ich meine, Adrian Cockroft ist offensichtlich kein Blöder, aber der ist ja eigentlich der, der ständig so bei LinkedIn schreibt, oh, heute nochmal 50.000 Zeilen Code generiert für meine Dingsbums-Software.
Aber die Software hat halt immer nur einen Nutzer, er selbst.
Das ist vielleicht dann auch nochmal so ein Unterschied.
Ja, wer darf das dann auch?
Der kennt die Tergrube.
Ja, genau.
Ich meine, es ist ja auch kein Produkt.
Das ist Software für eine Person, die ihr da macht.
Alright.
Es sind so fünf Minuten über der angepeilten Zeit.
Ich weiß nicht, ob ihr noch letzte Worte habt.
Es bleibt spannend.
Ja.
Das denke ich auch.
Frag mich halt, ob es irgendwie in einem Jahr oder so nochmal so ein Pivotal Moment gibt, wo vielleicht die Modelle so viel besser sind, dass vielleicht die Aussagen dann nochmal revidiert werden müssen.
Ja, vielleicht müssen wir in einem Jahr eine dritte Folge machen, wo wir uns dann darüber lustig machen, wie falsch wir haben.
Das finde ich cool.
Ich frage mich aber die ganze Zeit, was kommt nach den Agents?
Ja, also hier der, wie heißt der nochmal?
Also Jung und Naiv, dieser Podcast, die machen ja immer so, die machen immer ihre Jahres-, ihre Politik-Predictions.
Und dann praktisch ein Jahr später machen sie neue Politik-Predictions, aber gucken nochmal drauf, welche Predictions waren falsch.
Und das wäre vielleicht auch nochmal so eine Sache in einem Jahr nochmal, oder überhaupt mal so, ich würde mal sagen, Software Engineering Predictions zu machen und dann ein Jahr später nochmal drauf gucken, wie ist es denn eigentlich gelaufen.
Ja, es bleibt spannend.
Also es gibt einen Haufen spannende Themen, weil ich sage, die Modelle werden besser.
Also wahrscheinlich werden sie besser, vielleicht werden sie auch schlechter.
Also da bin ich auch noch gespannt.
Wäre vielleicht auch nochmal so ein Thema.
Also in den USA kriege ich jetzt mit, dass so die Empfehlungen sind.
Macht nichts mehr öffentlich.
Also wo ihr früher vielleicht so einen Engineering-Blog rausgebracht habt, macht es einfach nicht mehr.
Also alles bleibt intern, weil der Engineering Blog ist im Prinzip nur Lernmaterial für LLMs.
Und wir kriegen da jetzt auch mit.
Hier der Johannes Link, der hat, der glaube ich bei JUnit 5 dabei war und der auch so Property-Based Testing Framework für Java entwickelt, dass der praktisch ja auch sagt, dass er sozusagen ein Anti...
Anti-Gen-AI-Movement, dass es das gibt, wie man sozusagen Lernresultate verschlechtern kann, indem man irgendwie den Code oder Anweisungen reinschreibt, dass das Lernen schlechter wird.
Da könnte ich mir vorstellen, dass das halt viel mehr wird.
Und die Modelle vielleicht sogar schlechter werden.
Die Frage ist, ob das was bringt, weil ich meine, 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 Textragmente zu ignorieren.
Das sind immer so Schnellschüsse, das trägt halt nicht.
Ich halte da mehr davon, dass man eine Differenzierung macht, dass man auch nicht ausweist, was das AI generiert, sondern dass man eher ausweist, was das Menschen gemacht.
Dass man sagt, ich honoriere das mit einem entsprechenden Wert.
Das ist ein Unterschied, mein italienisches Restaurant, wo ich gerne hingehe, versus McDonald's.
Da honoriere ich halt, dass die Pizza von Hut gemacht wird.
Und ich sehe das, wie die entsteht.
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 Load produzieren, wenn die da meinen kompletten Server abscannen, meinen Fortio.
Das ist mir zu viel.
Aber prinzipiell ist das was, das können wir im Internet nicht verhindern, dass das passiert.
Und dann ist die Frage, ob wir aufhören zu publizieren oder nicht.
Also zu schweigen kann an der Stelle halt keine Option sein.
Irgendwelchen Fake da reinzumachen macht mir persönlich viel zu viel Arbeit.
Ja.
Also ich meine, ich hätte jetzt neulich in so einem US-Podcast war, ich glaube, es war ein US-Podcast, da ging es halt darum, also zum einen, jetzt kann ich mich wieder erinnern, war zu geil, also entweder OpenAI oder Entropic, also irgendwer hat versucht, DeepSeek zu verklagen, weil DeepSeek ja sozusagen so eine Model-Destillation gemacht hat und dann haben die gemeint, ja, aber die haben ja von uns geklaut.
Und dann war die Gegenaussage, naja, ihr habt halt von der gesamten Menschheit geklaut.
Also das ist irgendwie Quatsch, ja.
Aber in dem Zusammenhang kam halt raus, naja, wenn die schon von der, also die haben jetzt von der gesamten Menschheit geklaut und verkaufen das halt jetzt.
Also the biggest theft of all time.
Und in den USA gibt es scheinbar so ein Rage, dass, also ich weiß nicht, wie die Republikaner das sehen, aber ich bilde mir ein, hier hat noch gesagt, dass sogar viele republikanische Senatoren da drauf gucken, dass im Grunde genommen diese, dass die LLMs verstaatlicht werden müssen als Public Good, weil im Grunde genommen die Daten Public Good waren.
Also da bin ich auf jeden Fall mal gespannt, was sich in der Richtung tut.
Weil das ist halt schon ein Riesending.
Also du willst eigentlich publizieren, aber dann ist es halt so schwierig.
Ich würde sagen, wir publizieren unseren InnerQ Podcast trotzdem.
Wir publizieren den.
Trotzdem.
Und wir publizieren auch, also ich publiziere ja keine Artikel, aber Gerrit und Daniel publizieren weiterhin schöne Artikel.
Machen wir.
Die übrigens natürlich auch, wie sagen wir so, die können halt was, was die AI nicht kann.
Original Thought.
Ich weiß gar nicht, wie man das auf Deutsch sagen würde.
Muss man die AI fragen.
Urinelles Denken.
Kreatives Denken?
Ja, kreatives Denken, vielleicht ist das Richtige.
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.
Bis dann.
Tschüss.