# Agentic Engineering: Orchestrator Shift & Organizational Impact

**Podcast:** HMZE
**Published:** 2026-03-19

## Transcript

Ich mag, dass du meine Süfflöse, Süfflöse, Süfflöse, Süfflöse, wie heißt das?
Wir haben schon unseren ersten Outtake.
Süfflöse.
Süfflöse.
Herzlich willkommen zur siebten Folge unserer neuen Staffel von HMZE Beyond Vibe Coding.
Der Podcast, in dem wir den fundamentalen Change in der Softwareentwicklung begleiten.
Ich bin Sebastian Heidemeyer zu Erpen, CTO bei North.io.
Und ich bin André Neubauer, CTPO.
bei Trusted Shops.
Schön, dass ihr wieder da seid.
Heute machen wir ein bisschen was anderes.
Wir haben uns vorgenommen, mal ein Recap der bisherigen Episoden zu machen, so ein bisschen über die Erkenntnisse zu sprechen und da auch einen Workshop einzufließen zu lassen, den wir bei Trusted Shops vor kurzem gemacht haben mit Fabian Wessner und einem Kollegen, die zu Agentic Engineering uns ein bisschen Input geliefert haben.
Absolut spannende Erkenntnisse daraus.
Und was Auch spannend war für uns mal die bisherigen Erkenntnisse aus den ganzen Episoden zusammenzufassen und die Erkenntnis eigentlich, dass sich das alles relativ eins zu eins auch auf andere Wissensarbeitsdomänen übertragen lässt.
Softwareentwicklung ist hier einfach ein bisschen voraus.
Mehr dazu gibt es am Ende der Episode, also bleibt dran.
Freut euch drauf.
Viel Spaß beim Hören.
Herzlich willkommen.
Heute haben wir keinen Gast, den wir vorstellen müssten.
Und deswegen starten wir tatsächlich direkt in unser erstes Segment Text Setup.
Und genau, wir haben bisher ja primär unseren Gästen zugehört.
Heute teilen wir mal so ein bisschen, was bei uns eigentlich so los ist.
Ich erzähle eher so von meinem persönlichen Text Setup, weil bei uns in der Firma, wir haben ganz verschiedene Text Setups und sind gerade erst dabei, mal so ein bisschen zu gucken, was alles so benutzt wird und wie wir das vielleicht auch ein bisschen stärker koordinieren.
Ich bin gerade ganz wild am Experimentieren.
Ich habe über Weihnachten intensiv mit Anti-Gravity gearbeitet.
Das ist auch immer noch meine Idee der Wahl sozusagen, wo ich tatsächlich auch Cloud Code drin laufen lasse teilweise.
Und auch wenn ich mit Codex, damit experimentiere ich auch gerade rum, wenn ich mit Codex arbeite, dann habe ich mein Terminal da drin und schaue mir tatsächlich auch Files an, die erzeugt werden, einfach weil ich dann doch noch eine Nähe zu Config-Files oder teilweise auch Code haben möchte.
Und ich finde das grundsätzlich ganz spannend, habe aber als nächsten Schritt mir vorgenommen, mich mal wirklich in Goose und Py einzuarbeiten, weil ich glaube, dass im Harness sehr, sehr viel drin steckt.
Wenn man sich in so einem Harness von einer der von einem der großen Frontier Labs begibt, also sprich Antigravity, Cloud Code oder Codex, dann ist man eben auf diesen gepinnt.
Wenn man aber ein freies Harness nutzt, OpenCode, Goose, BI, also Harness im Prinzip, die Umgebung, die die Coding-Agenten steuert, dann hat man per se eine größere Freiheit und kann oft auch den Umgang mit dem Kontext besser konfigurieren und für die eigenen Zwecke benutzbar machen.
Und das ist mir ganz lieb, insbesondere auch, weil mir bei den Harnesses der großen Firmen zumindest für mich ist noch nicht genau transparent.
Ich habe mich da jetzt nicht in alle super tief eingearbeitet, aber wie man am besten das Kontextmanagement macht.
Die machen viel out of the box, was aber Genau, ich kann nicht gut einschätzen, ob das optimal ist.
Und bei Open Source Harnesses, da bilde ich mir ein, dass ich das besser einschätzen kann.
Und genau, das ist der nächste Schritt, wo ich mich einarbeiten möchte.
Hat noch den Vorteil, dass sollte es dazu kommen, dass irgendwann durch Competition einzelne von den Anbietern aus dem Markt gedrängt werden und dann die Preise steigen.
Könnte ja möglicherweise sein, zumal wir auch wissen, dass Cloud Code beispielsweise sehr stark subventioniert ist von...
von Anthropic, also wer mal über seine Quote rübergegangen ist und dann mal gesagt hat, okay, jetzt mal API Metering, der sieht, wie schnell so dann quasi 20 Euro oder welchen Vertrag man auch immer hat, aufgebraucht sind per API Metering.
Und da bieten Open Source Alternativen natürlich andere Möglichkeiten, dass man einfach besser switchen kann, insbesondere wenn die ganze Logik im Harness ist, dann kannst du einfach sozusagen einen anderen Agenten wählen.
Natürlich unterscheiden sich die Modelle ein Stück weit, aber rein jetzt in der Interaktion, ob es jetzt irgendwie ein Gemini ist, ob es jetzt ein Claude ist, ob es jetzt ein Codex-Modell ist, alle sind sehr, sehr capable.
Und mit dem entsprechenden Harness, glaube ich, kommt man mit allen sehr, sehr gut voran.
Geht so ein bisschen in die Prediction, die wir, ich weiß gar nicht, welche Folge da, also welche Nummer das war, aber die Folge mit Jörg, der ja auch gesagt hat, am Ende wird das alles Open Source.
Genau.
Bei den Models, da weiß ich noch nicht genau.
Also da nehme ich auch gerade viel wahr, dass jetzt, Gwen hat ja das, ich glaube, Version 3 von seinem Coder-Model gerade vorgestellt, was auch sehr, sehr gut ist.
Devstral und so, die ganzen Models, die waren alle noch, glaube ich, zu weit entfernt von den Frontier-Models.
Auch das Gwen-Coder-Model ist fairerweise In der größten Ausbaustufe kann man es auch nicht lokal wirklich laufen lassen und es ist auch dann doch weit weg von dem, was Frontier-Models können.
Da kann ich noch nicht genau sagen, ob man das irgendwann schafft, die Modelle so zu destillieren, dass sie für Coding optimiert sind und da dann nah genug an die Performance von Frontier-Modeln rankommen.
Oder der andere Stream, ob man es schafft, eine Hardware-Lösung zu finden, die es einem ermöglicht, oder ob es vielleicht Open-Source, also quasi offene Anbieter gibt, die sagen, wir betreiben einfach nur die Modelle und du kannst ja on-demand irgendwo was klicken und genau, kannst dann aus der Cloud die API konsumieren.
Das wird man sehen.
Ja, das gibt es schon.
Müssten wir jetzt mal nochmal kurz schauen.
Also quasi, dass du Inferenz halt einfach irgendwo kaufen kannst.
Ich musste gerade schauen, ich hätte also Gwen35, hätte ich gestern irgendwas bei LinkedIn gelesen, musste gleich nochmal schauen, quasi das lokal laufen zu lassen.
Das ist ja das, wo ich noch, wie soll ich sagen, das ist glaube ich das Endgame.
Das wird natürlich...
Ich bin gespannt, was das für den ganzen AI-Sektor und auch für die Bewertung von der Companies dann bedeutet, wenn du das halt lokal laufen lassen kannst, weil dann sind halt natürlich diese ganzen Subscriptions halt irgendwie weg.
Aber man sieht mehr und mehr Posts, wo Leute das lokal laufen lassen mit guten Ergebnissen.
Also die Maschinen sind natürlich noch viel zu groß oder viel zu teuer.
Lass mich so rum sagen, groß ist wahrscheinlich gar nicht so das entscheidende Problem, sondern halt einfach teuer.
Aber am Ende, glaube ich, weiß gar nicht, ob das so entscheidend ist, wie gut das im Vergleich zu Frontiermodels abschneidet, sondern eher wie gut das für die tägliche Arbeit ist.
Also wenn die Ergebnisse gut genug sind, und das wird wahrscheinlich dann auch wieder entlang der Industrien sein, für einige wird das gut genug sein und für andere eben nicht gut genug.
Und dann musst du halt irgendwie da deinen Stack wählen.
Aber genau, das ist eine der Herausforderungen, die wir auch haben.
Ich kann ja mal ein bisschen weitermachen.
Also ich habe gar nicht so viel, also ich probiere auch gefühlt alles immer wieder mal aus, habe aber ehrlich gesagt auch mit dem Shift, den wir bei Trusted Shops quasi vor uns haben, auch quasi eigentlich das praktische Beispiel vor der Tür.
Also brauche gar nicht so viel Pet Projects, weil ich es halt tagtäglich halt auf Arbeit habe.
Mit all den Herausforderungen, hat er ja schon am Anfang gesagt, jetzt so die ersten Schritte, auch im Training nochmal gegangen, mit all den Themen, die dann halt Augen aufpoppen, werden wir bestimmt gleich drüber reden.
Und da quasi ist natürlich auch eine wesentliche Frage, was ist das Tooling?
Also ehrlich gesagt, träume ich ein bisschen nach der Staffel, um mal so ein paar Sachen nochmal zu referenzieren.
Nach der Episode mit Markus träume ich ein bisschen von Cloud Code Everywhere.
Das ist natürlich dann, wie du auch gerade gesagt hast, am Ende wahrscheinlich auch eine Preisfrage, gerade für größere Organisationen, weil das natürlich schnell auch ins Geld gehen kann.
Aber die Durchgängigkeit von Software, also one tool to rule them all, so ein bisschen, finde ich eigentlich schon irgendwie spannend.
Finde ich schon spannend.
Genau.
Es kommt, glaube ich, darauf an, wie man das nutzt, weil ich nutze, so wie Markus das für Cloud Code beschrieben hat, nutze ich inzwischen OpenClaw.
Da sind meine Notizen drin, da ist meine Knowledge Base drin und kann insofern da OpenClaw auch ein relativ gutes Persistent Memory Management hat tatsächlich.
Also es kann sowohl Full-Text-Search machen über indexierte, also in der SQLite-Datenbank indexierte Texte, macht aber auch, nutzt auch Beddings, also Vector-Similarity-Search und hat sogar einen Scoring-Mechanismus, der 70-30 beides miteinander verknüpft und darüber eine relativ gute Architektur meines Erachtens nach abbildet.
Also schon wirklich sophisticated Memory-Management oder persistent Memory-Management für Agents.
Und damit klampen so Knowledge Work Tasks schon relativ gut.
Also es geht viel besser, dass das Ding ungefähr meinen Stil versteht und auch in dem Stil schreibt, dass es tatsächlich echte Informationen nutzt.
Das macht auch Halluzinationen immer noch.
Ich nutze es mit meiner Anti-Gravity-Subscription und für derartige Sachen.
braucht man gar nicht so viele Tokens.
Mit anderen Worten, da hat man gar nicht so ein Quota-Problem.
Quota-Problem hast du dann, wenn du länger laufende Agent-Tasks hast.
Dann läufst du genau und dann wird es wieder eine Preisfrage.
Aber für so reines Knowledge-Management ist es schon, glaube ich, ein ganz gutes Setup aktuell.
Ja, da können wir eigentlich direkt, wir können ja bisher.
Ist ja unser Podcast, wir können ja bestimmen, in welcher Reihenfolge das hier geht.
Können direkt mal so ein bisschen weitergehen.
Für mich quasi die Summary von diesen zwei Tage gehabt, Workshop, wie gesagt, mit Fabian und Dennis.
Erster Tag eher so Fundamentals, also wirklich Installation, Environment.
Wie funktioniert das?
Quasi agentenbasiert.
Was sind so die Terminologien?
Quasi Specs und Co.
Und der zweite Tag, also erster Tag dann auch mit so einem Greenfield-Produkt oder mit einer Greenfield-Projekt-Idee, die halt eigentlich immer klappt.
Also quasi so tief die Messlatte legen wie möglich.
Und am zweiten Tag dann tatsächlich an Themen, an denen wir quasi so arbeiten.
Genau, bloß mal, um ein bisschen den Kontext zu erklären.
Aber mein Takeaway von den zwei Tagen ist eigentlich Game-Changing, but complicated.
Also quasi, wenn du es richtig machst, dann ist das halt, ist es wirklich verrückt.
Für mich ergeben sich da auch gerade so ganz viele Schaubilder, so angefangen von, wie adoptierst du das?
Machst du das halt eher quasi so, also bleibst du halt irgendwie beim Tooling stehen?
Das ist eher so auf einer individuellen Ebene.
Ich glaube, hatten wir auch mit Sebastian, würde ich so sagen, quasi das, was wir mit Sebastian so ein bisschen besprochen haben.
Oder adaptierst du das halt als Gesamtorganisation?
Dann bist du eher so auf einer konzeptionellen Ebene.
Das Gegner ist natürlich viel tiefgreifender, hat viel mehr Power, aber auch viel mehr, setzt viel mehr Voraussetzungen, Voraussetzungen, Voraussetzungen.
Sehr gut.
Genau.
Und dieses complicated, das liegt halt einfach daran, dass es einfach eine neue Disziplin ist.
Wir werden ja wahrscheinlich auch gleich nochmal drüber sprechen, was so die Erkenntnisse sind.
Diese neue Disziplin, die halt irgendwie alle erst erlernen müssen und genau dann kommst du zu dem Punkt, wofür nutze ich es, wie nutze ich es und das wird wahrscheinlich auch das neue Handwerkszeug sein.
Dieses, wie instruiere ich, wie orchestriere ich, was nutze ich, wann wie.
Das war in dem Workshop auch, also du hast immer wieder gesehen, quasi Fabian, Dennis, die halt ja, einfach da wirklich die drei, vier Monate voraus sind, also oder beziehungsweise gar nicht drei, vier Monate voraus sind, aber sich drei, vier Monate halt intensiv damit auseinandersetzen und dann halt einfach wissen, wie man in gewissen Momenten halt irgendwie reagiert, welchen Trick man halt irgendwie anwendet, wo man Sub-Agents nutzt, wo man vielleicht das neue Teams-Feature oder Team-Feature nutzt.
Das ist, glaube ich, das sind die, wie soll ich sagen, das ist das neue Meet, was halt quasi dann die Bilder zukünftig brauchen.
Du musst eine Intuition dafür entwickeln.
Genau.
Was du gerade gesagt hast auch, dass es eine neue Disziplin ist und dass man einfach ein völlig neues Feld sich erschließen muss, hat mich daran denken lassen, Stefan Schmidt hat ja in Episode 1 auch gesagt, dass ein Multiplikator ist, dass du entweder einen negativen Multiplikator oder einen positiven Multiplikator hast.
Und jetzt habe ich gestern einen Talk gesehen von Laura Tacho, die war bisher CTO bei DX vom Pragmatic Summit von Gergely Orsch.
Und die hat tatsächlich zwei Slides gehabt, die ganz cool waren.
So in ihrer...
Gegenüberstellung.
Und zwar hat sie gesagt, dass Kunden berichten, dass sie doppelt so viele, also dass bestimmte Firmen berichten, dass sie doppelt so viele Customer-Facing-Incidents haben durch Agentik.
Und dann hat sie direkt danach eine Slide gemacht, dass Firmen berichten, dass sie 50 Prozent weniger Customer-Facing-Incidents haben, seit sie agentisch arbeiten.
Also genau dieses Die Spreu trennt sich vom Weizen sozusagen.
Wenn du es richtig nutzt, dann läuft es gut.
Wenn nicht, dann läuft es eben schlecht.
Ja, ja, ja.
Also das muss ich auch sagen, als ich für mich so ein Recap gemacht habe, der zwei Tage noch mal so runtergeschrieben habe, was sind ja meine Erkenntnisse oder meine Gedanken dazu?
Die Varianz in den Ergebnissen ist tatsächlich groß.
Das ist, glaube ich, ein deutliches Zeichen dafür, dass...
Also am Ende geht das halt über Adaption.
Und das ist halt Training, Training, Training mit der Herausforderung, dass sich Sachen halt wahrscheinlich auch nochmal dramatisch verändern werden.
Dieses Team-Feature, also im Endeffekt kannst du mit Cloud Code jetzt dir eine Organisation bauen.
Und zwar komplett, auch Team of Teams im Zweifelsfall.
Und das hat natürlich dann zur Folge, dass Du eigentlich nicht nur jetzt trainieren musst und dann hast du deine Organisation, sondern quasi kontinuierlich und das halt auch mit einer hohen Frequenz und halt, wie soll ich sagen, also auch mit immer einer gewissen Offenheit, weil auch gewisse Konzepte halt einfach wieder verworfen werden.
Also keine Ahnung, ob wir noch in drei Monaten über Subagents sprechen.
Und das ist, glaube ich, schon eine Herausforderung für Organisation.
Ja, ohne Po.
Genau, das ist tatsächlich so ein allgemeines Thema.
Da frage ich mich auch immer, sind wir einfach nur zu sehr, also sprich die Beschleunigung der Veränderungsgeschwindigkeit.
Da frage ich mich mal, sind wir eigentlich zu sehr im Moment oder ist es eigentlich nicht ganz normal, so wie wir es mit Markus auch besprochen haben.
Weil eine Beschleunigung der Innovation gab es ja in der Geschichte jetzt sicherlich nicht sozusagen linear, aber schon, wenn man rauszoomt, dann schon exponentiell.
Und die Leute haben immer irgendwie Schritt halten können.
Gerade fühlt es sich an, dass es sehr, sehr schwer ist, da Schritt zu halten.
Ja, aber ich glaube, die Rückschau ist immer einfach.
In der Rückschau ist es halt so eine Romantisierung.
Du vergisst halt einfach als Mensch schnell.
Ich kann mich auch ganz gut erinnern, als...
Eine Anekdote mit Stefan Schmidt, als wir, wie waren das, wer da waren das gewesen, Continuous Delivery, quasi gab es irgendwie so einen relativ bekannten Blogbeitrag, also jetzt in der Rückschau ist das ein bekannter Blogbeitrag gewesen, wo dann gesagt wurde, Mensch, hier, wir deployen mehrmals am Tag und Stefan und ich waren damals beim mobilen Scout.
Und haben halt irgendwie alle zwei Wochen gab es dann einen Release.
Und das hat irgendwie in den Grundfesten alles verändert und geschüttelt.
Keiner hat verstanden, wie soll das gehen?
Und das erzeugt so einen Stress.
Und in der Rückschau, jetzt würde man sagen, ja, war aber irgendwie eine wilde und war eine schöne Zeit.
Bis hin zu dem Punkt, auch vielleicht eine Anekdote, wo wir dann damals das Deployment, du warst ja dabei.
Sorry, muss ja gerade.
Wir können ja die gleiche Geschichte erzählen.
Ich kann sich noch an die Situation erinnern, dass wir irgendwann mal so schnell waren, dass die Mail, dass das Bild für die Produktion fertig war, vor der Mail kam, dass das Bild für die Produktion angestoßen wurde.
Das ist so, das ist, glaube ich, eine nette Anekdote, was eigentlich ein bisschen zeigt, wie sich dann halt auch so ein Weg ebnen kann.
Aber wenn du davor stehst...
dann sieht der Berg halt hoch aus.
Und ich gebe dir recht, aktuell sieht er halt sehr hoch aus.
Genau, ja.
Ja, möchtest du noch ein bisschen mehr in die Details gehen von dem Workshop?
Ja, ich kann ja mal so ein paar Gedanken einfach ausspeichern, wie man so schön sagt.
Also für mich war wirklich das Erkenntnis des Workshops so game-changing but complicated.
Ich glaube, das, was wahrscheinlich mittlerweile überall klar ist, also wenn du da eher methodisch auf Software-Ingenieuring schaust mit Inner- und Outerloop, dann ist eigentlich relativ schnell klar, dass der Innerloop halt eigentlich wegfällt.
Also für uns Menschen, das wird weitestgehend halt an Agenten halt irgendwie gehen.
Der Fokus geht ganz klar auf den Outerloop, auf die Sachen, die da liegen.
Ich glaube bis hin zu dem Punkt, mit Robert haben wir darüber ja relativ intensiv gesprochen.
Eigentlich gibt es einen neuen Loop.
Ob der jetzt Elastic heißt oder das, was ThoughtWorks quasi propagiert, ist egal.
Aber der Fokus geht halt ganz klar auf die Tätigkeiten, die eher heute noch im Outerloop liegen, also eher Requirements Engineering, viel stärker quasi sich Gedanken darüber machen, was man machen will.
Also eher das Um-das-Was, nicht das Wie.
Aber wenn man das so...
konsequent weiterdenkt, dann ändert sich halt eigentlich, ändern sich Workflows in den Teams.
Das quasi, es geht nicht mehr darum, halt irgendwie Software zu schreiben, sondern es geht darum, halt irgendwie ein System zu instruieren, quasi verschiedene Agenten zu orchestrieren.
Auch ganz lustig, so Anekdote vom Workshop.
Da laufen dann halt einfach drei Agents oder drei Agent-Teams oder Agents mit Sub-Agents an verschiedenen Themen.
Und das scheint möglich zu sein.
Ich hätte eher vermutet, dass das so ein bisschen aufs Cognitive Load halt irgendwie schlägt, dass man diese Kontextwechsel zu hart sind.
Aber so, erster Eindruck, nö, gar nicht.
Kann man wahrscheinlich nicht übertreiben oder also hat alles eine Limitation, aber du kannst tatsächlich parallel auch nochmal an mehreren Sachen arbeiten.
Also es ist nicht nur die eine Dimension, dass Agents Sachen übernehmen, sondern halt auch noch diese Parallelisierung von Agents, fand ich auch noch einen ganz netten Gedanken.
Und ganz kurze Frage dazu.
Ja, bitte.
Also ich meine, Cognitive Load ja auch, beziehungsweise für die Agents bedeutet das, die Sachen, an denen sie gemeinsam oder wo es einen Overlap gibt, da muss es einen Kontext-Sharing geben.
Also sprich, da müssen die...
miteinander kommunizieren.
Aber da gibt es ja bei den meisten Frameworks so einen Orchestrator-Agent oder so, der sich darum kümmert.
Aber es ist ja dennoch auch sehr großer Cognitive Load für die Leute, die so eine Agent-Teams dann betreiben.
Darauf war das gerade gemünzt.
Also es ist eben der menschliche Cognitive Load.
Ich glaube, für die Maschinen ist das...
Das ist eine technische Lösung, die muss halt in place sein.
Ich fände dahingehend spannend, dass viele Wege führen nach oben.
Also du kannst natürlich sagen, du baust mehrere Features in einem Team, jetzt mal Cloud Code, also mit dem Team Feature, wo halt einer der Lead ist und dann halt irgendwie die Tasks verteilt und die dann halt irgendwie in Sync sind.
Ich glaube, darüber kannst du das halt einfangen, dass sie sich nicht gegenseitig auf die Füße treten.
Kannst natürlich auch das...
also quasi die Orchestrierung bei dem Menschen halt lassen und halt einfach, da musst du dir halt selbst überlegen, quasi wie weit du quasi Features auseinanderbauen willst, damit die sich halt irgendwie nicht selbst auf die Füße treten.
Aber das ist auch, was ich meinte am Anfang.
Wir würden wahrscheinlich vor, hätten wir vor drei, vier Monaten angefangen, dann hätten wir gesagt, okay, wir können mehrere Agents laufen lassen.
Die müssen halt ein bisschen aufpassen, dass sie sich nicht gegenseitig auf die Füße treten und dann kommt so ein Team-Feature und dann denkst du, okay.
Also quasi alle die Gedanken, die du dir vorher überlegt hast oder gemacht hast, um das halt selbst zu steuern, die werden dir jetzt weggenommen.
Das ist, glaube ich, ein gutes Beispiel für, wie schnell sich das halt irgendwie weiterentwickelt.
Und ich glaube, das ist vielleicht auch noch eine spannende Anekdote dazu.
Diese persönlichen Glaubenssätze, wie Software Engineering oder Software Entwicklung funktioniert, das wird schon hart gechallenged.
Und das ist halt für einige leicht, für andere halt schwerer.
Also du hast wirklich diese Adaption-Curve, die gibt es.
Das siehst du.
Und Fun Fact, die Leute, die am wenigsten technische Erfahrung haben, für die ist es, glaube ich, am leichtesten, darüber hinweg zu kommen, weil die haben nicht das Bedürfnis, in den Code zu schauen.
Die sehen nur das Ergebnis.
Die Leute hatten halt auch im Workshop dann so Phasen.
macht jemand halt, also quasi, was hat denn der Agent jetzt an Software halt irgendwie gebaut?
Ist dieses Design jetzt irgendwie gut?
Quasi das Variable Naming halt irgendwie okay?
Klar, das musst du halt irgendwie im Tooling halt irgendwie passend, mit passenden Guardrails halt irgendwie ausstatten, aber im Zweifelsfall ist es auch egal, weil du den Code nie wieder lesen musst.
Jetzt mal richtig weit gesponnen.
Und ich glaube, da dann halt irgendwie sich selbst rauszuziehen und halt zu akzeptieren, dass man das, das liegt halt auch außerhalb des eigenen Einfluss, der eigenen Einflussmöglichkeit, das ist sicherlich auch ein Learning.
Ich glaube, das ist tatsächlich auch ein wichtiger Punkt in der Transitionsphase.
Also wenn wir davon ausgehen, dass agentische Systeme in Zukunft allen Code schreiben werden.
Aktuell glaube ich, wenn man so eine Prediction machen würde, dann wäre die nicht komplett whack, sondern im Gegenteil.
Das ist sogar wahrscheinlich größer, 50 Prozent wahrscheinlich, dass das für sehr, sehr viel Software zutreffen wird in Zukunft.
Dann musst du aber trotzdem auf dem Weg dahin, gerade wenn du schon ein System hast, was gewachsen ist, wo du mit, ich sag mal, den altbekannten Mitteln daran arbeitest, musst du ja trotzdem eine Transition gewährleisten.
Du musst ja auch genau Themen wie Ownership without Authorship lösen.
Du musst ja irgendwie hinkommen von dem einen Paradigma ins andere.
Und ich glaube, dafür ist es ganz gut, möglichst zu versuchen, das so einzupassen, dass du ja trotzdem noch Coding Guidelines oder du fängst auch eh erstmal wahrscheinlich mit Code Reviews an und versuchst dann eben die Coding Guidelines mit einzubinden, was ja auch alles geht.
Kannst du dem Tool ja mitgeben als Kontext und dann wird das so umsetzen und dann passt das auch wieder.
Und später, irgendwann wird es dann wahrscheinlich nicht mehr so relevant beziehungsweise einfach nicht wichtig, weil keiner mehr auf den Code guckt.
Das kann schon sein, ja.
Ja, ich glaube, du hast gerade ein super wichtiger Punkt, dass halt alles, oder was du gerade auch meintest, dass halt, ich glaube, Kontext und Spec ist halt alles, also quasi Schritt in, Schritt out.
Das ist mal um das ganz vereinfacht zu sagen.
Gerade halt im Endeffekt sind wir alle irgendwie in einem Brownfield-Environment.
Das ist ja quasi ein weißes Blatt Papier vor dir liegt, das ja eher...
ausgeschlossen.
Ist ja alles irgendwie was Gewachsenes.
Da den richtigen Kontext, also auch nicht alles reinzupacken, sondern den richtigen Kontext zu haben oder zu geben, gepaart mit einer guten Instruktion, was du halt machen willst.
Ich glaube, das ist halt vielleicht auch so ein bisschen sehr nah an dem Thema Training, Training, Training.
Das eine ist halt Instruieren, das andere ist halt, was packe ich da halt irgendwie rein?
Also zum Beispiel Ein Learning für mich schon ist halt, PRDs werden halt deutlich verboser.
Was ist das Deutsch dafür?
Umfangreicher oder ausführlicher.
Also expliziter, genau.
Also sie werden halt vor allen Dingen explizit.
Vielleicht ist das das bessere Wort.
Häufig liest du was und dann hast du halt einfach noch deinen ...
quasi einen eigenen Kontext, das ist halt irgendwie implizites Wissen, was du halt irgendwie mitbringst, das muss halt alles explizit werden, weil ansonsten ist es halt nicht da und dann an der Stelle quasi ist dann immer die Gefahr da, dass es halt irgendwo abbiegt.
Genau.
Und vielleicht daraus so ein bisschen nochmal ein anderer Block.
Das, was auch ganz nett war im Workshop zu sehen, ist halt, wie schnell halt irgendwie neue Botanics irgendwie auftauchen.
Also jetzt halt irgendwie der Innerloop ist soft.
Jetzt geht es halt um andere Themen und dann quasi, haben wir denn einen PRD?
Ist das denn halt irgendwie gut genug?
Haben wir denn halt all die Informationen, die wir brauchen, um halt das System halt irgendwie richtig zu instruieren?
Wir haben zum Beispiel, also wir werden damit richtig Produkte bauen und brauchst halt irgendwie ein Designsystem.
Und wenn das halt nur im Kopf ist oder unvollständig, dann wird dir das halt das System da irgendwo ausbüchsen, beziehungsweise brauchst du dich über die Ergebnisse halt irgendwie nicht Gedanken machen.
Und diese Bottinex, die werden super schnell sichtbar.
Da braucht man eigentlich bloß bis drei zählen.
Und das sind halt auf der einen Seite Systeme, das ist aber auch Organisation oder wie die Organisation technisch geschnitten ist, wer hat welche Systemverantwortung.
Und früher hast du dann gesagt, ich habe hier eine Abhängigkeit, kannst du mir mal irgendwie eine Schnittstelle bauen.
Das ist halt alles toxisch.
Das wird alles, alles toxisch.
Das wird so krass quasi Organisation, Team-Setups und Co.
verändern.
Da bin ich mir mittlerweile sehr sicher.
Ich will jetzt gar nicht, also auch ein Stück weit leider, weil das natürlich auch immer alles quasi dann Veränderung ist.
Veränderung muss halt irgendwie durch die Teamphasen.
Aber am Ende quasi.
in den Teams, entweder hast du da die volle Ownership, also inklusive den Dependencies oder du hast halt Abhängigkeiten und die sind dann halt as a service, um mal so ein bisschen bei Team Topologies zu bleiben.
Da darf es halt einfach keine Human Interaction geben, weil das passiert auf dem Innerloop und der ist halt agentisiert, falls es so ein Wort gibt.
Wenn nicht, dann hast du es gerade erfunden.
Ja, Coint.
Ja, Term Coint, agentisiert.
Genau.
Ja, macht Sinn.
Und ja, genau, ich glaube, das sind ganz, ganz wichtige Punkte.
Da sind wir auch wieder bei dem, was Markus ja auch beschrieben hat.
Oder ganz klassisch, Theory of Constraints.
Bisher war das Bottleneck halt die Umsetzungsgeschwindigkeit und das wird jetzt rausgenommen.
Wenn du das Wasser absenkst, dann kommen halt die nächsten Boulder zum Vorschein.
Ganz klassisch.
Aber auch eben halt wirklich die Geschwindigkeit, mit der das halt irgendwie passiert.
Wir haben ja auch beide, nochmal Anekdote, bei Immobilienscore damals so agile Methoden eingeführt.
Also du noch viel mehr als ich.
Und auch da sind ja gewisse Sachen halt irgendwie sichtbar geworden.
Ich kann mich noch erinnern, dass irgendwann mein Rechner nicht zur Verfügung stand.
Und dann, glaube ich, war die Lösung dafür, dass irgendjemand losgelaufen hat, was gekauft.
Mediamarkt oder Saturn.
Das ist ja quasi in der Rückschau ist das ja harmlos gegen das, was jetzt gerade passiert.
Das passiert in der Geschwindigkeit und in der Intensität.
Ja, Intensität ist ein schöneres Wort, danke.
In der Intensität, die hat ja nochmal eine ganz andere Dimension.
Was ich cool finde übrigens ist, man kann relativ gut mit Team-Topologies arbeiten.
Also das hilft tatsächlich als Konzept, um sich zu überlegen, was bedeutet das eigentlich für die Organisation.
Also ich glaube, so Mixed-Teams macht gar keinen Sinn.
Also Mixed-Teams im Sinne von den vier Typen, die es da gibt.
Also Teams, die quasi so Plattformen sind, also Services zur Verfügung stellen und gleichzeitig Stream-Aligned sind, also weil sie auch noch selbst ein Produkt bauen.
Das ist eher...
kritisch, weil du bist halt entweder das eine oder das andere.
Weil wenn du Service-Teams bist und du hast eine Abhängigkeit, musst aber selbst irgendwie, willst selbst halt irgendwie ein Produkt bauen, dann ist das quasi erst immer den Prio-Konflikt.
Also ich glaube, das wird dahingehend wird Gentic Engineering oder der Gentic Development Lifecycle Organisation nochmal ein bisschen aufräumen.
Ja, und wenn man das dann halt weiterdenkt, ich bin jetzt einfach mal so im Fluss.
Und wenn man das dann halt weiterdenkt, dann quasi hast du halt irgendwie so, wenn du das jetzt quasi alles mal zusammennimmst, dann hast du halt eigentlich eine Organisation, wo du andere Skills brauchst oder Skills jetzt wichtiger werden, einige Skills wichtiger werden, also Stichwort Requirements Engineering, aber sicherlich auch so Business Taste.
Das ist halt einfach, weil du viel schneller halt irgendwie was bauen kannst.
Das muss aber dann in line mit einer Strategie sein.
Und dann brauchst du vielleicht auch so ein bisschen Product Taste, damit das halt am Ende ein Produkt wird und nicht halt irgendwie nur Features.
Und das sind aber dann andere Teams.
Auch vor dem Hintergrund, dass du quasi mit Agents sehr schnell eben das Bottleneck der Software-Erstellung halt irgendwie rausnehmen kannst, wirst du wahrscheinlich kleinere Teams sehen, andere Setups.
Die Prediction spare ich mir jetzt, die kommt für später.
Aber ich glaube, wir werden halt viel kleinere Teams sehen.
Das ist eigentlich für mich schon klar.
Zum einen vielleicht auch, früher hatte man gesagt, naja, Agents werden sich halt gegenseitig auf den Füßen stehen.
Das mag halt irgendwie solved sein.
Aber du kannst halt eigentlich relativ gut den Innerloop halt eigentlich skalieren.
Die Herausforderung ist eher der Outerloop.
Da bist du halt eher, also ich glaube zwei, drei Leute.
Ich glaube, die Herausforderung wird werden, so die Superheroes zu finden.
Also ich glaube, die Superheroes gibt es halt einfach nur in sehr begrenzter Menge.
Also quasi die all das, was ich gerade so Business, Tech, Product oder UX, die das halt alles auf sich selbst vereinen, wird schwer.
Ich glaube, es ist selten.
Aber kriegst du das in kleinen Gruppen von zwei oder drei?
Ich glaube schon.
Aber das, glaube ich, wird wahrscheinlich, so ein bisschen Rahmenbedingungen für neue Organisationen sein.
Und dann Last but not least, das haben wir ja gerade eben schon so ein bisschen als Intro gehabt.
Ich glaube, so das Tooling, also quasi in all den Dimensionen, also das einmal das Geframete, was hast du, also was sind...
deine Boundaries auf der technischen Seite, was sind die halt irgendwie organisatorisch oder businessseitig, aber bis hin halt auch so zu, weiß nicht, Financial Compliance.
Also das kann ja auch schnell teuer werden.
Ich glaube, das darf man nicht unterschätzen.
Ich glaube, die Herausforderung da liegt halt vor allen Dingen irgendwas zu finden, was halt eine gewisse Langfristigkeit hat, ohne dass es halt irgendwie nicht unaustauschbar ist.
Weiß ich nicht.
Also heute Claude Co.
zu machen, ist glaube ich heute die richtige Entscheidung.
In einem halben Jahr wissen wir es alle nicht.
Gleichzeitig willst du halt vielleicht dich ein bisschen unabhängig machen, deren Modelle halt irgendwie zu nutzen.
Dann überlegst du halt, hast du irgendeinen Router dazwischen?
Vielleicht kommt das ja wirklich dann irgendwann mal auf die lokalen Maschinen.
Genau.
Und ich glaube, da gibt es so viele Dimensionen.
ist, glaube ich, wahrscheinlich eine Leadership-Aufgabe.
Das ist halt so Deciding Under Uncertainty.
Da gibt es so viele offene Variablen, da musst du dich halt einfach für irgendwas dann mal entscheiden und bereit sein, das halt anzupassen.
Und dann muss das halt einfach das Setup erfüllen.
Genau.
Ja, ich glaube, das fasst das ganz gut zusammen.
Wie Markus auch gesagt hat, rumfriemeln.
Ist jetzt das Richtige?
Weil wir sind noch in der Experimentierphase, wir können es noch nicht predikten, wohin es geht oder was das beste Setup ist.
Es kristallisieren sich so ein paar Themen heraus und jetzt geht es darum, die Rahmenbedingungen so zu bauen, dass man die Organisation mitnimmt auf die Reise, mal guckt, wie das in der eigenen Organisation am besten eingesetzt werden kann, weil am Ende, das ist halt ganz, ganz stark von der Domäne abhängig, wenn du, du hast es gerade schon erwähnt, Financial.
Compliance, wenn du jetzt in Finanzinstituten bist oder gerade in der Krankenkasse oder so, also undenkbar, dass du da irgendwie Anthropic oder so benutzt wahrscheinlich, also zumindest nicht in den Bereichen, die sehr kritisch sind und da musst du dich, trotzdem musst du dich mit dem Thema auseinandersetzen.
Vielleicht sind da lokale Modelle schon das Ding oder halt dann irgendwie DevStral irgendwo gehostet oder whatever.
Ja, muss man für jede Organisation tatsächlich starten und vor allem, wie du auch gerade sagst, Rahmenbedingungen bauen, die eine Guidance geben, aber flexibel sind, sodass du auf das, was sich ergibt, reagieren kannst.
Ich glaube, für mich ist das Bild quasi, willst du halt irgendwie Tool Adoption haben?
Oder willst du halt Concept Adaption haben?
Und Tool Adaption ist einfach.
Das gibt es zu jeder Person.
Machst ein bisschen Training drumherum.
Jeder wird es irgendwie nutzen.
Das ist quasi, Engineers werden das gut hinbekommen.
Ich glaube, Productleute, UX, das alles, das funktioniert, aber es stoppt dann halt auch dort.
Also du hebelst halt eigentlich nicht das, was du halt hebeln könntest.
Und gerade wenn du das halt dann eben ganzheitlich betrachtest, schweres Wort, aber wenn du das halt quasi wirklich alles zur Disposition stellst, dann kann das halt einfach ganz andere Skaleneffekte haben.
Und ich glaube, dazwischen, also sich nicht zu verrennen und halt irgendwie zu gucken, dass es halt nicht nur holistisch langfristig halt irgendwie das Richtige ist, sondern halt auch kurzfristig und halt aber eben nicht nur kurzfristig und dann aber irgendwie auch stoppt und einfriert.
Ich glaube, das ist die große Herausforderung.
Zusammengefasst.
Ja, genau, wenn ich so auch Revue passieren lasse, was so in den letzten Folgen, was wir so gehört haben, da hast du auch schon eben erwähnt, der große Shift vom Ausführenden zum Orchestrator, sag ich mal, also sprich, dass du eigentlich agentische Systeme nutzt, um genau diesen Innerloop möglichst quasi durch Agenten machen zu lassen, weil die es eben schneller können.
Wenn die die entsprechenden Guardrails haben, dann tun sie es auch in guter, vielleicht sogar in Teilen besserer Qualität.
Und dass man insofern stark kuratiert und gar nicht mehr so stark generiert.
Dann damit einhergehend diese 90-10-Regel, die Markus aufgestellt hat, dass 90 Prozent des bisherigen Know-hows, also genau diese Fachexpertise, irgendwie ich weiß genau, wie ich ein bestimmtes Framework nutze und wie ich ein bestimmtes technisches Problem löse und wo ich nachgucken kann, wenn ich irgendwie Hilfe brauche.
Das ist alles weg.
Also für Sachen, die bekannt sind, ist es weg.
Für Sachen, die nicht bekannt sind, gibst du dem Tool einen Pointer und sagst, guck dir das mal an und dann mach mal, setz mal das um, was ich gerne hätte.
Und dafür werden aber 10 Prozent halt unfassbar viel wertvoller.
Genau diese diese Fähigkeit zu verstehen, was sind denn die technischen Rahmenbedingungen sozusagen oder wie kann ich so eine Lösung am besten integrieren, wie kann ich Wert damit generieren, sowohl für den Kunden als auch fürs Unternehmen.
Das hätten wir, glaube ich, auch ein bisschen bei Stefan in der Folge.
Der hatte, glaube ich, quasi Fachexperten wären Superhumans.
Weil das quasi, du hast, also das wird so, so, so, so wichtig, diese fachliche Expertise, weil das im Endeffekt die Grundlage ist und der andere Teil fällt weg, beziehungsweise lässt sich leichter erschließen.
Genau.
Das ist bloß nochmal positiv frame.
Ja, ja, sehr schön.
Genau.
Und das ist genau das, was du vorhin auch gesagt hast, dass der Kontext, den du in deinem Kopf hast, den hat kein Modell quasi perfekt so im...
Kontext schon drin, beziehungsweise um einen perfekten Modellkontext so zu kuratieren, wie du es in deinem Kopf hast, würdest du extrem lange brauchen.
Das heißt, du musst im Prinzip eigentlich gucken, dass du dem Modell immer den Kontext mitgibst, den es aktuell gerade zu diesem Zeitpunkt für genau diese Task benötigt.
Und das ist exakt dieses höherwertige, diese Expertise.
Genau, dann ist der nächste Punkt natürlich, dass Validierung alles ist, also weil wenn du dich auf, ist wie bei Delegation als Führungskraft.
Wir auch gehört haben in der einen Anekdote, dass ein Mensch, der so eine Consultancy hat, die auch so Auftragsentwicklungen machen, der heiert als Coder dann nur Engineering Manager, weil die halt gewohnt sind zu delegieren und da auch ein Gefühl dafür haben, wie Delegation funktioniert.
Sprich, Ich muss eine Aufgabe definieren, Rahmenbedingungen, Kontext mitgeben und dann muss ich das Ergebnis überprüfen.
Und das ist im Prinzip das, wie sich die Rolle verändert.
Also Delegation und dann die Fähigkeit zu validieren, was zurückkommt, um sicherzustellen, dass das Problem auch so gelöst wird, wie man es sich wünscht und dass es den größten Wert bietet bei möglichst geringem Risiko.
Genau.
Elastic Loop hattest du auch schon gesagt.
Also sprich, wann, was ist eine Task, wo man dem Agenten sehr viel Freiraum lassen kann?
Was ist eine Task, wo man Agenten sehr eng führen muss?
Und tatsächlich, das stackt sich auch.
Also wir haben, habe ich dir, glaube ich, am letzten Wochenende ja mal gezeigt.
Ich habe hier meinen kleinen Agenten, der aus dem Transkript von unseren Podcast-Episoden dann schon bestimmte Artefakte generiert und das hat sich so gesteckt, dass im Prinzip eigentlich alle Beiträge und alle Textbausteine, die wir so benutzen, jetzt nicht zu 100 Prozent, aber ich würde sagen zu 95, 98 Prozent kommen die da fertig raus in unserem Stil.
Der passt auch für unsere Audience, weil verschiedene sozusagen kleinere Module gesteckt sind zu einem größeren Modul und da ist es jetzt ein relativ loser Loop, was jetzt rein diese Generierung der Artefakte angeht.
Wir lesen da immer nochmal drüber und wir müssen noch ein paar kleine Änderungen machen, aber ich muss sagen, 95 Prozent des Aufwandes für uns ist damit mehr oder weniger wegautomatisiert und in Teilen besser und ausführlicher und treffender als wir das, weil wir eben nicht die Zeit uns hätten nehmen können, machen konnten.
Und das ist genau der Punkt.
Wann klappt es, wann klappt es nicht?
Da muss man sich einfach rantasten und diese Intuition dafür entwickeln.
Und dann, was auch ein Ein schöner Punkt war, und das schließt ein bisschen an dieses Superhuman-Ding an, dass Wissensmonopole auch mit der Zeit verschwinden.
Also wenn du Agenten hast, die sich schnell in Sachen einarbeiten können, wenn sie so ein bisschen Doku kriegen oder ein bisschen Kontext kriegen und dir auch erzählen können, wie bestimmte Dinge bisher so funktionieren, so kannst du auch, wenn du ein Team hast aus Leuten, die in ihrem Bereich sehr, sehr gut sind, die können dann auch angrenzende Dinge ganz gut sich erschließen oder angrenzende Themenkomplexe.
Sodass auf einmal ja, keine Ahnung, auch für einen Otto-Normal-Menschen vielleicht das, was nötig ist, um eine Gesamtkostenkalkulation zu machen oder financial controlling oder so auch immer jetzt in der Finanzdomäne auch möglich wird mit der Hilfe.
Und dann im Prinzip wieder zurück auf diese Kompetenz, den richtigen Kontext mitzugeben und auch zu validieren, ob das Ergebnis da rauskommt.
Und also all diese Sachen, die gelten halt für uns in der Softwareentwicklung, für Techniker.
Und da sind wir gerade mitten in dem Schiff drin.
Also sprich, wir müssen uns dem annähern, für jede Firma genau diesen, den richtigen Ansatz finden und auch die richtige Elastizität dieses Loops.
Aber der, und das ist eigentlich das Spannende, der lässt sich ja eins zu eins abstrahieren für jegliche Wissensarbeit.
Dieses vom Ausführenden zum Orchestrator 9010-Regel der Fähigkeiten sozusagen.
Wo liegt die Wertschöpfung eigentlich drin?
Validierung statt Creation, wenn man so will.
Elastic Loop, also wann muss ich näher am Agenten sein?
Wann kann ich größere Tasks auch übertragen?
Und eben die Möglichkeit, sich Dinge zu erschließen, sich Domänen zu erschließen, die vorher ein Monopol waren von bestimmten Fachexperten.
All das sind Dinge, die auch in den anderen Wissensarbeitsdomänen kommen werden.
Nicht ganz so schnell vielleicht wie in der Softwareentwicklung, weil naturgemäß ist das an der Forefront sozusagen, würde man im Englischen sagen, aber auch in anderen Bereichen wird es kommen.
als Ganzes adaptieren willst, dann wird das halt auch quasi in der Produktentwicklung nicht halt machen, sondern dann geht das halt drüber hinaus.
Dann hast du das...
Und das zeigt ja im Endeffekt auch Cloud Cowork halt.
Dann hast du halt irgendwie die Skills, um halt eine Marketingkampagne irgendwie schnell zu machen.
Und das wird halt einfach rausgehen.
Ich glaube, du hast als Organisation dann so neue Herausforderungen, dass sie nicht so Daten verfügbar machen.
Ich glaube, du brauchst halt auch viel mehr Corruption oder Anti-Corruption-Layer, um halt irgendwie sicherzustellen.
Du hattest ja vorhin gesagt, hier wie Laura Tacho.
50 Prozent mehr Inzidenz.
Ich glaube, das Beispiel kannst du auch für intern machen, wo halt einfach Sachen halt intern dann schief gehen.
Und nichtsdestotrotz musst du diese durchlängliche Durchlässigkeit halt irgendwie hinbekommen, wenn du es halt in der ganzen Firma halt irgendwie haben willst.
Aber sehe ich genauso wie du.
Das beginnt wie häufig halt auf der Technologieseite, also in den Tech-Bereichen und dann wird es halt überall Einzug erhalten.
Ja, und wichtig genau sind die entsprechenden Rahmenbedingungen.
Ja.
Genau, das war der Hauptteil.
Ein guter Recap, oder?
Ein guter Recap.
Nicht selbstlob, aber ich glaube, wenn ich so überlege, wir haben glaube ich more or less auch alle Episoden nochmal gestriffen.
Ich denke auch, genau.
Ja, und ich bin gespannt, was noch kommt.
Vielleicht schon mal eine Vorschau.
Einmal werden wir sicherlich noch eine Episode mit jemandem von Mapbox aufnehmen, die auch schon mit mehreren Teams komplett an einem Agent, also komplett Agentic Software Engineering machen, die dann wirklich einfach in diesen Code Review Bottleneck reinkommen.
Und da, also genau wie du das auch gesagt hast, das nächste Bottleneck ist halt unmittelbar da.
Das geht so schnell und da musst du Lösungen dafür finden.
Dann gucke ich gerade in einen Talk von, ich habe den Namen vergessen, aber die wiederum auch dafür dann agentische Lösungen benutzen.
Und dann sagen, die bauen halt Schemata auf, die andere Agenten benutzen, um die Arbeit von bestimmten Agenten überprüfen zu können, damit du mehr oder weniger eine gute Balance hast zwischen der Geschwindigkeit, die dadurch entstehen kann, aber auch dem Risikomanagement und Qualitätssicherung, die du ja auf jeden Fall auch brauchst.
Genau, es bleibt spannend und geht, glaube ich, spannend auch weiter.
Definitiv, definitiv.
Wollen wir in dem Zusammenhang so ein bisschen mal ein paar Predictions halt irgendwie wagen?
Die müssen ja nicht unendlich weit in der Zukunft liegen, aber vielleicht irgendwas, was wir mal in einer zweiten Recap-Folge mal validieren können, ob wir da näher dran sind.
Wie ist los?
Genau, also meine Prediction, auch so ein bisschen Takeaway aus dem Workshop.
ist, wir werden ganz stark wieder Pair-Programming sehen.
Wird glaube ich nicht Pair-Programming heißen, sondern dann Pair-Instructing oder Pair-Orchestrating.
Was meine ich damit oder worum geht es da?
Ich hätte ja vorhin schon gesagt, was sich halt verschiebt, ist halt die Teamkomposition.
Also du brauchst halt andere Fähigkeiten in dem Team oder gewisse Fähigkeiten wären wichtiger.
Ich glaube nicht, dass man das so ohne weiteres halt in einer Person halt irgendwie findet.
Das ist super schwer, gibt es bestimmt, ist super schwer.
Aber du wirst das Setup halt in zwei oder drei Leuten halt irgendwie finden.
Und ich könnte mir vorstellen, also wie funktioniert da Zusammenarbeit, dass das halt einfach zusammen am einen Rechner passiert.
Weil das ist halt auch das Heavy Lifting, also wirklich das Instruieren, das Vorbereiten.
das quasi, also da wirklich alles explizit reinzustecken, um dann halt einfach das System mit den bestmöglichen Voraussetzungen halt irgendwie loslaufen zu lassen.
Und aus meiner Sicht ist das quasi the essence of pair programming.
Instructing zukünftig.
Sie haben es hier zuerst gehört.
Sehr gut, genau.
Kann ich mir sehr gut vorstellen tatsächlich.
Und Und das schließt, oder sagen wir mal, daran anschließend würde ich, ja, ich weiß gar nicht, eine Prediction, ja okay, man soll ja Predictions nicht nur raushauen, wenn man sich da sehr sicher ist, sondern auch mal so ins Blaue.
Ich habe eigentlich zwei Sachen, die ich so sehe.
Das eine ist, ich glaube, dass es so eine Bifurcation gibt, würde man im Englischen sagen, so eine Gabelung.
Also auf der einen Seite wird es, Also die Frontier-Modelle und die Hanesses etc., die bleiben einfach immer top-notch.
Und die Firmen, die die einsetzen, werden immer mehr Geld dafür ausgeben.
Also sprich, das wird sicherlich immer noch unter dem Preispunkt vom Gehalt von einem normalen Entwickler sein.
Aber es wird teurer werden, weil auch der Rechenaufwand größer wird.
Und das ist ein CapEx-Game.
Die Firmen, die die Modelle...
Betreiben, zur Verfügung stellen, müssen extrem viel investieren und müssen das Geld eben sich wiederholen über entsprechende Subscriptions.
Und dann gibt es die anderen, die wahrscheinlich eher dann sagen werden, ja, ich habe eben nicht diese finanziellen Möglichkeiten, weil spätestens wenn...
die ersten Competitor da aus dem Markt gehen, dann gehe ich schon davon aus, dass es da eine Preissteigerung bei den Top-Notch-Modellen geben wird.
Aber wie in jedem Markt gibt es halt diese Differenzierung auf der Produktebene oder halt die Preisdifferenzierung und dann wird es entweder Preistreiber nach unten geben, die ganzen chinesischen Modelle, die wahrscheinlich wie sich quasi herauskristallisiert, ja eher destillierte Modelle sind von Frontier Labs.
die aber dann preiswerter zur Verfügung gestellt werden können, was fairerweise immer noch nicht billig sein wird, solange Nvidia ähnliche Margen halten kann, wie sie es jetzt haben.
Also sprich, wenn es da mehr Konkurrenz gibt und auf der Inferenzseite mit Cerebras, CROC und vielleicht anderen Lösungen auch mehr Competition gibt oder halt durch die natürlich AMD, Intel und auch die einzelnen Big Tech Unternehmen, die ja auch alle in die Richtung die Produktion skalieren.
Dann könnte es endlich einen Preisdruck auch nach unten geben.
Dazu aber die eigene Hardware und dieses einfach ein Unified RAM System zu haben, wo Apple ja sehr stark ist, dass du mal oder weniger die ganzen 24, 36, was auch immer, 128 auf einem Mac Mini Studio oder wie alle heißen, RAM für so ein Modell nutzen kannst, dann kriegst du auch ein einigermaßen großes Modell mit einigermaßen gutem Throughput zum Laufen, sodass du anfangen kannst, das auch lokal für bestimmte Dinge zu nutzen.
Der nächste Punkt aber, und da weiß ich gar nicht, ob es eine Prediction ist oder ob es eher eine Fragestellung ist.
Ich glaube, ich würde es mal als Frage formulieren.
müssen wir nicht zwangsläufig auch Arbeitszeit anders betrachten als jetzt, weil ich weiß nicht, wie es dir geht, aber mein Job, der war immer intensiv.
Das gab selten Langeweile und eigentlich immer mehr zu tun, als ich hätte schaffen können und dann auch der ganze Kalender voll mit Meetings.
Meetings habe ich immer noch viele, aber die Zeit, die ich keine Meetings habe, die nutze ich jetzt für viel mehr Themen parallel als früher.
Und das sind ganz unterschiedliche Projekte und ein wahnsinniger Kontext-Switch, was Cognitive Load bedeutet.
Das ist extrem auslaubend und es sorgt in Teilen auch dafür, und das haben ja viele, die sehr, sehr früh auch sehr intensiv agentisch programmiert haben, es sorgt auch dafür, dass man weniger schläft in Teilen und sagst, ich habe jetzt hier noch dieser eine Prompt und dann habe ich das Problem gelöst oder keine Ahnung, meine Quota wird morgen renewed, ich möchte die jetzt noch ausnutzen, um noch diese zwei Probleme zu lösen, was auch immer.
Und ich habe einfach die Frage im Kopf, ob wir mit Arbeitszeit anders umgehen müssen, also ob wir einfach diese Phasen des intensiven Arbeitens, gerade wenn du sagst, ein kleines Team, die vorm Rechner sitzen und dann ganz intensiv sich selber die Bälle zuwerfen und dann mit dem Agenten interagieren, ob man da nicht dann wiederum Downtimes braucht, um einfach zur Ruhe zu kommen, dem Gehirn Zeit zu geben, das zu verarbeiten und auch wieder die Batterien aufzuladen.
Human Tokens.
So ein Rate Limiting auf den Human Tokens, meinst du?
Ich weiß, was du meinst.
Ich glaube, es ist natürlich jetzt, wenn du jetzt nach Output halt gehst, wahrscheinlich der Output wird halt deutlich größer, also das Racial dazwischen.
Und ich glaube, es kommt ein gutes, zu einem sehr großen Teil natürlich aus dem System, aber es kommt natürlich auch zu einem guten Teil aus, daraus, dass wir quasi die Instruktionen quasi immer, also der Outerloop bleibt ja und der ist halt anstrengend.
Und quasi das, ich will jetzt nicht sagen, das Einfache ist weggegangen, aber ein wesentlicher Teil, aber trotzdem bleibt halt eine gewisse Komplexität beim Menschen.
Die Frage ist halt, wie weit man, also ich sehe das sehr ähnlich.
Ich habe nicht den Eindruck, dass ich noch nicht den Eindruck, dass ich da irgendwie ausgelockt bin, aber das ist halt natürlich, diese Kontextwechsel, das Cognitive Flow, das ist schon alles da.
Die Frage, die ich mir stelle, ist halt, wie weit man das halt noch wegdrängen kann.
Weil ein Beispiel, das zeigt halt irgendwie das zum Beispiel wieder Cloud Code Team, dass du auch eine Orchestrierung im Zweifelsfall abgeben kannst.
Und das nimmt ja dann wieder Load.
Aber du hast recht, dass ...
irgendwie passt das nicht mehr so richtig zusammen.
Wobei ich auch, wenn du einmal die Bandbreite anguckst, das geht ja dann bis ins Gesetz rein, Arbeitszeit, das ist wahrscheinlich wirklich, das ist eine krasse Prediction.
Das ist schon eine sehr gute, by definition, eine sehr gute.
Ist ja eher eine Frage, die sich mir da stellt, so wie es in meiner Wahrnehmung ist.
Aber du hast natürlich einen Punkt, aktuell, ermöglichen die agentischen Systeme mir zwei Dinge.
Das eine, Dinge zu tun, die ich früher nicht tun konnte.
Mal eben eine große Go-Applikation, Kubernetes zu schreiben, Kubernetes-Cluster hochzuziehen in der Cloud und React-Frontend mal eben in ein paar Tagen zu bauen oder dann im nächsten Schritt eine lokale Mac-App.
als native App in Swift geschrieben ist.
Also es ermöglicht mir Dinge zu tun, die ich vorher nicht tun konnte, weil ich einfach bei die Barriere, mich da einzuarbeiten, so hoch gewesen wäre, dass ich einfach die Zeit nicht mir genommen oder gefunden hätte.
Und auf der anderen Seite macht es aber Dinge effizienter.
Also sprich Textgenerierung für verschiedene Beiträge in diesem Podcast oder teilweise auch in anderen Bereichen, wenn ich mit, keine Ahnung, Handwerkern interagieren muss und dann Angebote auswerten oder so.
Da macht es Dinge einfach viel, viel schneller.
Und das ist so eine Balance, zu gucken, die Geschwindigkeitsgains, die setzt man automatisch, glaube ich, ein Stück weit in mehr oder in den Freiraum, der sich daraus erzeugt, in neue Themen um.
Und da muss man wie immer einfach selber schauen, dass man sich nicht überfrachtet, dass man nicht einfach zu viele Baustellen aufmacht.
Amen.
Wie immer.
Alles bleibt.
Es geht jetzt nur auf eine andere Ebene.
Wollte gerade sagen, du kannst ja immer die Ableitung davon nehmen und da deine gewisse Gesetzgebungen bleiben halt einfach.
Oder wie wir früher immer gesagt haben, it depends.
Das war dann ein schöner Recap.
Der HMZE Podcast ist ein gemeinsames Projekt von Sebastian Heidemeyer 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.hmze.tech schicken.
Vielen Dank für deine Zeit.
Wenn es dir gefallen hat, abonniere den Podcast.
Bis zur nächsten Folge.