Stefan: 0:09

Hallo und herzlich willkommen zu Coffee Code & Consult. Heute mit einer etwas kontroversen Hypothese, KI kann zur Softwareentwicklung nicht sinnvoll in Legacy-Projekten angesetzt werden. Zumindest war das bis jetzt mein Verständnis davon. Jetzt haben wir natürlich letzte Woche, letzte Woche sage ich, letzten Monat, eine neue Folge aufgenommen zum Thema MCP hier. Benjamin und ich, wir sitzen hier gerade wieder zusammen und haben danach diskutiert darüber, Aber wie geht es denn mit der KI in der Softwareentwicklung überhaupt so weiter und sind genau über diese These gestolpert und über mein Verständnis dazu. Und das Ergebnis war, dass ich noch sehr viel zum Thema Prompting und KI zu lernen habe. Und deswegen sitzen wir hier wieder. Mein Name ist Stefan Groß, angehend das Softwarearchitekt und Benjamin Tenkel hier neben mir, Senior Softwarearchitekt. Wir beide bei Coventro und unterhalten uns wieder über ein KI-Thema. Heute über das Thema Context Engineering. Und da erstmal die Frage, Benjamin, wie kommen wir denn jetzt zu Context Engineering, wenn wir eigentlich darüber diskutiert hatten, Verwendbarkeit von der KI in Greenfield oder Legacy-Projekten?

Benjamin: 1:16

Ja, das war eine spannende Frage, die du letztes Mal aufgeworfen hast. Da kam mir direkt so der Begriff des Vibe-Codings in den Sinn. Die Quelle allen Übels für mich so als echter Ingenieur oder Architekt, weil dieses Vibe-Coding, Erstmal egal, ob es gut oder schlecht ist. Es ist ein Trendbegriff. Viele verstehen was drunter. Ich glaube, da gibt es auch keine klare Definition. Aber für mich sage ich immer, es ist eine neue Art der Softwareentwicklung, wo versucht wird, mit einfacher Sprache zu sagen, was man gerne möchte. Und die KI zieht los. Meistens ja Agentik-AIs, die das dann machen und versuchen, dir deinen Wunsch zu erfüllen und dir zum Beispiel deine 1-Million-Dollar-App zu bauen, was natürlich immer hervorragend funktioniert, wenn man nur zwei Sätze reinwirft.

Stefan: 2:02

Ich meine, die Gründe ist cool. Ich sage der KI was, das kommt irgendwas Cooles raus, das kann ich verkaufen und fertig. Warum brauche ich noch Softwareentwickler?

Benjamin: 2:08

Ja, genau. Da kommt auch immer schnell das Dopamin, weil man sieht direkt Ergebnisse. Das ist ein bisschen wie so Doomscrolling. Man macht, man sieht andauernd irgendwie, er macht was, er tut was. Es kommt ja auch was dabei raus. Am Ende hat man meistens eine App oder eine Oberfläche oder irgendeine Anwendung, die auch schon was macht. Allerdings würde ich sagen, ist natürlich der Reifegrad nicht unbedingt der, der zum Beispiel zu einem Enterprise-Umfeld passt. heißt, das ist auch meistens nicht genau die Anforderung, die man hatte, aber vorher auch. Man hat ihm auch in der Regel so nicht alle Anforderungen mitgegeben, sondern meistens nur ein Ziel gegeben, bauen wir mal eine App. Und währenddessen hat man versucht, immer so beim White Coding sehr typisch, dass man der Knie dann dieses initiale Ziel gibt. Dann gibt es ein Zwischenergebnis und dann sagt man, hätte man gerne den Button so, man hätte gerne aber noch das Feature, dann dies drin. Und das ist dann eher wieder so eine Konversation, die man mit dem Agent führt, mit dem Coding Agent und der das dann für einen macht. Und ich glaube, weil viele das so verwenden, gab es dann jetzt auch eine Studie von Stanford, vom Yegor Denisov Blanche. Ich hoffe, ich habe den Ratennamen richtig ausgesprochen. Der Werteherr hat eine Studie gemacht, weil er gesagt hat, hey, wissen wir denn überhaupt, seitdem jetzt seit eineinhalb Jahren KI groß in den Unternehmen, zumindest in den großen Enterprise-Umfeldern, gerade in der Tech-Branche stark eingeführt wurde? Weil alle sprechen ja davon, dass man da riesen Effizienzgewinne hat und man kann ja auch Leute lassen, man braucht weniger Leute oder kann mit weniger Leuten mehr schaffen. Und seine Ergebnisse waren relativ ernüchternd. Er hat dann auch gesagt, naja, in so einem Greenfield-Umfeld funktioniert das gut. Es funktioniert gut, wenn man das bei Startups nutzt, wo man natürlich nicht so diese Komplexität hat. Im Brownfield und in Enterprise-Umfeldern hingegen eher schlecht. Also da hatte, es war ja eine Umfrage, da haben eher alle eingeschätzt, es funktioniert nicht gut. Die sagen auch viel über so ein anderes Ergebnis, die gesagt haben, naja, 40 Prozent mehr. Wenn man aber dann nochmal ein bisschen tiefer reinschaut, merkt, ja okay, von diesen 40 Prozent mehr Code, die sie ausliefern, sind 20 Prozent fixes für den Slop, der beim letzten Mal generiert wurde. Also von diesem AI-Slop.

Stefan: 4:07

Der dann mitkommt. Wie viel gebracht.

Benjamin: 4:08

Genau, das heißt, die produzieren 40 Prozent mehr Code, aber davon 20 Prozent mindestens, dass sie diesen Code immer wieder versuchen zu fixen. Die von der AI kommen, merken, dass er nicht ganz so funktioniert oder zu dem passt das, was sie gerne hätten.

Stefan: 4:18

Genau, das heißt, die Wahrnehmung der Menschen ist erstmal so, eigentlich, hey, bringt was, mehr Code, aber wenn man dann auf die Qualität guckt und wobei der Code eigentlich gesteckt wird, dann fällt auf, der Gewinn ist eigentlich gar nicht so groß.

Benjamin: 4:31

Genau. Und es ist auch, glaube ich, auch dieser menschlich, es ist irgendwo menschlich, da gibt es einen sehr guten Artikel, kann ich empfehlen, können wir auch in die Shownotes dranhängen, von Rich Hague's Principles. Der redet viel, das war auch schon vor AI so, über simple und easy, also über, ich will jetzt auf Deutsch auch simple und vielleicht bequem oder leicht übersetzen. Und Menschen tendieren dazu, also nicht dieses Simple zu machen. Also genau irgendwas zu bauen ist eine Verantwortung, genau für eine Problemstellung die die optimale Lösung ist. Sondern eher den einfachen Ansatz, den naheliegenden. Und das ist halt meistens einfach mit der AI zu chatten, weil das einfach easy ist, einfach mal zu sagen, mach mal. Und auch nicht so viel Gedanken in sich zu machen, auch nicht so deep thinking zu machen, sondern einfach zu sagen, ich werfe einen Satz drüber und dann mach mal. Und das ist halt so ein Fallstreck, wo halt viele reinfallen. Und das Problem ist.

Stefan: 5:16

Warum das auch nicht so gut funktioniert,

Benjamin: 5:19

Ist das Grundproblem bei diesen Large Language Models, um da vielleicht nochmal hinzukommen. Ich habe da die perfekte Analogie gesehen, auch für diese ganzen AJ Gente Guy. Ich weiß nicht, ob du diesen Memento-Film kennst.

Stefan: 5:30

Tatsächlich kenne ich ihn nicht, aber du hattest schon angeteasert, dass das eine gute Etapher ist.

Benjamin: 5:34

Das ist die beste Analogie, genau, weil da geht es um einen Kerl, der wacht halt auf, der hat so Tattoos im ganzen Körper und dann weiß er nicht, also er hat kein Gedächtnis, der weiß nicht, was passiert ist. Und er versucht dann die Tattoos, die so beim Körper sind, rauszufinden, was eigentlich er ist, was seine Aufgabe ist, was passiert ist, was er jetzt machen soll. Und das passiert im ganzen Film halt immer wieder und dann macht er sich neue Tattoos.

Stefan: 5:54

Und im Endeffekt wie so ein Agent, dem man halt immer wieder ein paar Informationen mitgibt, aber eigentlich ist er dumm und weiß nur, okay, was du ihm an Informationen mitgegeben hast. Genau.

Benjamin: 6:02

Und in der Analogie ist, das Model, der Kerl, weil das Model, das ist ja erst mal stateless. Es hat kein Gedächtnis, es weiß von nichts, es hängt davon ab, immer was er so als Input bekommt, um seinen Output zu produzieren. Der Input wird maßgeblich von den Agents bestimmt, weil die machen ja diesen Kontextaufbau. Also die haben das Gedächtnis, die überlegen sich, was geben sie dem Large Language Model mit. Also auch vielleicht die Chat-Historie, Input-Sachen vom File-System, Tool-Integration. Und dann hilft es sozusagen, das sind dann die Tattoos, die dann dem LMM zu helfen, sich zu erinnern. Ah ja, stimmt, darüber haben wir gesprochen. Okay, dann das ist das nächste Ergebnis. Das ist das eine. Das andere ist, was ein viel Problem ist, wenn man viel hin und her chattet und so einen langen Kontext sich aufbaut. Anthropic, das sind ja die Macher von Claude, einer der größten Player, die nennt es Context Rod. Dexter, wie heißt der, liebe Kollege, ich hatte mir das aufgeschrieben, der Dexter Hoffi.

Stefan: 6:59

Der Dumb-Zone gephrased, also ich finde den Begriff viel geiler,

Benjamin: 7:02

Die Dumb-Zone, der hat gesagt, ich glaube, ich habe das schon mal irgendwo erklärt, dass wenn der Kontextfenster wächst, ist immer mehr Information drin. Und das ist ganz normal bei, wie diese Modelle, die basieren ja auf so einer Transformationsarchitektur, da kann man sich ruhig mal einlesen, ich würde da jetzt nicht tiefer reingehen, aber die bedingt es dadurch, wie diese Architektur ist, dass diese Information, wenn zu viel drin ist, dann weiß auch die AI nicht so richtig, okay, welche Informationen sind relevant, welche weniger und es wird so ein bisschen defokussiert, kann man so sagen, und dann kommen nicht so gute Ergebnisse raus. Das heißt, man muss ein bisschen aufpassen, dass man nicht in diese Dump Zone einfach reinrutscht, weil zu viele Informationen vorliegen für das Large Language Model.

Stefan: 7:41

Ich habe das auch rein intuitiv. Je mehr Informationen in meiner KI gibt, desto mehr Kontext hat sie ja theoretisch und desto mehr müsste ja eigentlich auch die Lösung besser werden.

Benjamin: 7:52

Genau, aber das ist, wie gesagt, was ich meine, diese Transformer Architecture. Das liegt ja daran, dass jeder Token, den du drin hast, kann jedem anderen Token im Modell in Verbindung gebracht werden. Und umso mehr Tokens du drin hast, wie gesagt, dann diffusioniert es ein bisschen, was willst du jetzt eigentlich so als Ziel raushaben?

Stefan: 8:06

Das andere ist, naja, das ist so wie beim Menschen. Also diese Modelfunktionen relativ ähnlich zum Menschen.

Benjamin: 8:12

Das, was du am Anfang sagst, das kann er sich besser merken, ein höheres Gewicht, das, was du am Ende sagst, dann wird es so wie beim Menschen. Du wirst das Erste und das Letzte in seinem Gespräch wahrscheinlich besser Erinnerungen haben wie alles dazwischen.

Stefan: 8:21

100 Prozent.

Benjamin: 8:22

Und umso mehr das dazwischen ist, umso schwieriger ist. Und das kann man sich wirklich eher so auch an Menschen halten. Also wenn du Menschen zu viele Informationen gibst, dann weißt du jetzt auch nicht, was war denn das Entscheidende in dem, was du mir gesagt hast. Und ähnlich verhält es sich bei Large Ranges, ohne jetzt zu tief in die Materie zu gehen, warum Models dieses Problem haben, weil ich glaube, das würde einen Rahmen sprengen.

Stefan: 8:40

Das ist wie, wenn mich jemand anschreit und mir ganz viele Informationen dabei gibt und ich sitze nur so da, oh mein Gott, was mache ich denn damit überhaupt, weil ich mein Ziel noch gar nicht kenne, weil ich kriege erstmal die ganzen Informationen und dann muss ich irgendwas daraus wissen und lösen und keine Ahnung und solange das nicht eine fokussierte Art von Information ist, die genau für das Problem halt auch wichtig ist, platzen die irgendwann in den Kopf.

Benjamin: 9:00

Genau, und defokussiert auch, dann bist du völlig am falschen Thema. Das dritte ist so, das ist das Interessanteste, finde ich, Das nennen sie im Englischen immer Trajectory. Ich würde es im Deutschen mit Gesprächsverlauf übersetzen. Also das ist typischerweise auch bei diesem Vibe-Coding, der naive Ansatz, das gehe ja hin, ich sage, hey, mach das mal. Und dann macht die KI was, dann bin ich ja nicht ganz happy. Und sagt der KI, ja, nee, nee, warte mal nicht so. Dann mach es lieber so und so. Das heißt, dann geht die KI hin, macht wieder was. Dann sage ich, ja, nee, stimmt nicht. Mein lieber so und so. Die KI wieder was. Und weil die KI ja so über den Gesprächsverlauf lernt, festigt sich auch irgendwann mal der KI so ein bisschen, na ja, er hat was gesagt, er hat was gemacht, es war falsch, Er hat was gesagt, ich habe was gemacht, das ist falsch. Er hat was gesagt, ich habe was gemacht, das ist falsch. Okay, das heißt, das Nächste, was er sagt, dann muss ich irgendwas machen und das ist wieder Falsches. Das ist ja die logische Schlussfolgerung, die irgendwann herauskommt. Plus, über die Historie bauen sich ja viele unnötige Informationen im Kontext auf, die einfach nur Klarifizierung waren von der eigentlichen Problemstellung und dich dazu hingeführt haben, was du eigentlich machen möchtest, aber dann am Ende gar nicht mehr so relevant sind. Und wie gesagt, das lenkt alles ab.

Stefan: 10:00

Das heißt, ich will auch nicht, dass mein Agent oder mein LLM irgendwas Falsches lernt, Und mir dann plötzlich Informationen gibt, die ich eigentlich

Benjamin: 10:07

Gar nicht erwarte. Genau. Oder auch halluziniert oder man auch nicht versteht, warum er jetzt plötzlich diese Antworten gibt. Genau. Er hat halt nur eine begrenzte Aufmerksamkeitsspanne. Kann man so sagen, wenn es jetzt mit menschlichen Wörtern übersetzen müsste.

Stefan: 10:21

Das heißt, Kontext ist key.

Benjamin: 10:22

Kontext ist key. Und genau da kommt, dass sich auch die ganzen Software-Engineers der Welt, oder es hat sich so eine Gruppe gebildet, die gesagt haben, Vibe-Coding, das ist es nicht. Das funktioniert auch nicht so gut und da fehlt uns dieser Engineering-Ansatz. Und die haben gesagt, ja, es geht ja um den Kontext. Und da ist dieser Begriff Kontext Engineering entstanden. Es kommt ursprünglich aus diesem Manifest 12-Factor-Agents vom Dexter, den ich vorhin erwähnt habe. Können wir auch in den Show Notes reinpacken. Das ist ein super GitHub-Repo. Das ist nochmal runtergebrochen. Daraus ist ein bisschen dieses ganze Kontext Engineering entstanden. Also er hat diesen Begriff mitgeprägt. Wird zumindest vom Internet behauptet. Oder er sagt auch selber, dass die meisten sagen, ihr hättet es mitgeprägt. Kann vielleicht sein, dass jemand vorgeprägt hatte.

Stefan: 11:06

Aber das ist Context Engineering.

Benjamin: 11:08

Das ist die Disziplin, würde ich sagen, um diese gesamte Informationsumgebung, also den Kontext für ein Large Language Model, also LLMM, strategisch zu designen und zu managen. Das Ziel davon ist, dass du einfach eine Zuverlässigkeit bei deinem Agentik-Behaviour bekommst, also wie sich dein Agent verhält und was dein Output ist und es nicht so extrem zufällig und deterministisch ist, wie es beim Vibe-Coling manchmal passiert.

Stefan: 11:31

Das heißt, dass ich mir vorher überlege, welcher Kontext ist hier gerade wichtig, um ein Problem zu lösen. Das heißt, ich stecke erstmal ein bisschen Arbeit überhaupt da rein, mir Gedanken zu machen, was frage ich meinen Agenten, meinen LLM, wie auch immer und nicht einfach nur vor mich hinrede und das Ganze wirkt und das wird dann am Ende so ein Information-Bloat.

Benjamin: 11:52

Genau. Aber es ist nicht nur der Prompt, weil der Prompt es ja meistens nur selber eingibt. Das gehört zum Kontext, aber auch der Memory. Also was behältst du im Gedächtnis in deinem Agent? Was sind die relevanten Informationen, die du für die nächste Anfrage wieder benötigst? Auch dieses RUG, also Retrieval Argumented Generation, das ist ja dafür da, dass man zum Beispiel Unternehmensdateien oder Unternehmensinformationen vorher in diesen Kontext reinbekommt, den er mitschickt zum LMM, die Historie vom Chatverlauf, auch diese Output. Wenn man zum Beispiel einen Coding-Agent hat, dann der baut ja auch dann mal die Anwendung, der teste mal die Anwendung, diese ganze Output, der wandert ja auch alles wieder in den Kontexten. Dann hat man vielleicht eine Agents-MD oder eine Claude-MD, also diese Markdown-Files, wo noch ein bisschen Kontext gegeben wird, wo man sagen, die wandern ja auch alle da rein. Und dann wächst halt schon so ein Kontext ziemlich an. Und viel geht darum, wie optimiere ich das? Und das ist genau dieses Kontext Engineering, wie kriege ich da eine Optimierung hin?

Stefan: 12:50

Das ist so, wie ich es verstanden habe.

Benjamin: 12:51

Man muss auch sagen, ich glaube, so ist es auch wieder, dass der Dexter, der diesen Gebrief als erst geprägt hat, verstanden hat.

Stefan: 12:57

Das ist so, wie wir es jetzt auch verwenden wollen in dieser Folge. So haben wir diesen Begriff verstanden und wollen uns darüber unterhalten.

Benjamin: 13:03

Genau. Ich habe da aber auch einen netten Begriff gefunden, Semantic Diffusion. Das kann man auch für Microservices verwenden und für andere Begriffe oder Agents. Was ist denn ein Agent? Ich habe gehört, Agents sind Microservices, Agents sind Workflows, Agents sind Rollen. Ich habe schon ganz viele Sachen. Agents sind Loops. Was sind Agents eigentlich? Und das Gleiche ist vielleicht auch bei Context Engineering. Kann es irgendwann dazu kommen? Müssen wir mal schauen. Aber es ist einfach eine gewisse Gruppe von Personen hat halt diesen Begriff definiert. Immer mehr nutzen jetzt diesen Begriff in anderen Kontexten, in anderen Gruppen. Die verstehen das dann immer ein bisschen leicht anders da. Und plötzlich hast du so 50 Definitionen.

Stefan: 13:38

So wie bei stille Post. Einer fängt was an, wenn das in Volldefinitionen und dann kommt irgendwas raus und denkst dir, nein, das habe ich niemals gesagt.

Benjamin: 13:44

Genau. Von daher, ob das in zwei Jahren immer noch Context Engineering heißt, Das weiß ich nicht, aber ich glaube auch, wenn man den Begriff googelt und wie wir jetzt hier heute verstehen, finde ich, ist es ein gelungener Begriff. Den wollen wir auch erstmal so verwenden, mal schauen, was da die Zukunft bringt.

Stefan: 13:58

Das heißt, wir haben jetzt einen wohl definierten Griff. Wir haben einen Kontext für eine Anfrage in irgendeiner Form, der nicht einfach nur der Prompt ist, sondern wo noch sehr viel mehr Dinge dranhängen. Den wollen wir optimieren, damit wir möglichst sinnvolle und gute Ergebnisse rausbekommen. Mit dem Ziel, dass wir dann am Ende an einer Stelle sind, wo wir nicht einfach nur in Anführungszeichen Vibe-Coding machen, das hauptsächlich im Greenfield-Ansatz findet, sondern dass wir zusätzlich dann an einen Punkt kommen, in dem wir KI auch in Legacy oder Brownfield oder wie auch immer man es betiteln möchte, Projekten mit anwenden können und auch eine Mehrwert daraus generieren können.

Benjamin: 14:39

Genau. Und die Leute müssen auch verstehen, so einen Kontext, die werden immer größer, die Anbieter gestalten auch immer größer. Aber der Grenznutzen-Grenzertag nimmt einfach ab, umso mehr man da reinsteckt. Das merken die halt auch. Das liegt einfach an der Architektur von diesen Modellen. Ich glaube, Cloud Code hat momentan so ein 200k Limit, vielleicht ist es auch mittlerweile mehr, das letzte Mal, wo ich geschaut habe. Und so die Faustregel, die ich von vielen Leuten gehört habe, was so momentan im Raum schwebt, so in der Branche, ist, dass man sagt, so 40%. Solltest du maximal von deinem Kontextbinder verbrauchen. Das heißt, dahin optimierst du, das kann auch mal 50, 30, das muss man ein bisschen austesten, das ist keine exakte Wissenschaft, das ist eher so Erfahrungsberichte.

Stefan: 15:16

Aber nicht auf Kante nähen, also nicht einfach an die 99 Prozent rangehen und so viel wie möglich, sondern den Kontext so klein wie möglich eigentlich halten.

Benjamin: 15:24

Auf keinen Fall, vor allen Dingen für komplexe Problemstellungen, muss man dann überlegen, weil das ist halt dann auch die Frage, die mir auch schon viele Leute gestellt haben, ist ja, wie viel Kontextengineering brauche ich denn? Wie viel muss ich mich denn damit wirklich beschäftigen, diesen Kontext zu gestalten? Das würde ich immer den Leuten empfehlen. Das hängt von der Problemstellung ab. Wie komplex ist die Codepace? Wie komplex ist das Problem, mit dem ich unterwegs bin? Bei einfachen Problemstellungen, klar, muss ich jetzt nicht zehn Stunden oder Tage oder Wochen investieren in Context Engineering, die sind richtig gut aufzubauen. Reicht auch vielleicht weniger oder deutlich weniger, aber das muss man dann einfach selber so einchecksen. Aber um je höher die Komplexität ist, umso mehr Zeit sollte man sich mit diesem Thema aufbringen und auch investieren.

Stefan: 16:02

Neben der Komplexität wahrscheinlich andere Faktoren. wie viel Zeit habe ich überhaupt, wie sicherheitskritisch sind die ganzen Sachen und so weiter. Je nachdem müssen wir mehr Context Engineering betreiben oder mehr Zeit für Context Engineering nehmen, um auch mit dem Ergebnis zu haben, was adäquat für die Taktivität ist.

Benjamin: 16:18

Würde ich so unterschreiben, Greenfield, Startup, Innovation Labs, braucht man jetzt nicht so viel Zeit unbedingt reinstecken. Aber wenn man im Enterprise, Brownfield, große Codebases, Legacy-Codebases, empfehle ich eher viel Zeit in Context Engineering zu stecken.

Stefan: 16:32

Was macht man da? Also worum geht es da?

Benjamin: 16:34

The name of the game oder in Deutschland Bespielregeln ist da, gibt es zwei wesentliche Sachen. Das eine ist Compaction. Das ist eines der wichtigsten. Da geht es einfach um Verdichtung von Informationen. Es gibt regelmäßig diesen Kontext zu resetten und zu überlegen, was in diesem Kontext. Klar, die Leute, die Claude kennen, es gibt Slash Clear. Das ist der naivste Ansatz, also einfach mal zu sagen, ja, ganz ehrlich, wenn man dann irgendwo mit einem Coding-Agent Sachen macht, muss man irgendwann sagen, irgendwann ist Spätestens der Agent, sagt, this is a good idea. Und dann fängt sowas in die Richtung, dann sollte man überlegen, ob man den Kontext resettet.

Stefan: 17:05

Und sie ist mal aus und mit der Hand geschaltet. Das ist typisch IT-Lösungs- Ja,

Benjamin: 17:08

Genau. Vielleicht genau so. Es gibt auch Slash-Compact in Claude. Da habe ich von vielen gehört. Es gibt ja viele Leute, die das Internet stark im Bein haben. Sie sagen, das wäre Trash. Ich würde sagen, vielleicht ist es nicht der eleganteste Approach, weil Claude muss natürlich Slash-Compact so bauen, dass es generisch für alle Problemfälle, für alle Kontexte, alle Domänen funktioniert. Wenn man ein Unternehmen ist, muss man, glaube ich, selber sich eine Compaction-Strategie bauen, wenn man selber Agents kreiert, muss man überlegen, wie man diese ganzen Informationen verdichtet, auch was sind wirklich relevanten Informationen, die halt in so einem Kontext sollten und viel über Compaction arbeiten.

Stefan: 17:41

Zum Beispiel dann über eine Domain-Language in irgendeiner Form, wenn man eben mit Domain-Driven Development unterwegs ist, dass man sich dann darauf fokussiert und sagt, hey, das ist meine Domäne und alles aus meinem Kontext, was irgendwie daran war, behalte ich nirgendwo Dinge nicht.

Benjamin: 17:54

Genau, aber vielleicht nur die, die gerade für die Aufgabe, die man vor sich hat halt Relevanz und die anderen Sachen lässt man halt raus.

Stefan: 18:00

Das andere ist Subagents,

Benjamin: 18:03

Also normaler Code, also es ist ein Coding-Agent. Mit dem kann man auch Subagents spawnen. Und viele benutzen das, dass der Hauptagent dann seine Subagent hat und die machen da so Rollenspiele. Und das finde ich ein bisschen fremdlich. Da habe ich schon viele Blogartikel gelesen, die sagen, ja, dann habe ich einen Subagent, der ist ein Entwickler und der ist dann ein Tester und das ist mein Scrum Master und das ist mein Product Owner. Und nein, das Einzige, würde ich sagen würde, für was Subagents da sind, wenn man sich das selber merken will, ist für Kontextkontrolle, weil du mit den Subagents noch einfach nochmal Aufgaben auslagern kannst und sagen kannst, hey, ich brauche ein Research, ich muss verstehen, wo was ist, ich muss einen Teil von der Codebase verstehen, wie der funktioniert, ich lagere das aus, schicke das an den Subagent, diesen Auftrag, gebe ihm den Kontext mit, den er braucht und das wirklich Wichtige, wenn man sich überlegen muss, vom Subagent zurück zum eigentlichen Agent, Also von dem Original-Kontext-Window zum Sub-Kontext-Window. Wie ist der Informationsrückfluss und wie ist das strukturiert und was sollte da wirklich drin sein? Da muss man viel Zeit und Energie reinstecken, das gut zu designen, weil man ja nur die relevanten Informationen vom Sub-Agent dann zurückhaben möchte.

Stefan: 19:12

Obahi, wenn man jetzt ein bisschen über die Softwareentwicklung selber rausschaut, klingt so ein Rollenspiel für mich jetzt erstmal nicht ganz falsch, wenn du dort halt einen Project Manager hast, einen Softwareentwickler und vielleicht einen UX-Designer als Sub-Agents, um dann darüber eine sinnvolle Gesamtentscheidung treffen zu können mit, wie kann ich die Deadlines einhalten bei der und der Softwarelösung mit dem und dem Design, was ich anwenden soll.

Benjamin: 19:38

Ja, aber ich glaube, das löst, das führt Leute in die falschen Gedankenmuster, weil dann werden das wirklich nur über Kontextkontrolle, weil du wirst nicht ein Softwareentwicklungsteam mit Agents ersetzen können. Nicht jetzt in den nächsten ein, zwei Jahren, aber so klingt das schon, dass du dann sagst, hast du deinen Entwickler, hast du deinen Tester und so. Es ist okay, weil es verschiedene Aufgaben sind und dann auch vom Testen, was soll vom Test zurückkommen. Von daher kann man das schon sagen. Ich finde das immer nur irgendwie ein bisschen befremdlich, dass wir den Rollen geben.

Stefan: 20:05

Ich hätte es auch eher als eben Input für eine Entscheidung genommen, aber jetzt nicht gesagt, damit kannst du eine komplette Software-Bildungsteam ersetzen. Was ich den Leuten sagen will,

Benjamin: 20:13

Wenn ihr das lest und die euch verkaufen wollen, dass Agent irgendwelche Rollen sind, dann es geht mehr um Kontext Engineering, es geht mehr um Kontext Control und denkt mehr daran, Kontext Kontrolle, als ob jetzt auf diese Rollensicht zu fokussieren. Vielleicht hilft es ja auch manchen in den Rollen zu denken, das will ich ja nicht kaputtreden. Naja gut, für was optimiere ich denn das Ganze? Also dieses Context Engineering, ich will Korrektheit, Vollständigkeit, Größe und die Trajektorie, also den Gesprächsverlauf. Wenn ich das invertiere und das als Probleme darstellen möchte, was ist das Schlimmste, was man im Kontext haben kann? Falsche Informationen.

Stefan: 20:47

Ist ja auch ein Sicherheitsrisiko, Context-Proofing.

Benjamin: 20:50

Genau, also je nachdem genau, was man da reinsteckt. Das Zweite sind fehlende Informationen, einfach Sachen fehlen, die ich benötigt hätte, um was zu bauen. Da kommt das Halluzinieren her, weil wenn er die Informationen hat, dann denkt er sich halt was dazu, was er denkt, was sinnvoll ist und halt zu viel rauschen, too much noise. Also wenn der Kontext bloated ist und viel zu viele Informationen drin sind.

Stefan: 21:10

Also im Endeffekt, wie man auch für eine Menschen umgehen würde, wenn wir ganz ehrlich sind, weil wenn ich als Menschen ein Problem lösen will, dann bringt mir das auch nichts, wenn ich die falschen Informationen habe. Ich kann nicht die richtigen Entscheidungen treffen, wenn mir Informationen fehlen und wenn ich zu viel habe, dann wird das wahrscheinlich nicht sehr viel länger brauchen, diese Lösung zu finden.

Benjamin: 21:26

Genau. Und wenn man diese Also da gibt es auch so ein Verfahren, was sich so etabliert hat. Na gut, wie machst du es jetzt konkret? Also weil ja, okay, Compaction verstanden, Subagents verstanden. Es gibt aber ein gutes Vorgehen, dass man diesen Problem wegkommt, diesen Magic Button beim Agent immer wieder zu drücken, indem man wieder ein paar Textschnitzel hinzuwirft. Das nennt sich RPI-Loop, also Research, Planning, Implement. Da gibt es auch schon verschiedene Ansätze, es wurde auch immer leicht genannt. Ich kenne es jetzt unter dem Begriff, vielleicht gibt es Artverbande, wenn ich es erkläre, wäre es glaube ich klar, was ähnlich ist oder wenn man schon was anderes gehört hat. Das erste ist Research. Darum geht es primär um Verdichtung von Informationen. Weil erstmal hat sich herausgestellt, was ganz gut ist, erstmal wenn man eine Code-Basis hat, wenn man Repository hat, wenn man Teams hat, dass man erstmal den Agent loslaufen lässt und einfach mal so die Wahrheit feststellen. Also was ist gerade, wie sieht der Code aus, wie ist der Codeflow?

Stefan: 22:22

Wie ist das System aufgebaut? Und da geht es immer einfach so darum, diese Wahrheit, diesem Code-Leak zu verdichten,

Benjamin: 22:29

Informationen, die ich in den Kontext geben kann.

Stefan: 22:32

Das tue ich an der Stelle aber dann selbst oder ist das auch schon eine Sache, die der Agent für mich übernimmt in irgendeiner Form, dass der Agent quasi selber in Anführungszeichen autark das System versucht zu verstehen?

Benjamin: 22:47

Beides. Also das System objektiv zu verstehen, davon nimmt man meistens den Agent, der geht dann durch, man schaut sich die Sachen an und man gibt ihm den Auftrag, was er sich natürlich raus und was er researchen soll, wie er es verstehen soll, die Codebasis und die legt er natürlich dann in irgendeinem Gedächtnis ab, also Vektordatenwagen, lokale Dateisysteme, Markdown-Files, wo auch immer, speichert diese Informationen ab, wo er an späteren Zeitpunkt, wenn man eine Aufgabe gibt, wieder darauf zugreifen kann, um die Codebasis zu verstehen.

Stefan: 23:13

Man kann das

Benjamin: 23:13

Natürlich mit dem Agent erzeugen, dann legt man das ab. Das Problem ist, wie es halt in Code-Basis so ist, diese Informationen veralten. Jedes Mal ein neues Feature haben, müssen wir das wieder neu generieren und machen. Und sind wir mal ehrlich, man macht es da nicht. Das ist ja wie mit Doku, die dann im Code ist. Größte Gefahr für Doku ist, dass er halt veraltet. Und das wird auch genauso, glaube ich, von diesem Research passieren. Was da machen oder viele Leute machen, ist on the fly Research und Compaction. Das zu sagen, sie gehen hin und machen das jedes Mal on the fly. Ich würde davon ein paar Sachen ausnehmen. Zum Beispiel, viele Sachen können ja aus dem Code inferiert werden und auch denen, was man mitgibt, wie er das machen soll. Aber ein paar Informationen, wenn man gerade auch in die Hierarchie denkt, ganz unten ist ja der Code als Dateien. Das braucht man nicht dokumentieren, da ist der Code die Wahrheit. Aber schon die Ebene drüber, wenn die Ordner, warum gibt es die Ordner? Was behält dieser Ordner für Klassen oder für Code? Oder dann Projekte oder Repositories. Oder Teams oder Org. Da gibt es auf verschiedenen Ebenen ja Informationen. Und da muss man, finde ich, ein paar Sachen halt selber festhalten. Aber das sollten eher beständige Sachen sein, die sich nicht mit jedem Feature ändern und Kundenlegen sagen, okay, die vielleicht doch irgendwo die Architektur beschreiben, wo ich sage, ich habe jetzt eine Clean Code gebaut. In dem Folder liegt eine Markdown, die dann beschreibt, naja, diese Klassen in dem Folder sind mein Repository Layer, der auf die Datenbank zugreift, der Hibernate nutzt, etc. Damit da, wenn die AI da hinkommt und was machen möchte in dem Bereich, diesen Kontext mitbekommt und weiß, okay, dafür ist es da, so funktioniert.

Stefan: 24:44

Und es einordnen kann. Aber exklusiv bei Dingen, die sich nicht so schnell ändern, damit du und ich in die Verlegenheit kommst, dass es veraltet ist und in falschen Informationen entsteht.

Benjamin: 24:51

Genau. Und das hilft auch extrem gegen Halluzinationen, weil das ist der Hauptgrund, wenn man diese Agent anfängt zu halluzionieren, dass der Research nicht gut genug, der kriegt nicht den Kontext, dass er weiß, welche Libraries verwendet werden, welche Patterns verwendet werden, welche Code-Guidelines verwendet werden und dann erfindet er halt seine eigene. Ist ja logisch. Es wäre genau das Gleiche, wenn ich einem Entwickler das geben würde und ich würde ihm das alles nicht erklären und sagen, gut, Genau, mach mal, hier hast du ein neues Feature, baue mal ein, man hat ihm nichts erklärt, dann wird er halt irgendwas hinbauen. Im Merch Request, bei der Review stellt man fest, oh, ja, komplett an der Sache vorbeigegangen, aber wie der hätte das denn wissen sollen? Bei Agents ist es nicht anders, da gibt es keine Magie. Man muss es denen sagen. Man muss eher Strategien für diesen Research-Teil finden, wie man den am besten macht und ad hoc und wie man da vorgeht.

Stefan: 25:35

Und das heißt, dieses On-the-Fly-Research würde dann bedeuten, zum Start meiner Konversation mit dem Agenten würde ich erst mal mit ihm über diesen Research-Teil reden, dann wäre es halt irgendwie in meinem Kontext auf jeden Fall mit drin und könnte danach in die weiteren Phasen des gleichen Kontextes gehen, würde es aber eben nicht irgendwo hinlegen, wegspeichern, sonst was, um eben diese Verhaltung entgegenzunehmen.

Benjamin: 25:59

Genau.

Stefan: 26:00

Wichtig wäre noch, dass es eine Verdichtung von Informationen ist,

Benjamin: 26:02

Muss nicht alles direkt schon im Kontext liegen. Der hat das ja erstmal angelegt und irgendwo abgespeichert. Der muss nur wissen, was wo liegt, wo er wieder reinschauen kann, in welche Töpfe, um mehr Informationen in seinen Kontext zu laden. Also das gesamte Research ist nicht immer direkt im Kontext mit drin. Nur nicht, dass jemand falsch versteht. Und dann kommt das Planning, weil der eine Research, also was ist schon da, in den Status Quo ermitteln ist gut, aber man will ja auch irgendwas verändern. Man muss ja auch aufzeigen beim Planning, was will ich machen, also was ist die Story oder was will ich da implementieren, das muss man ja auch irgendwie reinziehen und wie soll das gebaut werden. Und da habe ich gelernt, es ist ganz wichtig, auch Beispiele zu bringen, auch zu sagen, wie man zum Beispiel den Spring Controller schreibt, wie man Repository Klassen schreibt, wie man bestimmte Petters anwendet, dass man der AI auch Beispiele gibt, wie man das erwartet, dass er das löst. Und da muss man solche Sachen schon zur Verfügung stellen. Und da muss man viel über diesen Plan reden, auch im Team. Wie soll die AI das machen? Weil ich erkläre das immer so Leuten, naja, warum machen wir dieses Planning hauptsächlich und dann überlegen wir, wie wir das tun. Weil bei vielen Leuten ist es halt so, die Agentic AI oder Agentic Code Assistants nutzen. Du kannst irgendwann gar nicht mehr in den ganzen Codesichten damit generiert wird. Und dann ist es viel wichtiger, sozusagen über den Plan zu reden und sich darüber zu einigen, wie die AI Dinge tun sollte, im Vornherein, bevor man dann anfängt, die AI loszurennen. Weil das ist auch eine der wichtigsten Learnings, die ich gehört habe. Eine Zeile schlechter Code ist eine Zeile schlechter Code. Eine Zeile vom schlechten Plan können hunderte oder tausend Zeilen schlechter Code sein, der dann generiert wird. Und wenn ich dann sage, beim Research habe ich schon völlig falsch, bin ich falsch im Repository, bin ich auf der falschen Stelle, dann hat man vielleicht 50.000 Zeilen schlechten Code plötzlich in einem schlechten Research. Das heißt, man muss immer überlegen, wo habe ich den größten Hebel in dieser Arbeitskette und wo sollte ich die maximale Energie und Fokus von meinem Team und von meinen Developern und Engineers reinstecken. Und ich würde sagen, das ist bei diesen Planning-Phases, dass man überlegt, dass der halt gut ist und darüber sollte man diskutieren. Und darüber schafft man auch so ein Alignment im Team. Darüber ist hauptsächlich auch aus meiner Sicht Code-Review. Klar, dass die korrekte Lösungen rauskommen, dass bestimmte Guidelines angehen werden, aber es ist dieses Mental-Alignment, dass wir wissen, wie ändert sich die Code-Basis, was ist das hier gerade bauen, in welche Richtung entwickelt es sich und wo stehen wir. Und wenn der AI so viel Code generiert, dann musst du es mal eher über den Plan machen, dass du über den Plan halt weißt, okay, was verändern wir im System? Welche Richtung wird sich bewegen? Und dass wir da allein sind im Team.

Stefan: 28:34

Und dass man dann eben das Code-Review von dem generierten Code auch in so eine Richtung bringt. Dass man nicht zwangsläufig mal jede einzelne Zeiler-Review macht, sondern dass man relativ gut auf einer höheren Perspektive schon sieht, hat er sich an den Plan gehalten oder nicht? Genau.

Benjamin: 28:49

Und die Frage ist, aber das ist natürlich, man muss jedes Team für sich selbst beantworten, ob man den Coding dann gar nicht mehr reviewt oder welche Teile man vom Code reviewt. Da muss jeder so persönlich seine Erfahrungen machen. Es gibt auch schon Teams draußen, die schauen sich den Code gar nicht mehr zum Teil an, weil die sich sagen, wir fokussieren uns auf den Plan, den wir zusammen definiert haben, der typischerweise Markdown-Files heutzutage halt drinsteht, weil sich Leute wundern, ja, wo schreiben wir diesen Plan hin? Ja, es sind meistens Markdown-Files, sehr nüchtern, aber da steht es meistens einfach in normaler Sprache drin. Genau. Und es ist halt einfach effizienter, über den Plan zu reden, als den gesamten Code zu reviewen.

Stefan: 29:22

Und dann, klar, wenn man einen Plan hat,

Benjamin: 29:24

Dann kommt man erst zu Execution. Dann, wenn man diese ganze Vorarbeit gemacht hat, den Researches, Planning, man hat relativ viele Markte, man hat viele Informationen, die es in den Kontext geben kann, man gibt der AI viel Kontext einfach, dann gibt es auch eine hohe Chance, dass man das Problem one-shotten kann, also dass man einen Versuch hat und löst das Problem. Klar, muss man manchmal vielleicht trotzdem noch ein bisschen nachkorrigieren und dranbleiben bei AI, aber deutlich weniger, als man einfach nur sagt, ja, baue mir eine App oder baue mir dieses Feature XY. Ohne die ganzen Research- und Blending-Teile vor.

Stefan: 29:55

Das klingt für mich aber auch so, als wäre das relativ einfach in eine agile Softwareentwicklung einzubauen, weil es sind genau die gleichen Schritte. Wir haben am Anfang ein Research, ein Requirements Engineering, ein Story schreiben, wie auch immer es in einem Projekt eben ausdefiniert wird. Danach haben wir ein Planning in Form von, wie wollen wir die Story umsetzen, in Form des Refinements, aber auch des Planings globaler, mit wann, in welchem Sprint, welche Story umgesetzt, was auch immer, damit wir am Ende im Richtigen sind und dann implementieren wir das Ganze auch nach diesem Plan, den wir zum Refinement und Planning gelegt haben und führen das Ganze aus. Eins zu eins, die gleichen Schritte, nur dass wir jetzt nicht mehr nur mit Menschen reden, sondern potenziell eben auch mit solchen Erlebnissen.

Benjamin: 30:35

Genau. Aber die Versuchung ist ja groß, bei diesen Coding Agents, ist, dass man in diesen Modus verfällt, ich schreie die KI an und werfe die Informationen so peu a peu immer wieder rüber, lassen wir was machen und korrigieren dann immer wieder. Und deswegen bin ich froh, dass es mittlerweile sich auch diese Disziplin des Context Engineering sich etabliert hat. Deswegen wäre es zu dem Engineering wieder zurückgehen. Und auch bei diesem Planning Phase, da gibt es auch ein Buzzword, was momentan so in der Branche rumschwert ist, ist Speck-Driven Development, dass man sagt, man arbeitet eher mit Specs. Die Frage ist, hier kommt auch wieder dieses Semantic Diffusion zum Einsatz, was ist ein Speck? Da gibt es jetzt mittlerweile auch so große Diskussionen, ist das jetzt einfach nur eine Erweiterung von Anforderungsspezifikationen in einer ein bisschen anderen Form oder in mehr einem Detail? Es ist am Anfang nur eine bessere Prompt, also das andere Gegenteil. Auf der anderen Seite, es ist irgendwas dazwischen, es sind fachliche Anforderungen, es sind technische Leitbilder, es sind Patterns, es sind Erklärungen, wie was getan werden soll. Ich glaube, da tun sich viele schwer, so eine allgemeine Definition zu finden, was das Specs genau in dem Kontext sind.

Stefan: 31:41

Aber die Idee von Werder, man hat in irgendeiner Form einen definierten Speck, mit dem eine KI dann Code generiert.

Benjamin: 31:52

Genau. Also wenn man es überlegt, da gibt es auch einen kurzen Ausbrecher, Sean Groove von Open Air, der hat einen richtig geilen Talk, kann ich empfehlen, gibt es auf YouTube. Der hatte dann diese Hypothese, dass wir dann nur noch über Specs coden. Also du schreibst nur noch Specs und du schreibst gar keinen Code mehr selber, es wird alles nur noch generiert. Weil er sagt halt früher, ganz ehrlich, du hast den Code geschrieben, dann hast du einen Compiler gehabt und dann hast du eine Binary. Du hast dir auch nicht die Binary mit eingecheckt, du hast ja einen Compiler jedes Mal, der das neu erzeugt. Und er hat halt diese Hypothese, dass er sagt, na gut, die nächste Evolution ist einfach, dass du sagst, du hast deine Specs. Irgendwann ist das gut genug. Also ich glaube auch nicht, dass es heute schon da ist. Da würde ich ihm auch widersprechen. Das kann aber schon sein. Ich meine, das ist ein Zukunftsszenario. Ob so kommt, weiß keiner. Es ist ein spannender Denkansatz, weil der sagt halt, okay, aus den Specs generiere ich den Code und den Code brauchst du eigentlich auch nicht einschicken, sondern es ist auch nur so ein Zwischenergebnis, der dann rauskommt, wenn am Ende das Produkt genau das ist, was du willst und deine Requirements erfüllt, dann ist es ja eigentlich egal, wie der Code aussieht.

Stefan: 32:52

Das wäre aber wahrscheinlich eine Diskussion, die wir im anderen Rahmen nochmal führen könnten, weil meiner Meinung nach wird dazu kurz gedacht, weil gerade der Vergleich mit dem Compiler, ein Compiler ist deterministisch, was eine KI rausbringt, nicht. Und gerade über diesen Determinismus finde ich, sind wir noch nicht an einem Punkt, wo wir zumindest für mein Sicherheitsempfinden und so auf eine Peri verlassen können. Aber wie gesagt, ich bin da vielleicht auch noch nicht wissend genug. Ich glaube auch nicht,

Benjamin: 33:21

Dass wir da sind. Aber man muss auch sagen, wir sind momentan, wo früher die Programmiersprachen bei vielleicht C oder Assembly waren, Da sind wir jetzt gerade. Ich meine, die Programmiersprache ist man auch in der Abstraktion. Manche schreiben heute noch C++, wenn es Maschinen ist, dass es Use Cases dafür gibt. Aber die Hauptbusiness-Anwendung, also Anwendung, die wir auch bauen in unserem, Arbeitskontext für die Banken, höhere Programmiersprachen wie Java. Früher hatte auch keiner gedacht, dass du irgendwann das alles weg abstrahierst, wo du früher auch gedacht hast, klar, muss ich mich um mein Memory Management kümmert. Heute gibt es einen Garbage Collector. Und du kannst schon sagen, dass dieses mit dem AI einfach eine Abstraktionsebene wieder drüber ist mit diesen Specs und sich da halt weiterentwickelt. Und dann müssen wir halt schauen, wo wir da rauskommen. Das ist halt momentan schwer abzuschätzen. Ja, ich würde es heute auch nicht unterschreiben, dass man den Code nicht anschauen sollte und dass man die Leute nicht braucht. Ich finde immer das Gedankenspiel interessant. Weil man merkt, in welche Richtung die Gedankengänge sich entwickeln. Ich kann da auch von Brigitta Böckel noch einen Artikel empfehlen, der heißt Understanding Spec-Driven Development. Dann geht es auch um diesen Spec. Spec ist Source, Spec ist Truth, Spec First. Also wie stark nimmt man diesen Spec? Da ist es auch dieses, naja, ich generiere mir alles aus dem Speck, ich mache mir erst den Speck, generiere den Code für die Speck, update die wieder oder schreibe den Speck nach einmal und werfe ihn wieder weg. Da gibt es verschiedenste Ansätze, wie man das macht. Das ist ein Thema für sich, dieses Speck-Driven Development. Da kann man sich auch ein bisschen reinfuchsen, um zu sehen, welche Möglichkeiten es da einfach mittlerweile gibt.

Stefan: 34:45

Gut, jetzt sind wir über unser Context Engineering schon raus und ein bisschen in die Zukunft gegangen. Da wäre jetzt für mich so ein bisschen der Punkt zu sagen, wir runden das Ganze mal ab. Was war jetzt eigentlich unsere Erkenntnis? Was ist Context Engineering? Und was sind da so die Punkte, auf die man achten sollte? Wie du es schon angeteasert hast, was ich als letztes gehört habe, bleibt mir als erstes im Kopf, die RPI-Loop, also Research, Plan und Implement oder im Endeffekt sinnvolle, agile Softwareentwicklung, wie ich als halber Agingist leider sagen muss. Das heißt, das ist der erste Ansatz für ein Kontext-Engineering, den ich auf jeden Fall beachten sollte, dass ich mit so einem Ansatz da reingehe. Ja. Und damit das Ganze mache und nicht einfach anfangen, meine KI anzuschreien und einfach zu sagen, okay, Entwickler, ihr dürft jetzt mit KI entwickeln, macht halt einfach mal und wir hoffen, am Ende kommt was Gutes bei raus. Genau. Wenn dann geplant und mit einem sinnvollen Plan und entsprechend Research vorher. Der zweite Punkt war, dass der Kontext halt irgendwann sehr groß wird. Je länger ich mit meiner KI unterhalte, desto mehr Kontext habe ich dort in irgendeiner Form. Das heißt, es ist auf jeden Fall sinnvoll, meinen Kontext ab und zu vielleicht wirklich mal komplett wegzuschmeißen oder zumindest mal zu verdichten und dann auch darauf zu gucken, dass ich meinen Kontext-Window, auch wenn die immer größer werden jetzt mit der Entwicklung, dass ich zusehe, dass ich so maximal an die 40 Prozent eigentlich rangehe oder zumindest das Pi mal Daumen um die 40 Prozent, dass das so mein Ziel sein sollte für einen guten Kontext. Dass es natürlich begründete Ausnahmen gibt für mehr und für weniger, aber dass 40 Prozent die Erfahrung aktuell ist, dass man damit gut ins Rennen gehen kann. Der letzte Punkt, oder der vorletzte eigentlich fast, war, dass wir irgendwann an den Punkt kommen, dass wir überlegen können, wenn wir einen guten Plan haben, dass wir nur noch die Pläne reviewen und nicht mehr den Code selber. Wobei da mein Empfinden auch war, dafür muss man schon sehr stark und sehr viel mit einer KI entwickeln, dass man an den Punkt kommt. Aber dass es durchaus etwas in der Zukunftsmusik oder vielleicht teilweise schon Realität ist, dass man eben nur guckt, man hat einen guten Plan und die KI setzt in Planung und nicht mehr halt zahlenweise durch den Code durchgeht, um da entsprechende Dinge sich nochmal sparen zu können, die eigentlich unnötig sind, weil man sich darauf verlassen kann. Der Plan ist gut, alles andere davor waren gut. Und dann hat die KI da auch etwas generiert, auf dass ich mich zu einem gewissen Prozentsatz zumindest verlassen kann.

Benjamin: 37:10

Ich würde da noch ergänzen, zwei Sachen. Dieses On-Demand-Research, das auch mitnehmen, weil das alte Doku kenne ich einfach schon aus jetziger Softwareentwicklung. Schaut euch das an, macht euch Pläne, überlegt euch, wer diesen Research-Teil On-Demand immer wieder auffrischen könnt, machen könnt, dass das gut funktioniert. Der andere Punkt ist der Kulturwandel. Ich denke, es wird, auf den freue ich mich, weil ich denke, das Wie wird wieder interessant, dass wir uns vornherein über die Pläne Gedanken machen, diesen Research-Teil. und es ein bisschen mehr planen und vornherein mehr denken, wie wir Dinge tun sollten. Das andere ist, ich glaube, Test-Driven-Development wird auch ein bisschen Renaissance erleben. Einfach mit dem, dass man dann auch weniger sich den Code anschaut und müssen halt die Testsolide sein und sich auch den Fokus wieder auf Tests gelegt werden, damit man halt auch weiß, ob dann die Anwendung wirklich tut, was sie soll. Wenn man nicht mehr in der gesamten Code sichtet, das sind alles auch gute Dinge und auch mehr in die Doku-Richtung halt auch wieder gehen, wegen diesem Research-Teil und wieder mal versucht, mehr zu verstehen, was wir da eigentlich treiben und auch an diesem Alignment arbeitet. Und der letzte Punkt zu dem ganzen Thema habe ich mir zum Schluss aufgehoben. Ich finde, das ist das Wichtigste. Aber da gibt es, ich glaube, ich weiß nicht, von wem das Zitat ist, aber das war ein schöner Satz, den ich zu diesem Thema mal gehört habe. Don't outsource the thinking to the AI. Das würde ich voll mitgehen. Das Denken darf man nicht an die KI auslagern, weil die KI ist aus meiner Sicht nur ein Hebel. Der das Denken, was man gemacht hat, in vornherein verstärken kann und damit deutlich mehr Ergebnisse rauskommen mit der Denkarbeit, die vorher geleistet wurde, kann aber genauso ins Negative übergehen. Mit mangelnder Denkarbeit, die eingegangen ist, kommen auch viel schlechtere Ergebnisse raus und es multipliziert sich halt einfach nur. Das heißt, man muss aufpassen. Das ist ein Hebel in die positive und wie die negative Richtung. Wenn man das Handendenken auslagert, dann rutscht man eher in die negative Richtung.

Stefan: 39:02

Das heißt nach wie vor, die KI ist weiterhin ein Werkzeug für uns, aber sollte und kann uns nicht wirklich ersetzen.

Benjamin: 39:09

Nee, momentan nicht, würde ich sagen. Also macht euch keine Sorgen.

Stefan: 39:13

Und mit diesem schönen, vielleicht auch erfreulichen Schlusswort für den einen oder anderen, werden wir dann am Ende unserer Folge angelangt. War wieder sehr erleuchtend. Ich habe wieder viel gelernt. Mal gucken, ob wir noch eine weitere Folge zur KI aufnehmen. Das Thema ist auf jeden Fall noch nicht beendet. Es gibt noch viele Dinge darüber für mich zu lernen und vielleicht auch sogar für uns zu diskutieren mit immer mehr Wissen dazu, was ich vielleicht auch selber aufbaue, dass ich irgendwann auch den lieben Benjamin mal herausfordern kann oder E-Mails erzählen kann. Und damit, ja, euch noch einen angenehmen Tag, Abend oder wann auch immer ihr diese Folge hört.

Benjamin: 39:48

Hat mich gefreut. Danke für die Einladung. Macht's gut. Ciao. Ciao.