Der nachfolgende Text wurden mit KI erstellt und kann Fehler enthalten. Fehler gefunden? Bei GitHub editieren
So, dann herzlich willkommen zu einer weiteren Episode von Software-Architektur im Stream.
Heute geht es um das Thema Best Practices für Agent Coding mit Ralf und vor allem unseren Gästen Tobias und Yadu.
Tobias, möchtest du dich kurz vorstellen?
Sehr gerne.
Hallo, ich bin Tobias.
Ich arbeite seit knapp zehn Jahren als Softwareentwickler und Architekt beim IT-Dienstleister namens MaibornWolff GmbH.
Die längste Zeit war ich auf Webentwicklung fokussiert und jetzt gerade in den letzten paar Jahren ist mein Fokus etwas mehr in Richtung AI und Softwareentwicklung mit AI etwas abgewandert.
Und gerade in diesem Jahr ist mein Hauptfokus, den Leuten beizubringen, wie man mit AI gute Software entwickeln kann und halte dafür bei uns intern sehr viele Schulungen und gehe sehr viel auf die Fragen meiner Kolleginnen und Kollegen hinein.
Genau.
Yadu, möchtest du auch kurz was über dich sagen?
Klar.
Hi zusammen.
Yadullah Duman mein Name, aber die meisten nennen mich einfach Yadu.
Ich bin aktuell Fellow bei MaibornWolff, arbeite jetzt seit mehr als zehn Jahren in der Softwareentwicklungsbranche.
Vor allem sehr viel in IT-Modernisierungsprojekten gearbeitet.
Und jetzt seit knapp mehr als einem Jahr liegt mein Schwerpunkt auf Agenting Engineering.
Also Tobi und ich sind da sehr leidenschaftlich unterwegs.
Und wir haben auch sehr früh das Potenzial erkannt und hatten auch Glück, dass wir Mitte 2025, ich darf die Jahre jetzt nicht vertauschen, dann auch beim Kundenprojekt Cloud Code einsetzen durften.
Und wir haben da halt sehr viel gelernt und dann die Best Practices quasi distilliert mit Tobi zusammen, eine Schulung aufgebaut, die wir halt intern und auch extern anbieten.
Und genau, wir haben dann auch mit anderen Kollegen zusammen die Agenting Modernisation Gilde gegründet, innerhalb von MaibornWolff und wollen da einfach tiefer einsteigen.
Genau.
Und ja, ich freue mich generell, dass wir hier jetzt über ein paar Best Practices reden werden.
Ich rede gerne über das Thema.
Genau, freue mich.
Ralf sollte ja allgemein bekannt sein.
Also ich hatte mir erwähnt, nachdem das ein AI-Thema ist und das ja so ein bisschen Ralfs Fokus ist, da Verstärkung geholt.
Und ich freue mich natürlich auch, dass du es entrichten konntest.
Wollen wir dann gleich inhaltlich loslegen?
Also ich habe verstanden, es gab so drei Wellen bei euch in Bezug auf AI-Adaption und möchte ja darüber berichten erst mal.
Tobi?
Ja, du fangst gerne zu.
Es ist immer schwer, wenn zwei Leute da reisen.
Ja, gerne.
Also in dem Projekt, wo wir unterwegs waren, waren wir sehr lucky, dass wir in so einer Zeitspanne unterwegs waren, wo wir quasi alle AI-Wellen erlebt haben, von Chat-GPT bis hin zu dem ganzen Chat-Based Programming mit zum Beispiel Cursor, Windsurf und so weiter, Copilot-Chat, bis hin dann zu den ganzen Coding Agents mit Cloud Code unter anderem.
Und ich habe das halt stark verfolgt.
Wir hatten halt auch in der Firma quasi so eine AI-Change-Kultur, wo halt jeder versucht hat und geschaut hat, was funktioniert und was nicht.
Ich war tatsächlich bis zu den Coding Agents, also bevor Cloud Code rauskam, eher ein Skeptiker, weil in Brownfield-Projekten arbeitet man meistens mit einer komplexen Codebase und da ist halt sehr viel Wissen, was versteckt ist, das man dann extrahieren muss und so weiter.
Und die Modelle damals waren halt nicht gut genug, die Tools waren nicht gut genug und so weiter.
Und genau, die erste Welle mit Chat-GPT war für mich persönlich einfach nur ein Google-Ersatz.
Also wenn ich jetzt schnell Antworten gebraucht habe, dann war das so mein Go-To und ich hatte einfach kürzere Feedback-Schleifen und man geht natürlich auch immer mit einer Skepsis ran, man checkt die Antwort und wenn etwas ein bisschen shady aussieht, schaut man dann nochmal doppelt in Google oder so.
Aber man war schneller in so Research-Aufgaben, wenn man halt wirklich schnell Antworten gebraucht hat oder sowas wie, man sieht eine Fehlermeldung im Docker, die man immer wieder gesehen hat und man hat vergessen nochmal, was es bedeutet.
Wo man in der Regel auf Stack Overflow schaut und das hat sich jetzt so ein bisschen geshiftet auf Google oder jetzt Chat-GPT und man sieht jetzt auch, wie Traffic auf Stack Overflow immer weniger wird.
Das bricht mein Herz ein bisschen.
Aber ja, das war so die erste Welle.
Und mit dem ganzen Chat-Based Programming, das war dann interessant, weil zu dem Zeitpunkt sind dann Modelle rausgekommen, die dann auch Reasoning und so weiter hatten.
Die Cloud-Modelle, das war dann 3.5.
Zu dem Zeitpunkt wurden dann prominenter als Coding-Models vermarktet und ich habe das halt getestet und auch direkt bei uns im Projekt und das, was rauskam, war nicht gut.
Also jetzt wirklich so Produktionscode, da musste man viel nacharbeiten.
Es hat besser funktioniert bei so Sachen wie Boilerplate-Testerstellung, also Aufgaben, die sehr einfach sind, wo die Modelle noch den Intent ein bisschen verstanden haben und dennoch immer noch viel manuell programmiert und ich war da noch nicht überzeugt.
Und genau, dann kam Cloud Code raus und wir hatten ein paar Kollegen, die haben sich das schon seit dem Release, das war glaube ich dann so Februar 25 oder so, wenn ich mich nicht täusche.
Und genau, die hatten das dann in privaten Projekten erstmal getestet und haben dann bei uns intern gezeigt, hey, wie das funktioniert und so weiter.
Und dann habe ich mich mal mit einem Kollegen hingesetzt und habe gesagt, erklär mir das mal und ich will das mal wirklich verstehen.
Und ja, das hat dann bei mir so wirklich, da hatte ich so einen Wow-Effekt, das ist anders, das sieht halt wirklich anders aus.
Und der Grund ist einfach, weil das Tool, also ich nehme jetzt Cloud Code als Beispiel, lebt halt in deinem Projekt.
Du kannst halt deine Projektnuancen mitteilen, mitgeben über Instruction Files und die Modelle wurden auch über die Zeit besser.
Und wir haben das auch direkt getestet im Projekt und haben erstmal zu kleineren Storys angefangen und haben dann immer mehr größere Storys damit entwickelt und es hat funktioniert.
Also man hat am Anfang natürlich, man muss in kleinen Inkrementen arbeiten und auch das Tool lernen, ja, das ist alles neu.
Aber wenn man dann quasi jetzt über die Best Practices, über die wir dann sprechen werden, wenn man die gescheit anwandt, kriegt man Output raus, mit dem man leben kann im Projekt.
Also was mit den Qualitätsstandards von einem, wie sagt man, gerecht wird in einem Projekt.
Genau, ich finde nur noch ein Grund, was sich wirklich da mit diesen Coding-Agenten maßgeblich geändert hatte, war, dass diese Modelle immer besser darauf hin geworden sind, sogenannte Tools zu nutzen.
Also, dass sie sich nicht nur noch auf das interne Wissen verlassen, was immer etwas, was manchmal gut sein kann bei Fragestellungen, die oft im Internet beantwortet werden, bei anderen Fragestellungen weniger gut funktioniert, sondern dass diese Agenten halt diese Tools einsetzen können, um sowohl Daten zu lesen und damit halt sich auf bessere Quellen zu beruhen und auch die Umgebung, also das Totalsystem anzupassen und dass man damit weniger schleifen über ein Chat-Interface drehen muss.
Und ich erinnere mich noch, weil wirklich die Cloud-Modelle da Vorreiter waren.
Ich war in dem Projekt, in dem ich zu dem Zeitpunkt war, sehr auf die OpenAI-Modelle limitiert und ich habe auf jedes Model Release sehnsüchtig gewartet und geschaut, ja ist jetzt OpenAI endlich auch soweit, dass ihre Modelle Tools gut aufrufen können.
Und das hat sich eigentlich auch erst mit GPT-5 geändert.
Davor hat man immer bei den älteren Modellen gemerkt, dass sie damit einfach Probleme hatten und sehr schnell aufgehört haben, diese Tools zu nutzen und da einfach zuverlässig funktioniert haben.
Ich muss hier gleich mal nachraten.
Ihr habt jetzt in eurer Erzählung einen starken Schwerpunkt auf die Modelle gelegt, dass die immer besser geworden sind, besser, besser, besser.
Viele sagen ja, oh, ich habe jetzt hier meine 24 Agenten und die habe ich so gefeintuned, dass es endlich läuft.
Da gibt es ja diese verschiedenen Aspekte.
Wie kann ich meinen Flow verbessern, meinen Workflow?
Wie kann ich das Ganze zum Leben erwecken?
Aus eurer Erzählung habe ich jetzt so ein bisschen rausgehört, es sind die Modelle, die verdammt gut geworden sind, oder?
Tobi, ich überlasse es dir erstmal.
Sowohl als auch.
Ich würde sagen, es sind hauptsächlich die Modelle, die sich verbessert haben.
Gerade bei den alten Modellen gab es immer viele Tricks, die man anwenden konnte, um noch mehr Nuance aus den Modellen rauszuholen.
Aber am Ende waren zum Teil die Modelle einfach nicht weit genug.
Das sieht man ja auch, dass Cloud Code anfangs ein relativ einfaches Programm war.
Es war wirklich nur ein Modell, was gewisse Tools hat, um mit dem Dateisystem, mit dem Internet zu interagieren, was auf der Codebase läuft, mit noch relativ wenig Prompting.
Und dass das einfach sehr gut funktioniert hat.
Ich habe da auch viele Podcasts in dem Bereich gehört.
Und die Leute von Androphic haben auch gesagt, dass sie, wenn sie einen Fehler gefunden haben mit Cloud Code, dass sie anstatt ihren Prompt zu updaten, lieber das Modell auf diesen Fehler trainiert haben, sodass das Modell in Zukunft diesen Fehler nicht mehr machen wird.
Wenn wir aber dann natürlich in die Richtung des Best Practices schauen, gibt es auch einiges, was man tun kann, um halt das Modell dann auf einem bestimmten Use Case zu finetunen, zu schauen, dass das Modell die richtigen Informationen hat, dass es die persönlichen Präferenzen kennt.
Aber das kommt nochmal oben drauf.
Bevor wir jetzt in Richtung Best Practice gehen, noch eine Frage.
Ihr habt jetzt die verschiedenen Phasen angesprochen.
Setzt ihr den Cursor noch in das Editor-Fenster, Hand aufs Herz?
Macht ihr noch manuelle Edits oder geht das schon komplett über die Prompt?
Genau.
Ich würde auch gerne nur ein, zwei Sätze zu deiner Frage vorher verlieren.
Ich denke, das ist ein Mix aus beidem.
Also die Modellverbesserung als auch die Verbesserung der Coding Agents, also von einem Harness, weil das spielt auch eine Rolle, vor allem wegen Tool Calling und so weiter.
Und was wir dann auch zum Beispiel im Projekt, also gegen Ende letzten Jahres gemerkt haben, als Opus 4.5 rauskam, das war wirklich nochmal ein Game Changer.
Also da hat man die Änderung wirklich, wirklich gemerkt.
Aber es ist so ein Mix aus beidem.
Und tatsächlich bin ich der Meinung, dass die, ich nenne es jetzt mal Modellintelligenz, geht irgendwann bis zu einem Level, wo es dann wahrscheinlich eine Wand erreicht.
Aber das ist jetzt nur eine Prediction, wo dann die meisten Optimierungen auf dem Harness Level passieren werden, also von Coding Agenten.
Die zweite Frage, sorry, ich hatte die vergessen.
Nochmal, kannst du mal stellen?
Ob ihr noch den Cursor ins Editor Fenster stellt?
Ob ihr noch manuelle Edits macht?
Ich persönlich nicht mehr.
Also ich habe IntelliJ gelöscht.
Ich nutze persönlich nur noch VS Code, um Code zu reviewen tatsächlich.
Also wenn da mal größere Chunks landen.
Ansonsten mache ich alles mit Coding Agents, so viel wie ich kann.
Aber ich muss auch sagen, wenn ich so sehr kleine Änderungen machen muss, also da ist ein Coding Agent Overkill.
Wenn ich sofort weiß, was ich anfassen muss, dann mache ich es immer noch selbst.
Aber ansonsten so die meiste Arbeit über Coding Agents.
Ja, das geht mir auch so ähnlich.
Also ich war in den ersten fünf Jahren meiner Berufslaufbahn sehr intensiver IntelliJ Nutzer.
Und irgendwann hatte ich so einen Tick gehabt und bin auf NeoWim geswitcht und war dann sehr intensiver Wim Nutzer.
Also wirklich.
Also mir hat das auch sehr, sehr viel Spaß gemacht, einfach den eigenen Arbeitsfluss zu optimieren und so kleine Kniffe rauszubringen.
Finden, wie man etwas schneller wird im Codeschreiben.
Aber habe dann halt auch in den letzten Monaten gemerkt, dass ich dann immer weniger den Editor einfach eingesetzt habe zum Schreiben, sondern eher um den Code zu lesen.
Und ja, muss mir auch eingestehen, dass ich wirklich nur noch sehr begrenzt Code von Hand geschrieben habe in letzter Zeit.
Einfach weil man kann die Änderungen ja immer weiter runterbrechen und am Ende sind die Agenten einfach sehr, sehr gut da drin, die Sachen anzupassen.
Und da verspürt man dann nicht mehr die Lust, manuell Code zu verschieben oder größere Effekte zu machen.
Eine Sache, die ich halt bei der Vorbesprechung spannend fand, war das, was du gesagt hast, Jadu, dass du sozusagen vom Zweifler über die ersten beiden Wellen reithin zu das funktioniert wirklich und da hat sich was fundamental geändert, bei dem du Coding Agents gekommen bist, dass du da zu einer neuen Einsicht gekommen bist und auch implizit die Empfehlung gegeben hast, dass sich Menschen das deswegen noch mal angucken sollten, auch wenn sie von den ersten Tools sozusagen enttäuscht sind.
Was mich jetzt interessieren würde, Tobias, siehst du das genauso?
Ist das bei dir eine ähnliche Story oder hast du da irgendwie eine andere Erfahrung oder sah das für dich anders aus?
Also die ersten Entwicklungstools war ja quasi GitHub Copilot und da war der Fokus vor allem auf Autocompletion und das hat mich persönlich nie gereizt.
Also ich konnte immer recht schnell tippen und wusste auch meistens, wenn ich dann im Code war, was ich machen möchte.
Das heißt, da hat mich eher die Verzögerung, um auf die Autovervollständigung zu warten, eher genervt, anstatt dass es mir geholfen hat.
Was ich manchmal verwendet habe, war, dass man Teile im Code markiert und dann auf dieser Markierung Änderungen gepromptet hat.
Also das habe ich oft genutzt, um kleinere Effekte zu machen oder Sachen aufzuräumen.
Also das war was, was ich genutzt habe, weil ansonsten habe ich dann auch eher für Recherche und mit dem Chat gearbeitet.
Also ich habe zu dem Zeitpunkt viel per Plexity eingesetzt für Web-Suche, weil ich oft auch am Bahnsteig stand, irgendwelche technischen Fragen hatte und mich gefragt habe, ist das möglich.
Und dann habe ich einfach mein Handy getippt und als ich dann später an der Bahn war, konnte ich mir dann Reporter zu anlesen, was so die Antwort auf meine Frage war.
Und das nutze ich heute immer noch.
Ich nutze es für Plexity, aber ich nutze dieses Prinzip immer noch und das hat auch immer sehr gut funktioniert.
Anmerkung aus dem Chat von Marian Zeiss 4687 bei YouTube.
Ich habe Cursor hauptsächlich für komplizierte Setups und Reviews, ansonsten Cloud Codecs und Review in GitHub PRs, also per Request.
Ich weiß nicht, ob wir dazu noch was sagen wollen würden.
Sonst wäre die nächste Frage, die Frage nach dem Produktivitätsvorteil.
Das ist auch ein Ergebnis von der Vorbesprechung, die wir hatten.
Und zwar scheint ihr da ja tatsächlich Aussagen treffen zu können.
Also ob es jetzt mit Agents besser, schneller wird und wenn ja, wie viel?
Genau.
Also wir hatten keine konkreten Zahlen oder so gemessen, weil wir waren auch selbst irgendwie am Entdecken und schauen, wie das funktioniert, wie setzen wir das am besten ein und so weiter.
Ich habe das aber stark observiert.
Einfach auch so ein bisschen aus der Tech Lead Brille von einem Subteam.
Und es war recht interessant.
Also wir hatten quasi im Projekt, ich sage mal so drei Arten von Aufgaben, wo wir uns immer damit beschäftigt haben.
Und das eine war zum Beispiel Debugging.
Also wir hatten halt ein sehr fragiles System, das wir modernisieren mussten.
Und es war halt nicht unüblich, dass wir da jeden Tag mal mindestens zwei, drei Bugs hatten, die immer unterschiedlich kritisch waren.
Und da hat die Analyse vor den Coding Agents meistens ein paar Tage gedauert, bis man so eine Root Cause Analysis gemacht hat.
Kommt natürlich auch ein bisschen auf die Komplexität von dem Bug an.
Was aber dann wirklich interessant war, war mit Cloud Code hat sich das alles, also es wird viel, viel besser.
Wir saßen an diesen, ich sage mal Medium Level Bugs nicht mehr als einen Tag.
Also so eine Analyse hat dann meistens ein paar Stunden gedauert und wir konnten es dann am selben Tag noch fixen.
Und es ist halt recht spannend, weil die Agents haben natürlich den ganzen Kontext aus dem Projekt und man stiert die quasi selbst.
Man weiß quasi als Experte, wo was sein könnte und gibt so eine Richtung an.
Und dieses ganze Gruntwork, was man selbst machen würde, irgendwie massenweise Logs lesen und so weiter und Stack Traces lesen, das übernimmt der Coding Agent dann für mich.
Es ist halt sehr gut, Pattern Matching zu betreiben oder irgendwie so ein Nadel im Heuhaufen zu finden.
Also die Art von Bugs funktioniert super gut.
Da haben wir wirklich gemerkt, dass wir schneller geworden sind.
Und teilweise hat sich dann immer eine Person später nur noch um Bugs gekümmert und die anderen konnten sich dann um andere Themen kümmern und wir haben dann immer so rotiert.
Und davor war das meistens so, dass sich dann irgendwie zwei oder drei Leute aus dem Team sich um so Bugs gekümmert haben.
Und dasselbe ist dann auch in anderen, also Feature-Entwicklungen zum Beispiel, haben wir dann auch gemerkt, dass Arbeit schneller in Produktion gelandet ist als davor.
Und genau, als auch die Leute im Team irgendwann auch so eine Intuition entwickelt haben und auch die Tools besser verstanden haben, wie sie quasi arbeiten können mit den Tools, ist es dann irgendwann auch so weit skaliert, dass dann eine Person ein ganzes Epic übernommen hat.
Und wir konnten dann auch so schneller Features deliveren.
Ich sage immer ungern, ich hasse es irgendwie, Lines of Code oder PR als Metrik zu nehmen.
Das ist Schwachsinn, finde ich.
Aber was so ein Indikator für mich war, war, dass wir zum Beispiel immer vor unseren Schätzungen auch deliveren konnten.
Jetzt kann man auch sagen, okay, das liegt vielleicht an der Schätzung selbst.
Aber es war schon sehr, sehr interessant.
Also man hatte wirklich schon so ein Gefühl, dass man schneller ist.
Und genau, eine andere Art auch dann bei Migrationsaufgaben.
Also dann, wenn wir über die Modernisierung selbst sprechen.
Ganz am Anfang, also wir hatten wirklich eine sehr, sehr schlechte Codebase am Anfang.
Also ich habe das auch in meinem Blog ein bisschen beschrieben, aber mal so kurz zusammengefasst.
Also das alte Team war weg, wir hatten kaum Dokumentation, keine Tests, JavaScript, also kein TypeScript, keine Typen.
Es gab gar keinen Pattern zu sehen.
Also wir hatten noch sehr viel Code-Duplikation.
Naming war grauenhaft.
Und vor diesen ganzen Tools saßen wir da wirklich dann zu fünft und haben dann gesagt, okay, bevor wir modernisieren, wir müssen verstehen, wie dieses Modul funktioniert.
Wie sieht die Architektur dahinter aus?
Wie fließen Daten von A nach B?
Diese ganze Aufgabe, um diesen Ist-Zustand erstmal herauszufinden.
Und das hat in den Anfängen, es hat meistens über so eine Woche gedauert.
Wenn es ein komplizierteres Modul war, vielleicht anderthalb, zwei Wochen.
Und diese ganze Wissensextraktion konnten wir runterbrechen auf fast einen Tag mit den Coding Agents.
Also Wissensextraktion oder so Specs zu extrahieren, Dokumentation zu extrahieren, funktioniert sehr, sehr gut.
Und das war auch jetzt in dem ThoughtWorks-Techradar.
Da ist auch dann GenAI als Tool, um Wissen zu extrahieren von Legacy-Codebases, war auch im Kern, also im Adapt-Kern.
Und ja, funktioniert sehr, sehr gut.
Wenn du dazu noch eine Frage hast, gerne zuerst.
Ich wollte es eigentlich zusammenfassen, also von daher gerne ergänzen.
Ich glaube auch, die Produktivitätsgewinne sind nicht gleichmäßig über alle Aufgaben hinweg.
Je nachdem, in welchen Projekten man arbeitet, gibt es Aufgaben, die relativ einfach von Agenten gemacht werden können.
Sagen wir, man hat ein neues Webinterface, was man implementieren möchte, was man schon sehr oft gemacht hat.
Dann sind die Agenten da einfach sehr gut drin, die vorhandenen Patterns, die man schon oft genutzt hat, zu kopieren.
Oder man hat Automatisierungsmöglichkeiten in der Codebase, die man vorher nie genutzt hat, weil man nicht die Zeit hatte, ein paar Tage zu investieren, diese Skripte zu schreiben.
Das kann man mit Agenten mittlerweile auch extrem gut machen.
Und auch, weil ich beobachtet habe, in Trainings, die ich angeboten habe, in Projekten, dass diese Teams oft danach angefangen haben, deutlich mehr zu refactoren, weil einfach sie mehr Zeit hatten, solche Refactorings anzugehen und auch die Refactorings selber nicht mehr so viel Zeit gekostet haben, wie das früher der Fall war.
Wobei es auch sicher einige Kernaufgaben gibt, zum Beispiel in einem sehr komplizierten fachlichen Corps, wo die Agenten weniger hilfreich sind, weil einfach so viel Kontextwissen notwendig ist, um die Änderungen genau richtig zu machen und keine Fehler zu machen, weil jeder Seite im Code sehr viel Aussagekraft hat.
Was ich spannend fand und deswegen wollte ich auch gerne diese Episode machen, ist einmal, dass ihr, glaube ich, also ihr habt es ja selber gesagt, das ist halt nicht so, wie soll ich es sagen, wissenschaftlich.
Wir sprechen dann im Weitersprech mit Ingo nochmal über das Thema, Ingo Eichhorst über das Thema mit den wissenschaftlichen Studien zur Produktivität.
Aber es ist, finde ich, ein ziemlich starker anekdotische Evidenz, weil ihr ja sagt, dass ihr eben diese Module übersetzt und dass da vergleichbare Aufgaben sind, die da deutlich schneller gehen.
Wir reden ja immerhin über Faktoren.
Und das andere, was ich spannend fand, war, dass es eben auch insbesondere in der Arbeit mit Legacy System ja offensichtlich etwas ist, wo ihr gute Erfahrungen gesammelt habt.
Und deswegen finde ich das halt einen spannenden Hinweis erstmal.
Es gibt eine Frage aus dem Chat.
Ich bin nicht sicher, ob wir diesmal tatsächlich alle Sachen aus dem Chat durchdiskutieren werden.
Aber diese hier fand ich spannend.
Von M.
Heldev auf YouTube.
Seht ihr Nachteile, wenn man sich weniger intensiv mit dem Code beschäftigt, also nur noch Reviews?
Also ich glaube, da gibt es definitiv Nachteile.
Also man muss ja etwas abstrakter denken, wenn man den Code auf den höheren Ebenen quasi vor allem betrachtet und auch weniger damit beschäftigt ist, den Code selber zu schreiben, sondern halt vor allem zu reviewen.
Das heißt, ja, ich glaube, es kommt da immer mehr auf Architekturwissen auf und auf Wissen, was man normal mit jahrelanger Erfahrung sammelt.
Und ich glaube, wir müssen uns als Industrie schon die Frage stellen, wie bekommt man dieses Wissen dann, wenn man den Code immer weniger selbst schreibt?
Und auch, wie gehen wir damit um, dass das, was du schreibst, einfach immer stärker anwächst, weil der Code schneller geschrieben wird?
Also es gibt da auf jeden Fall Herausforderungen, wo ich glaube, auch keiner von uns behaupten würde, die Antwort daraus zu haben.
Das sind einfach Herausforderungen, mit denen wir uns als Industrie auseinandersetzen müssen und wie wir damit am besten umgehen.
Ja, aber ich weiß nicht, ob du da noch etwas zu ergänzen hast?
Ne, ich sehe das genauso wie du.
Wie steht ihr zum Code Review?
Muss jede Zeile gereviewt werden oder seid ihr da schon entspannter und vertrauter KI?
Habt ihr gesagt, die Modelle werden immer besser?
Das ist, glaube ich, so das Thema aktuell.
Also ich kann mal sagen, wie wir das zum Beispiel im Projekt angegangen sind.
Also grundsätzlich hatten wir die Regel, wenn jemand ein Pull-Request nicht erklären kann, was er selbst halt erstellt hat, dann wird es nicht gemerged.
Punkt.
Also weil wir tragen da halt eine Verantwortung.
Wir hatten auch zum Beispiel On-Calls und so weiter und das ist halt verantwortungslos, wenn dann jemand anders irgendwie den Code verstehen muss, wo das jemand jetzt, ich sag mal, geweibcoded hat.
Es ist jetzt halt interessant, weil alle stoßen genau auf dieses Thema, sobald sie, ich sag mal, ein bisschen besser werden mit den Tools und dann anfangen, Code zu generieren.
Und es ist dann, würde ich auch mal behaupten, natürlich, dass dann Leute anfangen, dann Riesen-PAs zu erstellen und so weiter.
Aber Code Review ist immer noch wichtig.
Und das war auch so das O-Ton zum Beispiel in der AI-Ingenieurkonferenz vor ein paar Monaten in London.
Also wir haben das zum Beispiel dann so gemacht, dass wir gesagt haben, okay, du hast jetzt mit Cloud Code einen Code generiert.
Dann war das Erste, wir hatten Review Agents auch.
Also wir haben dann so Custom Sub-Agents mit System Prompt definiert.
Damals gab es noch keine Skills.
Und wir haben dann da quasi unsere Review-Konvention so ein bisschen abgebildet und haben dann gesagt, okay, da fängt ein Sub-Agent an, reviewt das und der Sub-Agent hat dann meistens schon mal so einen ersten Balken gefunden.
Und dann habe ich als Entwickler das gefixt und habe dann danach selbst nochmal ein Review gemacht, weil ich bin immer noch der Experte.
Und ich schaue dann quasi, ob wir die Conventions, ob wir das Ziel und so weiter erfüllt haben.
Gehen wir in die richtige Richtung und so weiter.
Dann ist unser PR auf GitHub gelandet und da hatten wir nochmal einen Copilot Agent.
Der hat dann auch nochmal drüber geschaut und hat dann für den nächsten menschlichen Review eine Zusammenfassung erstellt.
Und damit dann, wenn ich jetzt zum Beispiel dann ein PR von einem anderen anschaue, schaue ich mir erstmal die Zusammenfassung an, sehe dann, okay, weiß dann, in welchem Kontext ich mich befinde und review dann auch nochmal selbst.
Also es war auch wichtig, weil ein Projekt, wo wir gearbeitet haben, das lief auf einer kritischen Infrastruktur.
Das heißt ja, wir haben auch jede Zeile gereviewt und ich finde, das sollte man immer noch machen.
Ich wollte nur noch was anschließen, Ralf, weil du auch gemeint hast, okay, auf welchem Level sollte man reviewen?
Und ich glaube, da spielt schon nochmal die Kritikalität des Systems eine entscheidende Rolle.
Das heißt, bei unkritischen Teilen des Systems, also zum Beispiel, sagen wir jetzt mal Frontend-Code, der in der Ecke vom System liegt, die erstmal nicht weiter erweitert wird oder unkritischen Code, da würde ich sagen, reicht auch meistens ein High-Level-Review erstmal aus, dass da jetzt keine großen technischen Schulden aufgebaut werden, dass sich das gut in die Architektur einfügt.
Aber dann hat man die Teile des Systems, die systemkritisch sind, also die wirklich die Kernlogik betreffen, die sehr häufig ausgeführt wird, wo Fehler sehr fatal sind oder Teile des Codes, die sehr häufig wiederverwendet werden im Laufe des Projektlebenzyklus, wo sich auch Fehler sehr stark auswirken auf das Projekt.
Und ich glaube, da muss man sich eigentlich jede Code-Seite anschauen, um da effektiv zu sein.
Aber wie gesagt, bei diesem Code, der vielleicht eher am Rande des Projektes ist, der weniger systemkritisch ist, den man auch schnell nochmal anpassen könnte, falls es da Probleme gibt, da kann man auch ein bisschen mehr auf die Funktionalität schauen, aber sollte weiterhin den Code wenigstens überfliegen.
Und ich glaube, das war aber auch schon vorher so.
Also das war auch so vorher, wenn man zum Beispiel ein Techlead in einem Projekt war, da hat man ja auch mit gewissen, bei kritischen Systemen nochmal ein Stück genauer auf ProRequest geschaut, als das der Fall ist, wenn man an eher unkritischen Punkten im System ein Review gemacht hat.
Das waren jetzt eigentlich drei interessante Punkte.
Die Verantwortung.
Ja, du, das hast du gesagt.
Verantwortung.
Und du bist der Experte.
Und dann noch das Risikoabwägung.
Ich finde den Punkt, dass wir sagen, ja, wir sind die Experten.
Wir müssen drüber gucken.
Spannend, weil ich habe das Gefühl, das kippt gerade, weil die Modelle werden immer besser und besser und besser.
Die haben einen größeren Lösungsraum als wir.
Und gerade jetzt, wo die neuen Modelle ständig durch die Presse gehen, was die für Sicherheitslücken in Code finden, die eben vorher nicht gefunden worden sind, da muss man ja schon fast sagen, so ein Security Review, das kann die KI mittlerweile fast besser als der Mensch, oder?
Wie ist da eure Einschätzung?
Ja, also ich verstehe deinen Punkt.
Und die KI ist tatsächlich gut.
Edge Cases und jetzt, ich glaube, du sprichst auch Cloud Meters an, also ich würde das eher als Tool in meinem Werkzeugkasten nochmal sehen on top.
Also ich kriege dann quasi Feedback von dem Modell, sehe Sachen, die ich vielleicht auf die Schnelle nicht finden würde, aber ich selbst schaue auch nochmal auf das Große und Ganze.
Ja, ich sehe das persönlich so.
Also es ist einfach ein Werkzeug in meinem Werkzeugkasten.
Ich wollte das nur nochmal unterstreichen, ganz kurz.
Ich glaube, am Ende, wir als Experten sollten die Modelle auch als Sparing Partner nutzen.
Es gibt gewisse Fähigkeiten in Modelle, wo sie besser sind wahrscheinlich als wir alle.
Also bei Security Review, weil ein Modell kann unermüdlich diese einzelnen Teile der Codebase durchsuchen, nach Security-Fehlern, die auf Zusammenhängen bestehen, die man als Mensch vielleicht leichter übersehen würde.
Oder das Modell hat ein sehr breites Wissensspektrum, weil quasi das ganze Internet in der zusammengefassten Form in dem Modell reintrainiert werden.
Das heißt, auch für so Sachen wie Brainstorming sind Modelle extrem hilfreich.
Also bevor ich große Architekturentscheidungen treffe, mache ich mittlerweile immer eine Brainstorming-Session mit dem Modell, um halt auch Wissenslücken in meinem eigenen Denken aufzudecken.
Oft schon mit einer gewissen Vorstellung, wie ich ein Problem angehen möchte.
Aber ich glaube, diese Zusammenarbeit ist extrem wichtig, dass die Stärken sich quasi ergänzen.
Tut mir leid, ich überrasche.
Ja, alles gut.
Ihr seid ja primär da.
Aber das ist ja nicht euer Thema.
Ich komme trotzdem nicht umhin, noch mal zu diesem Mythos-Thema etwas zu sagen.
Ich bin gestern über den Blogbeitrag von dem Menschen, der Curl gebaut hat, gestolpert.
Er hat gesagt, dass exakt eine große Vulnerability in Curl gefunden worden ist durch die AI-Modelle.
Wenn, dann halt kleinere und mittlere.
Und wenn Mythos halt so eine Geheimwaffe ist, kennt ihr Security-Fehler, die so gigantisch sind, die gefunden worden sind?
Mir sind keine bekannt.
Ich habe jetzt nicht tiefer in die Sicherheitslücken geschaut.
Und ich weiß, es gibt auch sehr viel Müll, der von so automatisierten AI-Systemen an Open-Source-Projekten gespürt wird.
Ich glaube, das ist ein Riesenproblem, was Open-Source-Medien aktuell haben, dass sie überschwemmt werden mit vermeintlichen Sicherheitslücken.
Aber ich finde, das spiegelt auch wieder, dass wir als Menschen da noch eine tragende Rolle spielen.
Das heißt, die Modelle sind eigentlich nur eine Verlängerung oder sind halt Werkzeuge, die wir nutzen können.
Aber am Ende müssen wir noch mal bewerten, ist diese Sicherheitslücke wirklich eine Sicherheitslücke oder ist das etwas, was das Modell ausgedacht hat oder vielleicht in der Praxis nicht relevant ist.
Genau.
Ansonsten, wir haben eine wahnsinnig große Anzahl an Fragen aus dem Chat.
Ich würde jetzt, also weil wir den Bereich, über den wir vorher diskutiert haben, Space Practices, noch nicht begonnen haben, würde ich vorschlagen, fangen wir mit dem erst mal an, bevor wir die Fragen diskutieren.
Wir könnten nochmal überlegen, ob wir irgendwann eine eigene Session machen, um die Fragen nochmal zu diskutieren.
Das wäre vielleicht eine Idee.
Ansonsten würde ich halt hoffen, dass wir da weiterkommen.
Sorry, eigentlich ist das Gegenteil, sonst wären wir da klar.
Genau, von daher wollen wir loslegen mit dem Context Engineering.
Ist das das erste, was mir in unseren Notizen steht?
Ja, gerne.
Ich mache da einfach mal weiter.
Genau, also Context Engineering ist eine Disziplin, die halt letztes Jahr sehr im Munde war.
Und das ist aber unter sich immer noch relevant und einer der ersten Techniken, die man einsetzen sollte, um bessere Ergebnisse aus den Agenten zu ziehen.
Um nochmal einen Schritt zurückzugehen, das Besüchnis Space Practices.
Also man kann jetzt sich eine Cloud-Subscription abschließen, kann Cloud Code öffnen und kann dann einfach lospromten und Cloud sagen, bitte schreibt mir Software X, Y und Z und Cloud wird das machen.
Aber man wird da recht her an Limitationen stoßen.
Gerade wenn man selbst Software Entwickler ist oder Architektin, wird man halt merken, die Qualität, die da aus diesen Systemen kommt, ist sehr unterschiedlich.
Manche Sachen funktionieren sehr gut, manche Sachen funktionieren weniger gut.
Und wenn man einfach so weiter promptet, wird man recht schnell an Probleme stoßen.
Und deswegen haben wir diese interne Schulung, wo wir diese Best Practices vermitteln.
Und wie gesagt, Context Engineering ist einer der ersten Best Practices und das beschreibt einfach nur die Best Practices um den Kontext des Modells oder der Agenten drumherum.
Also dazu muss man wissen, diese Sprachmodelle nutzen alle Text Tokens.
Also es kommt quasi Text in die Modelle rein und Text kommt aus den Modellen raus.
Dieser Text ist aufgeteilt in sogenannte Tokens.
Das kann man sich wie Silben oder Teile von Wörtern vorstellen, die in Zahlen encoded sind, dass das Modell das versteht.
Und diese Anzahl an Tokens, die in das Modell reinkommen, die sind in der Menge limitiert.
Und das ist das sogenannte Context Window.
Das war in der Vergangenheit meistens so bei 250.000 Tokens.
Mittlerweile ist eine Million Tokens der Standard.
Aber wenn man am Ende dieses Context Windows angelangt ist, dann kann man in der Regel mit seinem Chat nicht mehr weitermachen, also ohne diesen Context wieder zusammenzufassen.
Das heißt Compacting.
Und desto näher man ans Ende dieses Context Windows kommt, also desto länger der Chat geht, desto schlechter wird auch die Performance der Agenten.
Das heißt, wenn man jetzt ganz neu auf Cloud Code öffnet, man hat eine Aufgabe, man gibt Feedback zu der Applikation und macht immer weiter in diesem Chat, wird man mit der Zeit merken, dass das Modell immer mehr Details in der Konversation vergisst und immer mehr Fehler macht.
Und dieses Phänomen heißt Context Rot.
Deswegen beim Context Engineering geht es darum, diesen Kontext des Modells möglichst relevant zu halten und auch den Kontext möglichst klein zu halten, dass das Modell weiterhin fokussiert ist.
Und da gibt es dann verschiedene Techniken, die man einsetzen kann, was quasi die ganze Basis ist, wenn man mit Agenten arbeiten möchte.
Ich hoffe, das war jetzt nicht zu technisch.
Ich bin jetzt sehr schnell sehr tief eingestiegen.
Deswegen da auch noch mal offen für Fragen oder Ergänzungen.
Ich würde ganz kurz noch mal darauf einsteigen.
Du hast jetzt gesagt, den Kontext zusammenzufassen.
Habt ihr da Tipps und Tricks, wie man das am besten macht, wann und hat man da Einfluss auf die Zusammenfassung?
Das Ding mit der Zusammenfassung ist, Compacting ist eine Lossy Function.
Es kommt ein bisschen auf den Workflow an.
Es gibt einen sehr guten Talk von Dex Horthy, der heißt No Vibes Allowed.
Er beschreibt dieses Context Rot-Phänomen.
Man kann sich Context Rot so vorstellen, dass es eine Smart- und Dump-Zone gibt.
Die Smart-Zone befindet sich ungefähr bei 40 bis 60 Prozent von dem Kontext-Window.
Das heißt, sobald dein Kontext-Usage über diesem Threshold ist, wird dein Agent dümmer.
Wenn ich zum Beispiel sehe, dass mein Agent irgendwann sagt, you’re absolutely right, weiß ich wahrscheinlich, es ist in einer Dump-Zone.
Der Grund dafür ist, warum man früher Compacten will oder so ein Hand-off machen will in eine neue Session, ist, dass in der Smart-Zone der Agent fokussiert ist.
Man muss sich den Kontext-Window so vorstellen wie ein Kurzzeitgedächtnis.
Ein Modell kann eine Handvoll Dinge gleichzeitig im Kopf behalten.
Das heißt, je mehr man hinzufügt in ein Kontext-Window, desto mehr landet man in dieser Dump-Zone.
Das ist das Context Rot-Phänomen.
Deswegen gibt es unterschiedliche Workflows.
Ich persönlich compacte auch lieber früher und habe dann fokussierte Sessions und arbeite so.
Es gibt aber auch Menschen, die reizen das komplett aus und landen dann in dieser Auto-Compacting-Zone.
Da kann es dann auch passieren, dass dann Informationen verloren gehen, einfach wegen dieser Lossy Function.
Ich will direkt auf die Frage eingehen.
Man kann diesen Compacting-Vorgang auch beeinflussen.
Man kann bei Cloud Code und auch bei anderen Tools auch einen Prompt mitgeben, wo man sagen kann, fokussiere dich eher auf diese Ansätze oder auf diese Punkte in der Konversation als auf andere Punkte.
Eine Technik, die wir empfehlen und auch gerne einsetzen, ist, dass man diese Compact-Funktion eher weniger nutzt, sondern stattdessen dem Agenten sagt, speichere jetzt die Information aus der Konversation in einer Datei ab, meistens eine Markt-Datei, und dass man diese Datei dann mitnimmt in die nächste Session.
Das kann ganz viele Formen annehmen.
Man kann das ganz spontan machen und einfach eine Zusammenfassung in ein Dokument schreiben lassen.
Aber auch wenn man jetzt zum Beispiel in einer Konversation einen Plan erstellen möchte, kann man diesen Plan als Markt-Datei ablegen.
Die Agenten haben für Pläne schon sowas in der Regel eingebaut, aber diese Technik ist sehr mächtig und die kann man auch sehr gut für verschiedene Workflows verwenden.
Das bedeutet, die wesentliche Maßnahme ist, neue Sessions anzulegen mit den entsprechenden Informationen, die ich gerade relevant finde für das Thema, was ich gerade diskutieren will.
Also deswegen mehr Sessions mit den jeweiligen Ausrichtungen.
So habe ich das jetzt verstanden.
Genau.
Exakt.
Und gerade wenn man Markt-Dokumente erstellt, ist das gut.
Die hat man abgelegt.
Wenn man eine neue Session startet, lädt man direkt diese Markt-Datei rein.
Das heißt, der Kontext des Modells zu dem Zeitpunkt, wo man die Session startet, hat sehr hohen Informationsgehalt und ist sehr relevant für die Aufgabe, die man als nächstes angehen möchte.
Also zum Beispiel, das kann man sehr aktiv nutzen.
Man hat jetzt ein sehr kompliziertes Thema, über das man diskutieren möchte.
Da könnte man zum Beispiel erst mal eine Chat-Session starten, fokussiert auf Research, dass man dieses Thema sehr gut versteht, könnte die ganzen Research-Ergebnisse in einem Dokument speichern und dann mit diesen Research-Ergebnissen diese Konversation starten, dass man da fundiert, gleich loslegt.
Und ich hatte auch verstanden, diese Geschichte mit, wenn man sozusagen einen Weg geht, der aus irgendwelchen Gründen unsinnig ist, dass man dann eben versucht, sozusagen nochmal zurückzugehen und von dem davor anzufangen.
Genau.
Da wollte ich nur sagen, bei Cloud Code wäre das Escape, Escape.
Da kann man erst mal zurückgehen.
Wie gesagt, andere Coding-Agenten haben mittlerweile ähnliche Methoden.
Oft dann praktisch anders umgesetzt, aber sehr guter Einwand nochmal, dass man da auch immer zurückgehen sollte, wenn man sich auch vertippt hat oder einen Fehler hatte, anstatt halt im gleichen Chat den Fehler dann verbal zu korrigieren.
Dann haben wir als nächstes Thema das Workflow und Spec-driven-Development-Team oder haben wir noch was zu Context-Engineering?
Können wir gerne im Twitter machen.
Ja, du willst zu?
Welches Thema jetzt genau?
Workflow-Spec-driven-Development.
Wo wir ja auch schon die Episode hatten, die hattest du gemacht, Ralf, mit dem Simon zusammen.
Genau, und wir haben das Thema semantische Anker jetzt gerade ignoriert bei Context-Engineering.
Soll ich sozusagen dafür oder willst du dazu noch kurz was sagen, Ralf?
Lass uns zum Spec-driven weitergehen.
Was ist die konkrete Frage?
Also generell über Spec-driven?
Also wir sind ja bei Best Practices.
Das heißt, die Frage wäre, was für Best Practices haben wir in dem Bereich und wie gestalten die sich?
Wo muss ich aufpassen?
Also ich hinweise dafür, dass ich Agentic Coding auch erfolgreich hinbekomme.
Genau, ich kann da gerne weitermachen.
Also aus diesem Context-Engineering entstehen verschiedene Workflows.
Das heißt, ein relativ einfacher Workflow, den wir so als Start für unsere Studierenden nutzen, ist Research, Plan, Implement.
Das heißt, man hat drei Phasen.
Man hat erst eine Research-Phase, wo es darum geht, man möchte einfach die aktuelle Codebase verstehen, die aktuelle Implementierung von einem Feature.
Daraus erstellt man ein Dokument.
Dann macht man eine neue Session auf, geht in eine Planungsphase, wo man sich nur darauf fokussiert, einen Plan zu erstellen.
Oft in einem Q&A-Prozess mit dem Modell.
Wenn man dann damit zufrieden ist, speichert man das in einer Planmarkten-Datei ab.
Und dann geht es in die Implementierungsphase, wo in dem Plan schon genau drinsteht, was man eigentlich umsetzen möchte.
Und die Aufgabe des Modells eigentlich nur noch ist, diese Änderungen umzusetzen.
Und in diesem Workflow ist quasi Context-Engineering schon direkt eingebaut, weil man durch den Workflow gezwungen wird, die Sessions immer klein fokussiert zu halten.
Und da gibt es dann auch andere Workflows.
Superpowers ist etwas, was gerne erwähnt wird, die nochmal etwas mehr Phasen haben, aber auch ein ähnliches Prinzip verfolgen.
Und Spectre Development beschreibt so eine Kategorie von Workflows mit dem wesentlichen Unterschied, dass da nochmal stärker die Spezifikation im Vordergrund steht.
Das heißt, in einem klassischen Workflow wird man am Ende dieses Workflows eine Code-Änderung rausbekommen, ein Pull-Request, den man dann reviewen kann.
Bei Spectre Development hat man neben dem Code noch als Artefakt eine sogenannte Spec, die quasi in natürlicher Sprache beschreibt, was sind die Anforderungen für die Software, die man bauen möchte.
Ich glaube, immer noch das bekannteste Beispiel davon ist SpecKit von GitHub und Microsoft, was Anfang letzten Jahres sehr beliebt war.
In der Kollegschaft höre ich immer mehr raus, dass OpenSpec eine etwas leichtgewichtigere Alternative ist, die auch sehr beliebt ist.
Und ein Vorteil da ist natürlich, dass man diese ganzen Anforderungen, die vielleicht im Code auch nicht immer ganz klar erkenntlich sind, dass man die halt auch noch neben dem Quellcode im Projekt mit abpflegt und damit drüber iterieren kann.
Ein Nachteil davon ist aber auch, dass man quasi zwei Sources of Truth hat.
Man hat einmal den Code, der eine Wahrheit abbildet, und man hat die Spec, die eine andere Wahrheit abbildet.
Hoffentlich die gleiche, die halt auseinanderlaufen können.
Eine provokante Frage zu den Specs.
Simon Brown hat vor ungefähr drei Wochen mal gesagt, dass das Spectre Development für ihn keinen Sinn macht, weil aus Erfahrung sagt er, Entwickler schreiben nicht gern Dokumentationen.
Und warum sollte sich das jetzt hier ändern?
Warum sollen die auf einmal eine Spezifikation schreiben?
Wie seht ihr das?
Ich sehe das genauso.
Also ich habe so meinen Share mit Spectre Development über Route Flux gemacht, wo quasi die Specs auch die Treiber sind.
Und wenn man das halt wirklich richtig machen will, verschwendet man schon ein paar Stunden an den Specs, weil quasi dein Spec treibt den Code, der da generiert wird.
Das heißt, man muss dann sicherstellen, dass dein Spec fast lückenlos ist.
Und das ist fast unmöglich.
Und wenn man versucht, das lückenlos zu schreiben, dann sitzt man da in längeren Interview-Sessions mit dem Agent, dass man da so ein Shared Understanding entwickelt.
Und für mich hat das keinen Spaß gemacht.
Und das hat sich auch wie Zeitverschwendung angefühlt.
Also da könnte ich auch die Features tatsächlich ganz normal über einen kleinen Implement Workflow prompten.
Also das ist so mein Take.
Man sagt ja auch, dass eine Spec, die so detailliert ist, dass man daraus einfach den Code generieren könnte, ohne daraus zu schauen, quasi der Code selbst ist.
Weil ein Programmcode ist ja quasi eine Art, Anforderungen auszudrücken.
Es gibt ein Beispiel, wo ich gesehen habe, wo Spectre Development ganz gut bei MyGoogle funktioniert hat.
Und das ist ein Team, wo jetzt auch wegen Coding-Agenten, Requirements-Engineers und Entwickler deutlich enger zusammenarbeiten.
Und die nutzen tatsächlich Spectre Development, um Specs als Austausch-Medium und Jira-Ersatz zu nutzen.
Das heißt, die Requirements-Engineers erstellen quasi Specs basierend auf den Interviews, die sie mit Nutzern erstellen, die dann halt über die Specs in Handoffs zu den Entwicklern gehen.
Und das scheint da ganz gut zu funktionieren.
Aber da muss man auch sagen, die Specs sind da nicht auf dem Detail-Level, dass sie komplett den Code ersetzen, sondern sie sind auf dem Detail-Level, wie halt ein Jira-Level, dass die wichtigsten Anforderungen dort festgehalten werden.
Das wäre nämlich jetzt so ein bisschen, ich weiß nicht, wie ich es als Frage hätte formulieren sollen, aber mein Verdacht wäre gewesen, dass Specs etwas sind, was Domänexperten noch verstehen und Entwickler, also einfach, dass die Audienz vielleicht noch unterschiedlich ist.
Das scheint das ein bisschen zu bestätigen.
Die andere Frage, die sich halt für mich so ein bisschen, also ich glaube, das ist implizit klar, aber ich würde gerne noch mal zum Rückversichern nachfragen.
Ich nehme an, all diese Sachen entstehen im Dialog.
Das heißt, ich mache jetzt etwas bei Plan, kriege halt etwas von dem LLM und sage dann dem LLM netter Versuch, hier bitte sind die Sachen halt irgendwie noch nicht so, wie sie sein sollten, um dann halt irgendwie schrittweise weiterzukommen.
Und das ist dieses Human-in-the-Loop-Thema.
Richtig oder falsch?
Oder was ja dann bedeutet, dass Softwareentwicklung nicht mitnichten vollautomatisiert ist, sondern man ja immer noch da raufguckt?
Genau, also Human-in-the-Loop war in den letzten Monaten, glaube ich, so ein Ding, einfach weil die Modelle noch nicht auf so einem Level waren und man quasi immer mit einer Skepsis über die Ergebnisse drüber geschaut hat.
Ich glaube, das Ganze wird sich jetzt weiterentwickeln in so einem Human-on-the-Loop.
Und da ist ein sehr guter Beitrag von Keith Morris in dem Martin-Fowler-Blog.
Er hat es mir aufgeschrieben, Humans and Agents in Software Engineering Loops.
Und da geht es wirklich darum, um Harness Engineering.
Das A und O und eine der Best Practices, die wir auf jeden Fall, also Tobi und ich, versuchen zu vermitteln in den Trainings.
Und Harness Engineering beschreibt im Endeffekt, dass anstatt ein schlechtes Artefakt selbst zu fixen als Mensch, ändere ich stattdessen die Umgebung, die es erzeugt hat, damit mein Agent dann beim nächsten Mal das Richtige produziert.
Also das ist quasi, wenn man Backpressure, also Feedback Loops als Mechanismus verwendet, dann ist Harness Engineering die ganze Disziplin drumherum.
Und das ist so eines der Herzstücke, die wir quasi versuchen zu vermitteln, weil alle Konventionen, alle Regeln und so weiter, die man in einem Projekt enforcen will, kann man auf eine Art und Weise dem Agent vermitteln.
Ob das jetzt zum Beispiel Tests sind, ob das Linting-Regeln sind, ob das Architekturtests sind.
Ich glaube, das ist jetzt eine Disziplin, auf die jetzt stärker geschaut wird, weil das quasi die Autonomie eines Agents diktiert und wie weit man quasi einen Agent machen lassen kann, ohne selbst darauf zu schauen.
Das heißt, ich kann mich um die mehr komplexeren Themen kümmern und mein Agent kann sich um den ganzen Grundwork kümmern und wird dann auch auf die eigenen Fehler agieren, basierend auf den Regeln, die man definiert hat.
Sei es jetzt mein striktes Typsystem von der Programmiersprache bis hin zu vielleicht End-to-End-Tests und Custom-Tooling und so weiter.
Und das ist auch etwas, wo wir gerade sehr stark drauf schauen, wo wir auch sehr viel experimentieren und ich glaube, wo auch noch sehr viel Luft nach oben ist.
Und auch im Hinblick auf zum Beispiel Context-Efficient Backpressure, wo man dann auch diese beiden Disziplinen vermischt, also Context-Engineering, wo die Feedback-Loops, die der Agent dann wieder kriegt, kontexteffizient als Endpunkt bekommt.
Das sind zum Beispiel jetzt Tools am kommen wie RTK, die dann den Output von zum Beispiel einem Git-Status so komprimieren, dass ein Agent damit zurechtkommt.
Das mit dem Kontext, das ist ja dann auch dieses, wenn ich jetzt so einen Java-Stack-Trace zurückführen würde, dann ist der Kontext sofort voll, also ungefähr.
Richtig, ja genau.
Okay.
Genau, was ich da oder was wir da gerne machen, ist, dass man nochmal Skripte um diese zum Beispiel Testausführungen drüber rumschreibt, die die Aussatzungskontext reduzieren.
Zum Beispiel, wenn die Tests alle erfolgreich sind, dann kann da einfach ein Haken angezeigt werden.
Check, Tests sind erfolgreich.
Das sind dann fünf Tokens, die verbrannt werden, anstatt vielleicht hunderte von Tokens, weil man einen langen Stack-Trace noch sieht, weil vielleicht noch irgendwo Logs in den Tests versteckt sind.
Und das kann man auch auf die Spitze treiben und quasi bewusst den Output reduzieren auf das Wesentliche, was für den Agenten relevant ist.
Also das ist extrem spannend und kann halt auch, wenn man das gut macht, kann das dazu führen, dass man dann Sessions deutlich weiter treiben kann und dabei halt auch Kosten und Qualitätsverluste spart oder länger braucht, um diese Zone zu erreichen, wo der Agent einfach schlechter performt.
Hört sich für mich aber insgesamt, ich hänge halt noch an dieser, oder die Frage, die sich halt bei mir so ein bisschen aufdrängt, ist, okay, also es gibt ja diese Aussagen mit Entwicklern, insbesondere werden jetzt sehr bald arbeitslos sein.
Das, was ich jetzt raushöre, ist, oder das ist das Gefühl, was bei mir existiert, dass halt an vielen Stellen die Qualität von irgendwelcher Arbeit, die halt jetzt eine LLM macht oder Ergebnisse, die halt LLMs erzeugen, dass die ja bewertet werden müssen und dass halt ein Weg gefunden werden muss, um halt die Qualität dieser Ergebnisse weiter zu steigern.
Wie stark korridiert das?
Oder wie stark hängt das zusammen mit, sagen wir mal, klassischen EntwicklerInnen-Fähigkeiten?
Kann man sich vorstellen, dass das Menschen auf die Reihe bekommen, die halt nicht eine EntwicklerInnen-Hintergrund haben?
Ich glaube, man braucht, also technische Fähigkeiten sind sehr relevant.
Also gerade wenn man das Harness aufsetzt, gerade wenn man so Feedback-Schleifen aufsetzt, muss man ja sehr genau wissen, welche Tools kann man einsetzen, um dieses Feedback zu bekommen?
Welche Regeln sind eigentlich wichtig?
Und das sind eigentlich Aufgaben, die in der Vergangenheit eher Techleads und Architekten in dem Projekt gemacht haben.
Also ich glaube, da braucht man sehr viel technisches Wissen und Erfahrung.
Und ich glaube, viel Engineering-Arbeit wird da reingesteckt werden, weil man da sehr große Skalierungseffekte rausholen kann.
Und auch dieses Human-Immer-Loop ist meiner Meinung nach immer noch sehr wichtig und wird auch noch sehr lange wichtig sein.
Also dass man technische Experten hat, technische Expertinnen hat, die auf den Code draufschauen und auf die Änderungen draufschauen und halt bewerten können, welche Probleme eingeführt wurden und auch wie man die in Zukunft verhindern kann.
Und weil du das angesprochen hast, dass man vielleicht weniger Entwicklerinnen und Entwickler braucht oder dass man die komplett ersetzen kann.
Ich glaube, komplett ersetzen, da glaube ich nicht dran.
Vielleicht könnten die Teams kleiner sein in manchen Situationen, aber ich glaube, da ist es zum Teil auch ein bisschen overhyped oder auch Synth-Effekte werden dann viel interpretiert, dass das dann mit AI zusammenhängt.
Also ich glaube, erstmal haben wir da jede Menge technische Herausforderungen, die auf uns zukommen, die auch relativ neu sind.
Darf ich noch eine Frage stellen, so ein bisschen semi-persönlich sozusagen.
Also ich habe einen Hintergrund und ich kenne halt C, C++, Java.
Ich kenne halt nicht ernsthaft JavaScript oder TypeScript.
Und mich würde interessieren, in Bezug auf die technischen Skills, die man halt benötigt, würdet ihr mir empfehlen, ein Projekt zu machen mit, also ohne zusätzliche TypeScript-Kompetenz, wo ich halt agentic engineering mache mit TypeScript.
Also weil das ist ja eine C-ähnliche Sprache, das heißt, es wirft mich jetzt nicht um, wenn ich geschwäufte Klammern sehe.
Aber ich habe halt keine Ahnung von den Libraries, die ich typischerweise habe.
Ich habe halt nicht wirklich Ahnung von TypeScript und deswegen interessiert mich halt, ob dieses Skillset halt noch relevant ist aus eurer Sicht.
Also grundsätzlich wirst du in allen Programmiersprachen irgendwie klarkommen.
Also aktuell zum Beispiel bin ich jetzt in einem Projekt, wo viele Hardware-Entwickler da sind.
Also die müssen dann mit VHDL und so weiter klarkommen.
Und man muss das in der Hardware-Beschreibungssprache nicht kurz…
Er hat letztendlich in, ich glaube, sogar Schreibkreise umgearbeitet.
Richtig, richtig, richtig.
Grundsätzlich muss man das so sehen, also AI ist halt ein Multiplikator.
Das heißt, Agents werden in guten Prozessen und einer guten Codebase, werden die immer besser klarkommen als in schlechten Prozessen und einer schlechten Codebase.
Also was schlecht ist, wird verschlechtert, was gut ist, wird besser.
In deiner Expertise, wenn du jetzt irgendwie Java C++ kennst, das sind wunderbare Sprachen für Agenten.
Die sind typisiert, die werden da klarkommen.
Es kommt auch natürlich ein bisschen auf die Model-Capability an.
Also Frontier-Modelle werden da sehr viel besser funktionieren als zum Beispiel lokale Modelle.
Und dann geht es halt darum, diesen ganzen Harness drumherum aufzubauen.
Das heißt, in dem Moment, wo du dann merken wirst, dass gewisse Workflows oder gewisse Aktionen von dem Agent in die falsche Bahn driften, das ist dann quasi ein Signal für dich, wo du jetzt dein Harness verbesserst.
Also ob du jetzt irgendwie deine Agents-MD-File aktualisierst, ob du da vielleicht Tests oder deterministische Tools drumherum baust, um den Agenten richtig zu lenken.
Das ist quasi jetzt so das Engineering, was entsteht.
Und ich glaube, es ist immer noch sehr, sehr relevant, die ganzen Prinzipien, die wir in den letzten Jahren gelernt haben, weiterhin anzuwenden, gerade weil Agents in so guten, sauberen Umgebungen viel besser arbeiten.
Und ich würde noch ergänzen.
Ich glaube, du wirst sehr schnell etwas bauen können in TypeScript.
Und ich glaube, du hast auch das Hintergrundwissen, um alles andere schnell zu lernen.
Aber ich glaube, überall nach dem ersten Prototypen musst du immer noch lernen, weniger über die Sprache fährst du selbst, sondern mehr, in welcher Umgebung du laufst.
Ist das jetzt ein Node.js-Server?
Ja, Node.js ist Single-Threaded.
Welche Implikationen hat das auf mein Programm und wie ich mein Programm starte?
Oder ist es ein Frontend?
Welche Besonderheiten gibt es im Frontend?
Aber das kann man dann halt sehr gut auch mit dem Agenten aus einer C- oder Java-entwickelten Brille lernen, weil man dem Agenten sagen kann, hier, ich habe eher Java- und C-Erfahrung, erklären wir das mal aus der Brille oder mit dieser Zielgruppe im Hintergedächtnis.
Und ich glaube, dann kann man auch seine Lernerfahrung auch stark beschleunigen.
Genau.
Also nur auch mal als kleines Beispiel.
Ich bin kein DevOps-Entwickler.
Ich habe nur sehr high-level knowledge in dem Bereich.
Und in dem Projekt, wo wir zum Beispiel gearbeitet haben, da habe ich auch Terraform-Code und so weiter geschrieben mit einem Agenten.
Das wurde dann von einem DevOps-Kollegen gereviewt.
Aber ich konnte mich auf dieser hohen Ebene immer noch bewegen, sodass ich halt verstehe, wie Systeme und Komponenten miteinander interagieren.
Ich kenne die Details nicht, aber ich kann das in der natürlichen Sprache dem Agenten vermitteln und mir das auch noch mal erklären lassen.
Also das darf man auch nicht unterschätzen.
Man kann sehr, sehr viel lernen auch mit den Agenten.
Genau.
Wir sind so ein bisschen am Ende der Zeit angekommen.
Ich weiß nicht, ob es noch Themen gibt, die ihr jetzt den Zuschauerinnen und Zuhörern mitgeben wollt oder ob es noch andere Themen gibt, die wir ansprechen wollen.
Also was ich den Leuten immer gerne sage, ist probiert die Tools einfach mal aus.
Also wir haben auch von null angefangen und es dauert wirklich seine Zeit, wie mit fast allem, was man so lernt.
Also setzt euch da wirklich mal so einen Monat wirklich intensiv damit auseinander.
Lernt die Tools, wie sie funktionieren.
Was ich auch immer so als Anekdote mitgebe, das habe ich von der AI-Engineer-Konferenz im Oktober 25 gelernt.
Don’t outsource thinking.
Ich liebe das einfach.
Also sobald man in diesem Territorium ist, wo man das Denken der AI überlässt, ist man schon wahrscheinlich auf einer falschen Fahrt.
Also wir sind da immer noch die Experten.
Wir sind die Treiber.
Und man sollte das einfach als yet another Tool sehen im Werkzeugkasten.
Und es ist ein sehr mächtiges Tool.
Wenn man es wirklich versteht und weiß, wie man es einsetzt, kann man damit sehr, sehr viel erreichen, finde ich.
Und ich würde das mit dem Denken unterstreichen.
Es war noch nie so leicht, irgendwas Neues zu lernen.
Also wenn man mit den Agenten einfach erstmal einen Kickstart bekommt in jede Technologie, die man sich vorstellen kann und halt plötzlich dieses Etwas neben sich hat, den man einfach Fragen stellen kann.
Welche Frage man auch möchte.
Und wenn man die Antwort nicht versteht, kann man die Antwort sich nochmal runterbrechen lassen und in einfacher Sprache das formulieren lassen.
Also man kann sich das in einer einfachen Sprache formulieren lassen.
Und das ist einfach extrem mächtig.
Also damit, als ich studiert habe, hätte ich mir das gewünscht, dass mir manche Papers in einfacher Sprache erklärt werden, weil ich da schon manchmal Probleme mit den mathematischen Notationen hatte.
Aber das hat jetzt einfach jeder.
Und ich rate nur dazu, das auch einzusetzen.
Was ich übrigens auch deswegen spannend finde, weil ja im Moment die Diskussion halt ist, was halt mit den Juniors ist und was du halt im Prinzip sagst, ist, dass die, also nicht unbestrittenermaßen, haben die es sicherlich schwer auf dem Arbeitsmarkt, aber es gibt halt eine Chance, für die leichter zu lernen.
Keine Ahnung, ob das sozusagen Trost ist.
Gut, mehr noch?
Sonst würde ich sagen, vielen Dank, dass ihr da wart.
Vielen Dank für die vielen Einsichten.
Und sorry dafür, dass ich nicht alle Fragen aus dem Chat sozusagen beantworten konnte.
Aber das waren eben diesmal tatsächlich extrem viele.
Nächste Episode ist am Freitag mit mir und dem Ingo Eichhorst.
Da geht es um die Frage mit der Produktivität.
Und da gucken wir uns tatsächlich dann so richtig wissenschaftliche Paper an, die das nochmal im Detail alles diskutieren und schauen mal, was wir da über dieses Thema lernen.
Vielen Dank und bis Freitag vielleicht.
Bis dahin.
Bis dann, danke.
Vielen Dank.
Hier ein Hinweis in eigener Sache.
Softwarearchitektur im Stream ist live vor Ort.
Mehr Infos dazu und einen speziellen Rabattcode für unsere Community findest du auf unserer Website software-architektur.tv Sei dabei, stell Fragen und komm auch gern auf uns zu.