Stefan: 0:09

Hallo und herzlich willkommen zu Coffee Code & Consult. KI ist zurzeit in aller Munde, es entwickelt sich rasant. Es fällt total schwer manchmal wirklich den Überblick zu behalten. Was gibt es eigentlich aktuelles und wo bewegen wir uns gerade hin und was ist der nächste Hype?

Benjamin: 0:24

Und genau deswegen wollen wir heute mal so einen groben Überblick bieten.

Stefan: 0:28

Was sind denn die aktuellen Hype-Themen, die Entwicklungen, wo es sich hinbewegt? Ja, und mein Name, Stefan Groß, angehender Softwarearchitekt bei Cofin Pro. Neben mir sitzt heute wieder Benjamin Tenke, Senior Architect bei CofinPro. Und wir reden wieder über das Thema KI, wie schon bei unseren letzten beiden Folgen. Hallo Benjamin.

Benjamin: 0:49

Hallo Stefan.

Stefan: 0:51

Und Benjamin, du warst jetzt gerade auf der AI Engineer in London, hast dort die aktuellsten Eindrücke bekommen, kennst den State of AI. Und was ist denn das Thema, was dich dort am meisten fasziniert hat, als du dort warst?

Benjamin: 1:03

Und bevor ich auf die Faszination zukomme, würde ich euch an den Zuhörern sagen, ratet mal, wie oft Stefan das Intro vorher aufgenommen hat. Ich glaube, wir sind bei Take 10.

Stefan: 1:14

Ja, ganz so schlimm ist es bestimmt nicht. Aber ja, das gehört auch dazu.

Benjamin: 1:18

Aber ja, eher Engineering-Konferenz. Ich muss sagen, das Interessanteste, was mir als erstes so in den Sinn gekommen ist, wo ich zurückblicken muss, das war ja vor zwei Wochen, war meine erste Session, wo ich dann in diesem Publikum saß und der Speaker gefragt hat, Wer nutzt AI heutzutage in seinem Alltag? Dann haben einfach alle die Hand gehoben. Also der gesamte Raum, jede Person hat schon mit KI Berührungspunkte gehabt im Alltag. Das ist okay. Die nächste Frage war noch viel spannender. Die Frage war, wer schaut noch auf den Code?

Stefan: 1:51

Den sie mit KI generieren.

Benjamin: 1:53

Und da hat fast niemand die Hand gehoben. Also ich würde sagen, so 90, 95 Prozent der Leute, die in diesem Raum saßen, das waren 100 Leute, alles halt so Softwareentwickler, die schauen nicht mehr, die haben die Aussage getroffen, nicht mehr auf den Code. Und dann habe ich dann auch so danach der Konferenz so ein bisschen reflektiert und das ist mir aufgefallen, da gibt es einen richtigen Unterschied mittlerweile, mit wem du sprichst, wie du dieses Thema wahrnimmst. Und das empfehle ich auch den ganzen Zuhörern. Setzt es immer in den Kontext. Schaut euch immer an, wer erzählt es euch gerade. Zum Beispiel Big Tech. Jetzt Microsoft und Co. und M-Profic und wie sie alle heißen und Google. Natürlich über das Thema KI sprechen. Sprechen sie von Visionen. Und das sind meistens eher so Zukunftsmusik, was sie so einem erzählen. Und malen das immer sehr romantisch. Und ich glaube auch OpenAI hatte auf der Konferenz die Aussage getroffen, Tokens are cheap. Was ich jetzt so nicht unterschreiben würde, dass sie so günstig sind. Aber die haben natürlich eine intrinsische Motivation, dass diese Adoption von KI halt so hoch wird, damit halt die Leute es nutzen, weil die haben Geschäftsinteresse, die machen halt damit Geld. Natürlich verkaufen die es ein, auch die ganzen Folien von denen waren von Marketing getrimmt und du hast auch gemerkt, die haben das so vorher geübt und haben halt ihre Schuhe abgehalten. Dann gibt es natürlich die Leute, die so in Startups erarbeiten, die sind auch sehr euphorisch, weil man unglaubliche Geschwindigkeiten erreichen kann. Das sind meistens ein, zwei, drei Entwickler und die kommen da halt super vorwärts, sie produzieren irgendwas. Es gibt keinen Legacy-Code, das ist alles grüne Wiese und dann funktioniert das auch ganz gut, wahrscheinlich auf den Code nicht zu schauen, zumindest mal eine Zeit lang. Aber auch Startups überleben ja manchmal zwei, drei Monate nur und dann sind die auch weg oder vielleicht ein halbes Jahr mal. Dann gibt es natürlich diese Content-Creator auf YouTube, das sind auch meine Lieblinge. Weil die oft auch sagen, wie man mit KI arbeiten sollte, wie man Software entwickeln sollte und dass die auch zum Teil nicht auf den Code schauen und so. Und da muss man halt auch immer wissen, naja, die meistens arbeiten, die ja nicht in einem Enterprise-Umfeld. In der Regel machen die ja nur ihren Content-Zeug. Und alles, was sie da programmieren, ist meistens für ihre eigene Lernplattform oder für ihre Hobbyprojekte, wo sie alleine dran arbeiten. Und da funktioniert das wahrscheinlich auch sehr gut.

Stefan: 4:03

Du hast sehr viel geringere Sicherheitsanforderungen. Also spätestens da wird es, glaube ich, schwierig.

Benjamin: 4:08

Ja, und es muss auch kein anderer damit arbeiten. Sie arbeiten alleine dann. Sie haben kein Team. Und dann, das war das Spannende, auf der Konferenz waren auch viele oder ein paar Speaker, wo man gemerkt hat, die kommen aus einem Enterprise-Umfeld. Und da war der Ton schon ganz anderer. Die waren deutlich resignierter, was das AI-Thema, das KI-Thema angeht. Die haben dann zwar immer noch gesagt, ja, die nutzen KI und es hat auch einen deutlichen Mehrwert für die. Es steigert schon die Produktivität oder viele Dimensionen verbessert es einfach.

Stefan: 4:40

Aber die haben dann gesagt,

Benjamin: 4:42

Naja, man muss schon aufpassen, wie man damit arbeitet. Die haben schon viel über die Risiken gesprochen. Die haben viel darüber gesprochen, was man damit nicht so gut machen kann. Und wo sie auch vielleicht eher die KI der Leute ausbremsen. Und dass man sagt, man soll auf jeden Fall auf den Code schauen, weil irgendwann so die größte Gefahr, die natürlich die da sehen, die auch nachvollziehbar ist. Irgendwann verstehen die Entwickler gar nicht mehr, was so in dieser Code-Basis drin ist. Und das ist psychisch sehr belastend für die Entwickler. Da haben die zumindest berichtet, weil die sagen, die haben Code gesehen, den sie selber eingecheckt haben, wo sie gar nicht mehr wussten, dass sie den eingecheckt haben, weil die KI den halt generiert hat oder der Coding Agent. Und die haben gemeint, ja, man kann halt viel mehr Code produzieren, als man zum Beispiel auch reviewen kann. Und man muss halt diese Prozesse ein bisschen anpassen. Und das bringt so viele neue Risiken und Hürden mit rein, die aber, glaube ich, erst in so einem Enterprise-Kontext entstehen und in den anderen Use-Cases eher weniger auftreten. Und man merkt halt, dass jetzt aber immer mehr die Leute auch in den Enterprise-Umfällen Erfahrung sammeln und auch darüber berichten und dass die halt mit einem anderen Ton und einer anderen Sichtweise berichten, was ich sehr spannend finde. Deswegen immer, wenn Leute einen darüber erzählen, einwerten. Wer erzählt das gerade einem? Welchen Hintergrund hat der? Weil je nachdem ist es euphorisch oder vielleicht mal weniger euphorisch.

Stefan: 5:56

Das heißt, du siehst da eigentlich so ein bisschen eine Spaltung in der KI-Community, dass du halt auf der einen Seite die hast, die es dir verkaufen wollen und die, die damit Content machen, also es dir auch im Endeffekt was verkaufen wollen und die, die damit halt unglaubliche Geschwindigkeiten für einen Startup und so weiter gewinnen, für die das ein riesen Benefit ist. Und auf der anderen Seite siehst du die, die mit viel Legacy-Software arbeiten, die große Enterprise-Plattformen in irgendeiner Form betreiben, die zwar KI als Tool wahrnehmen, aber jetzt nicht ein automatisches Agent-Programmieren von allen Teams unterstützen würden. Genau.

Benjamin: 6:31

Und es wird oft besser verkauft, als es in der Realität ist, weil ich habe mich auch mit den Leuten von Google und Co. auf der Konferenz unterhalten. Da hat mir der eine.

Stefan: 6:40

Der war im Android-Security-Team, hat auch gemeint, ja, wir nutzen das schon sehr stark. Und dann habe ich gedacht, für was? Und dann kam schon so raus,

Benjamin: 6:48

Also ich nenne es immer gern Big Tech oder Fang, also diese großen Unternehmen da in den USA, wie Netflix, Apple und Co. Und Google, die bauen sehr viele interne Tools damit. Also da haben sie auch sehr viel Erfahrung gesammelt in den letzten zwei Jahren. Es ist unglaublich, viel interne Tools damit gebaut werden. Aber es ist auch nachvollziehbar. Es ist ein umgangsschut, low risk, Weil ich meine, das ist nur intern, wenn es auch mal kaputt geht, naja, dann fixt vielleicht einer oder auch nicht. Am Ende hat es ja nur die eigene Produktivität vielleicht im Unternehmen gesteigert. Aber das Produkt nach außen geht nicht kaputt. Klar, andere haben sich da schon weiter gewagt. Amazon hatte ja auch ein Audit von, glaube ich, neun Stunden mal wegen dem, weil KI-Slope-Code in Produktion gelangt ist mit einer falschen Config. Echt? Das habe ich gar nicht mitbekommen. Ja, ja, da gab es auch schon Probleme. Dann hat Amazon das ein bisschen angezogen, dass jetzt keine Junior-Developer mehr Merch-Requests merchen dürfen. dass immer ein Senior das akzeptieren muss, wenn das von der KI gemacht wurde. Also die, kriegen da auch Rückschläge, es bewegt sich hin und her, aber da investieren die gerade viel. Aber ich finde es auch gut, da anzufangen und nicht direkt in dem Produkt massiv mit der KI zu arbeiten. Von daher, da kann man sich das auch abschauen und erstmal in die eigene AI-Infrastruktur oder in die eigene technologische Infrastruktur mit der KI investieren und da viel bauen und Erfahrung sammeln. Das Spannende ist auch, weil ich es vorhin erwähnte, mit dem Token-Nutzen, Auch noch eine lustige Side-Story. Es gibt diesen Trend, auch gerade bei diesen großen Unternehmen. Da habe ich mit einem Entwickler gesprochen in London, der Algo-Trading macht, also die Algorithmen schreibt für die Algo-Trader.

Stefan: 8:17

Der hat gemeint und auch in den anderen Unternehmen wie Facebook,

Benjamin: 8:20

Dass es so Leaderboards gab. Die Praktik nennt sich Token Maxing, wo du gesehen hast, wer die meisten Tokens verbraucht. Das sogar intensiviert wurde, dass die Leute möglichst viel mit KI arbeiten und dass ein gewisser Druck entsteht, auch für Leute, die nicht damit arbeiten wollen, dass du das mitmachst, weil die Überzeugung ist ja, du bist ja damit schneller oder effizienter. Und deswegen will man das irgendwie fördern über diese Leaderboards. Und der hat da gesagt, der war ganz oben und der hat ungefähr 5000 Dollar an KI-Kosten alleine verursacht.

Stefan: 8:51

Der Werte ja pro Monat. Krass. Also das ist nämlich auch so ein Punkt, der aus der OOP, wo ich im Januar war oder Februar, Anfang des Jahres auf jeden Fall, wo ein Konsens von den Architekten dort war. Naja, zur Zeit werden diese ganzen Tokens noch stark subventioniert. Aber wenn du irgendwann an einem Punkt kommst, wo es nicht mehr subventioniert ist und die dann wirklich so viel kosten müssen, wie sie halt Kosten verursachen, dass wir dann alle vielleicht ein bisschen aufwachen, was die KI-Nutzung angeht.

Benjamin: 9:17

Es kann sein, weil wie gesagt, 5.000 ist auch schon geworden, wenn es irgendwann 10.000 sind pro Person. Aber ich meine, es kann auch sein, dass es günstiger wird. Die spekulieren auch da drauf. Das andere war, dass es auch bei Meta soweit war, also bei Facebook, dass die, die haben ja so eine komplizierte Bewertung von den Mitarbeitern, was die Performance angeht und dann auch Vergütung und dein Beitrag, wie viel du leistest. Dass da gibt es zig Data Points, wo sie dann nutzen, um zu bewerten, wie gut du bist. Und eine war tatsächlich auch die Token-Nutzung, wie viele Tokens du nutzt. Wenn du mehr, umso besser. Also es ist eine komische Richtung, aber ich muss sagen, wo das dann viel drüber geredet wurde, in den Medien auch, gibt es ja auch ein bisschen Gegenwind dazu, was auch verständlich ist, weil es ist sehr fraglich, wenn du mehr Tokens nutzt, weil zum Teil waren dann einfach Leute, die haben Agents im Loop laufen lassen über Nacht und haben halt Nonsent produziert. Einfach, dass du mehr Tokens nutzen.

Stefan: 10:06

Wie jeder KPI kann man dagegen optimieren und das Resultat ist vielleicht nicht das, was man sich wünscht.

Benjamin: 10:12

Genau, also deswegen sollte man sich das gut überlegen, ob man da irgendwelche Dealer-Boards ins Einbau oder viele Tools kommen tatsächlich mit diesen Boards, wo man sieht, wie viele Tokens nutzt.

Stefan: 10:20

Aber so dein Take-away war, von diesem ganzen Thematik ist es eigentlich sinnvoll, da als Unternehmen selber intern mit kleinen Software-Stücken so ein bisschen Erfahrung zu sammeln, zu gucken, wie können wir es sinnvoll einsetzen und dann zu gucken, mit diesen ganzen Erfahrungen und Erkenntnissen, wie können wir es dann vielleicht auch in einem Enterprise-Umfeld nicht nur intern nutzen.

Benjamin: 10:40

Genau, also ja, weil vielleicht auch während des Podcasts werde ich immer wieder ein bisschen so auf den Unternehmen rumbaschen, die sehr viel KI nutzen, weil auch viel Bullshit dabei ist, aber auf jeden Fall sollten sich Unternehmen dann beschäftigen und Erfahrung sammeln und wie du gesagt hast, das ist ein guter Ansatz. Das andere, was ich so noch auf der Konferenz so gehört habe, oder zwei Sachen, was ernst und nicht so funktioniert auch, oder wo der Trend eher weggeht, ist zum einen diese Workflows. Es gibt viele so Tools wie N8N oder auch andere, wo es so um Orchestration geht, wo man dann sagt, das erinnert mich immer ein bisschen so am BPMN, an die alten Hasen werden das noch kennen, so Prozessmodellierung, wo man auch versucht hat, Prozesse zu malen und die automatisiert, wenn man sie so in einem Standard gemalt hat. Hinten dran konnte es irgendeine BPM-Engine direkt auch technisch ausführen. Und diese AI-Workflow-Tools, das machen nichts anderes, die orchestrieren halt die AI. Typischerweise sieht man dann, dass es dann einfach so Boxen gibt, man kann Linien ziehen und man kann dann sagen, wie früher, if this, then that. Dass man sagt, wenn das passiert, dann soll das passieren, das passieren. Und zwar tut dann die AI das machen, halt irgendeine E-Mail schreiben oder auf irgendein Event reagieren. Aber dadurch, dass man das so stark orchestriert, kriegt man viel mehr Probleme mit diesem Orchestrieren. Und man schreibt wieder viel mehr selber Code oder Logik oder werkelt da dran rum. Und irgendwie hat man dann das Gefühl, okay, aber was hilft mir hier noch die KI? Mal am Ende versuche ich einen deterministischen Workflow irgendwie zu bauen, indem ich so diesen Rahmen mit diesen Workflow-Tools baue. und der Konsens war schon so eine herrschende Meinung auf der Konferenz. Ja, davon sollte man uns eher wieder wegbewegen, weil das klang ganz gut als Idee. Es gibt ja auch viele Tools, die das anbieten, aber wir sollten das wieder vereinfachen. Vor allen Dingen, das war auch so ein Konsens mit vielen Leuten, die ich hatte und ich auch selber die Erfahrung gemacht habe, also seit November, Dezember, wo jetzt Opus 4.5 rauskam, so nett, also von Antrofic, die neuen Models und auch die Updates zum Agent Harness, also Claude Cote ist der Agent Harness von denen, die sind so gut halt mittlerweile, dass da auch nochmal ein Sprung gemacht wurde. Und dann brauchst du diese ganzen Workflow-Orchestrationstools nicht mehr, weil die KI, die haben so ein gutes Model getrimmt und auch ihren Agent, den sie dazu haben.

Stefan: 12:52

Dass der selber entscheiden kann, ziemlich gut, was die nächste sinnvolle Schritt ist zu tun.

Benjamin: 12:57

Und deswegen kam auch ein neuer Trend auf, gibt es glaube ich auch seit zwei Monaten, wurde auch ziemlich viel auf der Konferenz geredet. Das nennt sich Ralph Wiggle Loops. Das ist der Charakter aus Simpsons, der Ralph, der immer so komische Aussagen macht, so einzelne Sätze und auch ein bisschen dümmlicher darüber kommt, aber der ziemlich stur ist und einfach Dinge macht. Ich glaube, danach kam auch der Name und die Logik ist einfach, dass du, einen Loop machst mit dem Agent, das ist wirklich eine Walschleife mit einem Shell-Skript, also einem Python-Skript hat es einer gemacht und der Kontext nach jedem Loop resetet wird, also so wie der vergisst, was er vorher getan hat und der dann einfach, da kann man dann so eine lange Taskliste geben, zum Beispiel ein blumpes Beispiel aus GitHub-Issues nehmen, du hast 100 offene Issues, lassen über Nacht da drüber iterieren in den Loop, dann hast du am nächsten Tag vielleicht 80 gute geschlossene, 20 musst du vielleicht noch offen lassen, aber du hast diesen AFK-Loop, da kannst du einfach die ewig lang arbeiten lassen. Und es funktioniert mit den neuen Modellen erstaunlich gut, dass die AI auch von sich erkennt, auch wenn das zum Beispiel logisch aufeinanderfolgende Tasks sind, in welcher Reihenfolge die am besten abarbeiten sollen. Und dadurch, dass du diesen Kontext-Reset hast, nach jedem Loop, hast du nicht diese Probleme, dass das dann blört oder er sich verliert oder verrennt, weil viel zu viele Informationen in seinem Kontext sind.

Stefan: 14:13

Okay, dann muss ich aber, um das Verständnis nochmal herzustellen, zumindest in meinem Kopf, Das heißt, du sagst, er kann entscheiden, was sind die logischen Schritte, die da hintereinander ausgeführt werden müssen. Der Agent, der das Ganze bearbeitet, Aber wie kann er diese logische Schlussfolgerung treffen, wenn nach jedem Schritt der Context resettet wird? Dann weiß er ja gar nicht, was vorher gemacht wird. Weil er sich

Benjamin: 14:36

Die ganzen Tasks wieder anschaut und er hat ja auch das Ergebnis. Also darüber kann er dann sich das schon herleiten.

Stefan: 14:42

Okay, das heißt, du gibst dann als Kontext quasi wieder die gleiche Tasklist rein und das bisherige Ergebnis und dann muss er daraus eben weiterdenken.

Benjamin: 14:49

Genau, die Prompt muss auch so gut sein, die man dann gibt für das Loopen. Das ist eine bestimmte Technik, wie man auch diesen Prompt schreibt, wenn wir jetzt nicht ins Detail gehen, aber das können sich die Leute selber online nachschauen. Da gibt es ohne Ende Artikel dazu. Wie man das Prompt hat, dass dieser Loop sehr gut funktioniert, ist halt wie eine Kunst für sich. Aber da haben Leute unglaubliche Resultate einfach damit erzielt. Und das ist ein Prompt und ein Loop. Und was sie damit gemacht konnten, schlägt halt die meisten so AI-Workflows. Und da merkt man, dass manchmal die Kunst ist, in was Simplem zu bauen, was sehr einfach ist, um einfach große Ergebnisse damit zu erzielen. Aber das ist so ein Trend. Und das andere, vielleicht nicht so überraschend, aber ich glaube, fast jeder Speaker, der sich ein bisschen wirklich auf die Softwareentwicklung konzentriert hat mit KI, hat gesagt, ja, Spectrum Development, nee. Das Thema ist eher wieder durch. Also es war ein netter Gedanke. Man versteht auch, woher er kommt. Ich meine, das hat man ja auch versucht damals in der normalen Softwareentwicklung. Aber das ist eher auch wieder so die herrschende Meinung. ja, machen wir lieber nicht, weil am Ende...

Stefan: 15:54

Der Konsens war, naja,

Benjamin: 15:55

Eine sehr ausführlich beschriebene Speck. Was ist es? Wie nennen wir das? Code. Also wenn man irgendwann so viele Specks schreibt, dass man fast schon den Code abbilden kann, wo ist denn der Hebel von der Zeitersparnis, dass wir halt so viel Zeit mit dem Speck verbringen und dass ja auch in diesem Enterprise-Umfeld immer mehr diese Erkenntniswachsen, wir müssen uns den Code anschauen. Und danach sowieso, naja, dann einmal in den Speck zu fallen, wenn nicht der Code rauskam, den wir wollen, dass wir die Specks abändern, wandeln, um den Output sozusagen zu verändern vom Code. Das ist nicht unbedingt der Lösungsweg. Das heißt, der Konsens ist eher so der neue Trend, den ich auch festgestellt habe, was am besten momentan funktioniert, um dieses ganze Requirements Engineering zu machen, es mit der KI im Gespräch zu führen. Also wie mit einem Menschen, also wenn du es delegieren würdest, ein Junior. Da gibt es eine bestimmte Prompt. Das ist der Grill-Me-Skill, wenn man das googeln möchte.

Stefan: 16:51

Grill-Me.

Benjamin: 16:52

Grill-Me, wirklich wie Grill-Me oder Roast-Me. Wo man dann der KI sagt, hinterfrag sehr kritisch. Also du musst eine Anforderung reinkippen, was du machen willst. Und der hinterfragt es dann sehr stark. Und auch in Anbetracht von deiner Code-Basis. Und dann stellt er ganz viele Fragen. Ja, wie würde ich denn das Down-Down umsetzen? Wie stellst du dir das Down-Down vor? Und dann muss man halt ihm ein bisschen erklären, wie man es so gerne hätte. Und dadurch fühlt man ja den Kontext mit diesen ganzen Lücken, die die KI normal einfach selber auffüllen würde, mit diesem Nonsens, den Training-Data einfach drin ist, der halt überhaupt nicht zu deinem Kontext passt. Und dadurch kriegst du genau die Informationen in den Kontext rein. Ich glaube, das löst auch so ein bisschen das Problem, dass man auch Entwickler ein bisschen fauler sind, das so detailliert aufzuschreiben. Und man fragt sich auch, was muss denn die KI wissen? Und man würde es ja auch vorne wegnehmen, weil man denkt, die Informationen sind wirklich relevant. Was aber festgestellt hat, die KI ist sehr gut darin, diese Fragen zu stellen, um wirklich die relevanten Informationen in den Kontext reinzubekommen.

Stefan: 17:50

Und wenn man dann diesen Kontext primed hat,

Benjamin: 17:52

Die richtigen Infos drin sind, dann erzieht man viel bessere Ergebnisse. Das heißt eher weg von diesem Spectrum Development mehr, würde ich sagen, in diese Discussion reingehen am Anfang, also Diskussionen mit der KI führen, bevor er überhaupt anfängt, diese Aufgaben abzuarbeiten.

Stefan: 18:06

Wenn man sich jetzt aber die verschiedenen Sachen anguckt, wie bewerte ich denn eigentlich, dass das, was ich da gerade tue, auch sinnvoll ist? Also bei dem Spectrum Development habe ich mir angehört, gut, mir passt das nicht, was als Ergebnis rausgekommen ist. Wahrscheinlich der Code, heißt aber, ich muss den Code auf jeden Fall lesen, um dann den Speck anzupassen. Ist das jetzt bei sowas wie mit dem Grimmy-Speck, nee, mit dem Grimmy-Kontext, ist das ähnlich, dass ich da auf jeden Fall auch nochmal den Code angucke oder habe ich dann irgendwelche anderen Konstrukte, über die ich bewerte, dass das, was da gerade passiert, auch das ist, was ich möchte?

Benjamin: 18:41

Das meinte ich mit diesen vorhin, je nachdem, wie du fragst, je nachdem, an was du arbeitest, aber der Konsens ist schon im Enterprise-Umfeld, du musst dir den Code anschauen. Brauchst das Vier-Augen-Prinzip. Du musst nochmal schauen, was da produziert wird. Unabhängig, ob du das spec-driven machst oder über diesen Grimmy-Skill oder mit der Diskussion mit der KI.

Stefan: 18:59

Bei dem Speck-Dream-Development ist,

Benjamin: 19:01

Da gibt es ja verschiedene Formen, aber in der puren Form ist es schon so der Gedanke gewesen, du schreibst die Speck und du schaust dir den Code nicht an, hast du einen Test oder testest das Produkt und schaust, ob es tut und was es soll. Und wenn nicht, passt du die Specks normal an, in der Hoffnung, dass er dann den Code produziert, dass das Verhalten rauskommt von deinem Produkt, was du gerne hättest.

Stefan: 19:18

Also war eh hoffnungsbasiert, also faktenbasiert, okay.

Benjamin: 19:20

Genau, es gibt verschiedene Formen, bestimmt gibt es auch einen Workflow, wo man sich den Code dann mit Specks auch anschaut.

Stefan: 19:26

Aber dann kommen wir eben in genau den Punkt, den du beschrieben hast mit, man schreibt im Endeffekt wörtlich hin, was der Code tut und dann kann man den Code auch direkt selber schreiben.

Benjamin: 19:34

Genau. Und diese Diskussion funktionieren in der Regel so ein bisschen besser. Aber wie gesagt, der Konsens war zumindest von den Enterprise-Leuten, ja, wer soll uns den Code noch anschauen? Macht Sinn, weil die KI, es werden immer mehr Defizite einfach klar mit dem Arbeiten von KI. Dass es zum Beispiel sehr lokal arbeitet, also wenn du eine KI erklärst, der kann nicht den gesamten Codebase im Kontext halten und diese ganzen Entscheidungen, die im Unternehmen getroffen wurden und das ganze Wissen über die IT-Infrastruktur und etc. In den Teams, diesen ganzen Wissen kriegst du nicht rein, weil der Kontext ist einfach limitiert von der KI, bewegt sich ja meistens so 200-300k Tokens, auch wenn die Kontext findest, irgendwann 1-2 Millionen werden aufgrund der Interhänden-Limitierung einfach von dem Transformer-Modell, was diese LNMS haben, gibt es die Simentierung. Und das erkennen auch immer mehr Leute, auch Antrofic und selber geben es ja zu, indem sie sowas wie Skills einführen, was ja nichts anderes ist, wie irgendwelche Ordner mit Anweisungen, Skripten und Ressourcen, die die Agenten dann finden können und on demand reinladen in den Agent, dann, wenn sie es brauchen, wo dann einfach nur drinsteht, also auch wie der Kontext ist, den der Agent sich reinlädelt, aber on demand halt, dass halt dieser Kontext nicht polluted wird. Und da bewegt es sich halt irgendwie hin. und so viele Kleinigkeiten habe ich auch in den Talks bemerkt. Der Konsens ist auch so mittlerweile, naja, deine Feedback-Loops, die du hast.

Stefan: 20:56

Auch beim Coden, aber ich würde argumentieren,

Benjamin: 20:59

Genauso in fachlichen Use Cases, wenn man die mit der KI umsetzt. Das ist so die Obergrenze, das Limit, wie gut zum Beispiel jetzt in dem Coding Use Case, wie gut deine Codequalität von der AI sein kann, was die produziert. Die wird nicht besser sein, wie deine Feedbackschleifen. Weil wenn du keine guten Tests hast, wenn du keine Linting Rules hast, wenn du nichts hast, wo die KI halt aufrufen kann, wo ihr verifiziert das Ergebnis, was es produziert hat, woher weiß nicht, was gut ist. Weil was die Leute immer vergessen ist, die ganzen Modelle wurden auf Trainingsdaten aus dem Internet trainiert. Das heißt, die gesamte Codebase von GitHub, von Stack Overflow. Und wenn wir mal ehrlich sind, der meiste Code da ist mediocre, also mittelmäßig oder schlecht. Es gibt da auch guten Code, aber das ist im ganz kleinen Bereich. Das heißt, das meiste, wo dann das Modell trainiert wurde, ist jetzt nicht unbedingt der allergeilste Code. Und du musst dem ja irgendwie erklären, wie für dich.

Stefan: 21:47

Guter Code aussieht. Da sind ja dann zum Beispiel auch selten Enterprise-Architektonen irgendwie umgesetzt, sondern du hast halt die Hobby-Projekte von Leuten und natürlich habe ich da keine hochklassifizierte Architektur, weil ich sie einfach nicht brauche, aber dann kann die KI, wenn sie auf sowas trainiert ist, dir halt auch nichts Besseres ausspucken, wenn sie keine Bewertung hat.

Benjamin: 22:03

Du hast den Nagel auf den Kopf getroffen. Die Projekte sind Hobbyprojekte, sind Beispielprojekte, sind Libraries, aber es sind keine Enterprise-Code. Der ist ja geschützt in irgendwelche privaten Repositories, auf denen halt nicht trainiert wurde. Und man muss auch immer bedenken, das erklären auch viele Leute, wenn du versuchst, die KI auch so zu verbiegen, dass sie gegen ihre eigenen Trainingsdaten arbeitet, viel Spaß. Das heißt, der Code wird ja immer mehr so, der mit KI produziert wird, wie halt diese Trainingsdaten, was auch nicht unbedingt gut ist. Aber da gibt es auch Methoden, das einzufangen. Wie gesagt, Feedback-Loops, also man muss viele Testfunktionen, Lins haben, irgendwelche Skills, wo man Skripte hat, die halt Code oder Architekturen vom Code auf irgendeine Weise, Art bewerten und den Coding-Agents sagen, ja, das ist so nicht gut, damit er halt weiß, okay, ich muss das vielleicht nochmal anpassen, nochmal weiter Schleife fahren. Das andere ist, da musste ich auch auf der Konferenz so ein bisschen lachen, das wird dich freuen. Die Leute, die das machen, sind oft Content-Creator oder auch so Leute aus Start-Ups und auch oft junge Leute. Und die sind so ein bisschen, die ihrer Bubble ist mir aufgefallen, weil die dann jetzt für sich mittlerweile entdeckt haben, dass es so Bücher gibt wie Pragmatic Programmer, Domain-Driven Design und dass man diese ganzen Sachen irgendwie der KI auch beibringen muss. Und oh Wunder, man erhält bessere Ergebnisse vom Coding-Agent, wenn der Coding-Agent versteht, dass man Deep-Modules bauen soll, dass man mit Interfaces arbeiten soll, dass man eher so kleine Tracer-Bullets, nennt sich das, glaube ich, bei Pragmatic Programmer, also so kleine isolierte Bereiche von Code arbeiten sollte, die aber vertikal den Code durchdringen und nicht horizontal arbeiten. Und wenn man das so der KI so ein bisschen erklärt, dann kommt man da auch auf bessere Ergebnisse. Aber das ist so spannend, dass so diese alten Tugenden wiederkommen und gepredigt werden, dass das Alte jetzt nicht irrelevant ist, sondern umso wichtiger wird, weil eine gute Code-Basis, wenn du ein starker, in deinem Repo der Code gut strukturiert, dass Menschen damit gut arbeiten können, das ist auch meine Hypothese, ich rausgelernt aus diesem Ganzen. Wenn deine Menschen gut damit arbeiten können, dann kann auch die KI gut damit arbeiten. Weil wenn man die Code-Basis wie es ist, viel zu komplex und strukturiert, nicht kleine, in sich geschlossene Module hast, dann kriegt die KI natürlich auch Probleme, weil sie sich nicht alles reinziehen kann in den Kontext. Das war so ein bisschen, wo ich schmunzeln musste. Test-Driven-Development hat ein Comeback, weil dir Leute sagen, wenn du erst deinen Test schreibst und er weiß, okay, du erwartest diese Tests, die sichtest du vielleicht auch manuell und schaust dir die an.

Stefan: 24:35

Die KI schreibt dann den Code dazu, dann weißt du zumindest, okay, der Code macht funktional genau das, was er sollte. Das heißt, wir gehen weg von dem, wir lassen die KI mal machen, sondern gehen dahin mit, wir bringen der KI sinnvolle Softwarearchitektur bei und Programmierkonzepte und Paradigmen und dann kommt plötzlich bessere Software bei raus. Genau.

Benjamin: 24:54

Welch Wunder. Ich glaube auch, was Unternehmen machen können, gerade im Enterprise-Umfeld dann mit diesen Skills, was, ich glaube, in Fortbeck hat das gepusht, aber das ist mittlerweile ein offener Standard. Viele von diesen Coding-Agents haben das adoptiert, weil ich auch gerade von der Welt habe, was eine von der Folder sind, wo, ich würde es so beschreiben, wo du Domänenwissen in Form von Markdowns ablegst, was du wiederum als Kontext für den Agents sehen kannst. Und die Kunst wird sein, in Enterprise-Umfeldern, das wird die Guten von den Schlechten unterscheiden, wie gut bekommt das Unternehmen hin, ihr Domänenwissen, ihr Kontextwissen in dieses Format zu bringen, für die Agents zugänglich zu machen. Und das auch so zu gestalten, dass der Agent zur richtigen Zeit den richtigen Kontext zieht und dass dieser Kontext, der dann auch verschachtelt sein kann, dass du ihn so aufbaust, dass immer nur genau das reingeladen wird vom Wissen, was der Agent für die Erledigung der Aufgaben braucht. Und das ist eine Kunst, glaube ich, für sich. Da werden viele Frameworks entstehen. Da wird noch viel gebaut werden. Aber das wird so ein bisschen die Kunst sein, dass du auch sagst, hey, okay, wenn der Coding Angel losrennt und er schreibt gerade Tests, dann tue ich ihm dieses ganze Domänenwissen oder auch Fachwissen zu, wie schreiben wir Tests? Also wie würde jetzt jemand, der im Unternehmen einen Test schreiben, würde das machen und dass er das in eine strukturierten, für ihn verwendbaren Form reinzieht machen? Das wird so der Game Changer sein, glaube ich, für Leute, die dann viel KI im Unternehmen nutzen.

Stefan: 26:19

Spannend. Was auch so rauskam,

Benjamin: 26:21

Das ist nur so Side-Note, Coding-Agent arbeiten anscheinend gerne horizontal. Warum das so ist, hat keiner so rausgefunden, aber das hat man einfach festgestellt. Das heißt, die schreiben...

Stefan: 26:30

Genau, horizontal erklären.

Benjamin: 26:33

Die schreiben so den Persistenz-Layer, dann den Business-Layer und dann den UI-Layer. Also die arbeiten gerne in diesem horizontalen Layer. Wenn man denen beibringt, dass sie vertikal arbeitet und wie wir auch Entwickler arbeiten würden, also man bringt denen immer mehr bei, wie ein Entwickler zu denken, kommen auch bessere Ergebnisse raus, weil dann schreibt er UI, dann schreibt er Business und dann schreibt er Persenz und es kommt besser Ergebnisse raus, als dass er erst die gesamte UI baut, dann die gesamte Business-Schicht und dann die gesamte Persenz-Schicht für alle Features. Das ist auch so eine spannende Erkenntnis, die so auf dieser Konferenz so gereift ist und die verschiedenen Talks einfach gehört haben. Das andere, was ich noch so erwähnt hatte, ich hatte es zwar vorhin nur angerissen, aber ich glaube, dass du soll dich auch noch ein, zwei Wörter verlieren, ist dieser Agentik Harness. Um das so ein bisschen zu beschreiben, ohne jetzt ins Detail zu gehen. Das ist alles außer das Model. Wir hatten mal eine Folge aufgenommen, wo ich im Kontextingenieur versucht habe zu erklären. Ich sagte, ja, da ist so eine Software-Schicht zwischen dir und deinem Chat-Interface oder deiner Bash und dem Model. Und das ist sogar die eigentliche Intelligenz, weil das Model ist ziemlich dumm. Das sagt ihr eigentlich immer nur, also einfach nur Prediction. Die wirkliche Intelligenz und warum das immer besser auch funktioniert, dass ja, die Models wurden besser, aber diese Zwischenschicht wurde besser. Und das haben sie einen Namen dafür mittlerweile. Das nennt sich Agentic Harness, das sind Tools, das ist das ganze Kontextmanagement, also was kommt in den Kontext rein, wie komprimiere ich den Kontext, was werfe ich aus dem Kontext raus. Da muss es ja irgendeine Logik geben, das muss eben jemand gecodet haben, der nach bestimmten Logiken das tut. Guardrails, Verifizierungsfunktionen, diese Loops oder so, also Cloud Code zum Beispiel ist halt auch der ganze Harness, den Profic gebaut hat. Und da würde ich sagen, da ist auch der wirkliche Hebel, habe ich so festgestellt, weil in der ganzen Konferenz ging es um Kontextmanagement eher. Also wenn du es wirklich auf eine Abstraktionsnehmende bringst, es ging immer nur darum, wie kriegen wir bestmöglich diesen Kontext gestaltet, den man in diesen Model reingebt. Weil die Models, die werden noch mal besser, aber das flacht halt ab. Also da sind wir ja schon ziemlich gut unterwegs. Ich glaube, bei den Models wird es eher noch so Edge-Device-Models geben, also so kleine Models, wie Gamer 4, wurde auch auf der Konferenz vorgestellt von Google, was man lokal auf Laptops und so ausführen kann. Da wird es noch viel mehr geben. Also Use-Case-spezifische Models werden eigentlich noch stärker in der Zukunft kommen. Aber diese Models, die alles so können, diese generalistischen, da sind wir schon ziemlich gut unterwegs. Und meine Einschätzung ist, da wird es jetzt nicht mehr so diese Riesensprünge geben, wie es jetzt in den letzten zwei Jahren gegeben hat. Klar werden die noch besser, aber der wirkliche Hebel liegt in diesem Agentic-Harness. Und zum Beispiel Big Tech investiert unglaublich viel Geld, diese zu bauen. Also ich habe mit dem von Google geredet. Das heißt, die bauen ihren eigenen Harness, also auch Enterprise-Umfeld, da kann man dann Use-Case-spezifische Harnesses bauen, dass man diesen Harness drin hat zum Beispiel. Auch wegen Security kann man verbessern.

Stefan: 29:23

Wie logge ich mich ein, bevor er überhaupt irgendwas,

Benjamin: 29:26

Zum Beispiel der Agent, für einen machen kann. Aber das kann man ja hart coden in diesem Harness, dass er hingeht, sich einloggen, Token holt, den ablegt und diese Credentials, die müssen dann auch nicht ins Large Language Model zum Beispiel geschickt werden, sondern das ist eine hartgecodete Logik einfach, wo dann diese Intelligenz sozusagen dahin ein bisschen verschoben wird. Und die Leute sollten sich halt darauf fokussieren, eher in diesen Harness-Zeit rein zu stecken, anstatt diese Models hinten dran groß zu tauschen oder auf das nächste Model zu warten. Investiert da lieber eure Zeit rein, würde ich ihm mal empfehlen, weil Kontext ist weiterhin King, darauf kommt es an und mit diesem Harness hat man halt diese Möglichkeit. Beispiel ist zum Beispiel Claude Code ist ja auch ein Harness, manche sind unzufrieden, weil die sagen, die haben keine Kontrolle über dieses Kontextmanagement von Claude Code. Der macht halt, was er will, die updaten das, die haben auch keine Transparenz drüber, wie das genau funktioniert von der Architektur. Das heißt, wenn man seinen Workflow ein bisschen darauf angepasst hat, dass der Agent sich mit der Context Compression auf eine gewisse Art und Weise verhält, die updaten das und das verhält sich ganz anders da, ja, dann breakt da vielleicht dein Workflow. Und deswegen gibt es auch mittlerweile sowas wie Open Code, glaube ich, heißt es, oder PI, also P, der P-Agent. Das sind einfach andere Harnessen, die man nutzen kann als Coding Agent. Zum Beispiel bei Pi kann man, die haben viel weniger wie Cloud-Code, also die können keine Sub-Agents, die können keine Loops oder verschiedene Sachen, Features haben die nicht, aber dafür kannst du das beliebig erweitern. Du hast sehr viel Transparenz, weil das Open Source ist auch von Code, wie die das machen und du kannst es halt sehr stark in deinem Unternehmen einfach customisen und für dein, wie dein Unternehmen oder deine Entwickler arbeiten oder für deinen fachlichen Use Case, den du einfach hast, sehr stark individualisieren und da hast du halt wirklich den Hebel, um die KI passend für deinen Use Case anzumachen.

Stefan: 31:19

Da vielleicht auch nochmal der kurze Segway zu einer anderen Folge, nämlich Context Engineering. Die haben wir letztens erst aufgenommen und veröffentlicht. Gerne da nochmal reinschauen, wenn ihr ein bisschen mehr noch zu dem ganzen Thema Context wissen wollt, weil da können wir leider in der Folge hier nicht so tief ins Detail gehen.

Benjamin: 31:35

Genau, da müssen wir auch vielleicht irgendwann eine Version 2 aufnehmen, weil da hat sich nochmal einiges geändert. Da können wir vielleicht auch nochmal eine Folge machen. Aber gerade weil wir noch bei Context waren, ein Talk war glaube ich auch Context is the new code. Weil, was auch so ein Trend ist, ich habe es ja mit Skills angerissen, Kontext wird heutzutage meistens über MCP zum Agent befördert, also dass du irgendwie dieses Protokoll hast, wo du meistens aktiv von irgendwelchen anderen Anwendungen, APIs, Datenbanken, Daten, die abgreifst und in den Kontext lädst. Aber um einfach Domänenwissen, was Leute einfach irgendwo aufschreiben, wie bestimmte Dinge im Unternehmen getan werden, wie wir Code schreiben, wie wir bestimmte Dinge tun, sind diese Skills. Und diese Skills ist halt Domänenwissen, Kontext. Die Frage stellt sich natürlich mittlerweile, ja gut, was mag da und falls, wie checkst du irgendwo in deinem Repo ein, aber dann hat nur dein Team das. Die nächste Stufe ist, das hat sogar schon Namen, wir haben das nächste Ops, Stefan. Das nennt sich Context Ops. Oh wow. Ja, nicht nur DevOps, SecOps, jetzt haben wir Context Ops, weil das hat ja auch einen Lifecycle. Also irgendwie musst du es ja paketieren, versionieren, veröffentlichen. Du musst es ja auch in Produktion ein bisschen beobachten, ob Veränderungen an diesen Skills und dem Prompt sozusagen und an dem Kontext, den du reingibst, ob das die Performance verschlechtert, verbessert. Dafür brauchst du auch Observability, was jetzt auch immer mehr kommt. Da haben auch viele über Konferenzgeräte, also wie kriegst du das hin, dass diese Agents... Irgendwie ein bisschen Tracing hast, ein bisschen siehst, was passiert denn da genau in diesen Agenten? Wie kommen die denn zu ihren Entscheidungen, dass du das irgendwo in den Daten einfach sammeln kannst, auswenden kannst und dann mit Rückschlüsse ziehst, ob das auch schlechter oder besser wurde mit den Agents und dass du halt da wie beim Code einfach so ein Lifecycle hast. Das heißt, du kannst dich freuen, es ist nur nur SecOps, DevOps, sondern es gibt auch ContextOps.

Stefan: 33:23

Perfekt. So muss das auch sein. Immer mehr Observability und Operations. Genau.

Benjamin: 33:28

Da sind wir mittlerweile Weile angekommen. Und da würde ich auch Leuten nicht empfehlen, oder generell so ein Learning für mich von der Konferenz oder auch einfach aus den letzten Monaten, schießt euch nicht auf Frameworks ein. Weil da gibt es jetzt auch schon Frameworks für diese ganzen Sachen. Aber da habe ich auch mit vielen geredet, das kann man meistens mit eigenen Boardmitteln machen, auch mit den Agents. Sich einfach interne Tools zum Teil selber bauen und auch nicht zu viel investieren, weil das ändert sich alle drei Monate. Es gibt dann wieder ein neues Framework, wieder neue Tools und spielt sich, also wenn ich überlege, vor einem halben Jahr, Jahr hätte ich ganz anders empfohlen, wie man diesen Workflow zum Beispiel hat, um mit der KI-Software zu entwickeln, wie heute. Und wenn man da schon zu stark in das investiert hat, muss man alles wieder umbauen. Und dann ist man auch schon manchmal an einem Vendor-Login. Das heißt, seid sehr zurückhaltend mit Frameworks. Würde ich nicht empfehlen, zu groß zu investieren. Spiel ein bisschen rum. Aber geht da nicht fullblown in irgendein Framework rein, sondern haltet die Dinge simpel. Sammelt Erfahrung. am Ende der Saison ein bisschen vielleicht wirkt es hensärmelig an manchen Ecken. Ist aber auch okay, weil ich weine, wir sind sehr früh in dieser ganzen, KI-Ära, also Dinge sind einfach unklar.

Stefan: 34:41

Dinge sind unklar, aber umgedreht hilft es ja dann auch, selber ein Verständnis aufzubauen, weil wenn ich verstehe, was dort passiert, dann kann ich auch besser beobachten, oder kann ich besser Rückschlüsse ziehen, was muss ich beobachten, um beurteilen zu können, ist das jetzt gut oder schlecht, was da passiert?

Benjamin: 34:56

Genau. Das ist auf jeden Fall. Security war auch nochmal so ein Thema der Konferenz. Spannend, da sind so gern so gar nicht drauf eingegangen manche. Der von OpenClaw, der hat mir ein bisschen leid getan, der kam nicht drumherum. Der hat sogar das in seinen Talk eingebaut, weil das ja im Inneren richtig gebashed wurde in den letzten Wochen und Monaten, weil die ja unglaublich viele Security-Lücken gefunden haben. Für alle, die OpenClaw nicht kennen, das ist so, wie würde ich denn das nennen? Das ist so ein Personal Agent. Also das kann man sich auf seinem Laptop, auf seinem Rechner, auf seinem, ich glaube, manchmal auf dem Handy auch installieren. Und das ist sein persönlicher Assistent. Also das ist wie Siri, nur noch auf Steroids. Also der kann noch viel mehr. Wenn man den Zugriff auf alles gibt, dann schreibt da auch einen für E-Mails, geht auf irgendwelche Webseiten, kann dir auch irgendwelche Tickets oder Reisen buchen, kann unglaublich viel einfach für dich tun. Aber ich glaube, das ist momentan, so würde ich sagen, das ist für Bastler. Das ist für Leute, die da gerne einfach damit rumspielen.

Stefan: 35:53

Und Leute, die wissen, wie sie diesem OpenClaw Gänzen setzen, dass sie nichts tun, was dich selber in den Ruin treibt versehentlich.

Benjamin: 36:00

Genau. Ich denke, das wird noch bestimmt ein paar Jahre dauern, bestimmt fünf Jahre oder so, bis es so in diesen Massenmarkt kommt, dass das mein Vater einfach drauf hat und der Computer für ihn Dinge macht. Weil das ist immer noch ein bisschen weit entfernt, auch wegen diesen ganzen Security-Problematiken, die es in der KI-Welt einfach noch gibt. Und wir müssen immer noch nach Lösungen suchen. Aber da bin ich auch gespannt.

Stefan: 36:24

Ich meine, gerade mit dem Thema Security kam es letztens auch von... Ich glaube auch von Anthropic, dass sie dieses Mythos-Modell, das neue haben, mit dem sie noch sehr viel besser solche Sicherheitslücken finden können. Kennst du dich damit ein bisschen aus? Ich habe es auch nur so teilweise in der Überschrift und in der kurzen Zusammenfassung verfolgt, aber hast du da irgendwas zu mitbekommen?

Benjamin: 36:48

Also ich meine, ich habe keinen Zugriff auf das Modell. Das heißt, ich habe auch nur Hören und Sagen. Aber was ich so jetzt in der Community wahrgenommen habe, ist, die haben mit älteren Modellen genau die gleichen Sachen gefunden. Security-Experten sind da sehr skeptisch, dass das jetzt so viel besser ist, um Security-Vulnerabilities in Frameworks zu entdecken wie die bisherigen Mittel. Die meisten, die das kritisch betrachten, das ist auch meine Einschätzung, es ist eher ein Marketing-Stunt, dass die damit viel Gesprächsstoff erzeugen. Warum sie das tun, ist alles nur Mutmaßung, ob sie das, weil es viel teurer ist. Also wo sich Leute einig sind, ich habe ja mit dem einen von Google gesprochen, der ja bei Android in dem Security-Bereich war, der nutzt das Model. Der hat mir gesagt, ja, es ist nochmal deutlich besser, aber wahrscheinlich auch teurer. Das hat nochmal einen Sprung gemacht. Aber ich glaube nicht, dass das jetzt so die Security-Welt revolutionieren wird. Und am Ende ist es auch ein Katz-und-Maus-Spiel, weil die Tools haben ja beide Seiten. Das heißt, die Security-Leute, zumindest so Experten, die ich gehört habe, die ich jetzt geäußert habe, die haben gesagt, ja, es gibt sich nichts, weil die werden es nutzen, um sich besser zu schützen, sich zu verteidigen. Die Angreifer werden es nutzen, um mehr Schwachstellen zu finden. Und das wird so ein Hin und Her sein. Aber das ist jetzt schon so. Ich glaube, Mythos wird das Game da nicht ändern. Von daher glaube ich ja, das Modeln ist besser, es kann auch vielleicht ein paar Sachen besser, vielleicht haben sie auch extra auf Security turniert, aber ja es wird jetzt nicht der Game Changer sein ist meine Meinung.

Stefan: 38:19

Mein Eindruck gut, danke für die Einschätzung, das hilft mir, dann habe ich ansonsten noch zwei oder drei Fragen, gucken wir an wie viel ich mich noch erinnern kann Weil du warst mit deinen größeren Themen so weit durch, wenn ich es im Kopf habe und aus deiner Beschreibung habe ich noch zwei, drei Fragen. Die erste ist, du hast zwischendrin erwähnt, dass es schlecht ist, gegen das Training von einer KI zu arbeiten oder dass man da schnell an seine Grenzen kommt. Wie ist denn da der aktuelle Stand, dass man tatsächlich Models hat, die auf den eigenen Daten trainiert sind? Also weil wenn ich mein Model auf meiner Enterprise-Architektur trainieren kann, die schon existiert, dann stelle ich mir vor, müsste das Ergebnis ja besser sein oder?

Benjamin: 38:58

Ja, das Problem ist nur, man braucht dafür sehr Spezialwissen. Man müsste die Leute finden, die sich mit diesen Architekturen auskennen, die dazu führen, dass man diese Modelle trainieren kann. Das ist unglaublich teuer, Modelle zu trainieren. Man braucht die Infrastruktur, die Hardware. Und das kann man nicht überall machen. Wenn man sich das einkauft, ist es auch teuer. Wenn man das irgendein Betreiber hat als Unternehmen, wo man seine IT hat und die haben dann sehr viel Hardware rumliegen, auf der man Modelle gut trainieren kann, okay. Aber man hat auch zum Teil nicht die Datenmengen. Also weil im Vergleich zu was im Internet an Code ist und was jetzt im eigenen Unternehmen ist, es gibt vielleicht Unternehmen mit 200.000 Mitarbeitern, die halt Milliarden von Lines of Cone haben, da ist das vielleicht ein Case, aber wenn du ein kleineres Unternehmen bist oder auch nur 1.000, 2.000 Mitarbeiter hast und auch nicht die riesige Code-Basis, ist natürlich die Frage, wie das funktioniert. Man kann ja auch das bestehende Modell nochmal feintunen mit Training. Das machen auch manche. Das ist die günstigere Variante, wo man dann den eigenen Code nimmt. Aber um ehrlich zu sein, gibt es da jetzt keine großen Studien, die dann beweisen, dass es jetzt besser ist. Selber das Modell zu trieren. Ich glaube, für die meisten Anwender ist es einfach, auch gerade, weil Profic mit Opus nochmal da diesen Sprung gemacht hat, lohnt sich das, glaube ich, weniger. Die sind so gut mittlerweile im Codeschreiben. Weiß ich nicht, ob sich das dann einfach lohnt. Aber ja, kann man versuchen, aber ist ein Edge-Case, würde ich sagen. Also für die meisten Unternehmen lohnt sich das.

Stefan: 40:30

Glaube ich, nicht. Gut, danke. Und dann habe ich als letzten Punkt vielleicht noch so ein bisschen kontrovers, was ich mit rausgehört habe. Okay, Juniors dürfen zum Beispiel bei Amazon keinen KI-Code mehr akzeptieren. Da braucht es einen Senior-Entwickler für. Also der ganze Vibe, den ich aus allem raushöre, ist, die Aufgaben, die herkömmlich Juniorentwickler gemacht haben, die fallen jetzt an die KI. Gab es da auch Bedenken zu, wenn wir jetzt plötzlich keine Juniorentwickler mehr brauchen, wie wir denn dann überhaupt an Seniorentwickler langfristig kommen, wenn die Juniorentwickler nicht mehr eingesetzt werden? Also ist das überhaupt ein Trend? Ist das überhaupt eine Gefahr? Kommt mir das nur so vor?

Benjamin: 41:12

Das wird gerne auf Slides, wurde das erwähnt oder auch in Nebensätzen, dass das ein Thema ist. Aber dafür gibt es jetzt, glaube ich, noch nicht die Lösung. Aber ja, das ist so ein bisschen, was alle verschweigen. Das merkt man ja auch am Arbeitsmarkt, dass es schwieriger ist, glaube ich, für jüngere Leute mit weniger Erfahrung einen Softwareentwicklungsjob zu bekommen, weil der Trend dahingehend bei Unternehmen sehr unsicher sind, weil das gerade so, zumindest kursiert es so auf dem Markt oder in der Branche, dass du keine Juniorenentwickler mehr brauchst, weil du, wenn du einem Senior halt diese Tools gibst, die jetzt immer besser werden. Dass das eigentlich reicht, weil für einen Senior bringt das auch unglaublich viel, der Hebel ist halt deutlich höher bei einem Seniorentwickler mit der KI als bei einem Junior, das ist Fakt, also das kann ich bestätigen. Aber das ist ja auch keine nachhaltige Strategie für ein Unternehmen, weil irgendwann, wenn die Seniors weg sind, was machst du? Oder generell war ja vor ein Jahr, zwei Jahren, haben ganz viele Leute darüber spekuliert, ja, brauchen wir denn immer weniger Entwickler dann? Naja, was man jetzt sieht in den letzten zwei, drei Monaten ist, dass die Unternehmen, also die Big Tech Unternehmen wie Microsoft und Co, sehr viele Leute entlassen haben vor dem Jahr. Diese Layoffs, die da auch vielleicht bekündet waren, dass die auch ein bisschen bloated waren, also dass der Wasserkopf bisschen so groß war, die haben einfach nicht so viele Leute gebraucht. Auf der anderen Seite haben sie festgestellt, diese Versprechen durch die KI kamen jetzt nicht und die stellen wieder ein. Die stellen auch wieder die ganzen Leute, die sie rausgeworfen haben, stellen die wieder ein. Das haben sie jetzt nicht so groß announced, aber es gibt viele Berichte, das kann man selber recherchieren, die werden wieder eingestellt.

Stefan: 42:50

Das heißt, es ist gar nicht so schwarz, wie das Bild manchmal gemalt wird, sondern die Unternehmen sehen auch selber, wir kommen nicht drum rum, wir brauchen auch noch Entwickler.

Benjamin: 42:58

Ja, oder auch so ähnlich, genau, du brauchst einfach selber noch Entwickler, die KI kann Dinge beschleunigen, die kann ein Hebel sein, ich denke, das wird auch mit den Jahren immer besser, weil die Leute immer besser damit lernen, umzugehen, kulturell, organisatorisch, technisch, auf allen Ebenen einfach, wie man das am besten einfach macht und dann kann das auch was bringen, aber das ist noch offen, also ich habe noch mit keinem geredet, der für mich, die Strategie hatte, wo ich gesagt habe, ja, das ist es, wie wir damit umgehen, dass wir jetzt sagen, wie kriegen wir die Juniorenleute trotzdem ausgebildet und enabled, wie kriegen wir das, wie irgendwann Senior werden oder wie machen wir das? Ja, da gibt es so fein Ideen und Ansätze, aber das ist noch ein Weg, den wir rausfinden müssen. Also das wird noch spannend die nächsten Jahre. Aber ich bin mir sicher, man wird da irgendeine Lösung finden.

Stefan: 43:47

Muss man es machen. Dann hast du noch irgendwelche abschließenden, was war so das Wichtigste, was du aus der Konferenz nochmal so mitgenommen hast, so als letzte kleine Zusammenfassung?

Benjamin: 43:59

Softwareentwickler werden weiterhin gebraucht.

Stefan: 44:01

Sehr gut.

Benjamin: 44:02

Halte Tugenden werden wichtiger denn je, wenn man mit KI arbeitet in der Softwareentwicklung, wie Architektur, Patterns, wie man Software gut strukturiert, wie man Code aufbaut. Das kann man nicht der KI überlassen, das muss man sozusagen beibringen, super wichtig. Weiterhin an Relevanz, Das habe ich, glaube ich, schon mal gesagt, aber würde ich immer wieder beim Thema KI betonen. Don't outsource the thinking. Ihr solltet weiterhin nachdenken, das Steuern, die KI führt nur aus. Und das Neueste ist einfach, don't believe the hype. Wertet ein, wer euch was erzählt in dem Kontext, wer hat welches Interesse. Man darf einfach das kritische Denken nicht ablegen, gerade insbesondere bei dem Thema KI. Es kann ein Riesenhebel sein, man kann damit wunderbare Dinge erschaffen, das für sich nutzbar machen. Aber es kann genauso gute Leute und Code-Basen in den Ruin treiben, wenn man es nicht richtig macht. Von daher, ich denke, wenn man die Dinge beherzigt und da mit einem kritischen Verstand draufblickt, dann kann man da ziemlich viel bewegen. Und ich bin sehr gespannt, was ich so in den nächsten ein, zwei Jahren entwickle, weil der Markt ist super volatil. Ich habe auf der Konferenz unglaublich viel gelernt. Ich kann auch jedem empfehlen, auf diese AI-Engineer-Konferenz zu gehen. Die war jetzt vor zwei Wochen das erste Mal in Europa, in London. Ich glaube, die nächste ist in Paris. Das ist eine sehr interessante Konferenz. Schaut es euch mal an. Und ich komme auch gerne immer wieder. Ich glaube, es gibt noch sehr viele spannende Themen zum Thema KI, wo wir darüber reden können.

Stefan: 45:35

Gut, vielen lieben Dank für deine Einsichten. Danke, dass ihr alle zugehört habt, meine lieben Zuhörerinnen und Zuhörer. Und damit verabschieden wir uns und hören uns hoffentlich demnächst wieder mit weiteren KI-Folgen.

Benjamin: 45:48

Danke dir für die Einladung, Stefan. Macht's gut. Ciao.

Stefan: 45:50

Bis dann. Ciao.