Latest / Beyond Vibe Coding / #053 Agentic Coding in Production - mit Sebastian Sigl (Adevinta)

Transcript

#053 Agentic Coding in Production - mit Sebastian Sigl (Adevinta) · Beyond Vibe Coding

• André Neubauer: Sebastian, herzlich willkommen im Podcast, ... herzlich willkommen an alle Zuhörer ... ... und Zuschauer, 6. Folge ... ... vom HMZE Bio & Vibe Coding Podcast. Sebastian HMZE: Ja, jetzt musst du den Gast noch bitten sich vorzustellen kurz. André Neubauer: Dann hast du das ja hiermit getan. Wir haben heute die besondere ... ... Herausforderung. Der Sebastian wird sich gleich vorstellen, ... dass wir zwei Sebastians dabei haben. Das wird sicherlich ein spaßiger Podcast. Aber Sebastian, stell dich doch mal vor. Sebastian: Ja, hallo, schön hier zu sein. Mein Name ist Sebastian Siegel, Softwareentwickler seit vielen Jahren, immer noch passioniert Fullstack voll und ganz und genau darf heute hier sein, nachdem mir André in der Nachricht geschrieben hat, dass einen spontanen Post von mir auf LinkedIn relativ spannend fand. Und ja, ich freue mich heute ein bisschen über Agendecoding zu sprechen. ⁓ André Neubauer: das relativ spannend, können wir streichen. Zumindest relativ habe ich nicht geschrieben. Ich fand es spannend. Ich glaube, ist das Thema, ... was viele bewegt. Ich glaube, das eine ist halt ... so bisschen das, was wir auch in den letzten Podcasts ... immer wieder diskutieren, ... so am Ball bleiben, neue Sachen ausprobieren ... ... und dann aber den Shift in die Produktion zu kriegen ... ... mit der Konsequenz, dass da halt auch dann ... eine ganze Organisation dran arbeitet. Nochmal andere ... ... Rahmenbedingungen, Spielregeln halt irgendwie gelten. Ich finde das super spannend, auch für meinen beruflichen ... also werde ich heute eine ganze Menge mitnehmen. Bevor wir da einsteigen, fangen wir mal mit ein paar ... Warm-Up-Fragen an. Und das, was wir als allererstes immer fragen, ist, wie ... arbeitest du heute? Also was ist dein täglich Brot? Sebastian: Als Staff Engineer habe ich tatsächlich einen sehr gesunden Mix zwischen Hands-on-Work, Entwicklung, natürlich spreche ich viel mit Techleads, spreche viel mit Businessleuten, schaue, dass alles passt. Wenn es ganz konkret um Agenda-Coding geht, total spannend, wie sich eigentlich auch meine Arbeitsweise in letzten sechs Monaten verändert hat oder eigentlich seit zwei Jahren, peu à peu. Aber man kann schon sagen, dass viele Dinge mit denen man zu tun hat, sei es ganz basic in Jira, Tickets mal hier und da erstellen, ManCode Review, meine Contribution, dass man eigentlich immer häufiger die Agents als Interface zwischen der eigentliche Arbeit hat. Das kann ganz unterschiedlich aussehen, das ist manchmal ein Chat GBT oder Gemini, das ist aber immer häufiger gefühlt irgendein CLI-Tour. André Neubauer: Hm. Sebastian: was sehr sehr sehr mächtig ist mit Hilfe von diversen Schnittstellen und man ist eigentlich nur noch so ein bisschen am orchestrieren, das klingt immer so distanziert, aber man macht so bisschen Peer Programming und mit Hilfe des Agents ist man da anders unterwegs. André Neubauer: Du hast gerade gesagt, bist zwei Jahre dabei. Also zwei Jahre in der ... Ich weiß gar nicht, ob das Agentic-Welt ist, aber zumindest Generative AI. Also angefangen wird das wahrscheinlich mit ... ... GitHub Copilot haben? Wie war denn so deine Journey bis heute? Sebastian: Das ist total spannend. erstmal, da ich auch ein bisschen was in Richtung ML gemacht habe, bevor die LLMs bekannt wurde, mir der Ansatz schon bekannt. Und irgendwann, dann so Chat-GBT, so ein Chat-Interface, da war was genau das gemacht hat, was man vorher in einem Notebook so spaßeshalber mal getrieben hat. Für mich war das eigentlich Chat-GBT wirklich erstmal damit herumgespielt, geschaut, okay, was kann man da machen. Ein bisschen Code erzeugt, bisschen Copy-Paste gemacht. Ich glaube, das waren die ersten Berührungspunkte. Copilot. kam dann zumindest für mich so ein bisschen später, hat für mich aber tatsächlich nie so richtig gut funktioniert. André Neubauer: Okay, weißt du warum? GitHub Copa, wir reden von GitHub Copilot oder von welchen Copa? GitHub Copilot. Ja, ja. Sebastian: Also ich habe es jetzt so verstanden, GitHub Co-Pilot, wie es klassisch war, diese Autovervollständigung, Autocompletion und Stereoids so ein bisschen. Ja, ich weiß nicht, das hat für mich nie so richtig Klick gemacht. Es gibt ja schon Autocompletion, diesen Entwicklungsstil einen Kommentar drüber zu packen und dann kriegt man eine bessere Autocompletion. Ich glaube, das war mal so eine Thematik. Ich weiß nicht. Wenn man relativ flüssig in der Entwicklung war, glaube ich, hat das einem nicht so viel gebracht. Viel spannender waren dann, als der Copilot quasi in Visio Studio so richtig reinkam, man konnte Fragen stellen und dann hat er, dann wurde es mehr zu einer agentik Experience so ein bisschen, wobei Copilot da ja wirklich ein bisschen langsamer war als ein Cloud Code oder andere Tools. Sebastian HMZE: Ich muss sagen, dass ich das damals genauso empfunden habe, auch dass ich erst war ich total fasziniert und habe auch mehr mehr Ggbt benutzt und war dann zum ersten Mal mit Cursor, wo ja der Agent oder dieses Chat Fenster in die IDE kam. Da habe ich dann gedacht, ja genau so muss es sein, dass der Medienbruch einfach weg ist und dann mit den Referenzen auf den Workspace, dass man bestimmte Files mitgeben konnte und irgendwann der Agent auch selber geguckt hat, welche Files denn relevant sein konnten. Das war noch nicht wirklich agentic, sondern es war eher Kontext bereichern sozusagen. Das hat dann schon die Arbeitsweise deutlich verändert. Stimme ich auf jeden Fall zu. Aber auch das war ja noch weit entfernt von dem, wo wir heute sind. Was waren so die nächsten Stufen, die du dann sozusagen genommen hast? André Neubauer: Hm. Sebastian: Ja, das ist eine gute Frage. hat gefühlt, dann irgendwann kam ja so Gemini. Gemini hat dann nochmal irgendwie Dinge anders und besser gemacht, irgendwie anders strukturiert. Ich hab relativ lange dann... Es war so ein Bruch, ne? Co-Pilot hat halt so ein bisschen funktioniert, aber nicht immer gut und für die größeren Batches dann irgendwie Gemini und Chetchibit. Und irgendwann kam ja dann Claude Code, ja? Und ich überleg grad, ob noch irgendwas dazwischen war. Aber ich glaube halt nicht. Es gab immer so ein Plateau. Egal ob es die Modelle waren, die auf einmal viel besser wurden, aber auch dieses Denken in Modellen. Jetzt habe ich irgendwie ein neues Modell und auf einmal könnte jetzt Dinge besser passieren. Das ist ja auch noch nicht so lange der Fall. Das ist wirklich erst so seitdem wir diese Agents benutzen, seitdem wir den Code so derartig schreiben lassen in größeren oder kleineren Batches sozusagen. Erst seitdem wurde das für mich ein Thema. Ich glaube, das war dann der nächste größere Sprung. Sebastian HMZE: Ja, genau, glaube, ne bitte André, das müssen wir rausschneiden. Ne, genau, habe auch wahrgenommen damals, dass Claude Cote der erste Agent war, also ich meine, ne, tatsächlich hat ja Körser sogar, glaube ich, den ersten Agenten in der IDE gehabt, ich weiß es gar nicht mehr so genau, aber Claude Cote war dann kurz danach, Copilot hatte dann auch seinen Agenten, den ich am Anfang sogar auch ganz gut fand. André Neubauer: Okay, das heißt ... Mach mal so was hin. Sebastian HMZE: Aber inzwischen hängt er doch deutlich hinterher, ich auch sagen. Sebastian: Es gab noch diese spannende Phase, das weiß ich noch. Da konnte man dann im Vichu Studio Code, ich habe nie Cursor und Co wirklich benutzt. Vichu Studio Code gab es dann diesen Edit Mode und dann hat er auf einmal eine Datei. und die haben total lange gebraucht, dann wirklich so richtig den Agent zu aktivieren. Das war dann der Hauptgrund zu sagen, hey, warum kommt denn das nicht, warum dauert das hier so lange, wo wir dann gesagt haben, hey, Claude Coat, es sieht interessant aus, verhält sich auf einmal komplett anders und fühlt sich auch komplett anders an. André Neubauer: war das eine bewusste entscheidung körser zu zu umschiffen Sebastian: Ich glaube das hängt mit meiner persönlichen Präferenz zusammen. Ich hatte so ein bisschen Bauchschmerzen dabei zu sagen, jetzt benutze ich dann für mich ist es schon ein frontend heavy tool und ich wollte gerne im Terminal oder in einem Bereich sein wo ich sage ich kann das backend und frontend ähnlich gut bedienen und da hat sich dieser Terminal Ansatz bei mir sehr sehr zeitig schon wirklich gut angefühlt. Das im Visual Studio Code war auch irgendwie komisch, es gab auch ständig Bugs. Cloud Code hat ja auch lange oder hat immer noch eine Vue Studio Code Integration oder IntelliJ Integration. Die machen aber irgendwie immer nur Error. Spätestens wenn man drei, vier, fünf Terminal Fenster mal nebeneinander auf hat, weil man halt an verschiedenen Tasks arbeitet, die auch manchmal bisschen Zeit brauchen, spätestens dann ist man eigentlich aus der Entwicklungsumgebung raus. André Neubauer: Okay, und das war dann so der Moment, du gesagt hast, all in, also quasi mit dem Stack bist du dann bis heute unterwegs. Sebastian: Ja, ja, aber ich bin tatsächlich vor kurzem in Richtung OpenCode gewechselt. Einfach weil ich da auf X so ein bisschen hinterher gelaufen bin. Hey, da scheint sich irgendwie was zu bewegen und ich bin sowieso ein großer Open Source Verfechter. Und was ich kann jetzt aktuell, ich habe jetzt im letzten Monat nur OpenCode benutzt, davor nur Cloud Code. Der Wechsel war innerhalb von drei, vier Tagen eigentlich erledigt und dann wollte ich nicht mehr zurück. Also so eine Beispiele wie in Cloud Code, wenn man mit Leuten redet, die Cloud Code benutzen, die sagen, ja eigentlich willst du immer so ein Planning davor haben. Man gibt irgendwas ein, dann rattert er, man kriegt so ein paar Fragen zurück und das führt in der Regel zu besseren Resultaten. Wenn man dann auf einmal Open Code aufmacht, da gibt es das zwar so ein bisschen, aber nicht derartig. Der Default ist, du gibst das ein und er legt direkt los. Und wenn man sich dann mal an diesem Working Mode gewöhnt, dann kriegt man mit Hey. Und wenn man mit anderen Leuten spricht, ich brauche ja gar nicht Switchen. Wenn ich jetzt möchte, dass mir das Modell vielleicht 3, 4, 5 Optionen vorschlägt oder mir vielleicht 5 Fragen dazu stellt, dann kann ich das halt auch schreiben oder reinsprechen. Dazu muss ich nicht noch mal gedanklich in so einen anderen Modus wechseln. Das hat sich für mich einfach besser angefühlt und Open Code. krieg kein Geld dafür oder so, ich hier OpenCode bewerbe. Aber dass man da den Luxus hat einfach andere Model Provider zu verwenden, das ist einfach ein totaler Luxus. Genau, das Summa Summaro führt dazu bei mir, dass ich aktuell vor allem OpenCode benutze. Sebastian HMZE: Benutzt du auch andere Modelle oder ist es dann doch wieder Sonnet oder so? Sebastian: Es ist am Ende Codex und Opus, was ich aktuell benutze. Die zwei sind einfach die Frontier Models. Die Resultate sind beeindruckend. wie die Modelle da funktionieren, es gibt so ein paar Vor- Nachteile. So ein Opus ist so bisschen, sag ich mal, kreativer und ein bisschen proaktiver. Und so ein Codex ist, der geht direkt in die Breite. Der will alles irgendwie wissen, guckt sich von selbst Dinge an. Aber braucht auch dann ein bisschen länger. ich glaube von den Model-Internas, Stärken, die sind sehr, ähnlich. Also die Fähigkeiten, aber dann das Feintuning der Modelle. scheint, ich habe heute gelernt, dass Codex eher ein europäisches Team ist und Claude Code eher ein amerikanisches Team. Also beim Feintuning unterscheiden sich da die Präferenzen der Teams. André Neubauer: Total spannend, weil wir in der letzten ... Episode mit Robert sind wir auch an dem ... Thema vorbeigekommen und hat es genauso ... beschrieben. Codex, nee, was hat gesagt, ... Cloud Code war eher so bisschen aufgeregt, ... will man sofort loslegen und Codex nimmt ... sich eher immer Moment Zeit, versucht das ... zu verstehen und quasi, genau, also ja, ... ... aber zu einer ziemlich ähnlichen ... Aussage kommen. Kannst du ein bisschen was zu deinen ... Sebastian: Mhm. André Neubauer: zu deinem Loop sagen? wenn du, ich nehme jetzt dem, dass du gar nicht so viel planst, quasi sind das dann eher kürzere Loops oder ja, wie muss man sich so deinen Arbeitsprozess dann vorstellen? Sebastian: Es hängt extrem von der Aufgabe ab. also sag ich mal im privaten, wenn es irgendwie darum geht, ein Seitenprojekt vorwärts zu bekommen, keine Nutzer, Greenfield, wenig existierende Dokumentation, wenig existierende Regeln, da ist man eher in so einem Batch-Modus. Ja, also ich selbst benutze aktuells Backkit von GitHub, aber am Ende spielt es keine Rolle, es gibt da verschiedene Frameworks, die dir einfach... Es ist am Ende ein Set von... commands die man benutzt mit ein paar templates und dann geht man so einen prozess durch man sagt erstmal was man haben möchte und warum und irgendwann putzender viele tasks raus und dann denkt man in increments und irgendwann sagt man implement und 30 20 minuten später hat man dann das resultat vor augen und dann guckt man sich eher die changes an poliert irgendwie noch mal nach lässt den agenten noch mal selber drüber testen und so weiter also das ist jetzt das beispiel wo ich sag bei aufgaben wo man eher badge-orientiert arbeitet, weil man viel schaffen kann, das Risiko relativ gering ist, dass da auch mal was schief geht, dann ist es eher so ein Arbeitsmodus. Vielleicht in einer Anwendung, die jetzt schon in Produktion ist, wo viel draufläuft, da geht man näher ran. Also da macht man die OpenCode zum Beispiel auf. Angenommen wir haben einen Bug. Irgendwo ist das beschrieben. Da könnte man ja jetzt eigentlich erstmal Open-Code-Fragen, Codex ist sehr gut im Bug fixen, dass man sagt, es gibt dieses und jenes Problem, das ist was nicht funktioniert, schau mal selber nach, ob du das Problem weiter spezifizieren kannst und dann erzähl mir mal, was du siehst, was du denkst und dann irgendwie mit dem Recreation-Test starten und dann implementieren. Da ist man quasi sehr, sehr, sehr nah dran. Ja, so ein bisschen wie Pair-Programming mit einem anderen Kollegen. Versus das erste ist dann wirklich eher so Batch orientiert, wo man vielleicht dem Team eine Aufgabe gibt und dann führte man ein paar Tage später zurück. André Neubauer: Spannend, spannend. Ich hab so ein bisschen gerade schon geschaut, wir sind irgendwie bisschen abgebogen ... ... sind schon ehrlich gesagt ein gutes Stück wahrscheinlich da, ... weshalb ich dich angefunkt habe. Du, vielleicht versuchen wir mal so noch mal den, ... ... quasi die Schleife. Du hast bei LinkedIn, das werden wir auch in die Show notes packen, bei LinkedIn quasi was gepostet, 15 15 agentic coding rules for success. Und ich nehme an, dass du da dir irgendwie Gedanken gemacht hast, quasi in welcher Reihenfolge du das machst. Insofern willst du uns da so bisschen vielleicht durchführen, dass wir die Struktur nicht ganz brechen. Sebastian: ... können wir gerne machen. Tatsächlich total spannend. habe ich mir irgendwie zwei Stunden bevor ich das gepostet habe, habe ich darüber nachgedacht und gesagt, ist ja eigentlich gar nicht so schwer heutzutage. Man beachte den ersten Punkt, den zweiten Punkt, den dritten Punkt und dann hat man es schon. Und dann habe ich irgendwie geschrieben und geschrieben und auf einmal hatte ich 15 Punkte. Und das habe ich dann einfach nochmal ein bisschen gegengelesen, kurz irgendwie eine LLM drüber korrigieren lassen, so die groben Schnitzer raus. Und dann habe ich es gepostet und tatsächlich fanden das viele Leute interessant. Genau, und am Ende umreise ich in den Post halt die essentiellen Dinge, sage ich mal, ⁓ Cloud Code, Open Code und die Tools, die sind von den Features ja heutzutage sehr, ähnlich. Was eigentlich ein Must-Have ist so, dass man nicht frustriert ist. Und das ist einfach Learning über die letzten sechs bis zwölf Monate, sage ich mal, wo sich wieder mal extrem viel verändert hat. Sebastian HMZE: würde ich sagen gehen wir doch mal genau direkt rein vielleicht kannst du uns da mal grob durchführen ⁓ Sebastian: Genau, Ja, Also eine Neuerung, so ein bisschen für Überraschung sorgt. Agenten wollen ja häufig so eine Konstitution haben. Das findet man häufig als Cloud-MD-File, Agents-MD-File. Das ist die Open Source Variante. Und für eine längere Zeit war das halt einfach der Text Schnipsel sozusagen, der einfach immer mit an das LLM geschickt wurde. Das heißt, eine Best Practice war einfach man arbeitet mit seinem Agendic Tool, hat ein Problem, naja, jetzt fügt das mal mit zu diesem Cloud-MD-File hinzu. Problem ist jedoch, und jeder, der das häufig benutzt, kann das sicher bestätigen, du kannst dem halt immer wieder sagen, mach mal, arbeite mal testgetrieben, oder mach bitte dieses und jenes nicht, und er wird es halt trotzdem immer wieder machen. das hängt häufig da dran, je mehr man da reinschreibt, desto weniger hält er sich dran. Und das hat einfach so eine best practice Gefühl, dass man sagt, Haltet diese diese constitution files minimal Aber die folge frage ist ja dann na ja aber ich möchte ja trotzdem meine java best practices irgendwo hinschreiben ja oder Ich möchte so ein bisschen guidance geben Keine ahnung wie das projekt aussieht und so weiter und das einfach de facto best practice jetzt ja Die aufgaben die man halt in diesem projekt macht wo diese cloud und die liegt sage ich mal, wenn das, was dort drin steht, sollte für 90-95 % der Aufgaben relevant sein. Das führt häufig dazu, dass es um Ordnerstruktur geht. Angenommen, man arbeitet irgendwie mit Domain Driven Design und Bounded Context, naja, dann passt das halt sehr gut da rein. Und dann kann man sagen, das ist die Ordnerstruktur, das ist der Bounded Context, ein bisschen beschrieben, also das ist die Business Domäne. Und ansonsten eher mit Wegweisern arbeitet, für Java-Probleme. Lad mal bitte immer diesen und jenen Skill. Und da merkt man dann schon, dann fängt man schon an, andere Tools zu verwenden von den Agents, die gebaut wurden, ⁓ Kontext so bisschen on demand zu füllen. das Problem war ja wirklich, der Kontext ist zu groß, die Konstitution-File ist zu groß. Ich möchte eigentlich dieses Wissen und diese Files wurden wirklich sehr, sehr groß. Das möchte ich eigentlich on demand reinholen. Wenn ich ein Git-Commit mache, ich vielleicht meine Git-Convention, das Wissen dazu reinholen. Wenn ich im Java arbeite, will ich meine Java-Conventions rein. Und wenn ich die Tests schreibe, die Testing-Conventions, wenn ich QA mache, die QA-Conventions. Und das kann man ja, also ich habe mittlerweile in einem Repo bestimmt über 25, 30 Skills. Und jedes Mal, wenn irgendwas nicht klappt, überlegt man, hey, welchen Skill steckt man das dann rein? Also ich habe es glaube ich nicht so klar definiert. ist das Skill? Ein Skill für so einen Agent ist wirklich, da gibt man einen Titel rein, eine Beschreibung und dann natürlich einen Content und eigentlich sollte der Agent anhand der Beschreibung und des Titels den Skill automatisch laden. Es hilft trotzdem ab und zu, wenn man in die Konstitutionen-File da noch eine Wegweise reinpackt und sagt, genau, bitte wirklich laden jetzt. Sebastian HMZE: Das machst du also in die Cloud-MD oder Agents-MD, dass du dann noch mal die Skills auflöstest und sagst, wenn das, dann das sozusagen. Sebastian: Genau, aktuell wird das immer häufiger. mache es nicht, es ist für mich kein Must-Have. Aktuell sage ich immer, hey, wenn ich merke, der Skill wird nicht geladen, hätte aber geladen werden müssen, dann versuche ich es nochmal über diesen Weg. Und so eine Situation hat man trotzdem noch. Man hätte gerne, dass dieses und jenes halt passiert. Es passiert trotzdem nicht immer, aber immer häufiger und vor allem mit den neuen Modellen funktioniert es besser und deswegen muss man Micromanagement, sage ich mal, machen. André Neubauer: Hm. Frage in dem Zusammenhang vielleicht also lasst uns mal bei den Sachen immer direkt rein fragen. Schert ihr die Skills? Also scherst du die Skills im Team oder habt ihr da ein gemeinsames Repo? Wie organisiert ihr euch da? Sebastian: Wir sind aktuell dabei tatsächlich für Teams und für mehrere Teams dann großes Repo zu erstellen. Da gibt es schöne Open Source Tools. Das heißt, Skillshare ist so ein wo man dann relativ einfach auf dem Repo zeigen kann. Dort kann man die Skills ablegen. Und das heißt, das was in so einer Konstitution drin ist, sollte in der Regel für jeden gelten. Das ist dann einfach Projektinformation. Da lässt sich relativ wenig debattieren. Aber für so eine Skills, zum Beispiel Testing. André Neubauer: Ja. Hm. Sebastian: Das ist immer so bei den verschiedenen Völkern von Entwicklern. Vielleicht der eine will eher mocken, der andere will irgendwie lieber von außen testen. Und da ist eher die best practice zu sagen, man legt mehrere Skills ab. Wir haben das tatsächlich in einem zentralen Repo. Fangen das aber jetzt erst bei uns an zu etablieren. Also die Lernkurve ist da, die Entwickler brauchen Zeit, die Teams brauchen Zeit. Aber Ziel ist jetzt schon, das Repo zu füllen. und dazu sagen, hey, lasst uns da mal die Skills ablegen und jeder Entwickler kann dann die Skills durchsuchen und kann sich selbst überlegen, welchen Skill er denn lädt. Sebastian HMZE: vielleicht dann noch mal eine Folgefrage. Wenn wir jetzt mal Testing nehmen, wie nutzt du denn den Skill? Der muss ja auch in den den Loop sozusagen richtig eingebunden sein. Also wenn man jetzt Loopen rein das TDD machen würde, würde man natürlich sagen, schreibe erst alle Tests, dann implementiere, dann gucke ob die Tests grün sind und erst dann quasi sie den Task als beendet an. Ich glaube das hat Steve Yagy so ungefähr auch in seinem Beats framework so hinterlegt also da halten sich die agents auch immer nicht dran kann ich aus eigener erfahrung sozusagen sprechen aber wenn ich sie dann noch mal drauf stube hast du wirklich alles gemacht was drin steht dann machen sie es auch genau wie nutzt du also jetzt mal ein beispiel von den testings skill wie nutzt du das Sebastian: ist eine total spannende Beobachtung. Wenn ich irgendwie nah rangehe, ich sage, ich habe keine große Planungsphase, gar kein großes Taskmanagement, dann hat man das irgendwann drin. Vielleicht legt man das sogar in einen Command ab, sagen, laden wir mal bitte diesen Skill und jenes Skill, so ein kleines Argument, das ist die Aufgabe. Dann benutzt man die Commands, ⁓ sich nicht immer wiederholen zu müssen. So lädt er dann automatisch die Skills rein. ⁓ habe ich zum beispiel auch ein testing skill wo ich sage behavior driven ich möchte eher refactoring enable schreibt bitte skills eher auf der use case ebene hier und da sind sind unit tests natürlich sinnvoll aber unterscheide da immer so ein bisschen und vermeide mocking außer in diesen und jenen fällen so ähnlich sieht das skill aus und da hält er sich tatsächlich relativ gut dran und bei den großen batch aufgaben wo man sagt man hat das kommando vielleicht nicht direkt ist es indirekt trotzdem im Kommando drin. Beispiel habe ich jetzt angefangen bei dem Task-Kommando. Also man spezifiziert erstmal was man machen möchte. Man spezifiziert den Textag und dann sagt man, planen wir mal für dieses Increment so ein paar Tasks raus. Eine lange Datei mit vielen Checkboxen und da stehen sozusagen dann die einzelnen Aufgaben. Jetzt kann man hier wieder einen Trick machen. Man kann halt hier wieder sagen, hey, das Modell vergisst irgendwie immer die Tests zuerst zu schreiben. Naja, wir können das aber als Task definieren. Man kann sagen, die erste Task schreibt man in den Use-Case-Test auf der Ebene, die Nachfolgenden sorgen dafür, dass der Test dann irgendwann grün wird. Und so findet man seinen Weg, entsprechend dem LLM immer wieder den Wegweiser in die Hand zu geben. Und zu sagen, vergiss bitte das Testing nicht. André Neubauer: ist schon aber auch sehr nah am Prozess. Also wirklich sehr stark. Du hast vorhin so ein schönes Wort genannt. Orchestrierend. Aber ich weiß gar nicht, ob das noch orchestrierend ist ... oder nicht schon fast steuernd. Das Orchestrieren hätte für mich eine gewisse Distanz in der Bedeutung des Wortes. Okay, aber verstanden. Sebastian: Ja spannend. Ich glaube, mit der Distanz man nicht weniger man macht mehr. Man muss immer voll dabei sein. Ich hatte ein paar Mal Erfahrung und die prägt sich ein. Man steckt jetzt irgendwie sechs Stunden in der Aufgabe rein, ist dann irgendwann fertig, guckt dann den Code an, weil man halt nicht genug gereviewt hat und auf einmal steckt man dann nochmal zweimal so viel Zeit rein, ⁓ alles zurechtzurefaktoren. Sebastian HMZE: Ja. Sebastian: Das macht keinen Spaß, aber trotzdem gehört es zum Learning mit dazu und das trifft es, glaube ich, ganz gut. Man muss immer die Distanz finden, die okay ist. Im Zweifelsfall lieber näher ran als langsam, anstatt im Nachhinein alles wegzuschmeißen oder ewig umzubauen. Sebastian HMZE: Ja, genau. glaube, das hängt wirklich auch vom Projekt ab. Wenn du hauptberuflich an einer großen Codebase arbeitest, wo quasi hunderttausende Millionen User täglich mit konfrontiert sind, dann gehst du da anders und musst du da anders rangehen als für ein kleines Pet-Project oder so. Genau. Und da ist dann viel mehr Orchestrierung schon der Fall und nicht mehr so eine fein detaillierte Steuerung. André Neubauer: Klar. Die Frage, die ich mir stelle, ohne dass wir jetzt hier ganz, ... wir machen gleich weiter mit der Liste, versprochen. Referenz zum Podcast, zum letzten Podcast mit Robert. Elastic Loop, wo wir halt irgendwie drüber geredet haben, ... ... im Endeffekt so bisschen der, der, der, der Cycle ... viel größerer wird. Ich frage mich, wie das halt irgendwie zusammenpasst. Wisst was ich meine? Sebastian: bedeutet die Feedback Loop sozusagen. Sebastian HMZE: Genau, also... Genau, also was er gesagt hat, er hat im Prinzip diese beiden Extremfälle beschrieben, die ich auch versucht habe gerade aufzumachen. es gibt oder er argumentiert, dass es im Ermessensspielraum der einzelnen Personen sein sollte, zu entscheiden, wann sehr, sehr eng mit dem Agenten gearbeitet wird, wann man aber auch sagen kann, ich lasse den jetzt über Nacht mal acht Stunden rödeln und er baut mir dann schon was Schönes. Sebastian: Ja, macht total Sinn. Und tatsächlich, das, da immer eine Punktlandung zu haben, also da die richtige Distanz zu finden, ich glaube, das ist die Königsdisziplin. Ja, ich kann mir auch vorstellen, dass das fällt mir und mit den Leuten, mit denen ich viel zusammenarbeite, auch da noch schwer. Diese agentische Entwicklung ist häufig noch irgendwie eine Einzelpersonen Disziplin. Aber es wird ja total spannend, wenn man mal sagt, man setzt sich mal zu zweit, zu dritt hin. jeder ist auf einem ähnlichen Wissensstand und denkt, hey, lass uns mal kurz darüber diskutieren, wie nah wir hier dran sein müssen. Weil, wenn man das wirklich gut einschätzt, dann spart man sich unglaublich viel Zeit. Sebastian HMZE: dann machen wir mal weiter. Wir haben noch ein paar Punkte vor uns. Sebastian: Ich lese gerade auch nochmal drüber. Ich hatte ja schon über Skills gesprochen, haben über die Konstitutionen gesprochen. Spannend vielleicht nochmal. Andre? Hast du noch eine Frage? André Neubauer: Ja, ich fand diesen Punkt, also den dritten Punkt hier ... ... Everskill Rule Needs an Automated Check, ... Your LLM will Wild Day Tools. Kannst da noch ein bisschen drauf eingehen? Das fand ich eigentlich ganz ... Genau, diese doppelte Klammer. Sebastian: Mhm. Ja, war für mich einfach ein riesen Gamechanger. Häufig hat man immer versucht, ich schreibe das jetzt in die Konstitution rein, ich schreibe das jetzt in die Skills rein. Aber das Beste eigentlich, was man machen kann, wirklich immer so einen Check drin zu haben. Unter der Voraussetzung, dass er relativ schnell ausgeführt werden kann. In der Entwicklung... Was spielt da eine Rolle? Klar, Tests, da müssen Tests sein. Wenn die Tests schnell laufen, super. Wenn sie halt bisschen länger benötigen, weil man irgendwie integrationsmäßig X-Docker-Container starten muss, dann ist das nicht schön, aber häufig auch okay. Aber Architekturregeln, ArcUnit im JVM-Bereich, super cool, im TypeScript-Dependency Cruiser. Wenn man sich da eine gute Struktur überlegt, also bounded context und irgendwie so bisschen hexagonal Architektur oder was auch immer, und das da schon als Regel aus ausführbaren Regelcheck ablegt in Kombination mit dem Wissen in irgendeinem Skill dann ist man richtig gut unterwegs und dann kann man so einen LLM auch mal ein paar Stunden auch mal arbeiten lassen, weil er realisiert die Fehler und korrigiert dann selbst. Also bei mir ist jetzt mittlerweile best practice, wenn es da irgendwie ein Problem gibt, ich überlege, okay Welche Regel folge ich denn hier? Und das kann was total Triviales sein. So ein i am Anfang von einem Klassenname. Gefällt vielen Leuten nicht, gefällt mir auch nicht. Ist total trivial. Aber passiert halt trotzdem irgendwie immer wieder. Naja, anstatt zu sagen, ich schreibe es jetzt nur in die Konstitution, habe ich mittlerweile mir angewöhnt zu sagen, du hattest hier ein Problem. Erstell mir doch mal bitte einen programmatischen Check. Ob das jetzt irgendwie ein Bash Script ist oder eine TypeScript-File oder was auch immer ist, ist erstmal egal. Aber dass man wirklich die Gewohnheit etabliert, wenn es irgendwie überprüfbar ist. Und das muss nicht perfekt sein. Es gibt immer irgendwelche Edge-Cases. Aber mittlerweile in einem TypeScript-Projekt habe ich da 15 Checks, die laufen parallel. Das geht relativ zügig. Und das wird einfach nur mehr. Ja, aber es fühlt sich sehr, gut an. André Neubauer: Danke. Sebastian: Genau, Commands zu verknüpfen ist glaube ich auch noch so ein... machen vielleicht schon einige, aber gefühlt ich mache es auch immer zu wenig, dass man sich so ein bisschen den Workflow überlegt. Man kann natürlich so einen Workflow auch irgendwie in so eine Konstitution reingeben, aber wenn es halt wirklich ein ganz klarer Workflow ist, erst das machen, dann das, dann das. Ich zum Beispiel in Seitenprojekten, wie gesagt, da geht es halt wirklich mit so einem... Spezifizierung, Texteq, dann Task Breakdown, dann kommt irgendwann die QA-Phase. Man will idealerweise sein Modell auch ermöglichen, irgendwie einen Browser zu steuern, Screenshots zu nehmen, einfach, ja es gibt Tests, alles gut, aber auch mal die visuelle Validierung und dann geht er einfach da nochmal drüber. Das kostet irgendwie 10 Minuten, 15 Minuten vielleicht auch Datenbankzugriff für die lokale Docker-Datenbank, sodass er sagt, alles klar, ich habe irgendwie Neues Feature gebaut, das spielt eine Rolle, falls ein Nutzer in dem und in dem State ist. Es funktioniert einfach unglaublich gut, dass das LLM dann genau diesen State herstellt. Das lieber nochmal manuell testet. Ich bin kein Freund von manuell testen, aber wenn es die Agenten machen, dann funktioniert das sehr sehr gut. Und das ist dann dieser Workflow und das lässt sich tatsächlich relativ gut mit Commands entsprechend verbinden. André Neubauer: Mhm. Sebastian: Genau, Hooks wurden hier noch, habe ich auch noch mal genannt. Hooks ist auch irgendwie sowas. Ich habe mich extrem lange gefragt, wozu benötige ich denn Hooks. Tatsächlich habe ich persönlich nicht so viele Use Cases, aber die Use Cases, ich habe, die sind relativ cool. Wo man halt wirklich sagen muss, wenn irgendwas gemacht wird, direkt beim Editieren oder direkt bei einer Kommando Ausführung, soll direkt etwas ausgeführt werden. Zum Beispiel das Linting, das Formatting. Einfach schnellere Code Updates, nicht das nervige, ⁓ man hat entwickelt, dann läuft der Linder drüber, der kann vielleicht korrigieren oder manchmal auch nicht. Und dann dreht man dann noch mal extra Runden versus wird direkt bei einem Schreiben entsprechend ausgeführt. Oder auch was ein spannender Use Case ist, ist zu sagen, hey, hier möchte das LLM irgendwie ein Kommando ausführen oder irgendwas machen, dass ich da ein paar Patterns ablege. Das bitte auf gar keinen Fall. Einfach ⁓ Worst Cases zu vermeiden. Und so kann man halt wirklich diese Hooks, ich glaube OpenCode nennt das eher Plugins, genau, sind einfach trotzdem hilfreich und ist sehr, einfach, einfach aufzusetzen. Ansonsten das Think Meter habe ich hier noch hinzugewägt, der neunte Punkt. Also irgendwie, wir als Menschen, wir sind ja immer so bisschen begrenzt im Denken. Man denkt sich, okay, ich habe jetzt Hooks, ich habe jetzt irgendwie so eine Konstitution, jetzt benutze ich halt das. Okay. Und dann gibt es halt Skills. Okay, na jetzt kann ich auch Skills benutzen. So, aber wie man die Skills definiert und diese Routinen. Also ich habe zum Beispiel einen Skill, der mir sagt, wie ich Skills am besten erstelle. Ja, und in dem steht drin, ein paar Best Practices dafür. und bitte einen automatischen, also einen ausführbaren Script dafür. Ja, wenn es irgendeine Regel ist, wofür ich einen Script schreiben kann. Ja, also man kann da immer irgendwie eine Ebene oben draufsetzen, wo ich sage, hier kann ich mir wieder versuchen Arbeit abzunehmen und immer wenn man irgendwie dahin kommt, jetzt muss ich hier gegensteuern, das als Chance zu nehmen, ja, besser zu automatisieren, mehr Wegweiser für das LLM aufzustellen. Sebastian HMZE: heißt du rufst quasi den skill auf, skill creation und du dann dem agent sozusagen ich würde gerne den und den skill kreieren und dann durchläuft Sebastian: Genau, oder eigentlich noch besser, ich sag dem Agent, ich möchte jetzt ein Skill kreieren, der Agent weiß, dass es den Skill gibt, für, die das Skills erstellen und lädt das automatisch. Ja. André Neubauer: ⁓ okay. Sebastian HMZE: Genau, genau, das meine ich. Und dadurch läufst du mit ihm quasi alles, was nötig ist, ⁓ diesen Skill fertigzustellen. Also inklusive Automated Check Beschreibung, was er tut etc. Ich habe tatsächlich von einer Person auch mal gehört, die das so ähnlich mit diesen Self-Improving Loops macht, die du auch erwähnt hast. Also sprich, dass man immer, wenn man feststellt, klappt irgendwas nicht so richtig, dass man mit dem Agenten selber so eine Retro macht und dann mal fragt, hey, wie ist denn der Task so gelaufen aus seiner Perspektive, was können wir tun, ⁓ das besser zu machen. ist ja auch nochmal dann die Metaebene. Habe ich selber ehrlich gesagt noch gar nicht ausprobiert, aber stelle ich mir auch ganz interessant vor. Sebastian: Irgendwann macht man das automatisch. das ist keine Ahnung, heute zum Beispiel habe ich bestimmt, weiß nicht, vielleicht 10 Commits in das Skill Repo von mir gemacht, weil ich Skills geupdatet habe. ist irgendwie, sobald was nicht klappt, sollte man immer die 20 Sekunden investieren und sagen, kann ich hier irgendwo mehr Guidance geben. Und häufig ist es, okay, es ist in der Session passiert, dann nochmal, hey, hier lief ja was schief, fassen wir einfach nochmal die Learnings daraus zusammen. Und in einer anderen Session geht man dann rein, hey, update mir mal den Skill, das sind die Learnings von der letzten Session, guck mal, ob du da noch an dem Skill irgendwas verbessern kannst. Und das kann man wahrscheinlich irgendwann noch mal verbinden. Aktuell ist das bei mir tatsächlich noch projektmäßig getrennt. Aber schön wäre es ja, wenn er das automatisch macht. Aber genau, da sind wir dann wieder in so einer Vollautomatisierung als Ziel, was aktuell zumindest bei mir noch nicht so gut funktioniert. Sebastian HMZE: leichter noch mal die frage hast du in deinen projekten also beruflich privat mit verschiedenen projekten auch zumindest so übertragbarkeit dass du die skills auch also diese skillsammlung übertragen kannst oder also du musst die nicht bei jedem projekt sozusagen wieder von vorne beginnen Sebastian: Korrekt, die Skills funktionieren bei den Code-Agenten so, da kann man sich überlegen, das Projekt-spezifische Skills oder sind das globale Skills. Und das Tooling darum ist auch super gut mittlerweile, da kann man auch sagen, alles klar, angenommen, ich greife jetzt auf ein Teamskill-Repo zu und kann sagen, diese Skills gehen bitte in meine globalen Skills rein, diese Skills gehen jetzt nur in das Projekt rein. Manche checken das auch einfach ein in das Repo, wenn es Projekt-Skills sind. Ja genau, das muss man immer so bisschen abwägen. Ich selbst habe noch so ein paar Probleme mit projektspezifischen Skills, weil ich immer denke, ja warum ist es denn projektspezifisch? genau, ich meine, wenn man viel mit anderen Teams arbeitet oder so, kann man sich das überlegen. Aber keine Ahnung, meine Java Best Practices sind häufig sehr, ähnlich oder meine Git Conventions. Aber klar, ein Consultant muss da wahrscheinlich anders arbeiten. Sebastian HMZE: Git-Conventions sind ja ein gutes Beispiel, aber Java-Conventions, wenn du halt ein TypeScript-Projekt machst, da wird es dann projektspezifisch oder oder testing musst du ja in Projekten auch unterschiedlich angehen, je nachdem. wie das Projekt so aufgebaut ist. Deswegen die Frage. Aber klar, gibt sicherlich allgemeinere und dann wahrscheinlich projektspezifischere. Oder bist du der Meinung, du kannst eigentlich alle relativ gut übertragen, musst nur ein bisschen anpassen? Sebastian: Naja, idealerweise, also ich zum Beispiel hab'n General Software Engineering Skill, dann hab' ich ein TypeScript Skill, ein JavaScript Skill und so weiter. Und dann wird das so ein Composing, bisschen. Und idealerweise findet ihr die Skills, halt für ihn jetzt zu dem Moment relevant sind. Und dann funktioniert das einfach. Deswegen meinte ich, dass mit den lokalen Skills und wenn man keine Ahnung mit Microservices vielleicht unterwegs ist, mehrere Repos, es... Sebastian HMZE: Ja, ja, stimmt. Sebastian: Ja, diese projektspezifischen Skills aktuell in zwei Teams benutzen wir auch eher Projekt- oder Skills, die wir halt einchecken. Aber das ist für mich aktuell noch so eine Zwischenstufe, bis wir sagen, wir haben wirklich ein gutes Reposetup, ein Skillsetup und jeder zieht die sich dann rein, wie er es gern hätte. Sebastian HMZE: jetzt verstehe ich. Genau. Und dann ist es am Ende auch, du nutzt ⁓ nur die Skills, du brauchst. Das heißt, wenn du einfach keinen Java Code hast, dann nutzt du halt den Javaskill einfach nicht. André Neubauer: nicht fehlen zu haben. hast vorhin gesagt, was nutzt ihr, ⁓ Skills zu teilen? Sebastian: Es gibt mehrere Tools, Skillshare ist so Tool, habe ich bisschen mit rumgespielt. Funktioniert sehr sehr gut und ermöglicht halt, legt erstmal in seinem Standard ein Skill an und dann sagt man nochmal so einen Sync. Der Entwickler selbst kann dann definieren, ich benutze Opencode und Cloudcode und Curse und was nicht und dann mit dem Sync legt er das dann dahin, wo es die Tools gerne haben. Sebastian HMZE: Skillshare. André Neubauer: Ja, okay. GitHub slash run kids slash Skillshare. Okay. Sebastian: Genau. Ja, ich gucke gerade nochmal in die Liste. Wir hatten das vorher schon mal kurz angerissen. Es geht in Richtung Frustration. Ich höre von Entwicklern und Entwicklerinnen, dass sie irgendwie unzufrieden sind. Dinge dauern zu lange, die Resultate sind nicht so richtig zufriedenstellend. Wir haben schon vorher mal besprochen, wie nah man rangeht. Wie baut man die Feedback Loop auf? Claude Kodig hat wirklich eine sehr, sehr lange Zeit. Da habe ich wirklich jeden Change approved. und das war wie so ein Pair Programming, da war ich sehr, nah dran. Und das macht auch total Sinn am Anfang. nur weil dann irgendwie jemand anderes sagt, nee, ihr müsst irgendwie über Nacht das Ding laufen lassen, probiert euch erstmal so mein Weg weiser. Und hier auch der Hinweis, dass man erst mal nah ran geht, eher approved, sich die Changes anguckt und jedes Mal, wenn man nicht zufrieden ist, merkt man so, hey, irgendwas stimmt noch nicht. Und wenn man dann merkt, 80 % sieht der Code eigentlich so aus, er aussieht, dann kann man weiter weggehen. Ich habe es hier geschrieben. A goal, one-shot task with zero issues. Das wird man nie erreichen. Aber man kommt immer näher da dran und je näher man rankommt, desto weiter kann man dann entsprechend wieder weggehen und so ein bisschen anfangen parallel zu arbeiten. Genau, letztes... und dann würde ich sagen, können wir nochmal schauen. Letzte Sache, wirklich gutes Design, gute Dokumentation. Hilft nicht nur uns Menschen, sondern auch den Agenten. Also ich war ja lange ein großer Fan von... ich habe jetzt irgendwie ein eigenes Projekt, was soll ich da großartig mit Bounded Context irgendwie herumhantieren. Ich kann das mir schon irgendwie arrangieren, aber ich bin immer mehr davon überzeugt... Wenn man von Anfang an, weil man schreibt sehr sehr schnell Code, wenn man von Anfang an sich überlegt, das ist hier irgendwie ein guter Kontext, man überlegt sich, das ist irgendwie so eine Domäne und die Domäne steht vielleicht für sich selbst oder hat einen Verknüpfungspunkt mit einer anderen Domäne, dass man sehr sehr zeitig schon anfängt seine Anwendung so zu schneiden. Und dann hat der Agent halt einfach nur, okay es gibt ein neues Increment, er guckt einfach nur auf den bounded Kontext. Er muss nicht überall links und rechts gucken. Er weiß, okay, der Contract geht in diese Richtung, vielleicht noch zu einem anderen Bounded-Context. Und das war's dann auch. Das heißt, es führt einfach zu einem viel besseren Design. Es fühlt auch die Entwicklern mit den Agenten fühlt sich besser an. Und ich tendiere immer mehr dazu, wirklich von Anfang an ein richtig gutes Design hinzulegen, das im Nachgang umzubauen, wird alles gehen. Aber genau, einfach eine halbe Stunde, eine Stunde mehr Zeit zu investieren. Wie würde ein bounded context aussehen, wie würden die aggregate roots aussehen? Wenn man da schon sich diese doku irgendwo hinlegt und dann einfach nur copy paste macht und dann beim increment das als context mit reingeht oder in einem skill ablegt, dann ist das resultat einfach ein viel besseres. Sebastian HMZE: Ja, ich glaube auch da trifft wieder zu Kontextmanagement. Also ein Großteil von dem, was du auch beschrieben hast, da geht es ja darum, die Agent MD oder Cloud MD klein zu halten, die Skills nur so zu laden, wie man sie braucht, Commands kurz zu halten und Baune Kontext. Das hilft halt alles, das Kontext Window des Modells nicht zu überfrachten. sodass es anfängt, dann Dinge zu vergessen, weil die einfach nicht mehr im Kontext Windows sind. Von daher macht auch insbesondere der letzte Punkt wieder viel Sinn. Und da sind wir wieder bei, sagen wir mal, was früher Best Practices waren für gute Softwareentwicklung, irgendwie, trifft dann auch immer noch zu, weil auch für die Modelle oder die Agents, auch die haben mit Cognitive Load zu kämpfen. den müssen wir managen, wie das bei Entwicklern genauso ist. Sebastian: Das stimmt. André Neubauer: Ich glaube selbst bei noch also mal angenommen das ... Thema Kontextwindow fällt sogar irgendwann mal oder ... man kann Kontext gut ... weiß ich nicht clean ... komprimieren sonst irgendwas ... ... für mich auch immer noch so ein bisschen wie ... ... bei Daten wenn du Daten analysieren willst ... am Ende muss ich halt auch um Sample halt irgendwie ... Gedanken machen wenn du das halt irgendwie wenn du ... ... das wenn du nur einen Ausstieg nimmst und das nicht ... richtig gewichtest dann ... Du halt irgendwie auch bloß nur für den Ausschnitt halt irgendwie die richtigen Insights. Und so ist es halt auch. Also ich glaube, das alles baut ein bisschen darauf auch auf. Also neben dem Kontextmanagement, dass es halt auch. Also ein guter Kontext ist, sei das ich glaube, das ist am Ende ist das quasi also Neues kriegt ein LLM halt auch relativ schlecht raus. Also quasi wenn du das halt irgendwie falsch fütterst, hat es halt einen Impact. Insofern. All diese Sachen, ich finde das eine der Sachen, ... der Hauptthemen für mich, ... die wir am Anfang sehr hochgehalten haben, ... all das Prompting ist so in den Hintergrund gerückt. Ist aber eigentlich so relevant, ... weil auch ein Skill kann halt, ... ... also da gibt es wahrscheinlich quasi Dimensionen dazwischen, ... die gut und schlecht sind, ... bloß weil ich ein Skill, ... ... also nicht jeder Skill ist halt irgendwie toll. ich glaube alles das, was du auch beschrieben hast, muss halt irgendwie richtig genutzt werden. darüber einen der Basissachen ist ... ... über Kontextmanagement, da bin ich total bei Sebastian ... ... und das andere ist halt irgendwie ... Precise sein. Ja. Ihr habt noch so paar Folgefragen. bin ... Ich muss das mal ein bisschen für mich ... noch besser in Kontext packen. Wie ... Was hatten das alles ... ... für euch als Auswirkungen, also alles, was du so bisschen erzählen kannst. Wenn ihr da in der Organisation ... quasi, also wenn das ein bisschen ein breiter getragener Ansatz ist, was hat denn das für eine Konsequenz? Ändert das was mit der, ändert das was so einer Teamkomposition? Habt ihr jetzt andere Rollen oder habt ihr gewisse Rollen nicht mehr? Habt ihr, sind, Teams kleiner, weil halt irgendwie überall Agenten rumrennen? Wie, wie, was sind denn die Auswirkungen davon? Sebastian: Spannende Frage. Also ich kann nur sagen, in den Bereichen, ich unterwegs bin, braucht es einfach noch Zeit. Es gibt die Pioneers. Jedes Team oder jedes zweite Team hat vielleicht so ein Pioneer. Ich habe schon ein paar Workshops in Richtung Cloud Code und so weiter gegeben. ist häufig sehr sehr kollaborativ. Und was ich spannend fand, ist wirklich, wenn man sich mal den Durchschnitt der Erfahrung und der Adoption anguckt, sage ich jetzt von einer 1 bis zu einer 10. 10 ist wirklich, jeder benutzt das sehr exzessiv. Sind wir da noch aktuell? Und da rede ich das, was ich bei verschiedenen Firmen von verschiedenen Leuten höre, noch relativ weit unten, vielleicht bei einer 2 von 10. So eine komplette AI-Company, irgendwie 10 X-Engineers, wie sie fandet, die werden sicherlich ganz anders arbeiten. Aber das ist das, was ich so sehe. Was sich anbahnt? ist, wenn so ein Entwickler auf einmal am Tag 5 oder 10 PRs rausschiebt, dann hat das eine Wirkung. keine Ahnung, die Kollegin ist vielleicht so bisschen genervt, dass sie jetzt irgendwie am Tag 5 PRs reviewen muss. Das war einfach vorher nicht, oder der Kollege. Oder ja, produktmäßig muss man halt ganz, ganz anders auf einmal, also die Flaschenhälse. wären auf einmal andere und dementsprechend muss sich alles darum irgendwie anders aufstellen. Man kann viel mehr Exploration machen, man kann mal schnell irgendwie ein Prototyp bauen, das geht sehr sehr gut und auch das für dann wieder in Richtung Aufwand nutzen, für die Leute die halt Agenda Coding entsprechend so benutzen, wird das auf einmal eine komplett andere Rechnung. Code wegwerfen ist auf einmal viel häufiger oder sollte viel häufiger sein. Das hat man sich ja immer so früher gewünscht. Lass uns mal ein Prototyp bauen, ein Proof of Concept, wir schmeißen danach alles weg. Und am Ende hat man es doch benutzt. Die Spielregeln ändern sich jetzt ein bisschen. André Neubauer: Okay, okay. Ich finde, das heißt aber auch im Umkehrschluss, ... das wäre meine Folgefrage noch gewesen, aber die hast du jetzt indirekt schon beantwortet. Ihr habt dann auch alle gar nicht das gleiche Setup. Also ihr könnt ja nicht, wenn du sagst, ... dass es in jedem Team quasi so einen Ambassador gibt. Und also jemand, da ... ... ein Pioneer hattest, du glaube gesagt, ein Pioneer, ... ... der das Thema jetzt sehr weit trägt. Ich frage mich immer, was die Konsequenz daraus ist. Quasi was ... bedeutet das für eine Organisation? Was bedeutet das für Prozesse, für Rollen? Gibt es so viel Spezialisierung? Ja, also quasi stehen die sich dann irgendwann auf den Füßen, wie sehr muss man standardisieren. quasi ist das jetzt, ich kann mich entsinnten, dass quasi Sebastian und ich noch Software geschrieben haben. Da gab es ja auch eine gewisse Vorliebe für IDIs. Und genauso wird es das wahrscheinlich auch heute sein. Der eine sagt halt, so wie du auch eingangs gesagt hast, gibt es eine Lernkurve. Mensch, hier Cloud Code und dann ach nee eher codex oder das eine für das eine und das andere ist andere glaube ich nennies podcast war das gerade eine der letzten voll leitenden letzten episoden das fähig der glaube steht uns noch echt eine menge vor punkt jetzt habe ich keine frage formuliert siehst du das genauso Sebastian: Ich glaube auch, wird sich viel verändern. Aber es wird auch Zeit. Es wird eine ganze Weile dauern. Ich glaube halt, man wird mehr die Arbeit machen, die wirklich wichtig ist. Nicht falsch verstehen, ich liebe es zu entwickeln. Ich habe sehr gerne sehr viel entwickelt. Aber die wirklich kritischen Entscheidungen, Customernähe, Marktbewertung, so eine Geschichten. Es gibt ein paar Bücher und paar Blogposts in Richtung Product Engineer. weiß nicht, ob das eine mögliche Arbeitsweise für Teams in der Zukunft ist, aber dass man sich halt ein bisschen mehr Produktverantwortung in Richtung Engineers abgibt. ja, weil die Entwicklung an sich wird einfacher. Ich will nicht sagen, die wird trivial in allen Bereichen, aber eine ganze Menge kann man halt einfach mit Agents schneller umsetzen, mit einer teilweise besseren Qualität. Und das verändert die Spielregeln so ein bisschen. Und da muss man sich fragen, na ja, wenn jetzt diese drei, vier Engineers pro Team, und dann so in Richtung 2Pizza Teams, denkt, wenn die jetzt auf einmal fünfmal so viel Output haben, dann funktioniert halt die ganze Rechnung nicht mehr und das Gleichgewicht passt nicht. André Neubauer: Hm. Sebastian HMZE: Das hört und sieht man immer wieder sozusagen in den Posts und Beiträgen und Und das wird jetzt, glaube ich, in diesem Jahr werden wir starke Veränderungen in die Richtung sehen. Es ist bisschen beruhigend auch mal von jemandem zu hören, der sagt, wir sind erst bei zwei von zehn sozusagen. Aber ich weiß nicht, wenn wir uns in einem halben Jahr unterhalten, Da würde mich mal interessieren, wo wir dann sind auf der Skala. In einem halben Jahr passiert so viel. Allein was jetzt in den letzten zwei Wochen passiert ist, ist schon der Wahnsinn. Genau was ich dann auch so hatte, auch der Gedanke ist Bild versus By kriegt eine völlig andere Dimension, weil Bild auf einmal ganz oft eine Option ist, die du früher nicht verfolgt hätte es. Das ist so ein bisschen andere sagt gerne wie your margin is my weekend project und ich habe gerade mehrere Projekte an denen ich so wirklich mit Agenten nebenbei arbeite. muss dann immer sagen der Teufel liegt im Detail. Also am Ende dauert es dann doch und man muss dann doch noch mal hinterher und dann hat man bestimmte Dinge doch nicht so gedacht und versteht dann auf einmal ach deswegen haben die das so umgesetzt. dachte, man hat eine viel bessere Idee, die sich dann als doch nicht so sinnvoll herausstellt. Aber ich sag mal, ein mittelkomplexes Tool zumindest abgespeckt so nachzubauen, dass es für den eigenen Anwendungsfall und man muss ja dann nicht zehn andere Integrationen haben oder noch irgendwelche Sonderfälle oder andere Fälle abdecken, sondern nur für den eigenen Anwendungsfall funktioniert. Das ist schon in endlicher Zeit mit endlichem, auch wirklich echtem Zeitaufwand möglich. Jetzt schon. André Neubauer: Kann ich aus der Erfahrung heute heute erlebt, aber beziehungsweise gestern bei LinkedIn gelesen, glaube irgendein Post so nach dem Motto WordPress.com hat noch sechs Monate und glaube einer der ersten Kommentare darunter war, ja, nee, das unterschätzt du WordPress kann schon sehr, sehr, viel und das halt irgendwie alles abzubilden. Und ich glaube, da liegt genau der Trugschluss. Du hast gerade eben zwei Sachen gesagt. Das ist halt das erste ist halt ist halt Blocks sind sehr, sehr gut beschrieben. Also was ein Block fachlich ist, quasi das kann man, das kann jedes LLM sehr gut spezifizieren. Und das zweite ist halt, du brauchst gar nicht diese ganze Heaviness, die halt die Tools mitbringen. Du brauchst halt, weiß nicht, beim Block irgendwie so ein paar Standardsachen, quasi Textkategorien, Textfeld, vielleicht ein bisschen Formatierung. Aber du brauchst eben nicht die 100 Plugins und hier noch die fünf SEO-Tools und da den Export und sonst irgendwas. Und das ist total at risk. Also habe ich heute live gesehen. Also heute hat jemand einfach mal zusammengepromptet ... und ein Blogsystem hat irgendwie gehabt. Und total, was du sagst, Sebastian, das ist schon durch das Thema. Sebastian: Ich glaube, was man da auch unterschätzt, ist so ein bisschen das Expertenwissen. Wo man vorher sagt, vor allem für so kleinere, mittlere Companies, so eine Experte, keine Ahnung, in der Bildverarbeitung oder irgendwo. Die Leute musste man früher finden, die wollten viel Geld haben. Oder man bezahlt ein Tool. Als ihr das gesprochen habt, habe ich an den Reddit-Post gedacht, wo es darum geht, dass jemand immer versucht hat, so einen Barcode-Scanner irgendwie nativ für iOS... zu bauen und die hingen da irgendwie an einer proprietären Software, die wurde schlecht gewartet, die hat zu Problemen geführt und er meint, es sei Opus 4.5, war es ein Prompt und es hat funktioniert. Das zeigt es halt dann. die Bau... A, derjenige hat nicht die Expertise, aber er kann sich das zusammenprompten, es funktioniert vielleicht sogar besser als das, was er da vorher gehabt hat. Ja, also ich würde jetzt nicht sagen, die Co-ops fangen sich an Slack zusammen zu prompten. Aber ich glaube so viel so kleinere Tools und so weiter, ja total valide. André Neubauer: Ja, Für mich so, vielleicht bevor wir dann auch in den Abschluss gehen, eine Frage, die mich auch zum Nachdenken bringt, seitdem ich, ich muss wieder auf Robert verweisen, letzte Episode, der hatte bei LinkedIn mal geschrieben, quasi worüber, also alle reden über Productivity, niemand redet über Qualität. Und das quasi denke ich die ganze Zeit drauf rum. Was ist es für dich? Sebastian, ist es eher Qualität oder eher Quantität? Sebastian: beides, wenn man es richtig verwendet. Das ist halt die Lernkurve. Vor allem die Engineers, die sich lautstark beschweren, sind manchmal auch ein bisschen mehr opinionated, wo man die Qualität stimmt nicht. Aber spätestens dann, wenn man ein paar Schritte zurück geht und vielleicht irgendwann mal für ein paar Engineers zuständig ist, dann schreibt man den Code nicht mehr selber und dann sieht der Code einfach anders aus. Also ich glaube tatsächlich die Agents, die AI-Tools ermöglichen uns schnellere Code-Changes. Das heißt, viel zeitiger kann man günstiger Refaktoren. Es macht Sinn, das sauber zu bauen, weil dann einfach der Rest einfacher funktioniert. Und über die Quantität, die Geschwindigkeit, das brauchen wir glaube ich auch nicht lange nachdenken. Wenn man weiß, was man machen möchte, wie man es machen möchte und die Tools benötigt, ist man da definitiv auch schneller unterwegs. Sebastian HMZE: Ende ist das, was ich jetzt auch schon öfter gehört habe, was glaube ich Stefan Schmidt auch gesagt hat, war nämlich, dass man einen Amplifier hat. Du hast einen Amplifier und wenn der Input schlecht ist, dann ist das Ergebnis schlechter sozusagen oder oder schneller noch schlechter sozusagen. Wenn der Input gut ist, dann wird er jetzt noch schneller, noch besser. Ich glaube, dass, also da muss ich gestehen, dass das ist so auch das was ich erlebe, wenn ich ein bisschen sloppy bin, ich, probiere mal schnell was aus, dann ist das Ergebnis deutlich anders als wenn ich sage, so ich mache mir jetzt wirklich Gedanken, überlege mir vorher was ich möchte, wie ich da rangehen möchte und welche Constraints und Guardrails ich mitgebe. Riesenunterschied. André Neubauer: Haken dran. Sebastian HMZE: Ja. Sebastian: Genau, ich wollte noch was dazu, eine Thematik, das fand ich damals ja spannend. Howard, ist von FASTA, der derjenige, eigentlich das Transfer Learning für die Sprachmodelle damals den Meilenstein erreicht hat, wo es darum geht, ich trainiere jetzt erstmal irgendwie ein Modell, neuronales Netz auf einem Wikipedia-Korpus und dann setze ich da irgendwie ein anderes Teil oben drauf, sodass ich dann vielleicht Antworten bekomme oder irgendwelche anderen Aufgaben lösen kann. Es gibt ein ganz cooles Interview mit ihm und noch eine sehr spannende Person. Das Name habe ich gerade vergessen, aber ich schicke gerne später mal den Link rum. Und die haben das total gut formuliert. Deren Prediction war folgende und da bin ich komplett dabei. Klar, man kann jetzt irgendwie sagen, es ist der Amplifier, aber spannend ist ja das Warum, wo ich glaube, wird ein riesen Unterschied spürbar, wenn wir jetzt anfangen diese Agenten zu benutzen, Software zu entwickeln. Man hat ein total anderes Lernpensum. Und manche lehnen sich zurück, so ein bisschen das Wipecoding, wie es halt so gerne definiert wird, und dann lassen die mal passieren und dann... Aber... Man hat ja auf einmal so diesen Personal Assistance an der Hand, wo so viel Wissen drin steckt. Das heißt, wenn man jetzt auf einmal mit einer doppelten dreifachen, fünffachen Geschwindigkeit anfängt zu lernen, in die Breite, in die Tiefe, Da wird es ja auch nochmal spannend. finde diese Komponente wird häufig unterschätzt. Wo man sagt, wir haben ein Performanceproblem, wollen wir jetzt vielleicht einfach mal einen Rust schreiben? Wir können ja keinen Rust. Na ja, vielleicht doch. Genau, und dann lernt man auf einmal. Also ich glaube, das wird unterschätzt und das wird auch nochmal gute Teams von durchschnittlichen Teams unterscheiden. Sebastian HMZE: Definitiv. Ja, super spannend. auch sehr cool, wirklich mal aus der Praxis von jemandem zu hören, der das mehr oder weniger sehr, sehr intensiv und sehr auch mit Teams quasi direkt betreibt. Von daher, ich glaube total wertvoll. Und tatsächlich, vielleicht müssen wir uns wirklich in sechs Monaten oder so nochmal treffen. Bin immer gespannt, wie viel sich da dann schon wieder verändert hat und auch wo deine Skala ist sozusagen, die du wahrnimmst. André Neubauer: Genau den gleichen Punkt hatte ich auch gerade im Kopf. sagen mittlerweile, wir müssen uns immer mal in sechs Monaten treffen. Vielleicht ist auch genau das, was den Podcast ausmacht. Alle sechs Monate gleichen Gäste und gucken, wie es weiterentwickelt. Sebastian: Gerne, meine Stimme habt ihr. Sebastian HMZE: schauen. Cool, ja, vielen Dank. Genau, dann haben wir zum Abschluss noch so zwei Segmente. Das eine ist so der Reality Check. Welches Tool hat dich zuletzt enttäuscht? Wo hattest du so WTF-Momente und wo warst du total positiv überrascht oder geflasht oder was, glaubst du, ist der heißeste Scheiße? Sebastian: Ja, ich fange erstmal mit dem an, was mich enttäuscht. Ich benutze schon eine ganze Weile Gemini und Chetchi BT. Ich weiß auch, dass in der Open Source Welt, wenn man jetzt irgendwie nicht im Enterprise unterwegs ist, wo es aus guten Gründen sehr restriktiv ist in Richtung Tool-Anbindung, aber gefühlt, was sich da in den letzten Monaten bewegt hat, ist für mich so bisschen frustrierend. Also man sagt, hey, keine Ahnung, der Zugriff auf den GitHub Enterprise. So eine Thematik. Genau, nicht so einfach, so wie kann ich sagen. Genau, zu Jira und den ganzen Tools. Weil diese Modelle, diese Agenten auch in Chetchibit profitieren natürlich unglaublich davon. Und auch so bisschen dieser Trend. Und ich verstehe die Publisher. Ich verstehe alle, die sagen, hey, ihr klaut jetzt nicht unseren Content. Aber wenn man so ein Tool benutzt und man sieht so bisschen Webfetch, das ist wahrscheinlich dann schon der Moment, wo ich sage, ich suche lieber selber oder frage meinen Cloud Code, meinen Browser aufzumachen. die Erfahrung, die Integration von den Tools, und ich glaube, das ist super, super wichtig, dass es gut funktioniert, dass wir da so langsam vorankommen in den Tools, die für alle zugänglich sind. Ich glaube, so ein Marketing Experte, der ist halt vielleicht nicht so flüssig unterwegs mit Cloud Code, aber so ein Chat-GBT halt schon. Also diese Verbindung und so ein bisschen diese Gegenwehr macht einfach die Adoption und die gute Experience ein bisschen schwer und es ist ein bisschen schade. Ansonsten, was ich super spannend finde, ich habe mir in der letzten Woche André Neubauer: Mhm. Sebastian: Und diese Woche noch ein bisschen weiter OpenClar so bisschen weiter angeschaut. Ja, ich weiß nicht, ob ihr schon den Podcast von dem Macher sozusagen angeschaut habt. geht drei Stunden, drei Stunden, ein zerquetschte. Kann ich empfehlen, kann man immer mal so ein bisschen weiterhören. Ja, also für Leute, die es nicht wissen, OpenClar am Ende eine sehr einfache Möglichkeit. Ihr nehmt euch irgendeine virtuelle Maschine oder ein altes MacBook. installiert das da drauf, gibt einen ChatchiBT API Key rein und dann darf der halt alles machen. Und ihr könnt dann zu dieser Maschine mit WhatsApp oder was auch immer kommunizieren und sowas wie, welche Termine habe ich oder hier ist ein Foto von einem Restaurant. Guckt doch mal, ob ich morgen Abend aufwärter irgendwie hingehen kann. Und der Agent macht dann los. Und was mich da so ein bisschen, was ich faszinierend fande, der Entwickler selbst, als er den Prototyp gebaut hat, hat OpenClaw, bisschen WhatsApp-Kommunikation, Textkommunikation hat funktioniert. Er hat das erste Mal eine Sprachnachricht geschickt. Und OpenClaw, zu dem Zeitpunkt hieß es anders, konnte die Sprachnachricht nicht verstehen. Eigentlich nur Text. Das heißt, es hat so bisschen gedauert und irgendwann hat der Agent geantwortet, hat die Frage beantwortet und er hat so, hä? Wie geht das denn jetzt? Das heißt, in dem Moment hat OpenClaw, diese Maschine, sich selbst weiterentwickelt und er hat dann gefragt, wie hast du das denn gemacht? Naja, ich habe in den Header geguckt, ich habe da gesehen, ist der Header. Ja, irgendwie das mit dem lokalen Modell hat nicht so richtig funktioniert. Dann habe ich aber einen Open API Key gefunden und den habe ich benutzt, habe die API bedient und dann konnte ich lesen, was du mir gesagt hast. Und keine Ahnung, das finde ich mega spannend. Das zeigt so, es ist natürlich scary, aber es zeigt, wohin es gehen kann. Dieser Personal Assistant, diese Schnittstelle zwischen Mensch, Maschine und dann unseren Aufgaben und Wünschen. Das fand ich schon ganz spannend, dass sich das einfach auch jemand getraut hat da weiterzugehen. Und in dem Podcast werdet ihr viel hören, was er da eigentlich für einen Stress hatte und wie er bombardiert wurde von irgendwelchen Attacken und Messages und so weiter. Also sehr, spannend. Sebastian HMZE: Crypto-Dudes. Sebastian: Genau. Sebastian HMZE: Ja genau, habe den Podcast auch gehört. Ist auch super spannend und genau, meinen OpenClaw, den muss ich noch ein bisschen füttern. auch da, ja eigentlich das gleiche Thema, was mit den großen Tools nicht funktioniert, ist genau der Hemmschuh. Wenn du halt einfach nur immer wieder eine Chagy B.T. Sitzung oder eine Gemini Sitzung aufmachst, da fehlt der komplette Kontext. Wenn du aber deinem OpenClaw einfach alles, was du irgendwie in deiner Notizen App hast, als MD-Files mitgibst, dann hat er den kompletten Kontext. Wenn du dann noch ein Knowledge Graph drauf aufbaust, dann hast du deinen second brain irgendwie ausgespeichert und dann kann der so Sachen machen wie, Moment mal, ich habe doch schon mal was gelesen von einem OpenAI Key und da gibt es ja Whisper und dann kann ich das vielleicht hier analysieren, vorher noch mit FFmpeg wahrscheinlich in Wave umwandeln. André Neubauer: Wir müssen eine Eigenwerbung machen, Sebastian, dass noch mal in Tiefe hören will. Letzte Folge mit Robert, da ist er auch tief eingestiegen. Also auch für dich, Sebastian. Wenn die Folge hier veröffentlicht wird, dann ist auch Roberts Folge vorher live. Quasi kann man reinhören. Er gibt aber relativ viele Leute, die da gerade in ins Rabbit hole verschwunden sind. Sebastian: Das höre ich mir an. Sebastian HMZE: Gut, dann sind wir auch schon fast am Ende. Wir haben immer am Schluss nochmal, du hast ja schon auch ein paar Predictions geteilt, interessanterweise bei uns im Gespräch ⁓ immer, weil logischerweise wir ja einen Change begleiten und da geht es natürlich ganz viel darum, wohin geht die Reise eigentlich. Aber gibt es noch irgendeine Prediction, die du jetzt noch nicht hast hören lassen, die du aber unseren Zuhörern noch mitgeben wollen würdest? André Neubauer: ...ein Sebastian: Ich glaube, die nächsten zwölf Monate vorher zu sagen, ist sehr, schwer. Weil die Dynamiken, wohin es gehen kann, was ist das richtige Interface für die Bedienung, ich glaube, das ist noch nicht geklärt. Ich glaube, da wird es Überraschungen geben. Ich kann nicht sagen, wie es ausschauen wird aktuell, dass sich die, keine Ahnung, fünf oder zehn Terminals parallel am besten anfühlen. Ich weiß nicht, ob das das Ende vom Lied ist. Da wird es sicherlich noch eine große Veränderung geben. Und ich bin natürlich total gespannt, ob es noch weitere Modellsprünge gibt. Der Sprung von Opus 4 oder so nicht, 4.5 zu Opus 4.5 war ja immens. Auch von Codex von 5.2 zu 5.3 war immens. Und wenn man so den CEOs von den großen AI-Companies zuhört, dann soll da ja noch ganze Menge mehr passieren. Also konkrete Predictions habe ich nicht. Ich glaube, wir werden immer mehr mit... AI-Arbeiten. glaube, die Entwickler und Entwicklerinnen werden alle nachziehen und es wird auch mehr Spaß machen oder anders Spaß machen, einfach schneller Software zu probieren, zu schreiben mit einer besseren Qualität. Sebastian HMZE: Vielen Dank. André Neubauer: Danke! Sebastian HMZE: Herzlich willkommen zur sechsten 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 erben CTO bei NorthIO. André Neubauer: Und ich bin andere Neubauer CTPO bei Trusted Jobs. Schön, dass ihr wieder da Unser heutiger Gast ist ein ehemaliger Kollege von und aktuell Staff Engineer bei A. Winter. Sebastian HMZE: Genau und diesmal ist es wieder ein Perspektivwechsel. Diesmal aus Sicht eines Engineers, der seit mindestens sechs Monaten tief in Rabbit Hole unterwegs ist und uns auch ausführlich über seine Erfahrungen und sein aktuelles Setup berichtet. Gerade für mich, der ich auch gerade in diesem Rabbit Hole sehr intensiv unterwegs bin, war es super spannend. Freut euch drauf. Viel Spaß beim Hören.