# Agentic Coding Enterprise Adoption Strategy

**Podcast:** HMZE
**Published:** 2026-02-11

## Transcript

Die gehen ja eigentlich damit um, dass wir, ich glaube, Nate Jones hat das mal genannt, dass wir ownership without authorship haben.
Also wir haben Ownership über etwas, was produziert wird, was aber nicht wir produziert haben.
Herzlich willkommen zur zweiten Folge unserer neuen Staffel von HMZE Beyond Vibecoding, der Podcast, in dem wir den derzeitigen fundamentalen Change in der Softwareentwicklung intensiv begleiten.
Ich bin Sebastian Heidemeyer zu Erben, CTO bei NorthIO.
Und ich bin André Neubauer, CTPO bei Trusted Shops.
Schön, dass ihr wieder da seid.
In der ersten Folge hat uns ja Stefan Schmidt Einblicke gegeben aus seiner Coaching-Praxis.
Wir halt Organisationen halt begleitet auf deren Weg.
Es hat auch deutlich gemacht, dass bei vielen TechOcs aktuell noch eine ganz schöne Lücke klafft zwischen dem auf der einen Seite so ein bisschen der Hype und auf der Seite die Realität.
Und da wollen wir heute anknüpfen.
Diesmal aber mit jemand, der halt auch Einblick in größere Unternehmen hat.
Genau.
Wir haben heute jemanden zu Gast, der durch seine Consulting-Praxis bei InnoQ tiefe Einblicke in genau diese Unternehmen hat.
Tatsächlich hat er auch verbraten, sogar bis knapp DAX Größe.
Und ich freue mich ganz besonders auf Jörg.
Er ist ein ehemaliger Kollege, war sogar mal mein Chef und hatte schon immer ein tiefes Gespür für was so Trends sind, war immer am Zahn der Zeit und kann insbesondere aus seiner aktuellen Tätigkeit bei NOQ heraus viele coole Impulse geben.
Genau.
Und er teilt so ein bisschen, was er gerade sieht, was sie auch mit dem Training machen, welche Themen die Unternehmen auch haben.
Dadurch kann man auch eigentlich sagen.
Positiver als das, was Stefan letztes Mal gesagt hat.
Also da reden wir drüber.
Und genau, hört rein, wieder ein paar gute Projekte Predictions, geht an der einen Stelle auch ein bisschen tiefer und dementsprechend.
Ja, macht euch bereit für eine spannende Folge.
Viel Spaß beim Hören.
Herzlich willkommen, Jörg.
Ich habe mich schon ganz besonders auf dich gefreut.
Wir kennen uns ja doch schon eine ganze Weile.
Und ich glaube, du hast tatsächlich auch einiges, insbesondere auch vor dem Hintergrund deiner neuen Aufgabe, deiner deiner neuen derzeitigen Tätigkeit sozusagen, die du bei InnoQ auch ausführst, einiges Spannendes zu erzählen.
Stell dich gern unseren Zuhörern einmal kurz vor.
Genau.
Ja, mein Name ist Jörg Müller.
Ich bin bei der Firma InnoQue Principal Consultant.
Es ist eine Rolle, die verschiedene Arten von Beratungen kombiniert mit Business Development und aber eben auch Trainings und ähnlichen Dingen, die wir dort machen.
Neue Rolle ist es gut.
Also es ist eigentlich keine offizielle Rolle, sondern es ist einfach ein Themengebiet.
Es ist tatsächlich so, ich fand mich sehr gefreut, dass ihr mich eingeladen habt, weil wir hatten uns ja tatsächlich ein paar Monate vielleicht nicht mehr getroffen.
Und die letzten, ja, ich sag mal, sechs Monate bei mir beschäftige ich mich in der Tat sehr intensiv mit dem Thema Agentic Software Development.
Das Thema KI begleitet mich in der Tat schon eine ganze Weile in meinem Leben.
Ich habe mal meine Diplomarbeit über neuronale Netze geschrieben.
Ja, ich habe wirklich mich wirklich nicht versprochen, ich habe Diplomarbeit gerade gesagt.
Alter, ne?
Wink-Wing.
Und das hat mich immer mal wieder so auf der Seitenlinie begleitet.
Ich fand es immer interessant, ich habe mich immer versucht, auf dem Laufenden zu halten bei dem Thema, aber selten die Gelegenheit gehabt, mich da wirklich tief und intensiv innerhalb meines Jobs damit auseinanderzusetzen.
Das hat sich jetzt in der letzten Zeit ein wenig geändert, gerade mit dem Thema, wie entwickeln wir damit eigentlich Software.
Und warum hat sich das geändert?
Nur ganz kurz, wir haben ungefähr Mitte des letzten Jahres bei InnoQ angefangen, ja, ich sag mal, Erfahrungen, sofern man das nach der Zeit, die das eigentlich existiert, schon nennen kann, mal zusammenzufassen und ein Trainingsprogramm aufzustellen, was wir den Kunden im Moment anbieten, ja, wie entwickelt man eigentlich mit diesen Agenten Software.
Was extrem gut ankommt, muss ich sagen.
Also es ist, wir haben das, wir machen recht viel Trainingsgeschäfte auch bei InnoQue.
Wir sind es durchaus gewohnt und haben da Erfahrung mit.
Wir haben aber, glaube ich, so einen Bedarf, wie wir dort gesehen haben, haben wir so noch nicht gesehen in der Vergangenheit.
Hat mich nicht.
Wir haben inzwischen fast zehn Leute, die in der Lage sind, dieses Training zu geben.
Und wir kommen kaum mit den Anfragen hinterher.
Also wir haben Schwierigkeiten, Termine zu finden.
Also, das ist schon enorm.
Also, das zeigt zumindest mal, wie sich auch die Industrie dafür gerade interessiert.
Und das ist spannend.
Das ist auf, ja, okay, ich greife schon ein bisschen vor.
Beschreibt auch.
Spannend zu sehen.
Beschreib doch ein bisschen, wie sich das Consulting-Feld vielleicht verändert, da werden wir sicherlich nachher auch noch drauf kommen.
Genau.
Ja, super cool.
Also das ist ja fast eine perfekte Überleitung zu unserem ersten Punkt, wo wir immer fragen, wie du gerade so arbeitest, unseren Gast.
Und wenn du sogar einen Trainingskonzept sozusagen dafür aufgebaut hast, dann bist du wahrscheinlich extrem gut sprachfähig zu sagen, wie du gerade Softwareentwicklungsprojekte angehst, welchen Toolstack du benutzt, auch welche Methoden, worauf du achtest.
Ja, erzähl doch mal gerne.
Ja, also man muss dazu sagen, wie gesagt, in der Rolle, in der ich unterwegs bin, ist das meiste, was ich wirklich selbst entwickle, sind dann eher Dinge, die wir auch selbst nutzen.
Das hat aber in interessanterweise tatsächlich zugenommen.
Weil ich glaube, ihr hattet das auch schon mal, ich habe André den einen oder anderen LinkedIn-Post verfolgt.
Und ich sehe es genauso, dass so die Return on Investment bei Individual-Softwareentwicklung sich gerade ziemlich drastisch verschiebt und das merkt man halt auch bei vielen Dingen, die man so ein Problem löst und was wir halt auch tatsächlich intern immer mal wieder lösen.
Ich glaube, ich habe letztens den Begriff Selfware mal dafür gehört.
Den fand ich ganz zutreffend.
Also so Software, in der man eigentlich nur für sich selbst und für seinen Umfeld schreibt und gar nicht irgendwie anders vertreibt und dir aber relativ schnell entwickelt.
Nicht ganz spannend.
Da arbeite ich persönlich, was so das Tooling betrifft, klar interessiert natürlich erstmal, okay, was nimmst du für einen Agenten zum Softwareentwickler und was für Modelle.
Da bin ich persönlich, kommen sehr gut mit Cloud Code zurecht.
Das ist auch tatsächlich das, was wir im Training verwenden.
Da haben wir uns dafür entschieden, weil wir uns für irgendwas entscheiden mussten.
Das ist jetzt nicht, weil wir sagen, okay, das ist jetzt das tolle Tool und andere Tools können das nicht oder so.
Wir haben gesagt, wir müssen für irgendetwas uns entscheiden.
Cloud Code war ein Trendsetter an der Stelle, ist auch an vielen Stellen immer noch so ein Trendsetter, die führen manche Features halt zwei Wochen früher ein als andere.
Und insofern passt es ganz gut.
Ich komme damit gut zurecht.
Das soll aber keine qualitative Bewertung für die anderen Tools sein, sondern das ist eher mein ganz persönlichen Geschmack an der Stelle.
Es gibt Tools, mit denen werde ich nicht so richtig warm, auch wenn ich mich damit beschäftige.
Ich bin eigentlich total fasziniert von so Sachen wie Open Code und Goose.
Bei Open Code muss ich ehrlich gestehen, ich habe es zwei, dreimal probiert.
Ich komme mit deren Philosophie des Textinterfaces nicht gut zurecht.
Das ist aber wirklich eine reine Geschmacksfrage.
Grundsätzlich bin ich aber ein großer Fan davon, dass wir uns da nicht von den großen Unternehmen abhängig machen, sondern eher auf Open Source-Lösungen setzen.
Ich versuche also immer mal wieder dort auch ein Blick reinzusetzen, was gibt es mit lokalen Modellen, wie kann ich damit arbeiten, wie kann ich das mit diesen Tools integrieren.
Es führt nur leider aktuell noch sehr oft an Grenzen.
Die Frage ist nur, wie lange noch.
Also, ich glaube, dass vieles davon sieht man ja, ist eher in Monaten gerechnet, als in längeren Zeitfristen.
Ansonsten programmiersprachentechnisch bin ich im Moment eher im Python-Lager unterwegs.
Krass.
Weil das so die für die meisten Dinge, die ich mache, die pragmatischere Sprache ist an der Stelle.
Wenn es mal wirklich schnell sein sollte, ist Rust immer noch eine feine Wahl.
Die JWM spielt bei mir ärgerlicherweise gerade nicht so eine große Rolle.
Das hat aber, ja, wie gesagt, ganz viele verschiedene Gründe dessen, was ich da tue.
Und ja, Idee ist, wenn ihr die Frage auch noch stellt, ich experimentiere gerade relativ viel mit Z.
Ich weiß nicht, ob ihr den kennt.
Das ist so ein von den Leuten, die den Atom-Editor ursprünglich mal geschrieben haben, in Rust implementiert, sehr schnell.
Sehr gute VI-Unterstützung, das ist mir immer wichtig.
Ich bin da irgendwann mal am Anfang meiner Karriere versaut worden.
Und ja, ich nutze es, weil ich festgestellt habe, selbst wie es Code, finde ich inzwischen bei der Arbeit mit so Agenten ziemlich, wie soll ich sagen, aufgeblasen.
Weil ich eigentlich das meiste auf dem Terminal mache und die Idee vor allem benutze, um selbst zu reviewen, was da entstanden ist.
Dazu brauche ich die ganzen tollen Features, die das ganze System langsam machen, eigentlich nicht.
Deswegen experimentiere ich gerade in die Richtung.
Eigentlich schon verrückt, wie sich der Weg zurück auf die Shell gebahnt hat.
Ja, das stimmt.
Bürst so kurze volle Abfrage dazu.
Wie gehst du?
Wie geht ihr mit dieser enormen Veränderungsgeschwindigkeit um?
Also du kannst ja einmal LinkedIn auf und dann hast du irgendwie drei neue Projekte, die man eigentlich mal ausprobieren sollte.
Der vorhin mal geschaut, hatte gelesen, hier Getting Shit Done, so als Extension für, was war für was läuft denn das?
Ich glaube, das war auch Claude Code.
Also ich kann mir beim Training vorstellen, das veraltet halt auch schnell.
Das ist tatsächlich schwierig.
Ich kann ja nachher mal ein bisschen was zu dem Training erzählen.
Wir versuchen tatsächlich einige Grundprinzipien auch beizubringen und nicht unbedingt jeden neuesten Trend hinterherzurennen.
Okay.
Und es gibt so ein paar Dinge, die während wir dieses Training schon machen, sich in der Tat verändert haben, wo es neue Tendenzen gibt.
Teilweise gehen wir sogar bewusst darauf ein und sagen, pass auf, wir machen hier manche Dinge mit euch gerade noch per Hand, zeigen euch dann aber auch, wie man das inzwischen schon anders machen kann.
Nur ihr solltet das Prinzip verstanden haben.
Was dahinter steckt.
Das ist so eine Sache.
Ansonsten, ja, ich habe bei InnoQ einen großen Vorteil, eine ganz große Menge von Kollegen zu haben, die sehr interessiert sind und sehr vielseitig interessiert sind.
Und dementsprechend natürlich bei uns in den internen Chatkanälen etc.
sehr, sehr viel Information einfach auch an mir vorbeifließt.
Das ist gut.
Ich für mich persönlich habe auch, das ist aber schon ein bisschen länger, dass ich das so mache, habe, halt eingeführt, dass ich ein, ich sag mal, festes Lernfenster mittlerweile in meine Morgenroutine eingebaut habe, wo ich eine Themenliste habe, die ich mir anschaue und ich setze mich quasi jeden Morgen hin und nehme mir bestimmte Themen vor und versuche dabei am Ball zu bleiben.
Aber das ist schwer.
Also das ist, also die Geschwindigkeit ist gerade wirklich, da wird einem schwindelig.
Ich fand es lustig, ich hatte vor einiger Zeit im Dezember einen Kundenworkshop.
Da hat dann ein Kunde am Ende des Workshops, den wir dort gemacht haben, da ging es eher so um AI-Use Cases und generell, was ist das eigentlich alles?
Und da meinte dann jemand als Feedback.
Er war vor allem überrascht, wie überrascht wir als Consultants von der Entwicklungsgeschwindigkeit sind.
Weil wir schon ja auch ganz offen dort gesagt und haben gesagt, hey, das geht teilweise gerade so schnell, dass wir kaum da hinterherkommen.
Und das fand der Kunde dann irgendwie für sich erschreckend und hat das so als eine Art Wegruf auch für sich gesehen.
Also gesagt habe, wow, also wenn jetzt die Consultants schon sagen, sie kommen da kaum noch hinterher, dann müssen wir da wohl auch mal was tun.
Also eine der Fragen, die ich mir auch persönlich stelle, ist halt, wie viel Zeit, also ich finde spannenden Ansatz.
Also ich versuche auch so ein paar, mir so ein bisschen Freiraum zu schaffen, um Sachen zu verfolgen, aber da das Mittelmaß zu finden, sich nicht zu verzetteln.
Und ich glaube, es ist immer wieder gut, neue Impulse halt irgendwie mit reinzunehmen, aber ich glaube, jedes Mal alles über den Haufen zu schmeißen, weil halt irgendwie die nächsten, die nächste Iteration halt irgendwie ansteht.
Also, ich finde das schwer und was ich auch schwer finde, also vielleicht nicht für heute, aber wie schafft man das auch, dass man eine gewisse Systematik in die Organisation kriegt.
So jetzt mal, du hast halt 50, 60, 100 Software-Engineers.
Wie sorgst du dafür auch eine gewisse Baseline, wenn sich das halt irgendwie so schnell entwickelt?
Wollen ich tatsächlich später nochmal tiefer drauf eingehen, weil ich könnte mir vorstellen, gerade Trainings sind ja ein relevanter Kanal sozusagen, um sowas zu verständigen, aber es reicht sicherlich nicht an sich.
Nichtsdestotrotz, also ich glaube, das fühlt gerade jeder.
Ich habe das Gefühl, auf der einen Seite wären Dinge möglich, die vorher einfach nicht möglich waren, so mal eine eben eine Enterprise-App mit Go-Backend und React Frontend und irgendwie highly scalable.
Baue ich gerade nebenbei, hätte ich nie machen können, weil ich nie so warm geworden bin und React auch noch nie gemacht habe immer Angular und andere Sachen, wie und so.
Das geht aber jetzt, gar kein Problem.
Und trotzdem fühlt sich das wahnsinnig stressig an.
Auf der einen Seite, weil man da ja viel, viel mehr auch, also ein Feature nach dem anderen, Kontext-Switch, immer wieder reingehen.
Und man muss auch wirklich höllisch aufpassen, dass man nichts übersieht.
Deswegen habe ich mich am Anfang auch wirklich schwer getan mit dem Terminal als Interface, weil ich die ganzen Helferlein der IDEs wirklich zu schätzen gelernt habe.
Aber ich habe jetzt auch jemanden gesehen, der einfach das Terminal-Fenster in der IDE ganz groß hat.
Das ist sozusagen das wesentliche Tool, mit dem der arbeitet.
Und drumherum nutzt er dann halt da, wo es sinnvoll ist, das Tooling der IDE, um keine Ahnung, wirklich mal ein File zu ändern oder halt Test-Runs extra zu starten und Code Quality-Metriken oder so zu sehen, ne?
Oder beziehungsweise wenn irgendwo ein Compiler-Error ist, den der, den der Agent manchmal auch übersehen kann, dann hilft die Idee und das fand ich total spannend.
Aber es ist einfach unfassbar stressig, genau, da mitzuhalten.
Wie sieht es denn aus?
Bist du so, guckst du dir an, so Skills und Workflows und so, also wie sich das Tooling der Agenten, das ist ja, kann man ja auch sagen, dass sich das eigentlich horizontal verändert im Sinne von Enthropic startet und dann wird es übernommen, auch von OpenAI, von Open Code, also hier von genau, von den offenen und auch von Google Antigravity und so.
Sieht es da aus?
Ja, ich gucke mir das auf jeden Fall an, klar.
Also müssen wir ja auch, weil im Rahmen der Trainings und so weiter und so fort, da kommen ständig neue Dinge hoch, die du dir anschaust.
Ich würde übrigens, ich würde es nicht ganz unterschreiben, dass sich das Claude immer startet.
Also es ist sehr häufig der Fall, aber es gibt durchaus auch Gegenbeispiele.
Also das Thema Rules zum Beispiel ist jetzt eher aus dem Bereich Cursor in Richtung Claude gewandert.
Die gucken sich da schon auch an, was auf dem Markt passiert und binden das auch ein.
Was jetzt Claude betrifft, habe ich mir in der Tat zur Angewohnheit gemacht, jedes Mal, wenn ich es starte, mal kurz slash Release-Notes aufzurufen und mal zu gucken, was hat sich denn so getan.
Es ist ja auch in der Tat fast schon ein Running Gag.
Okay, Spoiler, Spoiler-Alert für Leute, die das Training mitmachen, aber am ersten Tag prüfen wir natürlich, ist deine Umgebung richtig aufgesetzt, das machen wir mit dem Cloud-V und natürlich sage ich, hey, merkt euch mal die Nummer, mal gucken, wo wir übermorgen rauskommt, denn es ist tatsächlich enorm, wie viele Releases die pro Tag dort machen, teilweise.
Also ich hatte schon so fünf, sechs Point-Releases innerhalb eines Trainings.
Das dauert drei Tage.
Mit teilweise Major Features, die in der Zeit ausgerollt worden sind.
Es ist also in der Tat normal, aber ja, andererseits, ich habe auch vor, vielleicht Sebastian kann sich auch noch daran erinnern, wir haben auch Continuous Delivery-Systeme gehabt, die zehn, 20 Mal am Tag released haben.
Also so überraschend ist das auch nicht.
Es ist nur trotzdem erstaunlich, wie viele Features da teilweise rauskommen und was die da machen.
Aber man muss nicht alle verfolgen, sondern ich glaube tatsächlich ist es wichtig, mal zu schauen, okay, was gibt es so für Megatrends?
Und die so ein bisschen raus extrapolieren und zu schauen, okay, was davon sind jetzt Sachen, die tatsächlich interessant sind, die in neue Richtungen gehen.
Da war im Herbst mit dem Thema Skills war sehr stark dieses Thema Kontextmanagement, beziehungsweise ich habe, ich nenne es immer Lazy Loading.
Also sprich die Art und Weise, wie lade ich eigentlich Dinge in den Kontext rein, nur dann, wenn sie benötigt werden und nicht schon am Anfang, wie man das so Mitte letzten Jahres noch gemacht hat.
Ich finde es mal wieder erstaunlich, wie man da über Entwicklungen in ein paar Monaten redet, aber so ist es.
Also Mitte des Jahres war es noch völlig normal.
Du hast halt deine MCP-Server da verknüpft und dann hast du dir, weiß nicht, ich glaube, der von Atlassian, den finde ich immer faszinierend.
Der hat, glaube ich, 18.000 Tokens in den Kontext geladen.
Also wenn du dann da so ein Systemprompt davor und so eine Anweisung von dir dahinter hast, dann fällt ja fast gar nicht mehr auf, was du eigentlich noch von dem System wolltest.
Und das war ein Thema mit Skills und mit vielen anderen Features, was sich so im Oktober, November ziemlich stark ein Thema war.
Jetzt gerade beobachte ich so seit ein paar, ja, ich sag mal, tatsächlich Wochen so gestartet mit diesem ganzen Thema Ralf-Loop ist so die Frage, wie bekomme ich so ein Agenten eigentlich zum langen Arbeiten.
Also wie schaffe ich es tatsächlich, dass der sehr, sehr komplexe Aufgaben über einen sehr langen Zeitraum macht.
Da hat jetzt Claude gerade wieder seine Tasklisten irgendwie geändert, hat dort Dependencies eingeführt und all solche Dinge.
Also aber das sind so Megatrends.
Ich glaube, das lohnt sich, wenn man mal versucht, so rauszufinden, so welche verschiedenen Themen sind da jetzt gemacht worden, was ist so im Social Media gerade aktuell tatsächlich, ich glaube, viele Dinge, die man, denen man heute folgt, werden über Social Media total verfolgbar.
Einfach mal entspannt abends noch YouTube gucken und dann mal schauen, was da so die großen Stimmen im Markt gerade sagen oder was die großen Blogs sagen.
Und dann kann man so ein Gefühl dafür entwickeln, was ist eigentlich gerade der Trend, ohne dass man jetzt den Hypes hinterherrennt.
Ich glaube, das ist auch schlecht.
Ich glaube auch viele Grundprinzipien sind immer dieselben.
Und die ändern sich auch nicht so schnell.
Und das ist tatsächlich, also auch der Ralph Wigan-Loop oder das Plugin, wie habe ich dann zwei, dreimal bei so YouTubern gesehen, die ich verfolge und dann habe ich es mir auch mal angeguckt und so trennt sich so ein bisschen die Sport von Weizen, wobei es immer noch nicht klar ist, was davon ist jetzt Hype und was davon ist jetzt wirklich wirklich geil.
Also ein Beispiel, so Multi-Agent-Workflows habe ich tatsächlich noch nicht so gut hinbekommen in meinen Projekten zumindest, weil die sich dann doch immer ein bisschen in die Quere kommen.
Und in Antigravity ist es erstaunlich so, dass dann wirklich auch der Agent einem sagt, so, ah ja, hier hat jetzt gab es eine andere Änderung schon wieder in der Zwischenzeit.
Die nehme ich mal mit rein sozusagen und passe meine Änderung daraufhin an.
Aber so hundertprozentig treffsicher ist das auch immer nicht.
Da hatte ich das bisher noch nicht so richtig Erfolg.
Deswegen habe ich es gerade erwähnt, das ist ja nun gerade brandneu und wird wahrscheinlich, wenn die Hälfte der Leute hier den Podcast-Search schon wieder ein alter Hut sein.
Dieses Thema Multi-Agent, lange Loops, etc., das glaube ich, wird so eine der Sachen sein, die wir in den nächsten Monaten erleben werden, wie sich das ändert.
Ich fand, also die Rive-Loope finde ich gar nicht so spannend.
Das ist ein netter Trick mit diesem Stop-Hook da hinten.
Aber interessanter fand ich zwei andere Entwicklungen in dem Zusammenhang.
Das ist einmal das, was Claude gerade macht, dass sie Tasklisten haben, die Dependencies abbilden, die man dann auch in verschiedenen, ich sag mal, Agent-Instanzen parallel benutzen kann.
Das ist ein interessantes Feature, wo darüber nachgedacht wird.
Und das andere tatsächlich erst ein paar Tage her, fand ich es sehr spannend, Simon Wilson hat das, hatte auch ein Interview dazu gemacht mit jemandem von Cursor, der hat einen Browser schreiben lassen von Agenten.
Und das ist sehr, sehr spannend und das tatsächlich auch über mehrere Monate, zwei bis drei Monate.
Ich glaube, er hat im Oktober damit angefangen und jetzt sind sie so weit, dass sie im wesentlichen Webseiten rendern können, etc.
Und da haben die halt bei Cursor wirklich Experimente gemacht, wie man langlaufende Loops und langlaufend bedeutet bei denen teilweise eine Woche lang.
Also wirklich, dass mehrere Agenten eine Woche lang an dem Ding gearbeitet haben ohne Unterbrechung.
Das finde ich schon interessant und bin gespannt, was da an Produkten rausfällt.
Weil das ist jetzt, glaube ich, einfach nur, die experimentieren auch nur, kochen da auch nur mit Wasser.
Aber die lernen natürlich dadurch sehr intensiv.
Ich glaube, das wird sehr interessant zu sehen, was sie da haben.
Also, er spricht ja zum Beispiel von Agenten, die halt Planung machen, von Agenten, die als Worker agieren, etc., also von solchen Unterscheidungen.
Sehr interessant, ich bin sehr gespannt, was da so in den nächsten Wochen und Monaten an der Stelle rauskommt.
Und das ist auch in der Tat der Punkt, langsam der Punkt, wo ich dann sagen muss, da müssen wir dann möglicherweise aufs Training anpassen oder die Arbeitsweise, wie wir so in der Softwareentwicklung überhaupt arbeiten.
Weil das wäre vor einem, selbst vor einem halben Jahr noch nicht wirklich denkbar gewesen.
Und das lernen wir auch momentan noch nicht so, dass man so lang laufende mach mal und ich gucke mal nach einer Woche, wie es was rauskommt, Prozesse haben.
Ja, und dann auch in der Reflexion wieder, wie lang ist, also lang genug.
Also das auf der einen Seite ist natürlich charmant, weil die Grenzkosten relativ niedrig sind.
Auf der anderen Seite hast du halt, sag mal, so Opportunity, also wenn du dir so eine Opportunity halt anschaust, hast du im Zweifelsfall auch eine Woche verloren.
Wenn das dann in die falsche Richtung geht.
Das ist genau ganz andere Themen dann nochmal, die man berücksichtigen muss.
Ich habe auch gerade an die Kosten gedacht.
Und ich glaube tatsächlich, wenn man alles hineinfaktoriert, dann ist es schon auch teuer, so ein Agent-Network eine Woche laufen zu lassen.
Weil am Ende, was Enthropic und Co.
gerade machen, ist, die subventionieren ja gerade massiv.
Das alle guckt sind.
Und am Ende dann sagen sie, okay, und jetzt berechnen wir euch mal wirklich, was es kostet und machen noch eine Marge obendrauf.
Das wird richtig teuer, dann wird auch Open Source wieder relevant, aber auch Open Source.
Ich meine, es gibt noch keine gute Hardware, wo du sagen kannst, ja, du kannst irgendwie vier Mac Minis zusammen schließen als Cluster und dann darauf irgendwie kleinere Models laufen lassen.
Aber das wird längst nicht, Jörg, du hast es ja vorhin schon gesagt, an die Qualität von so einem wirklich State-of-the-art-Model von einem von einem Foundation-Lab sozusagen rankommen.
Oder Frontier Lab.
Ja, von daher, das wird auch noch spannend werden.
Aber am Ende aktuell, schon gesagt, wir sind gerade wirklich in der Experimentierphase und auch das wird, da wird sich auch wieder Open Source herauskristallieren und es wird sich auch herauskristallisieren, dass man nicht unbedingt ein gigantisches Large Language Model braucht, was dann irgendwie, keine Ahnung, mehrere hundert Gigabyte RAM braucht, um irgendwie im Speicher gehalten zu werden und noch Kontextlengt mitgeben zu können, sondern eine Nummer kleiner wird es wahrscheinlich dann auch tun für viele Use Cases.
Also tatsächlich bin ich der festen Überzeugung davon, dass diese ganze Art und Weise der Softwareentwicklung denselben Weg gehen wird, wie sie eigentlich fast alle Infrastruktur gegangen ist, die wir kennen.
Wenn man jetzt Linux sich anschaut, wenn man die meisten Programmiersprachen sich anschaut, etc.
Es wird irgendwann in Richtung Open Source gehen.
Und das wird Commodity.
Die Modelle werden besser.
Also, wenn man sich genau damit beschäftigt oder auch tatsächlich mal mit lokalen Modellen spielt, ist es überraschend, was die Modelle teilweise sogar an Performance-Verbesserungen innerhalb eines Jahres gesehen haben.
Einfach nur wegen, ich sag mal, schlauerer Architekturen, Mixture of Experts und verschiedenen anderen Mechanismen.
Also auf derselben Hardware, ich probiere hier auf meinem eigenen Rechner, habe ich mit Modellen in einer ähnlichen Größenordnung heute teilweise das Drei- oder Vierfache an Token pro Sekunde, was ich vor einem Jahr mit ähnlich großen Modellen hatte.
Ja, also mit so 20 Milliarden Parameter-Modellen.
Und das ist schon erstaunlich, A, was sich da entwickelt.
B, Hardware entwickelt sich weiter.
Also das ist nur eine Frage von maximal wenigen Jahren, dass wir sehen werden, dass solche Mechanismen auch mit Open Source, mit OpenWaid, muss man einfach ein bisschen unterscheiden, mit OpenWate-Modellen funktionieren und wir damit arbeiten können.
Damit soll man auf jeden Fall rechnen.
Also diese großen Konzerne, die wir da gerade vorne sehen, die werden versuchen, sehr lange sehr weit vorne zu sein und neue Features zu bilden und vielleicht wird ihnen das auch gelingen.
Ich kann mir langsam fast nicht mehr vorstellen, was sie noch machen wollen an der Stelle, aber am Ende, glaube ich, werden wir auch dort im Open Source-Bereich landen.
Ja.
Erstmal müssen allerdings RAM und SSDs und so wieder preiswerter werden.
Allein, glaube ich, da zu dem Thema können wir wahrscheinlich eine separate Folge machen.
Ich bin da bei dir, Jörg, probier da auch viel.
Ich sehe auch immer wieder LinkedIn-Posts, wo quasi wirklich das, also quasi im Endeffekt Cloud-Code mit anderen Modellen quasi genutzt wird.
Mich würde die Qualität dahinter tatsächlich interessieren, aber ich glaube auch, es ist eine Frage der Zeit.
Fairerweise allerdings nicht ganz zu den Ausgaben auf der quasi Cloud-Infrastrukturseite.
Also das, was man so an Data Center-Kapazitäten braucht, da könnte man natürlich argumentieren, es gibt genug andere Use Cases, aber die Kapazitäten, die da gebaut werden, sind schon gigantisch.
Wobei ich das tatsächlich, also das halte ich tatsächlich auch für eine Fehlentwicklung.
Also ich bin einerseits, glaube ich, dass wir sehr viele, ich sag mal, Veränderungen, positive Entwicklungen durch dieses geamte Gen AI sehen.
Andererseits glaube ich, dass da gerade auch an einigen Ecken massiv übertrieben wird.
Und ich fürchte, dass durch viele dieser Rechenzentren, die da gerade gebaut werden, in fünf bis zehn Jahren ziemlich viel Staub wählen wird.
Ja, es ist so ein bisschen so eine philosophische Frage, beziehungsweise eigentlich eine große Wette.
Sehen wir AGI und insofern eigentlich ein Modell oder eine wie auch immer geartete Lösung-Suite von Large Language Models und anderen Architekturen, die einfach quasi jeden Knowledge-Worker-Job machen können, dann wird es extrem viel Rechenpower brauchen und wird auch sehr nachgefragt sein wahrscheinlich.
Wenn wir das aber nicht sehen, dann kommt es genau so, wie du sagst, Jörg.
Und am Ende ist für mich, muss ich gestehen, da die Messe noch nicht gesungen.
Ich bin auf der einen Seite, sagen wir mal, wird es wie immer kommen bei so technologischen Veränderungen.
Also, ich glaube, es wird, dass wir der Change ist da, der wird fundamental und das wird sich wahnsinnig viel verändern.
Das ist, glaube ich, uns klar.
Die Frage ist, inwiefern ändern sich die Jobs dadurch und inwiefern wird die Zusammenarbeit zwischen Menschen und AIs sozusagen später aussehen.
Das kann irgendwie noch keiner so richtig predicken.
Ja, genau, werden Sie sehen.
Ohne das jetzt in die Richtung auswenden zu wollen, ich bin ein bisschen auf der Seite von Jan Lacun.
Ich halte auch LLMs nicht für den Weg zum AGI.
Das halte ich für völlig übertriebenes Marketing.
Sie sind super nutzbringende Werkzeuge.
Es ist auch total faszinierend, wie die Dinger funktionieren.
Also zum Thema, mit was beschäftige ich mich sonst noch.
Tatsächlich lese ich gerade ein sehr spannendes Buch und versuche mich da auch ein bisschen am Praktischen probieren.
Das heißt Building LLM from Scratch.
So von Sebastian Raschka.
Das finde ich tatsächlich sehr spannend, das Buch.
Und hilft mir übrigens auch nebenher bei den Trainings, die wir machen und so.
Also ich habe, also ich lege tatsächlich, also wir legen Wert darauf, dass wir, wenn wir den Leuten versuchen beizubringen, wie sie mit diesen Systemen umgehen, dass sie auch in etwa verstehen, was diese Systeme eigentlich tun.
Also was ist ein LLM und wie funktioniert es.
Weil wir sind in der Situation, dass wir auch verstehen müssen, wie lenken wir das, was da an Ergebnissen rauskommt.
Und das zu können, muss man auch verstanden haben, wie diese LLMs eigentlich funktionieren.
Weil da gibt es unglaublich viele Missverständnisse da draußen.
Also, was ich schon so mit Leuten unterhalten habe und gehört habe, was sie denken, wie sowas funktioniert, weil ich so, huuh, das ist leider nicht richtig.
Und dann wird es halt auch schwierig, das zu steuern.
Eine gute Buchempfehlung müssen wir gleich mal irgendwie für, vielleicht auch noch irgendwie besonders das besonders hervorheben.
Ich habe mal auch von einer ganzen Zeit lang ein Tutorial nachgemacht.
Ich bin ja tendenziell, also ich muss das ausprobieren.
Kann ich aber, ich bin komplett bei dir.
Es macht halt einen Riesenunterschied und ich würde sagen, trotzdem kratzt man nur in der Oberfläche.
Also es ist bei Weitem nicht, dass man dann irgendwie ein Skillset hat, um weiß ich nicht, bei OpenAI einzuheuern oder so.
Aber es hilft halt grundsätzlich zu verstehen, welche Mechanismen greifen und also das, wie soll ich sagen, also quasi, was Weights halt irgendwie für einen Einfluss halt auf solche Modelle haben, quasi wie weit halt ein Kontext relevant ist und wie wann halt auch nicht mehr.
Hattest ja vorhin schon mit Jira, das Gira im Atlasin MCP genannt.
Finde ich auch nochmal ein, glaube ich, ein gutes Nugget für die Leute, die zuhören.
Zusammenhang kann ich auch nur die Videos von André Carpati dazu hervorheben.
Die am Anfang hat ja auch hier der Olfram Alpha-Gründer, der hat ja auch viel gemacht und da erklärt, was ich auch super spannend fand und da auch viel gelernt habe.
Genau, aber André Capati, der halt wirklich eine Coding-Session macht und einfach da in Python so ein Mini-LLM quasi baut, was dann Shakespeare irgendwie rezitieren kann.
Das war schon extrem, oder nicht rezitieren, aber basierend auf Shakespeares Werken war extrem spannend.
Ja, das Buch geht in eine ähnliche Richtung.
Also, weil das Buch versucht, das da auch tatsächlich, also es gibt den Quellcode dazu, man schreibt es im Prinzip auch selbst.
Wobei ich immer ein bisschen anders arbeiten muss.
Ich muss erstmal das gesamte Bild kriegen und fange dann an, das zu schreiben.
Ich brauche da mal zwei Deutsch-Durchläufe für.
Ja, das geht mir tatsächlich auch so.
Ich will schon so ein grobe, eine grobe Idee von dem Gesamtsystem haben, um dann in die Details reinzuschauen.
Tatsächlich, ja, genau, kann ich genau vollziehen.
Genau, wir müssen vielleicht andere mal so Shownotemanagement machen, dass wir das alles in die Shownotes packen, aber kriegen wir irgendwie hin für unsere Zuhörer.
Genau, ich würde langsam mal zum zweiten Teil sozusagen in unserem Podcast-Format kommen, nämlich zum Hauptteil sozusagen, wo wir darüber sprechen, oder gerade heute auch mit dir darüber sprechen wollen, wie dein Einblick in die Organisationen so ist.
Also was, wo siehst du die Organisation stehen.
Stefan hat beim letzten Mal schon angedeutet, Spoiler, bitte alle nochmal hören, wenn wer es noch nicht gehört hat, aber dass viele Organisationen da wirklich strugglen und das ist auch gar kein Wunder, weil einfach die Änderungsgeschwindigkeit so groß ist, du hast es vorhin beschrieben, früher hat man noch einfach alles reingeladen, da Kontextmanagement war da noch gar kein Thema.
Heute ist Kontextmanagement irgendwie alles.
Das wird sich wahrscheinlich auch wieder ändern, wenn die LLMs dieses Needle in der Haystack-Problem lösen und irgendwann einen Kontext-Window von einer Million oder mehr haben, dann ändert sich das möglicherweise auch.
Aber zurück zur Hauptfrage, genau, wie ist denn so dein Einblick sowohl aus der Trainingspractice, die du so wahrnimmst, aber auch aus dem Consulting oder auch, wo ihr wirklich entwickelt mit und bei Firmen, genau, wie siehst du die Firmen da?
Keine Namen nennen denn nur so allgemein.
Ja, ja, ja.
Also man muss klar dazu sagen, oder ich muss einschränkend dazu sagen, dass die meisten Firmen, mit denen ich da gerade zu tun habe, natürlich auf uns zukommen, weil sie entweder Trainings wollen oder Workshops an dem Bereich.
Das heißt, die sind natürlich dem schon mal positiv entgegen.
Also die sind dem schon irgendwie anders positiv ausgerichtet.
Wenn ich aus der Gesamtsicht all unserer Projekte gucke, dann sieht es sicherlich auch nochmal ein bisschen anders aus, aber da habe ich auch nicht in jedes Projekt jetzt Einblick.
Also InnoQ hat, ich weiß nicht, wie viele Projekte wir parallel haben tatsächlich.
Das kann ich jetzt gerade gar nicht genau sagen, würde ich vielleicht auch nicht sagen wollen.
Aber es sind auf jeden Fall mehr, als ich jetzt alle im Kopf habe.
Und insofern da wiederum, allerdings bei den Kunden, die da wirklich auf mich zukommen, habe ich, glaube ich, einen recht guten Einblick, weil auch gerade bei sowas wie Trainings machen wir natürlich am Anfang immer eine Abfrage, hey, wo stehst du denn gerade, was machst du gerade, womit beschäftigst du dich und so weiter und so fort.
Insofern kann ich da relativ gut drauf eingehen.
Das meiste sind natürlich Entwickler.
Wir haben überraschenderweise übrigens sehr viele Product Owner auch bei uns in den Trainings sitzen.
Das ist spannend, die interessanterweise auch relativ gut mitkommen.
Auch das ist so, ist so ein Thema.
Und die meisten, also was ich, was ich sagen kann, ist, ich sag mal so Grundwissen darüber, wie bediene ich ein Chatbot oder wie mache ich Bildgenerierung und so.
Das ist komplettes Grundwissen, das hat jeder.
Also, das ist überhaupt nichts, was irgendwie überraschend ist.
Die meisten haben auch schon im Alltag, ich sag mal, das, was wir, was ich immer gerne so das Assistant-Level von Code-Entwicklung nenne.
Also sprich, entweder arbeite ich mit dem Chatbot und lass mir an bestimmten Stellen helfen oder ich kriege Code-Completion von einem Chatbot etc.
Also so das, was wir, was so State of the Art 2023, 2024 war, ist tatsächlich auch mittlerweile fast überall angekommen.
Und wird auch eingesetzt.
Also, das ist Alltag.
Also, zumindest bei den, wie gesagt, positiv biased Kunden.
Biasedon ist, glaube ich, kein wirklich gutes deutsches Wort, aber also bei den Kunden, die diesen Bias haben, ist das da.
Das agentische Entwickeln, das, was wir halt, ich sag mal, man zitiert ja immer Claude als Anfang, stimmt ja gar nicht.
Also, Cursor hat das ja auch schon Ende 2024 relativ gut gekonnt.
Natürlich noch auf einem nicht so komplizierten Level, aber da ging das ja eher schon los.
Dieses agentische Level ist eher noch nicht so weit verbreitet.
Da haben die meisten erst so maximal private Erfahrungen, manche haben es auch überhaupt noch nicht gesehen.
Wirklich sich intensiv damit auseinanderzusetzen, wie, wie nutze ich das in meinem Alltag, wie organisiere ich ein größeres Projekt damit.
Da sind zumindest die Leute, die wir im Training haben, eher selten da.
Eher selten.
Auch da muss man wieder Unterschiede machen.
Also wir haben auch Firmen, teilweise Firmen, die die Trainings jetzt schon mehrfach gemacht haben oder die sich schon länger damit beschäftigen, bei denen wir manchmal gucken und sagen, wow, was baut ihr denn da für tolle Sachen?
Das ist ja nett.
Also die haben wir teilweise so auch noch nicht gebaut.
Das ist unterschiedlich, aber das ist eher die Ausnahme.
Übrigens scheint es in anderen Ländern da schon ein bisschen weiter zu sein.
Ich hatte mich mit einer oder zwei Leuten, ich glaube, ich weiß gar nicht, ich glaube zwar der Entwickler Summit in Berlin im Herbst unterhalten, die sich auch mit Startups vom Silicon Valley beschäftigt haben.
Da war die einheitliche Aussage, die machen das alles nur noch mit Cloud Code.
Also es zu vermuten, kann ich zumindest von den Kunden, die jetzt da gerade bei uns sind, so jetzt erstmal noch nicht bestätigen.
Da bin ich aber, muss ich gestehen, auch immer ein bisschen skeptisch, weil ich glaube, der Bubble-Faktor ist da nicht zu unterschätzen.
Wenn man so Leute hat im eigenen Umkreis, die das super intensiv nutzen, dann auch Creator dazu konsumiert, sozusagen, kann sich da auch ein Eindruck erschließen, der nicht ganz der Realität entspricht.
Auch wenn ich glaube, dass es im Silicon Valley natürlich viel, viel immanenter ist, auch einfach weil die ganzen Firmen da sitzen so.
Deswegen, du kommst da gar nicht drum rum, dass du dich damit tiefer auseinandersetzt.
Ich glaube, und auch da muss man ganz deutlich übrigens sagen, das habe ich kürzlich mal in einem Podcast von einem Bekannten tatsächlich gelernt, der so als Product Owner Coach unterwegs ist oder war, auch in den USA für mehrere Jahre, der auch ganz klar sagte, es gibt das Silicon Valley und es gibt auch den Rest der USA.
Und der Rest der USA ist, zumindest war das, das war jetzt seine Sichtweise auf das Thema Product Ownership und wie man damit umgeht, wie man, wie man halt Product Management macht, ist da kaum zu unterscheiden von dem, was wir in Deutschland kennen.
Es ist wirklich nur diese eine Bubble dort in San Francisco, die anders tickt.
Auch da hast du die Adoption-Curve.
Und quasi Silicon Valley ist dann, sind dann die First Mover und quasi im Rest der USA ist ja dann halt auch die Normalverteilung, wie wir sie halt auch haben.
Genau, genau.
Ja, also das ist so ein bisschen der Stand zu dem, was ich so beobachten kann, wo stehen die meisten Leute.
Ist doch positiver als das, was Stefan, glaube ich, auch so geteilt hat.
Würde ich jetzt sagen.
Muss man natürlich sagen, Jörg hat ja die Einschränkung gemacht, dass es primär die Kunden bezieht, die auf sie zukommen bezüglich Trainings, was das Thema angeht.
Das heißt, die sind schon mal wahrscheinlich offener als der Durchschnitt, könnte ich mir vorstellen.
Das stimmt.
Auch die Teams, die wir im Moment trainieren, sind natürlich meistens eher die Teams, die da an der Speerspitze stehen.
Auch das muss man sagen.
Also, das sind oftmals sehr häufig übrigens überraschenderweise oftmals Plattform-Teams.
Also, es gibt in vielen Unternehmen so diese typischen Plattform-Teams, die beschäftigen sich gerade sehr intensiv mit dem Thema.
Das habe ich also in mehreren Fällen gehabt, war auffällig.
Und ja, also das sind schon Leute, die in den Unternehmen auch nochmal relativ weit vorne mit dabei sind, die wir dort haben.
Insofern, den Bias muss man ganz klar sehen.
Aber trotzdem, es ist jetzt, also ist es nicht so, dass man jetzt sagen könnte, ach naja, die schlafen alle und niemand macht da was in die Richtung.
Also das würde ich auf gar keinen Fall behaupten.
Sondern es wird sich sehr intensiv damit beschäftigt.
Und du musst, glaube ich, auch mit den Leuten starten, die da Lust drauf haben.
Ja, klar.
Ich glaube, du kannst, du solltest nicht quasi damit starten, die Leute davon zu überzeugen, die irgendwie da ganz große Bedenken haben.
Du musst mit denen, also du musst quasi diesen, für mich ist es mal so ein Gummiband, das musst du halt irgendwie ziehen und dann zieht es halt irgendwie den ganzen Rest halt, also die restliche Organisation halt irgendwie mit.
Deswegen, ja.
Aber ich würde sagen, ihr habt, also ja, bei euch melden sich Leute, die grundsätzlich Interesse haben.
Das stimmt.
Ich würde aber auch sagen, ihr habt wahrscheinlich trotzdem einen guten Querschnitt der Tech-Firme in Deutschland.
Also nicht nur Startups, sondern wahrscheinlich auch nicht nur Mittelstand, sondern auch bestimmt große Unternehmen dabei, wo man es von außen nicht vermuten würde.
Ja.
Also gerade letzte Woche habe ich ein Training bei einem sehr großen Unternehmen gehalten.
Also, das war kein, ich weiß gar nicht, sind die im DAX und weiß ich nicht, im Namen will ich jetzt nicht sagen, aber wenn, dann sind sie höchstens kurz unter DAX.
Genau, das wäre tatsächlich meine nächste Frage gewesen.
Das heißt, also ihr habt wirklich einen Einblick in eine relativ große Bandbreite, wahrscheinlich weniger Startups, könnte ich mal vermuten, oder würde ich vermuten, ne?
Ja, tatsächlich, also wir haben ein paar kleinere Startups und Firmen, mit denen wir zusammenarbeiten, aber das ist eher nicht unsere typische Zielgruppe, das stimmt.
Meistens sind es dann eher die Scale-Ups, die dann eher mit uns zusammenarbeiten.
Und ich sag mal so unsere Kernkundengruppe bei NOQ sind eher so die großen Mittelständler, Hidden Champions, die man so typischerweise kennt.
Oder nicht kennt.
Deswegen sind sie ja hidden.
Das ist immer wieder ganz faszinierend, was ich da so für Firmen kennenlerne, die wirklich auch Weltmarktführer sind und beeindruckende Produkte haben, von denen du noch nie was gehört hast.
Berühmte deutsche Mittelstand.
Ja, ja, also da gibt es schon tolle Firmen und das ist eher so das Typische.
Wir sind nicht ganz so stark vertreten in so den ganz großen deutschen Unternehmen, weil dazu sind wir einfach auch zu klein.
Weil da gibt es halt gewisse Anforderungen zum Thema, wie groß, welche Teams und wie viele Leute wollen wir da gerade haben und da gibt es Rahmenverträge mit dem Einkauf, der natürlich nur mit Unternehmen zusammenarbeitet, die mindestens 2000 Mitarbeiter haben oder ähnliche Dinge und dann sind nicht ganz erfüllt.
Da hilft es nichts, wenn wir viel Know-how mitbringen, weil wir passen in andere Filter nicht rein.
Ja, das ist, könnte ich mir vorstellen, auch, also kommt mit ganz eigenen Herausforderungen, in so ganz großen Firmen zu arbeiten.
Und ja, da, ja, egal, will ich jetzt gar nicht werten.
Ja, aber super spannend und vor allem, also und in der Form rundet es insofern auch das Bild ab, was wir in der letzten Episode mit Stefan sozusagen schon mal gezeichnet haben, wo er eher Einblicke hatte in sehr kleine Firmen.
Was ich da auch nochmal spannend fand, er hat ganz viel auf den Product Engineer oder Creator abgestellt, ne?
Und Plattform-Teams, und das ist genau ein Thema, mit dem ich mich auch gerade beschäftige, sind ja naturgemäß ein bisschen weiter weg vom Product oder vom User, als als die vom Business.
Frontend Entwickler.
Genau.
Von daher finde ich das total spannend.
Also hast du da irgendwie so Patterns, wo du sagst, irgendwie, da siehst du den, oder warum die sich denen besonders öffnen oder oder haben die einen bestimmten Need oder sind es einfach Leute, die generell Juicy Challenges mögen und sehen, da passiert gerade was und die sind einfach super interessiert.
Wie gesagt, das ist ja nur ein Teil der Beobachtung in der Tat.
Also wir haben auch, wie ich schon auch reinbrachte, das Thema Product Owner da häufig mit dabei.
Die, obwohl wir wirklich richtige Software entwickeln, oftmals relativ problemlos durchs gesamte Training durchkommen.
Das fand ich auch faszinierend.
Übrigens auch andersrum gedreht, viele Entwickler, die bei uns im Training sitzen und sagen, boah, wir werden ja jetzt Product Owner, die brauchen wir ja gar nicht mehr.
Was sicherlich gerade auch was damit zu tun hat, dass wir uns den ersten Tag sehr viel damit beschäftigen, wie man eigentlich Requirements richtig aufbaut und dokumentiert und macht und tut.
Wir müssen immer reinschieben, dass wir also in unseren Trainings, ihr werdet vielleicht enttäuscht sein, aber am ersten Tag werdet ihr noch kein Code entwickeln.
Sondern wir werden uns erstmal mit all dem anderen drumherum beschäftigen.
Und insofern, da kommen natürlich Product Owner ganz gut mit.
Warum die Plattformteams dort irgendwie einen relativ hohen Anteil haben, ich glaube, das hat was mit zwei Dingen zu tun.
Erstens tatsächlich sind es oft Leute, die sich durchaus einerseits sich mit Dingen beschäftigen, die allen anderen helfen, dabei Software zu entwickeln.
Und letzten Endes ist das ja genau das.
Also wir schaffen es jetzt, bestimmte Constraints, die wir hatten, in der Softwareentwicklung zu verbessern, schneller zu entwickeln.
Das ist letzten Endes genau das, was du auch bei Developer-Plattformen etc.
versuchst zu tun.
Und deswegen sind das wahrscheinlich die Leute, die sich offen, die oft den Auftrag auch kriegen, sich damit zu beschäftigen.
Irgendjemand im Management hat festgestellt, oh, ich habe von meinem guten Kollegen gehört, dass man damit schneller Software entwickeln kann und beschäftigt euch doch mal damit und macht mal ein Angebot in den Rest des Unternehmens damit zu arbeiten.
Ich glaube, der Weg, den habe ich zumindest jetzt nicht nur einmal so gesehen.
Als Multiplikator sozusagen läuft als Multiplikator.
Also Plattformteams, die dann eigentlich gar im Sinne von Team-Topologies gar keine Plattformteams mehr sind, sondern eher Enabling-Teams.
Enabling, aber diese Rolle des Enabling-Teams kommt oftmals aus der Richtung oder habe ich mehrfach jetzt schon gesehen aus der Richtung von den Teams, die sich halt mit diesem Thema Developer-Plattformen beschäftigen.
Spannend.
Ja, interessant.
Du meintest zwei Punkte.
Waren das schon beide oder oder hast du den zweiten jetzt geflissen?
Ja, macht nichts.
Ich habe ja auch dazwischen geguckt.
Cool.
Und wenn du jetzt so drauf guckst, wie die danach rausgehen, also ihr habt ja auch, du hast ja auch gesagt, die haben teilweise auch, die Firmen machen mehrere Trainings bei euch.
Merkst du dann da tatsächlich so ein Trend, der in Gang gesetzt ist?
Oder beziehungsweise vielleicht auch immer andersrum gefragt.
Ist das der richtige Hook sozusagen, um die Organisation in die Richtung zu entwickeln oder ein wichtiges Tool im Werkzeugkasten?
Gibt es noch andere Tools, um wirklich dich Organisationen an die Systeme annähern zu lassen und da wirklich substantive Fortschritte zu machen?
Substanzielle, sorry.
Also das Training ist natürlich immer nur ein Startpunkt.
Das ist klar.
Also das ist für uns oftmals auch der erste Kontakt, mit dem wir so mit manchen Unternehmen in Kontakt kommen.
Natürlich, wir werden ein schlechtes Consulting unternehmen, wenn wir nicht auch Beratungen danach anbieten würden.
Das tun wir natürlich auch und das machen wir auch bei dem einen oder anderen Kunden, dass wir, ich sag mal, dann eher on-the-job-Coaching machen.
Ja, wo wir tatsächlich auch mit den Kunden gemeinsam reingehen und uns in die Teams setzen und versuchen, dort dann in den Alltag, in die richtigen, in die realen Produkte, nicht in das synthetische Beispiel, was wir im Training bringen, quasi wirklich dort dann die Probleme zu lösen und dort dann diese Art der Arbeitsweise zu etablieren.
Und da kommen ja dann auch erst die richtigen Probleme hoch.
Also wir haben ein konstruiertes Beispiel, das ist klar.
Da gibt es Quellcode, den man durchgehen kann, man hat Requirements, wir haben teilweise Checkpoints in unserem Code-Repository, die man dann, wo man dann wieder aufsetzen kann, sollte sich das LLM doch mal verirrt haben.
Es ist eine Neuentwicklung in dem Sinne und in der Realität hast du aber sehr häufig eher die Brownfield-Situation, wie gehst du dann damit eigentlich um?
Das heißt, wie bringst du diese Art der Arbeit in vorhandene Projekte ein?
Was musst du dafür aufsetzen?
Das sind alles nochmal ganz andere Fragen, die man dann stellt.
Und die teilweise die Teams da machen, aber da muss man auch ganz ehrlich sagen, das sind alles Dinge, die da reden wir über, da kann ich nicht über elendig lange Erfahrung berichten, sondern das sind maximal Monate, wo wir sowas jetzt schon bei bestimmten Kunden gemacht haben.
Und natürlich machen wir es teilweise auch bei den Projekten, wo wir schon länger drin sind und wo es geht.
Wo muss man ganz klar sagen, wir sind natürlich als Consulting-Firma in einer Situation, wo auch der Einsatz von solchen Werkzeugen sehr stark vom Kunden abhängt.
Sehr stark von den Anforderungen des Kunden, von den rechtlichen Rahmenbedingungen, von dem, wo er ist, ne?
Du wirst, es gibt Unternehmen, da kannst du problemlos die Software-Entwicklung mit Cloud machen.
Es gibt eine Menge Unternehmen, die sagen, um Gottes Willen, ne?
Also, wenn du jetzt in der Gesundheitsbranche unterwegs bist, da gibt es interessante Implikationen.
Da kann schon das Weitergeben einer Information an so einen Chatbot zu einer später regulierungsrelevanten Veröffentlichung interpretiert werden.
Das ist also, habe ich kürzlich gelernt, weil ich auch etwas buff.
Also solche Dinge da schon eine Rolle spielen können und sehr oft musst da Legal auch mitspielen.
Super, super spannendes Thema.
Also hast du da, sagen wir mal, Einblick, wie derartig in Compliance oder Regulation, so sagen wir mal, eingebettete Firmen damit umgehen?
Also die sind ja nicht so frei in der Art und Weise, welche Tools, beziehungsweise auch wofür sie diese Tools einsetzen können.
Also kristallisiert sich da was raus, haben sie dann eigene LLMs oder gibt es da Anbieter, die dann datenschutzkonform, hundertprozentig sind oder es gibt, es gibt definitiv Unternehmen, die sich damit auseinandersetzen und damit beschäftigen.
Und ich glaube, das ist der Hauptpunkt gerade.
Es gibt einige Leute, die sagen, also bestimmte Dinge können hier einfach so nicht übertragen werden.
Wir können unseren Quellcode, der jetzt uns zu wichtig, den können wir nicht regelmäßig nach Kalifornien übertragen oder wo auch immer das da passiert.
Und da ist ein hohes Interesse an lokalen Modellen.
Leider, also sagen wir mal, das Firmen, es gibt tatsächlich Firmen, ich kenne Firmen, die stellen sich auch entsprechend komplexe Grafikkarten in den Keller und lassen dort lokale Modelle laufen.
Weniger, aber es gibt einige, die das machen.
Es gibt andere, die versuchen, das gerade mit, ich sag mal, eher so deutschen Rechenzentrumsanbietern etc.
zu machen.
Also da gibt es auch eine Tendenz, die Angebote sind da leider noch ein bisschen dünn.
Also wenn da draußen jemand zuhört, der bei einem der großen deutschen Cloud-Anbieter arbeitet.
Herr Joh hat da schon was.
Da darf gerne noch mehr gemacht werden.
Ja, Johannis hat da schon was, aber nicht spezifisch für Coding tatsächlich.
Ja, genau, genau.
Also das ist halt, klar kann man, also man kann halt so ein Modell dort betreiben und kann da mit Open Code sich drauf verlinken und kann dann das dort nutzen.
Wir haben sowas auch schon intern probiert.
Es ist aber tatsächlich auch nicht so einfach.
Man braucht schon eine Menge Hardware, um auch gerade eine größere Menge von Entwicklern zu versorgen.
Und ja, diese Hardware ist ja teilweise auch unverschämt teuer.
Deswegen ja, einerseits kann man sich darüber beschweren, was eben so ein Modell wie Cloud Code kostet, speziell, wenn man es über die API, also nicht das Modell, das ist ja nicht Cloud Code, sondern Opus, über Sonnet.
Speziell, wenn man dort die API benutzt, sind das ja Wahnsinnspreise, die da aufgerufen werden.
Aber andererseits die eigene Hardware ist noch viel, viel teurer, leider aktuell.
Aber ich nehme für mich in der Summe mit, dass das eher ein Tooling, Infrastruktur, also eher harte Fakten sind, als halt Mindset, was, also klar, ist jetzt wieder der Ausschnitt.
Also wenn man sich mit, wenn man sich an euch wendet, ist man zumindest offen.
Würde jetzt sagen, aber dann kann nur ein Ausschnitt sein.
Und dann frage ich mich, wie groß der Ausschnitt aus der Overall-Bubble ist.
Ja.
Ja.
Es ist schwer zu sagen.
Also, ich glaube, du spielst so ein bisschen auf ein Teil der Entwickler an, die ja eher, sagen wir mal, sehr contra eingestellt sind zu dem gesamten Thema.
Also es gibt zumindest eine Reihe von Leuten und wenn man bestimmte Open Source-Projekte betrachtet, gibt es da schon Leute, die sagen, oh, um Gottes Willen, hier darf auf gar keinen Fall irgendwas KI-generiertes eingereicht werden oder bestimmte Dinge, die man liest, so, oh, ich habe da was eingereicht und bekam Feedback von einem KI-Roboter, ich werde da nie wieder was einreichen.
Das gibt es, das gibt es auch definitiv, aber in der Tat, ich bin da jetzt gerade in dieser Blase von den Leuten, die sich dafür interessieren.
Ich hätte auch mehr bei Trainings mit Leuten gerechnet, die sehr skeptisch sind.
Ich versuche auch nebenher bemerkt, wirklich realistisch an das Thema ranzugehen und das nicht in irgendeiner Form, ich bin jetzt hier der Apologet und predige euch die tolle rosige Zukunft der KI-generierten Softwareentwicklung.
Das ist nicht so, man muss das als Werkzeuge begreifen, die auch ihre Nachteile haben, die man wissen muss, wie man sie benutzt, weil sie sonst ziemlich viel Mist produzieren können.
Aber ich beobachte nicht so viel, also dieses, was man teilweise in Social Media sieht, beobachte ich in der Realität ehrlich gesagt eher selten.
Ich versuche, ich versuche mir gerade die Frage zu beantworten, was halt die Relev, was die vollständige Blase ist.
Wahrscheinlich ist es, wahrscheinlich ist es die Social Media-Blase.
Nichtsdestotrotz, ich glaube, dass wenn du an diesen harten Themen halt ankommst, die sind viel leichter zu lösen.
Also quasi quasi kann ich irgendeinen Service nutzen, der in Deutschland ist, oder stelle ich mir halt irgendwie Hardware in ein Keller.
Das ist halt irgendwie, das kann ich in einem Excel beantworten.
Das Mindset, also wie kriegt man Leute, also wie öffnet man quasi, wie schafft man die Bereitschaft, sich mit diesen Themen halt auseinanderzusetzen, finde ich halt viel schwieriger, weil das halt, dann sind wir wieder Tech is a People Business.
Das andere ist halt Tech is a financial business, ja, wenn man so will.
Da wird sich auch, wenn wir da mal den Schwenk machen, da wird sich, glaube ich, auch einiges ändern müssen in der Art und Weise, wie wir halt selber auch dem Entwickeln von Software gegenüberstellen.
Also wir versuchen tatsächlich im Training das auch an der eine oder andere Stelle ein bisschen stark zu vermitteln, also auch die Effekte zu vermitteln.
Also typische Effekte, die man sieht, wenn man auch mit diesen Tools arbeitet, dass man sich komplett überfordert fühlt von dem, was die da erzeugen.
Dass man eigentlich sich nicht mehr in Kontrolle fühlt bei dem, was man da tut.
Das ist in der Tat normal.
Und das ist, das sind aus meiner Sicht vor allem die Skills, auf die es ankommt, die man entwickeln muss, um da hinzukommen.
Also das eine ist vielleicht das Mindset zu sagen, ich stelle mich überhaupt offen hin und sage, okay, ich bin offen, dem gegenüber damals zu lernen, was in die Richtung geht.
Es ist aber, glaube ich, nochmal ein anderes Thema als überhaupt das, was auf uns zukommt, wie wir, ich vermute, in Zukunft anders arbeiten werden.
Und das ist diese, das ist einerseits eben dieses, ich steuere jetzt etwas anderes, was das für mich erstellt.
Das ist so dieses eine Ding, also das zu verstehen, dass ich eigentlich eher wie, ich sitze jetzt beim LKW am Lenkrad und versuche immer zu korrigieren, in welche Richtung das gerade läuft, was da passiert.
Aber ich selber bin nicht derjenige, der trampelt, sondern das macht der Motor unter mir.
Das ist so das eine.
Und das andere ist, finde ich, fast noch viel dramatischer.
Wie gehen wir eigentlich damit um, dass wir, ich glaube, Nate Jones hat das mal genannt, dass wir Ownership without authorship haben.
Also wir, wir haben Ownership über etwas, was produziert wird, was aber nicht wir produziert haben.
Wir sind aber trotzdem dafür verantwortlich.
Wie gehe ich damit um?
Was kann ich tun, um dafür zu sorgen, dass ich diese Ownership weiterhin also auch empfinden kann.
Also ich würde das wirklich auch auf die Gefühlsebene ziehen wollen.
Zu sagen, fühle ich mich eigentlich als derjenige, der diesen Code, der das alles erzeugt hat, bin ich bereit dafür verantwortlich zu sein?
Oder sage ich nur, das ist irgendetwas, was irgendwas anderes produziert hat und ich bin dafür nicht verantwortlich.
Das sind tatsächlich, finde ich, die Themen, die viel, viel relevanter werden.
Spannend dabei natürlich, aber ich vermute, vielleicht hat der Stefan bei euch auch schon gesagt, die Erkenntnis oder die Beobachtung, dass einige von diesen Skills Dinge sind, die man eher als Manager lernt als als Softwareentwickler.
Also die Fähigkeit der klaren Formulierung von Aufgaben, die Fähigkeit, Feedback zu geben, aber auch die Fähigkeit, ein delegiertes Arbeitsergebnis als Arbeitsergebnis zu akzeptieren, auch wenn es vielleicht anders ist als das, was ich gemacht hätte.
Das sind natürlich alles so Dinge, die lernt man als Softwareentwickler normalerweise erst, wenn man so in diese berühmte Stufe kommt, oh, jetzt wirst du Teamleiter.
Jetzt hast du irgendwie andere Aufgaben, andere, ne, das ist eine andere Welt für dich.
Was vielleicht übrigens auch erklären kann, warum man so CTOs und Manager immer so totale Fans von diesen Tools sind und der typische Seniorentwickler es vielleicht gar nicht so toll findet.
Weil die Art und Weise, wie man damit umgeht, eine andere ist und etwas ist, was viele jetzt auch, glaube ich, noch zusätzlich lernen müssen.
Das sind eigentlich so die Dinge, die, glaube ich, da eine ganz große Rolle spielen.
Was ich übrigens nicht glaube, ist, dass der Product Owner in Zukunft der Einzige ist, der Software entwickelt und wir den Softwareentwickler nicht mehr brauchen.
Das halte ich für kompletten Unsinn.
Vielleicht ist das jetzt eine falsche Vorhersage von mir oder eine von mir gefärbte, weil ich hoffe, dass ich nicht überflüssig werde.
Aber ich glaube tatsächlich, das wird nicht passieren, weil das, was ich immer wieder merke, ist, dass viele Dinge, die ich über Jahre gelernt habe, zu sehen an Softwaresystemen, jetzt mir wahnsinnig gut helfen.
Ich erkenne halt anhand bestimmter Muster, wie er was entwickelt worden ist, A, da lauert ein Problem.
Lass uns da mal tiefer reingucken.
Und das kann, glaube ich, jemand, der diese Erfahrung nicht gemacht hat, der wird das nicht können.
Der wird Schwierigkeiten haben, dort zu erkennen, dass da jetzt ein Problem lauert, was weiß ich, ich habe letztens ein System entwickelt.
Da musste zum Beispiel Mandantentrennung relativ scharf aber in einer Datenbank implementiert sein.
Und ich weiß, was das für ein Problem ist.
Und ja, die KI hat es nicht hinbekommen.
Sie hat an mehreren Stellen explizit versagt und dann musste ich sie halt in die richtige Richtung steuern und dafür sorgen, dass dann da wirklich, also ich glaube, ich habe dann sogar explizit erklärt, wie er das bitte in den Tabellen aufbauen sollte, damit das auch funktioniert.
Das war mir fast klar.
Ich habe dem Ding die Aufgabe gegeben und es war mir fast klar, dass es ein Fehler läuft.
Weil mir das aber auch fast klar gewesen wäre, wenn ich das jetzt im Juniorentwickler in die Hand gegeben hätte, hätte er ja wahrscheinlich hätte ja wahrscheinlich dieselben Fehler gemacht.
Beziehungsweise ich habe die Fehler selbst auch gemacht in der Vergangenheit.
Deswegen konnte ich sie, war mir klar, dass das Ding die Fehler wahrscheinlich auch machen wird.
Das ist die perfekte Überleitung zu der gängigen Frage, was das eigentlich mit dem Nachwuchs unserer Branche halt irgendwie tut.
Wird es zukünftig noch Junior Engineers geben?
Berühmte Junior-Entwicklerfrage, ja.
Ich sage deswegen die berühmte, weil es gibt, glaube ich, kein Training, wo ich nicht irgendwann in der ersten oder zweiten Pause danach gefragt werde.
Oder auch irgendwo andere, wo man dort sitzt.
Ich persönlich bin da hoffnungsfroh.
Ich sage, wir haben schon immer das Problem, auch in der Softwareentwicklung gehabt, dass wir Entwickler haben, die eine hohe Neugier haben und die wissen wollen, wie Dinge funktionieren.
Und wir haben Entwickler, die das als Job ansehen und die nur auf die Ergebnisse gucken.
Das hat sich früher geäußert in, ich kopiere jetzt hier irgendwelchen Code aus Stack Overflow, der ungefähr passt und dann ändere ich die Zeilen so lange zufällig rum, bis es funktioniert, zumindest bis ich denke, dass es funktioniert.
Und dann liefere ich das als mein Ergebnis ab.
Oder der andere Entwickler, der eben wirklich versucht hat, das von Ground ab zu verstehen und zu entwickeln und reinzuschreiben.
Und ich glaube, der letztere Entwickler wird auch in der heutigen Welt keine Probleme haben, sondern ganz im Gegenteil.
Es ist viel, viel leichter heute, wenn ich das Interesse daran habe, zu verstehen, wie das da funktioniert, die Antwort auf dieses konkrete Problem zu bekommen.
Und da muss ich zum Beispiel sagen, also wenn ich jetzt ein Stück Code habe und ich habe dort bestimmte Abschnitte drin, ich möchte zu diesem Abschnitt wissen, wie funktioniert jetzt jetzt genau oder was macht diese Funktion da?
Und wenn ich das in LLM frage, dann antworten die, also sagen wir mal, zumindest innerhalb des letzten Jahres eigentlich fast immer richtig.
Also meistens überprüfe ich es dann nochmal hinterher.
Ich teste die Dinger gerne, auch immer, indem ich ihnen Fragen stelle, deren Antworten ich schon kenne.
Und dann mal gucke, was sie so antworten.
Und ich sag mal so, seit zwölf Monaten, ich habe da kaum noch gemerkt, dass da irgendwas drin war, was wirklich Blödsinn war.
Ab und zu ist vielleicht auch mal was nicht ganz richtig, aber das ist bei einem Menschen auch so.
Also, wenn ich einen Kollegen frage, wie funktioniert das eigentlich und der gibt mir eine Antwort, dann gibt es da auch eine fünfprozentige Wahrscheinlichkeit, dass da Unsinn gerade bei rauskam.
Wir tun auch immer so, als wenn, also redet jetzt mal an meiner Rolle, in meiner früheren Rolle als Software-Ingenieur, als wenn wir nie Fehler gemacht hätten.
Also Bugs gab es nie.
Und quasi dieser eine Ausrutscher wird dann, oder auch gerne diese zwei, drei Ausrutscher werden als Grund genommen halt irgendwie einen Trend quasi halt irgendwie abzuschreiben.
Das ist auch mehr als einmal gehört.
Das ist übrigens auch so dieser Punkt mit diesem Authorship-Thema.
Also das ist vielleicht sogar ein Fehler von uns, dass wir uns immer einbilden, wenn wir der Autor von dem Ganzen sind, dann wird das schon richtig sein.
Also ich kann für mich alleine sprechen, ich kann nicht für andere sprechen, aber ich für mich alleine, also meinem Tod zu vertrauen, das ist auch, glaube ich, ein Fehler.
Also sollte man nicht machen.
Also ich mache es jedenfalls nicht.
Deswegen schreibe ich ja Tests und ähnliche Dinge, weil ich weiß, dass der Code, den ich schreibe, normalerweise mindestens im ersten Wurf bestimmt ein Fehler drin hat.
Und das ist, finde ich auch eine wichtige Sache, die wir wieder auch bei den Trainingsversuchen zu vermitteln, dass viele von den Dingen, die wir früher gemacht haben, jetzt nicht plötzlich umsonst sind, sondern eher noch viel mehr gebraucht werden.
Also, so ein Agent, der braucht eine ordentliche Feedback-Doop, der braucht einen Test-Tarnis, dann kann der viel besser arbeiten.
Nicht umsonst ist es so, dass diese langlaufenden Projekte, die jetzt gerade so rauskommen, so HTML-Parser und dieses Browser-Projekt, dass die alle relativ gut funktionieren.
Das sind alles Umgebungen, wo es extrem umfangreiche Testtarnnesses gibt.
Für jeden kleinsten Ausnahmefall existiert da irgendein Test, wie das funktionieren soll.
Und dann funktionieren auch die Agenten hervorragend.
Was kann man daraus Schlussfolgern?
Naja, vielleicht sollte man das in eigenen Projekten auch so machen.
Und auch das Erstellen von Tests ist dadurch vielleicht nicht mehr ganz so schlimm und nicht mehr ganz so schwierig.
Also, das ist wieder, da kann man sich dann auch wieder helfen lassen, diese Tests zu erstellen.
Aber die braucht man.
Feedback ist wahnsinnig wichtig.
Genau, es ist ein wichtiger Constraint, wenn man Agent-Ecoding macht.
Du brauchst einfach gute Tests und du brauchst ein gutes Tooling drumherum, damit du überprüfen kannst, ob das wirklich sinnig ist, was da rauskommt.
Genau.
Ja, super, super spannend.
Wir wollten eigentlich in dem jetzt Beyond-Vibecoding ein bisschen kürzer werden in den Episoden.
Ich könnte noch eine halbe Stunde länger quatschen.
Aber wir müssen, ich glaube, wir müssen auf jeden Fall nochmal eine Follow-Up-Folge in ein paar Monaten vielleicht auch machen mit dir, um dann auch zu gucken, was sich seitdem wieder getan hat.
Ich würde nochmal eine letzte Frage stellen wollen und dann zum Abschluss kommen, so ein bisschen.
Und die letzte Frage ist, weil das ja auch super relevant ist für die, also für die meisten, die gerade anfangen, du hast es auch vorhin kurz angesprochen, man hat ja immer schon was, ne, Brownfield.
Wie geht man damit um?
Wie nähert man sich dem?
Hast du da schon irgendwelche Pattern, die du sehen kannst oder musst du sagen, was ja auch gemeint, ne, auch fairerweise noch nicht so eine lange Datenbasis sozusagen, aber gibt es da schon was, was sich da rauskristallisiert?
Also eigentlich würde ich da fast Werbung machen wollen für einen meiner Kollegen, der Markus Harrer, der sich da extrem intensiv beschäftigt.
Vielleicht solltet ihr den auch mal einladen.
Gut an das, danke.
Der da tatsächlich viel, viel tiefer drin steckt als ich.
Grundsätzlich ist das, also erstmal vielleicht eine wichtige Erkenntnis dabei, die hat mich auch persönlich überrascht ein wenig.
Diese Agenten sind nicht unbedingt am besten beim Greenfield, sondern wenn sie mehr Dinge haben, an denen sie sich orientieren können, sofern diese Dinge natürlich gut sind, dann arbeiten die deutlich besser.
Und insofern ist ein Brownfield-Projekt nicht unbedingt schlechter, sondern kann durchaus helfen, dabei erweiterte zu werden.
Ansonsten gilt da eigentlich das, was ich auch aus, wie hieß das gute Buch damals, Working Effectively with Legacy Code, was man doraus kennt, bau dir einen Testharnes, suche die entsprechenden Themes.
Zu dem Testharnis kommt jetzt, glaube ich, bei den Systemen noch dazu, bau dir auch eine Dokumentation, wenn du sie nicht hast.
Also sprich, lasse quasi rückwärts den Agenten reverse engineeren, was eigentlich in dem System existiert.
Und wenn du ein Test-Harnis hast, wenn du die Dokumentation, die rückwärtig richtig erarbeitet hast, etc., dann kannst du den Agenten auch aktiv an den Systemen arbeiten lassen.
Dabei allerdings wichtig, mache bitte keine Refactorings, für die es vernünftige, feste deterministische Algorithmen gibt, also sowas wie eine Funktion auszulagern oder irgendwas zu renamen, mache sowas bitte nicht mit einem Agenten.
Das machst du bitte mit den Tools, die wir schon hatten.
Die sind da stabiler dafür.
Also, das sehe ich manchmal so, dass Leute dann hingehen und sagen, so, rename mir mal folgende Variable.
Dann nehme ich eine Idee, die hat ein Language-Graphen, die kann lasst das Ding bitte das machen, das kann das besser.
Aber so, das ist so die Welt in dem Legacy, aber ansonsten tatsächlich würde ich euch den Hinweis geben, ladet euch doch mal den Markus ein.
Der kann euch da richtig viele Sachen zu erzählen.
Super guter Punkt.
Machen wir sehr gerne.
Cooler Tipp, genau, ja.
Und ich muss auch kurz sagen, also Renaming Function ist genau so ein What the fuck, was ich auch schon hatte, wo ich dachte, ich habe die komplexesten, bei mir hat die KI tatsächlich mit viel Guidance, aber die hat es mit dem Modell zumindest für eine Multiten-Applikation sehr gut hinbekommen.
Die Implementierung dann wiederum nicht.
Da war dann die Tenant-Zuordnung teilweise doch ein bisschen schwammig.
Mal ist der Name genommen worden, mal die ID, manchmal wurde auch eine E-Mail-Adresse für die User-Zuordnung herangezogen, wenn die ersten beiden aufgrund von irgendwelchen Migrationen nicht mehr hingehauen hat.
Also, das war sehr eigentlich nicht so, wie man das secure haben möchte, sozusagen, damit es da keine Vermischung gibt.
Aber das Renaming und so ist tatsächlich deutlich, sagen wir mal, weniger gut gewesen, als ich mir das vorgestellt hätte nach anderen Erfahrungen, die ich gemacht habe.
Ja.
Alright.
Genau, das ist eigentlich auch eine schöne Überleitung zum Abschlusssegment sozusagen bei uns, nämlich diese What the fuck-Momente.
Genau.
Was sind bei dir so What the fuck-Momente, die du immer noch hast, wo du denkst, so, wie konnte das jetzt schief gehen?
Und dann vielleicht nochmal im zweiten Teil der heißeste Scheiß sozusagen.
Also du hast ja schon ein bisschen was genannt, aber wenn es da noch was gibt, genau, aber erstmal what the fuck.
Ah, what the fuck.
Ich sag mal, Loop of Doom kennen wir ja alle von den Agenten.
Dass es irgendein Problem gibt, wo er sich jetzt festfrisst.
Gerne sind das Dependencies.
Das habe ich immer wieder gehabt, dass irgendwelche Sachen er einfach die falschen Dependencies reingezogen hat oder schlichtweg vergessen hat, die Dependencies zu sünden, also ein MPM-Install oder ein UV-Sync zu machen.
Ich muss allerdings dazu sagen, das ist in den letzten Monaten deutlich besser geworden.
Also das war von einem, ja, ich sag mal, vor einem Dreivierteljahr oder sowas hat man damit festgerechnet, dass man nach einer halben Stunde Arbeit irgendwann an so eine Doom Loop reingekommen ist.
Und das war dann immer so, das ist so, jetzt ernsthaft, du findest die Lösung immer noch nicht.
Okay, ich guck mal kurz rein.
Ah, du musst da einfach nur dieses eine Kommando kurz anwenden.
Danke.
Und dann ging es auch weiter.
Das war schon so ein, meine Güte, echt jetzt.
Oder auch, naja, dieses Mandantenthema, wobei, ich habe damit gerechnet, dass er den Fehler macht.
Ja, neue Trends, ich habe es ja vorhin schon gesagt, das haben wir ja schon ein bisschen reingeworfen, dieses ganze Thema langlaufende Agenten und wie entwickelt sich das eigentlich weiter.
Weil bisher bin ich eigentlich ein großer Fan davon, auch bei der Implementierung immer noch in kleinen iterativen Schritten zu gehen.
Es ist aber faszinierend zuzugucken, wie einige da jetzt gerade experimentieren, diese Dinger teilweise über Stunden oder Tage laufen zu lassen, um Ergebnisse zu erzielen.
Das ist etwas, was ich mich vielleicht aktuell noch nicht trauen würde, aber sehr gerne tatsächlich mal damit experimentieren würde.
Das ist aber natürlich tatsächlich auch eine Preisfrage.
Die sind auch in der Tat, das ist vielleicht auch so ein kleiner Worte-Funk-Moment.
Wir machen ja dasselbe Training schon seit mehreren Monaten und das hat die gleichen Inhalte.
Die Token-Kosten haben sich aber in den letzten zwei bis drei Monaten verdoppelt.
Ach, spannend.
Ja, obwohl die nicht pro Token doppelt geworden sind.
Aber die Agenten arbeiten anders.
Die braten offensichtlich.
Die sind deutlich ressourcenintensiver.
Man sieht auch, dass sie ganz anders arbeiten.
Aber dann habe ich schon so, da haben wir irgendwie, es waren so die letzten Wochen eigentlich, wo wir raufgeguckt haben und gedacht haben, warum zum Beispiel ist die Rechnung jetzt eigentlich doppelt so hoch, als wir es gewohnt sind.
Das war auch so.
What the fuck?
Haben die das halt auch richtig so optimiert?
Ist auch massiv intransparent, ne?
Also, das ist auch das ist sicherlich nochmal, da kommen wir wieder auf das Thema eigene Infrastruktur und Co.
Ja, das ist tatsächlich, was man ja im Allgemeinen sieht, dass viel von vom Trainingslauf sozusagen jetzt verschoben wird auf die Inferenz.
Das bei der Inferenz einfach viel mehr passiert.
Und das ist natürlich auch bei den Coding-Agents.
Auf der einen Seite Kontext-Window-Management über Skills und alles sonst, ne?
Auf der anderen Seite hast du aber auch wirklich verschiedene, sagen wir mal, ich weiß gar nicht, ob es dann Agenten sind, aber teilweise ja schon, dass du nochmal einen Review-Agenten hast, der da nochmal drüber schaut, beziehungsweise die Agenten und das sieht man ja auch, wenn man da sich anguckt, wie die auch denken, also zumindest bei Antigravity sehe ich das immer, die dann quasi sich selbst verbessern und wahrscheinlich wirklich verschiedene Loops an starten sozusagen oder verschiedene Experten starten.
Und das ist natürlich genau das.
Also sprich, in der Inferenz passiert mehr.
Das heißt also, es werden mehr Tokens produziert, obwohl man eigentlich sogar Kontextmanagement macht und eigentlich weniger Tokens verbrauchen sollte.
Das kann ich übrigens vielleicht so als einen letzten Tipp, den ich Leuten auf den Weg geben kann, wirklich sehr empfehlen.
Es gibt Tools, die in der Lage sind, die Session-Verläufe wirklich zu visualisieren.
Also so eine Cloud-Code-Zeit, also Cloud-Code zum Beispiel, zeigt ja nicht übermäßig viel darüber, was da wirklich passiert.
Da steht dann irgendwie Thinking und so weiter.
Also, das, was man da so im Terminal sieht, ist nicht sehr aussagekräftig.
Aber der gesamte Verlauf der Session im Detail wird tatsächlich abgespeichert.
Der ist in deinem Home-Verzeichnis, den kannst du da finden.
Ist nur in einem unglaublich schlimm lesbaren JSON-P-Format.
Also das möchtest du nicht so durchlesen.
Aber es gibt eine Reihe von Tools, mit denen ich das wunderschön in Webseiten visualisieren kann, was da wirklich abläuft, die das dann interpretieren, wo du dann genau siehst, was ist das Thinking etc.
Wenn man also mal ein bisschen genauer auch lernen möchte, wie man das Ganze steuert, ist das ein super Mittel, um sich selbst auch mal das Feedback zu geben.
Okay, ich habe dem jetzt das gesagt.
Was tut er denn dann?
Der Agent.
Nochmal ein richtig gutes Auto, um sich selbst zu optimieren.
Genau.
Ich wollte nur genau das gleiche sagen.
Also ein richtig guter Tipp nochmal zum Abschluss, den hier rausbrustjack.
Vielen Dank.
Ja, das würde ich sagen, war sie unsere Folge.
Es hat mir großen Spaß gemacht.
Es war sehr cool.
Danke, dass du da warst.
Und wie gesagt, ich würde mich freuen, wenn wir dich in ein paar Monaten oder so nochmal begrüßen dürften bei uns, um ja, vielleicht dann zu hören, was es Neues gibt aus deiner Sicht und wie sich auch die Firmen im Laufe der Zeit gewandelt haben, tatsächlich schon.
Sehr gerne.
Und ja, es war mir ein Vergnügen.
Danke, dass ihr mich eingeladen habt.