# Agentic Engineering: Operating Model Shifts & ROI Strategies

**Podcast:** HMZE
**Published:** 2026-06-04

## Transcript

Drück doch mal auf Recording, falls hier irgendwas Cooles dabei ist.
Vielleicht sagen wir zum Unterschickhaus.
Habe ich gerade gesagt.
Ich fand es nur als Outtake ganz lustig.
Ach so.
Ich drücke mal auf Recording, falls hier was Cooles dabei rauskommt, wenn wir miteinander reden.
Soll ja mal vorkommen.
Auch ein blindes Huhn.
Herzlich willkommen zu einer neuen Episode von HMZE Beyond Vibe Coding.
Der Podcast, in dem wir den fundamentalen Change in der Softwareentwicklung begleiten.
Ich bin wie immer Sebastian Heidemeyer zu Erben, CTO bei North.io.
Und ich bin André Neubauer, CTPO bei Trusted Shops.
Schön, dass ihr wieder da seid.
Genau, heute wieder mal eine andere Episode aus zwei Gründen.
Einmal, wir nehmen mal wieder was ohne Gast auf.
Das haben wir jetzt aber auch schon das ein oder andere Mal gemacht.
Insofern, so neu ist es da nicht.
Aber zweitens, Trommelwirbel.
Wir haben am Ende vom Podcast noch eine spannende Ankündigung.
Ganz genau.
Also bleibt dran bis zum Ende.
Aber zuvor schauen wir uns an, wie fortschrittliche Tech-Organisationen Agentic Engineering in der Praxis wirklich adaptieren.
Und zwar besprechen wir einen Report, den ich jetzt die Tage erstellt habe, der alle möglichen Quellen zu den Ansätzen von verschiedenen Unternehmen in Bezug auf Agentic Engineering mal zusammenfasst.
der Einsatz von Coding Agents ohne Technical Excellence sich tatsächlich negativ auswirkt.
Spannend, genau.
Magst du vielleicht am Anfang mal so ein bisschen ausführen?
Du hast ja schon gesagt, verschiedene Quellen zusammengefasst, aber was du gemacht hast?
Ja, sehr gerne, genau.
Und zwar habe ich im Februar oder März, glaube ich, gab es den Pragmatic Summit von Gergelio, der ja auch den Pragmatic Engineer macht.
Da habe ich mir so eine ganze Reihe von Talks reingezogen damals, auch zu dem Thema, die ich schon damals sehr cool fand und hatte immer im Kopf, die mir nochmal so richtig, man guckt die ja immer so weg, die nochmal so richtig zu Gemüte zu führen und zu gucken, was da so drinsteckt.
Habe dann noch einen Artikel von Cloudflare gefunden, die auch sehr, sagen wir mal, auf bestimmte Art und Weise sehr ins Detail gehen, also gerade bei der Infrastrukturebene und Security Compliance Ebene, wie Sie das Thema haben.
angehen und dann gab es ja von ThoughtWorks, das hatte, ich glaube, Ralf erwähnt bei uns, der Podcast-Gast von ThoughtWorks, den Future of Software Development Retreat, wo es so ein Dokument gibt, was so die Key Takeaways zusammenführt.
Ich glaube, es war Robert Glaser.
Das kann auch sein.
Der hat das nämlich gerade gefunden damals und die hatten genau das Ähnliches beschrieben wie er, aber kann man auch nochmal in die Folge reinschauen.
Exakt.
Oder reinhören.
Guter Hock, genau.
Dann habe ich unsere Podcast-Episoden insbesondere von Mapbox und Abwest genommen, weil das ja auch so ein bisschen größere Tech-Organisationen sind.
Und ja, insofern geguckt, was die Quellen sind, die ich zur Verfügung habe für so fortschrittliche, größere Tech-Organisationen.
Und habe die grob nach Themen so Erfolgsmessungen, Adoption Practices, Tool-Choice, Governance, Security, Compliance mal durchgeguckt und dann in so einen zehnseitigen Report gepackt.
Die Aussagen im Report sind alle mit entsprechenden Quellen belegt, eben aus diesen Talks, Podcast-Episoden, Artikeln.
Und im Anhang sind da nochmal so, ist wirklich so ein Vergleich, so eine vergleichende Analyse, weil die ganzen Talks und Episoden und so, die gehen schon ziemlich ins Detail zu diesen ganzen Punkten.
Das heißt, man findet da eigentlich von allen Unternehmen irgendwas in den meisten Kategorien.
Und die habe ich da nochmal en Detail zusammengeführt, natürlich mit agentischer Hilfe auch.
Genau.
Was ich ausgelassen habe, sind die wissenschaftlichen Studien, denn, und das hatte Ingo Eichhaus ja in unserer Episode auch schon beschrieben, dass die alle tatsächlich doch zu alt sind.
Also die neueste, die ich so gefunden habe, ist aus Mai, sorry, ist aus dem Februar gewesen und hat aber Daten von vor, weiß ich nicht, vier Monaten gehabt.
Das heißt, also da war Cloud Code ja noch gar nicht groß.
Das heißt, dass man eigentlich den Stand von damals...
nicht vergleichen kann.
Aber es gab halt Cursor und Windsurf und Lovable.
Das kann man noch nicht vergleichen mit dem, was Cloud Code dann geschafft hat.
Deswegen habe ich das ein bisschen rausgelassen.
Ja, insofern alle relevanten Quellen tatsächlich von Februar bis Mai 2026 da mit reingenommen.
Und genau, das können wir jetzt mal durchgehen.
Genau.
Bevor wir da durchgehen, finde ich das irgendwo?
Den können wir online stellen.
Packen wir auf die Seite?
Sollten wir machen.
Finde ich gut.
Genau.
Nicht einschüchtern lassen.
Das sind insgesamt 32 Seiten, aber nur die ersten zehn sind tatsächlich relevant.
Der Rest ist Anhang.
Ja, wer das Dokument von vorne liest, der lernt schnell, dass man eigentlich nur die Summary lesen muss.
Und dann die Bereiche, die interessant sind.
Gut, dann lass uns doch mal starten.
Was denkst du, was ein guter Einstieg hier ins Gespräch ist?
Ja, es gab...
Es gibt so ein paar interessante Sachen, die da immer wieder hochgekommen sind.
Und das eine ist, ich würde es mal mit ThoughtWorks Worten den Middle Loop nennen.
Die sagen, es gab halt vorher so diesen Coding Loop, also sprich irgendwie das Dead oder auch Inner Loop, wo es halt wirklich ums Coden geht und dann den Outer Loop, der die Delivery, also sprich um so ein Produkt oder so ein Feature.
zu liefern, aufmacht.
Und dazwischen ist jetzt noch so ein Middle Loop entstanden, tatsächlich, der so eine Brücke baut, wo Engineers ja eher mit Agenten zusammen beide Welten verbinden.
Und das ist so ein Grundtenor, den wir auch immer wieder bei uns mal beschrieben haben, den auch Fiona Fong in ihrem Code with Claude Talk aufgreift, wo sie sagt, Was wir gerade sehen, ist eigentlich ein Operating Model Change.
Das ist kein Tool, was da kommt, sondern ein Operating Model Change, der damit eingeleitet wird.
Und das ist ein Punkt, den auch Laura Tacho in ihrem Talk, vormals DX, die natürlich unfassbar datengetrieben, basierend auf zigtausenden Antworten von Entwicklern aus Developer Experience Surveys, die das sehr schön aufbereitet.
Der Talk ist absolutes Must-Watch sozusagen, sehr empfehlenswert.
Und sie sagt auch, dass die Gewinner das Thema eher als Organisations- und Change-Management-Problem betrachten werden.
Und da gibt es natürlich auch unterschiedliche Ansätze.
Es gibt Top-Down, Bottom-Up.
Mischung ist wahrscheinlich wie so oft das Beste.
Und dann verschiebt sich halt, wie wir auch schon gesagt haben, die Rolle des Ingenieurs vom Low-Level.
Ich weiß, wie ich ein Diff zentiere.
Ist natürlich immer das blödeste Beispiel.
Aber ich sage mal, syntaktische Probleme oder technische Probleme lösen hin zur zu dem Drumherum sozusagen, Systemgrenzen, Business-Anforderungen verstehen, verifizieren von Ergebnissen, gucken, dass man das wartbar hält.
Ich wollte bloß hinzufügen, das ist das, was man eigentlich auch immer wieder jetzt hört, dass das die Rolle von einem Engineer eher, ich würde mich mal aus dem Fenster lehnen, sowas wie ein Manager wird.
Also Manager im Sinne von orchestrieren.
Ich glaube, aus dem Zusammenhang heraus, ich glaube, das ist so ein Gedanke, den ich immer wieder höre.
Und das andere ist, da bin ich auch komplett bei dir, wenn man jetzt aber nochmal so aus dem anderen Blickwinkel da drauf, Dan Shapiro, diese sechs Level von Argentic Engineering, wie bei Trusted Jobs, wir haben quasi für uns definiert, wir wollen da auf Level 4, nicht Dark Factories, aber quasi wirklich Factories.
Und der Sprung zwischen 3 zu 4 ist halt einfach.
das ist nicht linear, sondern exponentiell.
Und dafür musst du halt, und das passt zu dem, was du gerade gesagt hast, quasi also mit Verweis auf den Talk von Laura Tacho, das ist halt, also es inkludiert halt organisatorische Changes.
Ja, genau.
Sehe ich genauso wie du, ja.
Nur der Vollständigkeit halber, diese sechs Levels sind natürlich 0 bis 5, was bedeutet Level 4 ist auch das vorletzte Level sozusagen von Dark Factory.
Und dann kommt natürlich, und das ist dann eigentlich schon die Überleitung zum nächsten Punkt, zur Erfolgsmessung, der Fakt, dass Code-Generierung, wissen wir alle, jetzt billig ist und sich Engpässe eben nach weiter hinten verschieben zu Review, Planning, Security, Ownership, dieses Thema Ownership ohne Authorship.
Da bin ich, ich weiß gar nicht, wo wir, in welchem Kontext wir das hatten.
vielleicht fällt es dir gleich ein, dass quasi, ja, der Code wird woanders geschrieben, aber du hast trotzdem die Ownership.
Hatten wir auch in irgendeiner Episode mal intensiver diskutiert.
Ich glaube, das ist, ich weiß gar nicht, wie das bei dir in der Organisation ist, bei mir ist es tendenziell weniger ein Thema.
Ich glaube, es kam mal kurz auf, aber ist auch schnell wieder verschwunden.
Genau.
Ist eigentlich ja auch logisch.
Wir hatten das ganz explizit, glaube ich, mit Uli besprochen, bei Mapbox ist ganz klar.
Wenn du den PR öffnest, egal, auch wenn es deinen Agent macht oder dein Agent in deinem Auftrag, du bist dafür verantwortlich.
Und das hatte ja auch Jörg, glaube ich, der hatte genau diesen Punkt aufgemacht.
Ownership without authorship.
Das ist tatsächlich auch ein Thema, was sich komplett durchzieht.
Was auch alle gesagt haben, Engineers sind nach wie vor verantwortlich.
Ist, glaube ich, immer ein gutes Beispiel für Responsibility versus Accountability.
Niemand sagt, dass quasi du den Code eins zu eins gelesen haben musst, aber du musst halt irgendwas getan haben, um dir halt sicher zu sein, dass das so okay ist.
Genau.
Dann sind wir wieder bei unserem Wort 2026 Harness.
Genau.
Aber lass uns da nochmal ein bisschen tiefer so Thema Erfolgsmessung, Return on Investment halt irgendwie reingehen.
Du hast ja da im...
Reports auch so ein paar Kategorien beschrieben.
Kannst du uns da mal durchführen?
Sehr gerne.
Erfolgsmessung ist tatsächlich bei allen, finde ich, ein bisschen schwammig.
Also was da immer hochkommt, ist natürlich Throughput.
Spotify sagt 93% mehr PRs.
Uber sprach im Februar noch von 10 bis 15, was wir heutzutage quasi wenig erscheint, weil bei Unternehmen, die das eine Weile machen, da steigt es deutlich an.
Atlassian, Mapbox, Upbest, alle haben davon gesprochen, dass der Throughput sich steigert.
Und Laura Tacho, die hat in ihrem Talk nochmal so ein paar Kategorien aufgemacht, wie man ansonsten auch agentik messen kann.
Da geht es aber erstmal, sagen wir mal, initial, glaube ich, wenn die auch von Throughput sprechen, die ganzen Firmen, geht es erstmal darum zu messen, machen es unsere Entwickler.
Also werden wirklich, wie viele PRs sind jetzt agentic und so.
Das ist eine Kategorie, die sie auch aufmacht.
Utilization, also sprich, wie viel werden die Tools genutzt?
Also wie viele Daily Active Users, Weekly, so das Übliche.
Dann percentage of PRs, die AI-assisted sind, Committed Code und so weiter.
Oder Tasks assigned to Agents, auch ein Thema.
Dann kommt das Thema Impact.
So, da sind so Themen drin wie AI-driven Time Savings.
Das ist natürlich sehr subjektiv, weil das...
kriegst du ja nur in aller Regel nur über Umfragen raus.
Das ist natürlich wieder DX, die ja Developer-Umfragen machen regelmäßig, deswegen aus der Perspektive.
Dann Developer-Satisfaction, aber dann so auch so ein bisschen in Richtung DORA, also PR-Throughput und Perceived Rate of Delivery und ähnliche Sachen.
Also man versucht so ein bisschen da eher zu quantifizieren, wie viele Stunden von menschlicher Arbeit man durch Agenten ausgeführt hat.
Oder am Ende kommen natürlich Kosten als letzte Kategorie, AI-Spend und irgendwie eine Time-Gain per Developer, sowas.
Da muss ich sagen, habe ich immer noch ein Störgefühl.
Also ich habe bis vor kurzem hat man auch immer, also gab es ja diese Nachricht unter anderem halt, Uber hat halt irgendwie das gesamte AI-Budget innerhalb von, also für das gesamte 26, innerhalb von wenigen Monaten durchgebracht.
Ich habe mir immer so gedacht, ich weiß nicht, ob das eine Metrik ist, die ich so feiern würde.
Also quasi nur Geld quasi.
Also ist wahrscheinlich wie bei jeder Technologie.
Am Anfang geht es wirklich um Utilization.
Insofern ist da natürlich Kosten schon ein interessanter Aspekt.
Auf der anderen Seite, und vielleicht ist es eben zu viel, also zu früher Wunsch, aber ich finde, und das hast du ja gerade gesagt.
bis jetzt wenig Blick auf Impact.
Also, und das ist ja eigentlich, also vielleicht ist es, wie gesagt, verfrüht dazu.
Ich vermisse trotzdem die Diskussion und halt auch, wie Firmen das machen.
Wirklich positive Erfahrungen.
Wir reden viel von, was ist denn so Budget und wie viel wollen wir dann ausgeben?
Aber man redet wenig von, so und das ist jetzt tatsächlich Impact.
Das, was wahrscheinlich noch am besten geht, hast du ja auch gesagt, ist.
quasi Output.
Aber Output nicht gleich Impact.
Genau, das versuche ich dann auch im Report so ein bisschen aufzugreifen.
Also sprich, mehr generierte Diffs oder PRs oder was auch immer sind.
nicht automatisch mehr Umsatz.
Und das fehlt halt wirklich bei allen.
Das ist sehr, sehr spannend.
Und vor dem Hintergrund ist auch, da ist Uber auch wieder so die erste Firma A, die Ersten, die sozusagen dieses ganz öffentlich gemacht haben, dass sie durch ihr ganzes AI-Budget durchgebrannt sind, schon nach vier Monaten.
Und der CFO hat ja jetzt in so einem Podcast auch gesagt, dass er eigentlich noch nicht so richtig sehen kann, wie sich das in Businessmetriken übersetzt.
Dieser ganze erhöhte Throughput und die ganzen Kosten, die da.
die da jetzt entstanden sind.
Und auch, was du eben sprachst, dieses Token-Maxing, diese Leaderboards, die, ich glaube, Meta und Amazon und so, da gab es bei vielen Firmen, die halt wollten, dass ihre Engineers das stark adaptieren.
Das ist, glaube ich, alles wieder abgeräumt worden.
Also gab es jetzt auch vermehrt Artikel, Amazon macht das nicht mehr, ich glaube, Meta macht das auch nicht mehr, nachdem irgendjemand mal, keine Ahnung, Millionen in einer Woche da verbraten hat in Tokens, was ja völlig...
Irre ist.
Was ich tatsächlich immer benutzt habe, ist so eine Scorecard, die auf Outcome, Output, Tech Health und Team Health gesetzt hat.
Irgendwie, glaube ich, relativ irgendwie normal.
Jetzt ist Outcome immer schwierig, irgendwie bei reinen Tech-Organisationen zu messen.
Das ist aber auch der falsche Anlasspunkt in meinen Augen.
Sondern da ist dann halt der, eigentlich die gesamte Produktorganisation zu sehen, meines Erachtens nachher, wirklich die Business-Metriken.
Die sind halt das.
worauf es am Ende ankommt.
Wie heißt es doch im Deutschen, entscheidend ist, was hinten rauskommt.
Ja, irgendjemand hat das mal gesagt, genau.
Ja, mal gucken, ob wir das noch rausfinden.
Ich finde das auch gut, muss ich sagen, dass quasi diesen Versuchen, so eine Art Klammer drum zu machen, weil, wie gesagt, das nur auf Kosten und Utilization abzustellen, finde ich schwer.
Auf der anderen Seite natürlich.
Überhöhte Erwartungen helfen halt auch nicht.
Ich glaube, das ist schon Legging.
Es ist ein neues Tool.
Man muss halt irgendwie wissen, wie man es anwendet.
Ich glaube auch, dass wir Themen wie viel besseres Tokenmanagement, genauso wie wir eben so ein bisschen, also diesen Trend rund um Kontextmanagement, da wird man noch viel sehen, neben dem Aspekt, dass das...
hoffentlich, wahrscheinlich alles ein bisschen günstiger wird.
Vielleicht kommt es irgendwann mal lokal.
Nvidia CEO hat ja gerade auch angekündigt, dass sie in Notebooks gehen.
Also vielleicht ist das halt auch so der Startschuss, dass man da nochmal einen stärkeren, also auf der Kostenseite halt einfach ein ganz anderes Setting halt sieht.
Ja, man war ja auch schon mal drüber gesprochen, dass man irgendwann dann von OPEX nach CAPEX auch verschieben kann.
Und ganz ehrlich, mir fällt da der Ausblick noch, ein bisschen schwer, weil du hast ja verschiedene Themen, die gegeneinander laufen.
Auf der einen Seite hast du eben die massive Nachfrage, die gerade ja auch dazu führt, fairerweise, dass die Preise steigen, zumindest bei den Frontier-Modellen, dass Subscriptions, da die Limits runtergefahren werden oder bestimmte Subscriptions einfach auslaufen, ob das jetzt also GitHub ist, die jetzt gar keine festen Subscriptions mehr haben in dem Sinne, sondern wo du halt wirklich metert irgendwie, also nach Tokens.
oder Requests oder so abgerechnet wirst.
Und das ist natürlich insbesondere dann, wenn du davon ausgehst, dass da Konsolidierung passiert, dann ist es noch gefährlicher, wenn du sagst.
Und am gefährlichsten eigentlich, wenn die, also die LLMs per se sind ja nicht so stark differenziert.
Klar würde man sagen, oh ja, Opus 4.8 ist das Beste zum Coden, aber Ganz ehrlich, du kannst auch mit Opus 4.6 wahrscheinlich relativ gut coden oder mit GPT 5.5 oder auch mit was auch immer.
Also immer natürlich das neueste Modell.
Das darf nicht zu viele Generationen hinten dran sein.
Du wirst wahrscheinlich ganz gut damit auch arbeiten können.
Und auf der anderen Seite hast du eben aber auch dann die chinesischen Anbieter.
Jetzt gerade ganz neu irgendwie Kimi.
Bei den Versionsnummern, da komme ich auch durcheinander, aber die irgendwie zu einem Zehntel, glaube ich, der Kosten von den Frontier-Modellen anbieten.
Aber ein Modell, was wirklich on par ist, quasi laut Benchmarks, die ja auch immer so ein bisschen mit Vorsicht zu betrachten sind.
Und deswegen, ich finde es relativ schwer, auch wenn man sich anguckt, der Bedarf nach Compute, der, wenn der...
Also wenn der Demand weiter da ist, dann wird der Bedarf nach Computer weiter hoch sein, dann werden die Komponenten weiter teuer sein, dann werden auch, by the way, Desktop-PCs oder so oder Laptops, die werden einfach auch unfassbar teuer sein, weil du brauchst einfach extrem viel RAM.
RAM ist teuer, diese GPUs, die ja besonders schnell RAM haben, sind teuer und deswegen ist, finde ich, schwer, das so vorauszusehen.
Aber was ich sagen kann, wenn man es kann, dann...
machen lokale Modelle schon Spaß.
Also ich habe tatsächlich neulich auf der Bahnfahrt mal hier auf meinem Mac, der hat 36 GB RAM, da habe ich mal QN 3.6 mit 25 Milliarden Parametern ausprobiert.
Lief leider unfassbar langsam, aber das Ergebnis von der Qualität her war schon relativ gut.
Und wir haben dann das leicht größere Modell mal, wir haben bei North so eine DGX mit 8.
A100 GPUs, haben wir irgendwann mal von Nvidia bekommen, nutzen wir zum Model-Training für eigene Modelle tatsächlich für uns und da haben wir mal auf Vieren per VLLM das größere QN 3.6 Modell mit 35 Milliarden Parametern installiert.
Also Token-Durchsatz stieg immer noch an.
Ich glaube bei 733 hat dann der Test, ich habe LM-Perf, glaube ich, Benchmark mit 16 Usern parallel gemacht.
Keine komplette Saturierung.
Also das ist unfassbar, wie schnell das war.
Und ganz ehrlich, bei der Qualität, die das Model schon geliefert hat, damit könnten wir die Firma wahrscheinlich komplett bei dem Durchsatz mit Chatbots und wahrscheinlich sogar auch einen Teil der Coding-News quasi abbilden damit.
Das waren nur vier GPUs, das war schon sehr beeindruckend.
Ich glaube, was man festhalten kann, ist, dass sich da viel tun wird.
Ich glaube, das ist super schwer vorherzusagen, in welche Richtung das geht, aber es gibt, und das hast du gerade aus meiner Sicht total richtig gesagt, viele Effekte, die leider nicht in die gleiche Richtung ziehen, also eher gegenläufig sind.
Deswegen wird es spannend zu sein, wie das, also was für mich so das Allerwichtigste ist, oder das Alleroffensichtlichste ist halt quasi, was der Anreiz für Frontier Model quasi local zu gehen.
Das quasi torpediert ja ein Geschäftsmodell.
Und gleichzeitig, wie du gerade beschrieben hast, gibt es halt einfach diese disruptiven Player, auch wenn das bloß destillierte Modelle sind am Ende, oder zum guten Teil basierend auf destillierten Modellen, die das halt einfach möglich machen.
Mal gucken, wo da die Reise hingeht.
Genau.
Und jetzt ganz kurz noch dazu.
Deswegen bin ich so ein Fan von...
Open-Source-Harnesses, weil du da offen bist per se.
Du meinst Open-Code und Co.
Und Pi und sowas.
Jetzt gibt es ganz neu.
Oh, my Pi ist nochmal ein advancedes Pi und andere.
Wenn die LLMs nicht differenziert sind, also zur Commodity werden, dann müssen die LLM-Provider natürlich vertikal integrieren.
was sie ja tun, über genau die spezialisierten Coding, aber auch so Knowledge-Work-Umgebungen.
Und je tiefer die integrieren in die Geschäftsprozesse der Firmen, desto schwieriger sind die zu ersetzen durch irgendwas anderes.
Und deswegen, da bin ich halt wirklich ein Fan davon, so Open-Source-Harnesses zu benutzen, weil es da leichter ist, eben dann quasi das auszuhebeln.
Hat für und wieder.
Ja, oder im Endeffekt, was die Open-Source-Anbieter machen, die du meinst, sind ja im Endeffekt agnostisch.
Ich glaube, es gibt ja auch agnostische Paid-Provider.
Kannst du auch Long-Chain zum Beispiel nutzen.
Bin mir nicht sicher.
Perplexity, glaube ich, geht auch den Weg, wenn ich das jetzt richtig mit einem Auge verfolgt habe.
Dass die eher zu so einem Hub für Models wären, also die dann im Endeffekt passend orchestrieren und auch routen.
Genau.
Aber um mal wieder den quasi einen Bogen zurück zu dem Report von dir zu bekommen, das ist ja wahrscheinlich nicht das, womit man halt als Unternehmen halt anfängt.
Also quasi wie, und das hast du ja auch beschrieben, also vielleicht steigen wir da nochmal ein bisschen so ein, wie adaptieren Unternehmen diese neue Technologie?
Genau, kannst du da mal einen Einblick geben?
Genau, da gibt es auch da wieder alles von Top-Down, irgendwie alle machen jetzt das und wer es nicht macht, der hat hier keine Zukunft mehr.
Probiert einfach mal aus, experimentiert und guckt mal, gibt es da auch irgendwie alles Mögliche.
Und was man da sieht, finde ich, oder was irgendwie rauskommt, eigentlich niemand gesagt hat, auch in der späteren Phase, ist da so eine Governance beim Tooling, sondern es sind eigentlich bleiben, also am Anfang ist ja eh wichtig, dass jeder das nimmt, wo er mit er oder sie am besten irgendwie klarkommt.
Und das bleibt tatsächlich dann auch im Weiteren bei den Firmen, wobei die dann später Tooling drumherum aufbauen, was wiederum zu einer Konvergenz dann führt, weil bestimmte Toolkits gebaut werden, die dann spezifisch für bestimmte Agenten gebaut sind oder die ganz großen, die eben Plattform-Teams haben, die plattformisieren dann, also die kodifizieren bestimmte Prompts und Skills und auch Integration, also schon fertige Schnittstellen zu, was auch immer relevant ist, in fertigen Agenten sozusagen, die dann auch gesandboxed sind und so und die werden dann halt genommen, sodass du gar nicht mehr, das Harness ist dann nicht mehr der Hauptpunkt, an dem die Firmen da ansetzen.
Und was man sieht, dass das am Anfang immer einfacher ist, mit sogenannten Toll-Tasks anzufangen.
Also sprich, zu sagen, wir gucken jetzt mal, ob wir eine Migration damit gut hinkriegen oder eine Refactoring, Bugfix.
Oder auch interne Tools, also die Toll-Tasks, da hat Uber sehr stark in ihrem Talk drauf abgestellt.
Interne Tools war ja sehr beeindruckend von Mapbox, wo Uli da von einer quasi wie so einer Art Kambuschen Explosion von internen Tools gesprochen hat.
Weil natürlich sowohl bei Refactorings als auch Backfixes Migration auch internen Tools.
die der Erfolg oder die Qualität relativ gut überprüfbar sind.
Durch bestehende einfach Tests oder bestehende, sagen wir mal, wenn du ein Tool baust, dann weißt du ja genau, was du als Ergebnis sehen möchtest.
Das kannst du halt relativ gut überprüfen.
Und später...
Ja, genau, machen wir weiter.
Später ist dann natürlich, also habe ich jetzt schon ein bisschen vorgegriffen, aber geteilter Kontext, was du auch schon angesprochen hast, relevant, der wird quasi dann Teil der Infrastruktur.
kommen eben AI-Toolkits, wie Abwest das beschrieben hat, oder bei den größeren sogar dann Coding-Agents eigene sogenannte und auch Open-Source-Tools.
Also Spotify macht da relativ viel mit FleetShift und noch ein zweites Tool haben die erwähnt in ihrem Talk, was die intern nutzen, um ihre Ja, tatsächlich, FleetShift ist eher, meine ich, so ein Tool, mit dem sie ihre verschiedenen Instanzen von verschiedenen Systemen agentisch updaten können.
Genau, aber auch da wieder ganz viel so katalogisieren.
Also sprich, dass du immer weißt, welcher Stand wo deployed ist gerade.
So was können Agenten ja auch sehr gut quasi sich zusammensuchen, minimalinvasiv.
Oder du auch ganz einfach steuern kannst, welche Version für...
welches Release du jetzt gerade nutzen möchtest.
Also da kommen dann at scale.
Da geht es immer um at scale, was du vorher halt eher mühsam machen musstest.
Von Hand machen jetzt dann Agenten.
Da kann ich bei vielen Sachen Haken hinter machen, wenn ich so unsere Journey bei Trusted Shops sehe.
Also am Anfang auch relativ divers in den Tools gewesen.
Er versucht nicht zu viel zu blockieren, sondern zu schauen, dass man quasi ausprobiert.
Und jetzt halt, also wir konsolidieren gerade Richtung Claude, wahrscheinlich jetzt auch nicht der progressivste Move, sondern eher quasi konservativ.
Aber genau wie du sagst, halt irgendwie ein Harness haben, sich eher Gedanken machen, dass man halt irgendwie einen gewissen Standard in der Firma halt etabliert.
Und dann halt auch da wieder Dan Shapiro, also das quasi entlang der Levels quasi sich halt irgendwie hochfrisst in der Kette.
Und dann kommt man halt aber auch an Themen vorbei, die ein bisschen sportlicher sind, die wir dann immer mit Harness und Co.
beschreiben, aber die halt gerade bei größeren Organisationen, wenn ich so Richtung Security, Compliance und so schaue, ja auch einfach ein Fund sind, die man einfach nicht so einfach quasi löst.
Das hast du ja auch in deinem, in dem Report so ein bisschen nochmal analysiert.
Genau, ja, das hat man ja schon auch angesprochen, dass die goldene Regel einfach bleibt, der Engineer ist für den Code verantwortlich, unabhängig davon, ob das jetzt mit dem Agenten erzeugt ist oder nicht.
Uli in der Mapbox-Folge.
Fiona Fong macht es auch in ihrem wirklich coolen, sehr sehenswerten Talk sehr, sehr deutlich, was da dran hängt sozusagen und was auch für einen Typ von Leuten da gebraucht wird, beziehungsweise wie sich einfach die Einstellung auch der Entwickler da oder auch aller Beteiligten da ändern muss.
Denn Agentic Engineering.
verändert bei denen auch die gesamte, eigentlich den gesamten Software Development Lifecycle.
Man spricht auch davon, dass Designer einfach dann auch Code erzeugen.
Und wenn es nur ist, um irgendeinen Prototypen zu bauen, einfach um daraus dann die Requirements zu enginehren zum Beispiel.
Ich wollte jetzt auch wieder zum Thema Compliance und Security und dann immer wieder das alte, Agenten dürfen keine zentralen Agenten sein, die irgendwie allmächtig sind und quasi theoretisch an alles ran können, sondern es muss immer ein Korsett geben sozusagen, was die Rechte des Agenten immer auf die Person einschränkt, die diesen Agenten nutzt.
Ab West, da hat der Florian ja gesagt, dass sie das Impersonation nennen, dass der Agent immer wie so eine Person, eine bestimmte Person die Rechte hat.
Und genau, also insofern strikte rollenbasierte Zugriffe und gerade auch bei Ab West.
Datenklassifizierung, also sprich, welche Daten darf welcher Agent sehen.
Abwehr ist da ja auch ganz cool, weil bei Google mit Gemini es eben möglich ist zu sagen, es darf nur auf europäischen Servern verarbeitet werden sozusagen und da gibt es Zero Data Retention.
Deswegen können bestimmte Use Cases, wo einfach geschäftskritische Informationen drüber laufen, nur mit Gemini.
Modellen verarbeitet werden, während fürs Coding, was den Quellcode angeht, dann wird Cloud Code genommen, wo diese Einschränkungen nicht möglich sind, aber eben auch nicht nötig sind.
Ich finde, das ist also insbesondere, wie man die Agenten oder den Harness im Endeffekt mit der eigenen Welt halt koppelt, mit dem eigenen Kontext.
Das ist für mich eine der, so ein bisschen so aus der Erfahrung sprechend, eine der Hauptchallenges.
Gerade für mittlere, größere Organisationen, die haben ein anderes Risikoprofil, also meistens höheres Risiko, weniger Risikoappetit.
Da ist das halt deutlich schwerer, das halt umzusetzen, auch weil da eine gewisse Legacy halt einfach vorherrscht.
Anstatt halt quasi, du bist halt irgendwie klein, schnell, hast nicht so viel zu verlieren.
Das sind ungleiche Konstellationen.
Wie du gerade sagst, die Folge mit Uli, die war für mich so Eye-Opener.
Aber auch die Folge mit Florian.
Also quasi gerade dieses Impersonation, das ist auch eine der Sachen, in die wir ein bisschen tiefer reinschauen gerade.
Dieser YOLO-Mode und dann einfach Zugriff auf Confluence, Jira oder was so die Knowledge-Bases sind, ist halt mitunter gefährlich, weil du nicht weißt, was da alles an Daten liegt.
Genau, das finde ich tatsächlich auch spannend.
Also hatten wir auch in der Folge mit Florian von Abwest, dass deren starker Fokus auf Compliance als Fintech sie jetzt in eine Lage versetzt, dass sie Agenten halt viel gefahrloser, sage ich mal, einsetzen können als andere, weil sie eben im Gegensatz zu anderen Organisationen, wo es in ganz vielen Digitalorganisationen geht, es ja darum, Wissen möglichst zu teilen, dass jeder alles sich angucken kann, damit jede Person zu jeder Zeit alle Informationen zumindest in Reichweite hat, um die richtigen Entscheidungen zu treffen.
Und in bestimmten Oder in den Bereichen, in denen es eben nicht so geht, wurde es auch nie so gemacht und die haben jetzt dadurch eine viel stärkere systemische Abgrenzung, wie er auch beschrieben hat, dass die Zugriffe auf die produktiven Services ganz stark eingeschränkt sind.
Es gibt immer diese Break-Glass-Accounts für Notfälle, aber im Normalfall.
gibt es nur ganz bestimmte Accounts, die irgendwelche Änderungen am System vornehmen können.
Es gibt andere Accounts, die irgendwie Logfiles lesen können und Metriken einsehen können.
Diese Grundlage, die hilft Ihnen jetzt massiv.
Und das ist was, was tatsächlich insgesamt auch durchscheint durch das alles, wenn man vorher, und da würde ich mal sagen, also rausgezoomt, wenn man vorher in Technical Excellence investiert hat und wirklich technically exzellent ist und das geht halt dann auch bis eben in die in sehr gute Compliance und Security Posture, dann hat man es, würde ich sagen, einfacher.
Laura Tacho hat in ihrem Talk das so wunderschön aufbereitet.
Sie hat erst eine Slide drin, die sagt irgendwie, die Hälfte der Organisationen aus ihrem umfangreichen Dataset berichten.
davon, dass sie mehr Inzidenz haben als vorher.
Und da hat sie die nächste Slide und sagt, 50 Prozent der befragten Unternehmen berichten von weniger Inzidenz.
Und das ist im Prinzip der ganze Punkt, was wir auch schon mal gesagt haben.
Es ist halt so ein Multiplier.
Böse würde man sagen, shit in, shit out.
Oder eben genau das Gegenteil.
Das ist schon spannend.
Und insofern finde ich aber auch irgendwie, fast ein bisschen beruhigend.
So habe ich die Folge mit Florian auch wahrgenommen.
Die Sachen, die wir immer sagen, wo wir immer sagen, die sind immer wichtig und auf die haben wir schon immer geachtet, dass du ein gutes Test-Setup hast, dass du CICD sauber durchdekliniert hast, dass du eine gute Observability hast, einfach generell technisch exzellent, das hilft dir halt.
Und das ist jetzt umso wertvoller.
In der neuen Phase.
Der Punkt, den du gerade gemacht hast, im Endeffekt, das multipliziert alles.
Also das Positive wie das Negative.
Das ist halt im Endeffekt das, was man sieht und das, was du ja auch im Endeffekt im Report beschrieben hast oder was man rauslesen kann.
Am Ende ist das halt ein riesiger Beschleuniger, der in alle Richtungen natürlich funktioniert.
Und ich glaube, jedes Unternehmen auch ganz natürlich läuft da entlang.
der Dan Shapiro Levels und alle wollen natürlich höher, schneller, weiter und erreichen halt an der einen oder anderen Stelle halt irgendwie so ein Dach und da müssen sie dann halt irgendwie dran arbeiten und absolut richtig, ich fühle mich gerade so, als wenn ich es alles wiederhole, wenn du das halt in den letzten Jahren gut gemacht hast, dann kommst du weiter, wenn du da Baustellen hast, dann wird das halt sehr schnell sichtbar, sehr schnell sichtbar.
Ja, das ist auch, sagen wir mal, der erste Teil schon aus dem Fazit eigentlich.
Und ein weiterer, den ich persönlich so ein bisschen fast beruhigend oder wohltuend finde.
Ein zweiter Punkt, der auch in die Richtung geht, ist, dass auch die ganz Großen noch nicht wirklich verstanden haben, wie das so funktioniert.
Denn, was wir auch schon gesagt haben, ROI ist...
noch nicht belegt.
So, das können auch die ganz Großen noch nicht.
Die können keine direkte Verbindung ziehen zwischen dem Token-Maxing oder den Ausgaben und dem Business Impact und die Thematik, wie ändert sich eigentlich die Organisationsstruktur, ändern sich Teamgrößen, welche Rollen wird es geben?
Das war absent.
Also es war einfach nicht, es ist kein Thema gewesen in den Talks, die ich mir angeguckt habe.
Es gibt natürlich noch andere Berichte, wo es eher theoretischer dann in so eine Richtung geht.
Aber da habe ich noch von keiner Firma gehört, die es schon wirklich implementiert.
Das heißt, neulich gab es einen Artikel von Coinbase.
Die bauen die Organisation jetzt so um und noch irgendwie eine andere.
Aber es gibt noch keine Erfahrungsberichte, wie es dann aussieht.
Könnte man irgendwann mal Bastian halt irgendwie nochmal einladen.
Bastian Buch Getaway Group.
Die haben das ja gemacht.
Ein bisschen kleiner.
Aber du hast recht.
Quasi in groß.
Und quasi dann jetzt so Erfahrungsberichte kenne ich auch nicht.
Und ich finde halt, du hast es ja gerade schon angerissen, die Kosten, die jetzt da eigentlich entstehen.
Das eine ist natürlich das Token Maximizing, aber halt auch.
all die Kosten der Organisationen halt umzustellen, bis hin zu, am Endeffekt, womit wir uns zum Beispiel auch beschäftigen, ist halt, inwiefern wir die Architektur umstellen müssen.
Weil also so in einer Welt von vielen, also ich habe den Eindruck, Microservices sind nicht Best Practice für agentische Systeme, weil du quasi, also quasi der Kontext, die Boundaries halt relativ eng sind.
Auch da, also quasi du investierst in Architekturarbeit, legst Systeme vielleicht zusammen und so weiter und so fort.
Und quasi eigentlich ist es noch gar nicht proof, dass das oder zu welchem Grad das halt einen Impact auf die Organisation, nicht auf die Organisation, aber auf die Company hat.
Auf den Umsatz, auf den Erfolg, wie man das auch immer nennen will.
Ja, mit Microsoft ist das finde ich ganz spannend, weil intuitiv würde ich dir ein Stück weit recht geben.
Wobei ich mich da gleich auch verbessern würde, denn in einem Monorepo wiederum ist es dann weniger ein Problem.
Es kommt halt darauf an, was du sonst für Kontext hast.
Ich glaube halt, die Frage ist halt, warum hast du, aber das ist vielleicht auch quasi so ein bisschen Aufruf an jemanden, der da Lust hat, mit uns zu diskutieren.
Warum hast du halt früher geschnitten?
Wenn du geschnitten hast, um halt Cognitive Flow drunter zu kriegen, dann würde ich sagen, ist der Schnitt heute egal.
Wenn du halt irgendwie sklavisch geschnitten hast, weil, weiß ich nicht, wir haben zum Beispiel enorm viele Lambda Functions und haben das halt entlang der quasi HTTP-Methoden geschnitten, dann quasi auch das brauchst du wahrscheinlich nicht.
Andere Schnitte werden sinnvoll sein, entlang von gewissen Domänen-Grenzen.
Das macht schon total Sinn.
Ich will sagen, dass aber auch hier agentische Systeme nicht Halt machen.
Und wenn du das halt quasi maximieren willst, dann wirst du da auch daran müssen.
Und das sind alles Kosten mit einem, ich will gar nicht sagen ungewissem Ausgang, aber wo zumindest noch nicht hinten raus klar ist, quasi was ist der tatsächliche Impact aufs Geschäft.
Also ich glaube Geschwindigkeit, da kann man einen Haken hinter machen.
Aber tatsächlich wirtschaftlicher Erfolg.
Und das ist wahrscheinlich auch okay, dass es heute noch nicht beantwortet ist.
Aber bemühe mal eine Phrase, da bleibt es spannend.
Total, genau.
Trotzdem sehe ich ehrlich gesagt keine Realität, in der das wieder verschwindet.
Vielleicht geht es ein bisschen anders an, aber ganz verschwinden wird es wohl nicht.
Das mit der Architektur finde ich tatsächlich spannend.
Also ich habe da auch noch Florian im Kopf.
Die haben ja eine sehr ausgeprägte Microservices.
Und für die rentiert sich das wieder massiv, weil da ja genau wieder die eigenen Environments der Services, die Boundaries der jeweiligen Environments inklusive Zugriffsrechte helfen wiederum, agentische Fehler zu minimieren oder das Risiko durch Agenten zu minimieren.
Und tatsächlich.
Also was natürlich bestehen bleibt, ist irgendwie unterschiedliche Load Patterns.
Wenn du Services hast, die relativ wenig stark frequentiert sind, das bleibt bestehen, das macht immer noch Sinn.
Und dann habe ich auch gedacht, gerade das mit den HTTP-Methoden, da kann es natürlich sein, dass du viel häufiger liest, als du schreibst.
Das ist ja oft so.
Insofern, das macht dann vielleicht immer noch Sinn.
Aber auch die...
Agenten haben ja begrenzte Kontextfenster.
Und auch da kommt es dann wieder darauf an, sozusagen, also die Grenzen des Services, die hängen halt eigentlich auch da wieder, wie vorher auch davon ab, wo durchgeht der Business Value, also worauf optimierst du, was du häufiger ändern möchtest.
Es ist nie gut, wenn du häufiger irgendwie immer wieder die gleichen drei Services anpassen musst, weil du quasi häufig daran iterierst, wie genau dieser Prozess, der da durchläuft, sich verändern muss.
Genau, wobei, wenn ich jetzt so genauer darüber nachdenke, dann kann sich genau auch diese Wertschöpfung durch Agenten ja komplett ändern.
Das heißt, das, worauf du früher optimiert hast, auch bei dieser sozusagen Anpassungshäufigkeit durch die Wertschöpfungsketten im Unternehmen, das kann sich total ändern, weil auf einmal diametral andere Wertschöpfungsketten entstehen.
Von daher ist es offen, I don't know, weil es ein bisschen philosophisch ist.
Ich glaube, wir haben unterstrichen, dass da noch viel ungeklärt ist.
Insofern, auch wenn wir hier vielleicht nochmal ein paar Monate nochmal einen Blick zurückwerfen und gucken, wie sich Zeit verändert hat.
Ich glaube, es wird enorm sein.
Oder wie war früher?
mit Andreas auch immer gesagt haben, it depends.
Lieblingsspruch.
Ich glaube, damit sind wir einmal gut durchgerauscht.
Wir packen den Report auf der Webseite, würde ich sagen.
Da sind auch ganz viele Ressourcen drin.
Die ganzen Talks kann ich nur empfehlen, wenn man Zeit und die Muße hat, sich da mal durchzukauen.
Der Report enthält auch Zusammenfassung von einigen der Quellen.
Wenn man eben nicht ganz so viel Zeit hat, kann man sich die auch durchlesen.
Oder man knallt es sich in Notebook-LM und lässt sich irgendwie einen Podcast davon erzeugen oder so.
Genau.
Das heißt, du hast viele Podcasts zu einem Dokument gemacht, die dann wiederum dazu verwendet wird, dann einen Podcast zu machen.
So schließt sich der Kreis.
Spannend.
Und wir haben ja jetzt diesen Podcast gemacht.
Also von daher braucht man es auch nicht durch Notebook-LM zu jagen, weil Wir sind ja der Podcast dazu, hast eigentlich recht.
Perfekt.
Dann machen wir jetzt hier einen Strich und dann war es das mit dem Deep Dive.
Wollen wir zur Ankündigung kommen?
Kommt jetzt die Ankündigung, würde ich sagen, genau.
Dann schieß mal los.
Wer ist schwanger?
Oh, sieht man es denn schon?
Das war die vorherst letzte Episode auf Deutsch.
Tatsächlich ab demnächst, um nicht zu sagen ab nächster Woche, partnern wir mit Impala Search.
und werden den Podcast dann unter dem Titel Beyond Vibe Coding auf Englisch weiterführen.
Das Ziel ist tatsächlich, den Fokus auch im Laufe der Zeit ein bisschen zu erweitern.
Wir werden immer, Agentic Engineering wird immer der Kern sein, aber da das ja ein Operating Model change ist, macht es halt beim Engineering ja nicht halt.
Wir wissen ja schon, dass zumindest Product Management, aber auch Design, aber auch andere.
Funktionen relevant sind und auch betroffen sein werden.
Und das wollen wir uns im neuen Format angucken.
Und als ersten Gast haben wir einen wahnsinnig spannenden CPO von einem europäischen AI-Posterchild.
Wir haben die Episode schon aufgenommen.
Das Gespräch hat uns total geflasht.
André?
Das war tatsächlich, wie hast du es gesagt, sehr kompakt, sehr viel Inhalt.
Genau.
Ich hatte danach tatsächlich einen glühenden Kopf.
Hat ein bisschen gedauert, als ich das alles so prozessiert habe.
Und insofern gibt es uns natürlich auch die Möglichkeit, dann auch nochmal anderssprachige, also quasi englischsprachige Gäste einzuladen.
Wir hoffen, der Change ist für euch nicht allzu groß.
Und ihr bleibt uns gewogen.
Hört rein.
Wir bemühen uns weiter, spannende Gäste zu bekommen.
Und insofern freuen wir uns natürlich auch immer auf Empfehlungen und sagen bis demnächst.
Bis nächste Woche.
Der hmzde-Podcast ist ein gemeinsames Projekt von Sebastian Heidemeier zu erben und André Neubauer.
Infos zum Gast und Themen aus dem Podcast findest du in den Shownotes.
Diskutieren kannst du mit uns bei LinkedIn und für alles andere, zum Beispiel wen du gerne mal hier hören möchtest, kannst du gerne eine E-Mail an podcast.hmzde.tech schicken.
Vielen Dank für deine Zeit.
Wenn es dir gefallen hat, abonniere den Podcast.
Bis zur nächsten Folge.