# Agentic Coding: Context Management & Automated Checks

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

## Transcript

Wenn heute die besondere Herausforderung, der Sebastian wird sich gleich vorstellen, dass wir zwei Sebastians dabei haben.
Das wird sicherlich ein spaßiger Podcast.
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.
Und ich bin André Neubaur, CTPO bei Trusted Shops.
Schön, dass ihr wieder da seid.
Unser heutiger Gast ist ein ehemaliger Kollege von mir und aktuell ist Stuff Engineer bei Ade Winter.
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 Erfahrung 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.
Hallo Sebastian.
Herzlich willkommen im Podcast.
Herzlich willkommen an alle Zuhörer und Zuschauer.
Sechste Folge vom HMZE B<unk>Vibe Coding Podcast.
Ja, und jetzt musst du den Gast noch bitten, sich vorzustellen kurz, ne?
Dann hast du das ja hiermit getan.
Aber Sebastian, stell dich doch mal vor.
Ja, hallo, schön hier zu sein.
Mein Name ist Sebastian Siege, Softwareentwickler seit vielen Jahren, immer noch passioniert dabei.
Full Stack, voll und ganz und genau darf heute hier sein, nachdem mir André eine Nachricht geschrieben hat, dass er einen spontanen Post von mir auf LinkedIn relativ spannend fand.
Und ja, ich freue mich heute ein bisschen über Agenda Coding zu sprechen.
Genau, das relativ spannend können wir streichen.
Zumindest habe ich, also relativ habe ich nicht geschrieben.
Ich fand es spannend.
Ich glaube, das ist das Thema, was viele bewegt.
Also, ich glaube, das eine ist halt so ein 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, vielleicht Rahmenbedingungen, Spielregeln halt irgendwie gelten.
Ich finde das super spannend, auch für meinen beruflichen Background, also werde ich hoffentlich heute eine ganze Menge auch mitnehmen nochmal.
Genau, bevor wir da aber einsteigen, fangen wir mal mit so ein paar quasi so ein paar Warm-up-Fragen vielleicht an.
Und das, was wir als allererstes immer fragen ist, wie arbeitest du heute?
Also was ist denn so quasi dein täglich Brot?
Als Stuff Engineer habe ich tatsächlich ein sehr gesunden Mix zwischen Hands on Work, Entwicklung, aber natürlich, ich spreche viel mit Tech Leads, spreche viel mit Businessleuten, schau, dass alles passt.
Wenn es ganz konkret um Agent Decoding geht, total spannend, wie sie eigentlich auch meine Arbeitsweise in den letzten sechs Monaten verändert hat oder eigentlich seit zwei Jahren immer so peu à peu.
Aber man kann halt schon sagen, dass viele Dinge, mit denen man halt zu tun hat, sei es irgendwie ganz basic in Gyra, Tickets mal hier und da erstellen, mein Code-Vew, meine Contribution, dass man eigentlich immer häufiger die Agents als Interface zwischen der eigentlichen Arbeit hat.
Das kann ganz unterschiedlich aussehen.
Das ist manchmal ein Chat-GBT oder ein Gemini.
Das ist aber immer häufiger gefühlt irgendein CLI-Tool, was sehr, sehr, sehr mächtig ist mit Hilfe von diversen Schnittstellen.
Und man ist eigentlich nur noch so ein bisschen am Orchestrieren, finde ich immer, klingt immer so distanziert, ja, aber man macht so ein bisschen Pair-Programming, ja, und mit Hilfe des Agents ist man da anders unterwegs.
Ja.
Du hast gerade gesagt, bis zwei Jahre dabei, also zwei Jahre so in der, ich weiß gar nicht, ob das Agentic-Welt ist, aber zumindest Generative AI, zum Beispiel, also angefangen wird das wahrscheinlich mit GitHub Copilot haben, Fragezeichen.
Of wie waren so deine Journey bis heute?
Es ist total spannend.
Also erstmal, da durch, dass ich auch ein bisschen was in Richtung ML gemacht habe, bevor die LLMs bekannt wurde, war mir das der Ansatz schon bekannt, ne?
Und irgendwann als dann so ein 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, ein bisschen Copy-Paste gemacht, ja.
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.
Okay.
Weißt du warum?
Also GitHub-Copilot, wir reden von GitHub-Copilot oder von welchem Co-Pilot, GitHub-Copilot.
Also, ich hab's dir so verstanden, GitHub Copilot, wie es klassisch war, diese Autovervollständigung, Autocompletion und Stereoids so ein bisschen, ja.
Ja, ich weiß nicht, das hat für mich nie so richtig Klick gemacht.
Es gibt ja schon Auto-Complete, diesen Entwicklungsstil ein Kommentar drüber zu packen und dann kriegt man eine bessere Autocompletion.
Ich glaube, das war mal so eine 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 Visual Studio so richtig reinkam, man konnte Fragen stellen und dann hat er, dann wurde es mehr zu einer Agentic-Experience, so ein bisschen, wobei Copilot da ja wirklich ein bisschen langsamer war als ein Cloud-Code oder andere Tools.
Ich muss, ich muss sagen, dass ich das damals genauso empfunden habe, auch dass ich erst, war ich total fasziniert und habe auch mehr und mehr ChatGPT benutzt und war dann halt zum ersten Mal mit Cursor, wo ja der Agent oder dieses Chat-Fenster in die Idee kam, da habe ich dann gedacht, ja, genau so muss es sein.
Also 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 dann relevant sein konnten.
Das war noch nicht wirklich Agentic, sondern es war eher Kontextbereichern 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.
Ja, das ist eine gute Frage.
Man hat gefühlt dann irgendwann kam ja so Gemini, Gemini hat dann nochmal irgendwie Dinge anders und besser gemacht, irgendwie anders strukturiert.
Ich habe relativ lange dann, es war so ein Bruch, ne, Copilot hat halt so ein bisschen funktioniert, aber nicht immer gut und für die größeren Badges dann irgendwie Gemini und Chat-GPT.
Und irgendwann kam ja dann Cloud Code, ja.
Und ich überlege gerade, ob noch irgendwas dazwischen war.
Aber ich glaube halt nicht.
Es gab immer so ein Plateau.
Egal ob es jetzt, 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 Badges sozusagen, erst seitdem wurde das für mich ein Thema.
Ich glaube, das war dann der nächste größere Sprung.
Ja, okay, genau.
Das müssen wir auch rausschneiden.
Nee, ja, und das, genau, ich habe auch wahrgenommen damals, dass Cloud Code so der erste Agent war, der dann.
Also wie ich meine, nee, tatsächlich hat ja Cursor sogar, ich glaube ich, den ersten Agenten in der IDE gehabt.
Ich weiß es gar nicht mehr so genau, aber Cloud Code war dann kurz danach.
Copilot hatte dann auch seinen Agenten, den ich am Anfang sogar auch ganz gut fand.
Aber inzwischen hängt er doch deutlich hinterher, würde ich, würde ich auch sagen, ja.
Es gab noch diese spannende Phase, das weiß ich noch, ne?
Da konnte man dann im Visual Studio Code.
Ich habe nie Cursor und Co.
wirklich benutzt, ja.
Visual Studio Code gab es dann diesen Edit-Mode, ja, und dann hat er irgendwie auf einmal eine Datei bearbeitet.
Und die haben total lange gebraucht, um dann wirklich so richtig den Agent zu aktivieren.
Das war dann der Hauptgrund zu sagen, hey, warum, warum kommt denn das nicht?
Warum dauert denn das hier so lange?
Wo wir dann gesagt haben, hey, Cloud Code, es sieht interessant aus, verhält sich auf einmal komplett anders und fühlt sich auch komplett anders an.
War das eine bewusste Entscheidung, Cursor zu umschiffen?
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-Havy 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 eben in Visual Studio Code war auch irgendwie komisch, das gab auch ständig Bugs.
Cloud Code hat ja auch lange oder hat immer noch eine Visual Studio Code Integration oder IntelliJ Integration.
Die machen aber irgendwie immer nur Ärger.
Und spätestens, wenn man drei, vier, fünf Terminal-Fenster mal nebeneinander auf hat, weil man halt an verschiedenen Tasks arbeitet, die auch manchmal ein bisschen Zeit brauchen, spätestens dann ist man eigentlich aus der Entwicklungsumgebung raus.
Spannend.
Okay, und das war dann so der Moment, wo du gesagt hast, quasi all in.
Also quasi auf dem, mit dem Stack quasi bist du dann bis heute unterwegs.
Ja, Terminal ja, aber ich bin tatsächlich vor kurzem in Richtung Open Code gewechselt.
Einfach weil ich da auf X so ein bisschen hinterhergelaufen bin und sagen so, 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 Moment und hat nur Open Code 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 radtert 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 so 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 drei, vier, fünf Optionen vorschlägt oder mir vielleicht fünf Fragen dazu stellt, dann kann ich das halt auch schreiben oder reinsprechen.
Ja, dazu muss ich nicht nochmal gedanklich in so einen anderen Modus wechseln.
Und das sind so Sachen, das hat sich für mich einfach besser angefühlt und Open Code kriegt kein Geld dafür oder so, dass ich hier Open Code bewerbe.
Aber dass man da den Luxus hat, einfach andere Model Provider zu verwenden, das ist einfach ein totaler Luxus.
Genau, das Summa Sumaro führt dazu bei mir, dass ich aktuell vor allem Open Code benutzt.
Und benutzt du auch andere Modelle oder ist es dann doch wieder irgendwie Sonnet oder so?
Es ist am Ende Codex und Opus, was ich aktuell benutzt, die zwei sind einfach die Frontier-Models, die Resultate sind beeindruckend.
Und wie die Modelle da funktionieren, es gibt so ein paar Vor- und Nachteile.
So ein Opus ist so ein bisschen, sag ich mal, kreativer und ein bisschen proaktiver.
Und so ein Codex ist, der, der geht direkt in die Preide, der will alles, alles irgendwie wissen, guckt sich von selbst Dinge an, aber braucht auch dann ein bisschen länger.
Aber so, ich glaube, von den Model-Internas, die Stärken, die sind sehr, sehr ähnlich, also die Fähigkeiten, aber dann das Feintuning der Modelle.
Da scheint, ich habe halt gelernt, dass Codex eher ein europäisches Team ist und Cloud Code eher ein amerikanisches Team.
Also beim Feintuning unterscheiden sich da die Präferenzen der Teams.
Das ist total spannend, weil wir in der letzten Episode mit Robert sind wir auch an dem Thema vorbeigekommen und hat es genau so beschrieben.
Codex, nee, weil gesagt, Cloud Code war eher so ein bisschen aufgeregt, will man sofort loslegen.
Und Codex nimmt sich eher immer Moment Zeit, versucht das zu verstehen und quasi, genau, also ja, egal.
Aber das sind da ziemlich ähnlichen Aussage.
Kannst du ein bisschen was zu deinen zu deinem Loop sagen?
Also wenn du, ich nehme jetzt, nehm 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?
Es hängt extrem von der Aufgabe ab.
Ja, 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 Badge-Modus.
Ja, also ich selbst benutze aktuell Spec Kit von GitHub, aber am Ende spielt es keine Rolle.
Es gibt da verschiedene Frameworks, die da 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 putzeln da 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 nochmal nach, lässt den Agenten nochmal selber drüber testen und so weiter.
Also, das ist jetzt das Beispiel, wo ich sage, bei Aufgaben, wo man eher Batch-orientiert arbeitet, weil man viel schaffen kann, das Risiko relativ gering ist, dass da auch mal was schief geht, ja, dann ist das eher so ein Arbeitsmodus.
Vielleicht in einer Anwendung, die jetzt schon in Produktion ist, wo viel drauf läuft, da geht man näher ran.
Also da macht man die Open Code zum Beispiel auf.
Angenommen, wir haben einen Bug, ja.
Irgendwo ist das beschrieben.
Da könnte man ja jetzt eigentlich erstmal Open Code fragen.
Codex ist sehr, sehr gut im Bug fixen, dass man sagt, hey, es gibt dieses und dieses 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 einem Regression-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 einem Team eine Aufgabe gibt und dann würde man ein paar Tage später zurückkommen.
Spannend, spannend.
Ich habe so ein bisschen gerade schon geschaut, wir sind irgendwie ein bisschen abgebogen und sind schon ehrlich gesagt ein gutes Stück wahrscheinlich da, weshalb ich dich angefunkt habe.
Du vielleicht versuchen wir mal so nochmal den quasi die Schleife.
Du hast bei LinkedIn, das werden wir auch in die Show Notes packen, bei LinkedIn quasi was gepostet, 15 Coding, 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 ein bisschen vielleicht durchführen, dass wir da die Struktur nicht ganz brechen.
Können wir gerne machen.
Tatsächlich total spannend.
Das habe ich mir irgendwie zwei Stunden, bevor ich das gepostet habe, habe ich darüber nachgedacht und denke so, hey, ist ja eigentlich gar nicht so schwer heutzutage.
Man beachtet 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.
Ja, und das habe ich dann einfach nochmal ein bisschen gegengelesen, nochmal kurz irgendwie ein LLM drüber korrigieren lassen, so die Grubenschnitzer raus.
Und dann habe ich es gepostet und tatsächlich fanden das viele Leute interessant.
Genau.
Und am Ende umreiß ich in den Post halt die essentiellen Dinge, sag ich mal, um Claude Code, Open Code und die Tools, die sind von den Features ja heutzutage sehr, sehr ähnlich.
Was eigentlich ein Must-Have, ist so, dass man nicht frustriert ist, ja.
Und das ist einfach ein Learning über die letzten sechs bis zwölf Monate, sag ich mal, wo sich wieder mal extrem viel verändert hat.
Da würde ich sagen, da gehen wir doch mal direkt rein, ne?
Vielleicht kannst du uns da mal grob durchführen.
Ja, gerne.
Also eine Neuerung, die so ein bisschen für Überraschung sorgt, Agenten wollen ja häufig so eine Constitution haben, das findet man häufig als CloudMD-File.
Agents MD-File, das ist der, die Open Source-Variante.
Und für eine längere Zeit war das halt einfach der Textschnipse 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üge das mal mit zu diesem CloudMD-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 Test getrieben oder mach bitte dieses und jenes nicht und er wird es halt trotzdem immer wieder machen.
Das hängt häufig daran, je mehr man da reinschreibt, desto weniger hält er sich dran.
Und das heißt, hat einfach zu einer Best Practice geführt, dass man sagt, halte diese Constitution-Files minimal, aber die Folgefrage ist ja dann, naja, aber ich möchte ja trotzdem meine Java-Best Practices irgendwo hinschreiben.
Oder ich möchte so ein bisschen Guidance geben, keine Ahnung, wie das Projekt aussieht und so weiter.
Und da ist einfach de facto Best Practice jetzt ja, die Aufgaben, die man halt in diesem Projekt macht, wo diese CloudMD liegt, sage ich mal, wenn das, was dort drin schützt, 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 ja Bounded Context ein bisschen beschrieben, also es ist die Business-Domäne.
Und ansonsten eher mit Wegweisern arbeite.
Also für Java-Probleme, lade 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, um Kontext so ein bisschen on-demand zu füllen.
Also das Problem war ja wirklich, hey, der Context ist zu groß, die Constitution-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, will ich vielleicht meine Git-Convention, das Wissen dazu reinholen.
Wenn ich im Java arbeite, will ich meine Java-Conventions reinholen.
Wenn ich die Tests schreibe, die Testing-Conventions, wenn ich QR mache, die QA-Conventions, ja.
Und das kann man ja.
Also, ich habe mittlerweile in einem Repo bestimmt über 25, 30 Skills.
Und jedes Mal, wenn irgendwas nicht klappt, überleg man, hey, in welches Skill steckt man das dann rein.
Also ich hatte es, glaube ich, nicht so klar definiert, was ist ein Skill?
Ein Skill für so ein Agent ist wirklich, da gibt man ein Titel rein, eine Beschreibung und dann natürlich ein 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 Constitution-File da noch einen Wegweise reinpackt und sagt, genau, bitte wirklich laden jetzt, ja.
Achso, das warst du also ins die Cloud MD oder Agents MD, dass du da nochmal die Skills auflistest und sagst, wenn das, dann das sozusagen?
Genau, aktuell wird das immer häufiger.
Ich mache es nicht, sie 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 diesem 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 weniger Micromanagement, sag ich mal, machen.
Eine Frage in dem Zusammenhang, vielleicht, also lass uns mal bei den Sachen immer direkt reinfragen.
Schert ihr die Skills?
Also scherst du die Skills im Team oder habt ihr da ein gemeinsames Repo?
Wie organisiert ihr euch da?
Wir sind aktuell dabei tatsächlich für Teams und für mehrere Teams dann großes Repo zu erstellen.
Da gibt es mittlerweile schöne Open Source Tools.
Das heißt, Skillshare ist so ein Tool, 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 Constitution drin ist, sollte in der Regel für jeden gelten.
Das ist einfach einfach Projektinformationen.
Da lässt sich relativ wenig debattieren.
Aber für so eine Skills, zum Beispiel Testing, ja, das sind wir 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, okay, man legt mehrere Skills ab.
Wir haben das tatsächlich in einem zentralen Repo.
Fangt 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 da zu sagen, hey, lasst uns da mal die Skills ablegen und jeder Entwickler kann dann die Skills durchsuchen und kann sich selbst überlegen, welches Skill er denn lädt.
Vielleicht dann nochmal eine Folgefrage.
Also, also wenn wir jetzt mal Testing nehmen.
Wie nutzt du denn den Skill?
Also, der muss ja auch in 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 Jeggi 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 nochmal drauf stupen und sage, hast du wirklich alles gemacht, was drin steht, dann machen sie es auch.
Genau, wie nutzt du, also jetzt mal am Beispiel von den Testing-Skill, wie nutzt du das?
Das ist ein total spannende Beobachtung, ja.
Also, wenn ich irgendwie nah rangehe, ich sage, ich habe gar keine große Planungsphase, gar kein großes Taskmanagement.
Naja, dann kann man, dann hat man das irgendwann drin.
Vielleicht legt man das sogar in ein Command ab, zu sagen, hey, lad wir mal bitte diesen Skill und jenes Skill, so ein kleines Argument, das ist die Aufgabe, ne?
Und dann benutzt man die Commands, um sich nicht immer wieder wiederholen zu müssen.
Und so lädt er dann automatisch die Skills rein.
Da habe ich zum Beispiel auch ein Testing-Skill, wo ich sagt, Behavior driven, ich möchte eher Refactoring enablen, schreib bitte Skills eher auf der Use Case-Ebene.
Hier und da 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 der Skill aus und da hält er sich tatsächlich relativ gut dran.
Und bei den großen Batchaufgaben, wo man sagt, man hat das Kommando vielleicht nicht direkt, ist es indirekt trotzdem im Kommando drin.
Zum Beispiel habe ich jetzt angefangen, bei dem Task-Kommando, also man spezifiziert erstmal, was man machen möchte, man spezifiziert den Text-Sag und dann sagt man, plan mir 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.
Also man kann halt sagen, okay, die erste erste Task schreibt man ein Use Case-Test auf der Ebene, die nachfolgenden, denn sorgen dafür, dass der Test dann irgendwann grün wird.
Und so findet man sein Weg entsprechend, da dem LLM immer wieder den Wegweiser in die Hand zu geben und zu sagen, vergiss bitte das Testing nicht.
Es ist schon aber auch sehr nah am Prozess, ne?
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 wäre für mich, hätte eine gewisse, hätte eine gewisse Distanz für mich.
So in der Bedeutung des Worts.
Okay, aber verstanden.
Ja, ich glaube, das mit der Distanz, ich glaube, man macht nicht weniger.
Man macht mehr.
Man muss immer voll dabei sein.
Ich hatte so eine so ein paar Mal die Erfahrung und die prägt sich ein.
Man steckt es irgendwie sechs Stunden in eine 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, um alles zurecht zu refactorn.
Das macht kein Spaß.
Ja, aber trotzdem gehört es halt 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ß oder ewig umzubauen.
Ja, genau.
Ich 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-Projekt oder so.
Und da ist dann viel mehr Orchestrierung schon der Fall und nicht mehr so eine fein detaillierte Steuerung.
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 darüber geredet haben, dass im Endeffekt so ein bisschen der Cycle ein viel größerer wird.
Ich frage mich, wie das halt irgendwie zusammenpasst.
Wisst ihr, was ich meine?
Bedeutet die Feedback Loop sozusagen, wenn es du.
Genau, also was er gesagt hat, ist, also er hat im Prinzip diese beiden Extremfälle beschrieben, die ich auch versucht habe, gerade aufzumachen.
Also es gibt 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 macht mir dann, baut mir dann schon was Schönes.
Ja, macht total Sinn.
Und tatsächlich, dass 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 ein Einzelpersonendisziplin.
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 sagt, 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.
Alright, dann machen wir mal weiter, ne?
Wir haben ja noch ein paar Punkte vor uns.
Ja, ich lese gerade auch nochmal drüber, ja.
Ich hatte ja schon irgendwie über Skills gesprochen, wir haben über die Constitutional-File gesprochen.
Spannend vielleicht nochmal, Antwort.
Ja, ich fand diesen Punkt.
Also den dritten Punkt, hier, every skill rule needs an automated check, your LLM will while they toolate rules.
Kannst du da noch ein bisschen drauf eingehen?
Das fand ich eigentlich ganz gut.
Genau, das doppelte Klammer.
Genau, das war für mich einfach ein Riesen-Game Changer, ja.
Also häufig hat man immer versucht, ich schreibe das jetzt in die Constitution rein, ich schreibe das in die Skills rein.
Aber das Beste eigentlich, was man machen kann, ist wirklich immer so ein 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 laufe, super.
Wenn sie halt ein bisschen länger benötigen, weil man irgendwie integrationsmäßig X-Stocker-Container starten muss, dann ist das nicht schön, aber häufig auch okay.
Aber Architekturregel, ne?
Arc-Unit im JVM-Bereich, super cool, im TypeScript Dependency Cruiser.
Wenn man sich da eine gute Struktur überlegt, ja, also Bounded Context und irgendwie so ein bisschen hexagonale 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, welcher 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 Constitution, habe ich mittlerweile die, die mir angewöhnt zu sagen, hey, du hattest hier einen Problem, erstell mir doch mal bitte einen programmatischen Check.
Ob das jetzt irgendwie ein Bashscript ist oder eine TypeScript-File oder was auch immer, 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, sehr gut an.
Okay, danke.
Alright.
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.
Und dass man sich so ein bisschen den Workflow überlegt.
Man kann natürlich so einen Workflow auch irgendwie in so eine Constitution 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, Text-Stack, dann Task-Breakdown, dann kommt irgendwann die QR-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.
Ja, das kostet irgendwie 10 Minuten, 15 Minuten vielleicht auch Datenbankzugriff für die lokale Docker-Datenbank, sodass er sagt, alles klar, ich habe irgendwie ein neues Feature gebaut, das spielt halt eine Rolle, falls ein Nutzer in dem und 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.
Genau, Hooks wurden hier noch, habe ich auch nochmal genannt.
Hooks ist auch irgendwie sowas.
Ich habe mich extrem lange gefragt, wozu benötige ich den Hooks.
Tatsächlich habe ich persönlich nicht so viele Use Cases, aber die Use Cases, die ich habe, die sind relativ cool.
Man halt wirklich sagen muss, wenn irgendwas gemacht wird, soll direkt beim Editieren oder direkt bei einer Kommandoausführung soll direkt etwas ausgeführt werden.
Zum Beispiel das Linting, das Formatting.
Einfach schnellere Code-Updates, nicht das nervige, oh, man hat entwickelt, dann läuft der Linter drüber, der kann vielleicht korrigieren oder manchmal auch nicht.
Und dann dreht man da nochmal 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 ablegt.
Das bitte auf gar keinen Fall.
Ja, einfach um Worst Cases zu vermeiden.
Und so kann man halt wirklich diese Hooks, ich glaube, Open Code nennt das eher Plugins, genau, sind einfach trotzdem hilfreich und ist sehr, sehr einfach, die einfach aufzusetzen.
Ansonsten Ding Meta habe ich hier noch hinzugefügt, der neunte Punkt.
Also irgendwie, wir als Menschen, wir sind ja immer so ein bisschen begrenzt im Denken.
Man denkt sich, okay, ich habe jetzt Hooks, ich habe jetzt irgendwie so eine Constitution, jetzt benutze ich halt das.
Okay.
Und dann gibt es halt Skills, okay.
Ah, 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 Skills am besten erstelle.
Ja, und in dem steht drin, so ein paar Best Practices dafür und bitte einen automatischen, also ein ausführbaren Script dafür.
Ja, wenn es irgendeine Regel ist, wofür ich ein Script schreiben kann.
Ja, also man kann da immer irgendwie eine Ebene obendraufsetzen, 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.
Das heißt, du rufst quasi den Skill auf, Skill Creation und dem Agent sozusagen, ich würde gerne den und den Skill kreieren, zack.
Und dann kann ich auch nicht mehr so schön.
Genau.
Oder eigentlich noch besser, ich sage dem Agent, ich möchte jetzt ein Skill kreieren.
Der Agent weiß, dass es den Skill gibt für die Skills erstellen und lädt das automatisch.
Ja, okay, genau, genau, das meine ich.
Das meine ich.
Und dadurch läufst du mit ihm quasi alles, was nötig ist, um 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-Improvement Loops macht, die du auch hier erwähnt hast.
Also sprich, dass man immer, wenn man feststellt, hier klappt irgendwas nicht so richtig, dass man mit dem Agenten selber so eine Retro macht, ne?
Und dann mal fragt, hey, wie ist denn der Task so gelaufen aus deiner Perspektive?
Was können wir tun, um das besser zu machen?
Das ist ja auch nochmal dann die Meta-Ebene.
Habe ich selber ehrlich gesagt noch gar nicht ausprobiert, aber stelle ich mir auch ganz interessant vor.
Irgendwann macht man das automatisch, ja.
Also, das ist keine Ahnung, heute zum Beispiel habe ich bestimmt, weiß ich nicht, vielleicht zehn Commits in das Skill-Repo von mir gemacht, weil ich Skills geupdatet habe.
Ja, das ist irgendwie, sobald was nicht klappt, sollte man immer die 20 Sekunden investieren und sagen, kann ich hier irgendwo mehr Guidance geben?
Ja, und häufig ist es okay, es ist in der Session passiert.
Dann nochmal, hey, hier lief ja was schief, fass mir einfach nochmal die Learnings daraus zusammen und in einem anderen, 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.
Ja, ja.
Und das kann man wahrscheinlich irgendwann nochmal verbinden.
Aktuell ist es 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.
Vielleicht dann nochmal die Frage: Hast du in deinen Projekten, also beruflich, privat, verschiedenen Projekten, auch zumindest so eine Übertragbarkeit, dass du die Skills auch, also diese Skill-Sammlung übertragen kannst?
Oder also du musst die nicht bei jedem Projekt sozusagen wieder von vorne beginnen.
Korrekt.
Die Skills funktionieren bei den Coding Agents so, da kann man sich überlegen, sind das projektspezifische Skills oder sind das globale Skills.
Und das Tooling darum ist auch super gut.
Mittlerweile kann man auch sagen, alles klar, angenommen, ich greife jetzt auf ein Team-Skill-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 ein bisschen abwägen.
Ich selbst habe noch so ein paar Probleme mit projektspezifischen Skills, weil ich immer denke, ja, warum ist es denn projektspezifisch?
Also, 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, sehr ähnlich oder meine Git Conventions.
Aber klar, ein Consultant muss er wahrscheinlich anders arbeiten.
Also Git Conventions, genau, sind ja ein gutes Beispiel, ne?
Aber Java-Conventions, wenn du halt einen TypeScript-Projekt machst, also da wird es dann projektspezifisch, ne?
Oder Testing musst du ja in Projekten auch unterschiedlich angehen, je nachdem, wie das Projekt so aufgebaut ist.
Also deswegen die Frage.
Aber klar, es gibt sicherlich so allgemeinere und genau, dann wahrscheinlich Projektspezifischere.
Oder kannst du, bist du der Meinung, du kannst eigentlich alle relativ gut übertragen, musst du ein bisschen anpassen.
Naja, idealerweise, also ich zum Beispiel habe ein General Software Engineering Skill, dann habe ich ein TypeScript-Skill, ein Java Skill und so weiter.
Und dann wird das so ein Composing so ein bisschen.
Und idealerweise findet er die Skills, die 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.
Ja, dieses Projektspezifische 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, hey, wir haben wirklich ein gutes Repo-Setup, ein Skill-Setup und jeder zieht die sich dann rein, wie er es gern hätte.
Jetzt verstehe ich, genau.
Und dann ist es am Ende auch, du nutzt eh nur die Skills, die du brauchst.
Das heißt, wenn du einfach kein Java-Code hast, dann nutzt du halt den Java-Skill einfach nicht.
Es tut nicht weh, ihn zu haben.
Du hattest vorhin gesagt, was nutzt ihr, um Skills zu teilen.
Also es gibt mehrere Tools, Skill Share ist so ein Tool.
Habe ich ein bisschen mit rumgespielt.
Funktioniert sehr, sehr gut.
Und ermöglicht halt, legt erstmal in seinem Standort ein Skill an und dann sagt man nochmal so ein Sync.
Der Entwickler selbst kann dann definieren, ich benutze Open Code und Cloud Code und Cursor und was nicht.
Und dann mit dem Sync legt er das dann dahin, wo es die Tools gerne haben.
GitHub slash RunKits slash Skillshare.
Okay.
Ich gucke gerade nochmal in die Liste.
Ja, wir hatten das vorher schon mal kurz angerissen.
Es geht in Richtung Frustration.
Ich habe häufig höre ich von Entwicklern und Entwicklerinnen, dass sie irgendwie unzufrieden sind.
Dinge dauern zu lange, die Resultate ist nicht so richtig zufriedenstellend.
Wir haben schon vorher mal besprochen, so ein bisschen, wie nah man rangeht.
Wie baut man die Feedback Loop auf?
Cloud Code, ich hatte wirklich eine sehr, sehr lange Zeit, da habe ich wirklich jeden Change approved und das war wie so ein Pair-Programm, da war ich sehr, sehr nah dran.
Und das macht auch total Sinn am Anfang.
Also nur weil dann irgendwie jemand ander sagt, nee, ihr müsst irgendwie über Nacht das Ding laufen lassen, ja, probiert euch erstmal so mein Wegweiser und hier auch der Hinweis, dass man erstmal nah rangeht, 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, zu 80 Prozent sieht der Code eigentlich so aus, wie 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 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 herum hantieren.
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 Context.
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 es dann auch.
Das heißt, es führt einfach zu einem viel besseren Design.
Es fühlt auch die Entwicklung dann mit den Agenten fühlt sich besser an.
Und ich tendere 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 Agrigoods aggregut 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 Kontext mit reingeht oder in einem Skill ablegt, dann ist das Resultat einfach ein viel besseres.
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, irgendwie die AgentMD oder CloudMD client zu halten, die Skills nur so zu laden, wie man sie braucht, Commands kurz zu halten und Bounded Context, 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-Window sind.
Von daher macht auch insbesondere der letzten Punkt wieder viel Sinn.
Und da sind wir wieder bei, bei, sagen wir mal, was früher Best Practices waren für gute Softwareentwicklung, ist 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 und den müssen wir managen, so wie das bei Entwicklern genauso ist.
Das stimmt.
Ich glaube, selbst bei noch, also mal angenommen, das Thema Kontext-Window 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 musst du dich halt auch um Sample halt irgendwie Gedanken machen.
Wenn du das halt irgendwie, wenn du das, wenn du nur einen Ausschnitt nimmst und es nicht richtig gewichtest, dann kriegst du halt irgendwie auch bloß nur für den Ausschnitt halt irgendwie die richtigen Insights.
Und so ist es halt auch, ne?
Also ich glaube, das alles baut ein bisschen darauf auch auf, also neben dem Kontextmanagement, das ist halt auch, also ein guter Kontext ist.
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 halt eine der Sachen, einer der Hauptthemen für mich, die wir am Anfang sehr hoch gehalten 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, ne, bloß weil ich ein Skill, also nicht jeder Skill ist halt irgendwie toll, ne?
Und ich glaube, alles das, was du jetzt auch hier so, was du auch beschrieben hast, muss halt irgendwie richtig genutzt werden.
Und aber das war einem der Basisssachen ist halt, Kontextmanagement, da bin ich total bei Sebastian und das andere ist halt irgendwie precise sein.
Ja.
Ihr habt noch so ein paar Folgefragen.
Ich bin, ich bin, ich muss das mal ein bisschen für mich noch besser in Kontext packen.
Wie, was hat denn das alles für euch als Auswirkung?
Also alles, was du so ein 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, was so einer Teamkomposition, habt ihr jetzt andere Rollen oder habt ihr gewisse Rollen nicht mehr, habt ihr, werden Teams kleiner, weil halt irgendwie überall Agenten rumrennen.
Was sind denn die Auswirkungen davon?
Spannende Frage.
Also ich kann nur sagen, in dem Bereichen, wo ich unterwegs bin, braucht es einfach noch Zeit.
Es gibt die Pioneers, das sind so 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.
Das 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.
Dann 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 zwei von zehn.
So eine komplette AI-Company, irgendwie 10 10x Engineers, VC fandet, ne, 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.
Von, keine Ahnung, die Kollegin ist vielleicht so ein bisschen genervt, dass sie jetzt irgendwie am Tag 5 PRs review muss.
Das war einfach vorher nicht.
Oder der Kollege.
Oder ja, Productmäßig.
Muss man halt ganz, ganz anders auf einmal, also die Flasche hält, 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ührt 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.
Ja, 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.
Okay.
Okay.
Ja, okay.
Ich finde das, das heißt aber auch im Umkehrschluss, dass wir meine Folgefrage noch gewesen haben, 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 halt in jedem Team so ein quasi so ein Ambassador gibt und also jemand, der da ein paar Pioneer hattest du, glaube ich, gesagt, ne?
Ein Pioneer, der das Thema als sehr weit trägt.
Ich frage mich immer, was die Konsequenz daraus ist.
Quasi, was bedeutet das für eine Organisation, was bedeutet das halt 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?
Also quasi ist das jetzt, ich kann mich entsinnen, da jetzt quasi Sebastian und ich noch Software geschrieben haben.
Dass da gab es ja auch eine gewisse Vorliebe für IDEs.
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 Claude Code und dann, ach nee, eher Codex, oder das eine für das eine und das anderes fürs andere.
Ich glaube, Lennys Podcast war das gerade.
Eine der letzten letzten Episoden.
Das finde ich, da glaube ich steht uns noch echt eine Menge vor.
Punkt.
Jetzt habe ich keine Frage formuliert.
Siehst du das genauso?
Ich glaube auch, es wird sich viel verändern.
Aber es wird auch Zeit.
Es wird eine ganze ganze Weile dauern.
Ja, ich glaube halt, man wird mehr die Arbeit machen, die wirklich wichtig ist.
Ja, jetzt nicht falsch verstehen.
Ich liebe es zu entwickeln.
Ich habe sehr gerne sehr viel entwickelt.
Aber die wirklich kritische Entscheidungen, Customer-Nähe, Marktbewertung, so eine Geschichte.
Es gibt ein paar Bücher und ein 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 ein bisschen mehr Produktverantwortung in Richtung Engineers abgibt.
Und 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, naja, wenn jetzt diese drei, vier Engineers pro Team und dann so in Richtung Two-Pizza-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.
Genau.
Das hört und sieht man immer wieder, sozusagen in Posts und Beiträgen und so.
Und das wird jetzt, glaube ich, in diesem Jahr, werden wir starke Veränderungen in die Richtung sehen.
Es ist ein bisschen ein 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 vs.
Buy kriegt eine völlig andere Dimension, weil Build auf einmal ganz oft eine Option ist, die du früher nicht verfolgt hättest.
Das ist so ein bisschen, andere sagt gerne irgendwie, Your Margin is my weekend project.
Und ich, ich habe gerade mehrere Projekte, an denen ich so wirklich mit Agenten nebenbei arbeite.
Ich muss dann immer sagen, der Teufel liegt im Detail.
Also am Ende dauert es dann doch und man muss dann doch nochmal hinterher und dann hat man bestimmte Dinge doch nicht so gedacht und versteht dann auf einmal, ach, deswegen haben die das so umgesetzt, weil man dachte, man hat eine viel bessere Idee, die dann aber sich als doch nicht so sinnvoll herausstellt.
Aber ich sag mal, so 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, ne?
Kann ich außer Erfahrung heute, heute erlebt, aber beziehungsweise gestern bei LinkedIn gelesen, ich glaube, irgendein Post, so nach dem Motto, WordPress.com hat noch sechs Monate und glaube, eine der ersten Kommentare darunter war, ja, nee, das unterschätzt du, WordPress kann schon sehr, 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, es ist halt Blocks sind sehr, sehr gut beschrieben.
Also was ein Block fachlich ist, quasi, das kann man, kann, 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, was weiß ich, beim Blog 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 einen Blocksystem halt irgendwie gehabt.
Und total, was du sagst, Sebastian, das ist, das ist schon durch das Thema.
Ich glaube halt, was man da auch unterschätzt, ist so ein bisschen das Expertenwissen, wo man vorher sagt, vor allem, glaube ich, für so kleinere, mittlere Companies, so ein Experte, keine Ahnung, in der Bildverarbeitung oder irgendwo.
Die Leute musste man früher finden, die wollten viel Geld haben.
Oder man bezahlt halt einen Tool.
Ich habe, als ihr gesprochen habt, habe ich an einen 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, die hingen da irgendwie an einer proprietären Software, die wurde schlecht gewartet, die hat zu Problemen geführt und er meinte, seit Opus 4.5, war es ein Bront und es hat funktioniert.
Das zeigt es halt dann, ne?
Also die, die A, derjenige hat nicht die Expertise, aber er kann sich das zusammen prompten, es funktioniert vielleicht sogar besser als das, was er da vorher gehabt hat.
Ja, also ich würde jetzt nicht sagen, die Korps fangen sich an, Slack zusammen zu prompten, aber ich glaube, so für so kleinere Tools und so weiter, ja, total valide.
Ja, ja.
Für mich so, vielleicht bevor wir dann auch in den Abschluss gehen, eine Frage, die mich auch zum Nachdenken bringt, seitdem ich 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?
Ich glaube beides, wenn man es richtig verwendet.
Ja.
Weil, das ist halt die Lernkurve.
Das ist, und vor allem die Engineers, sag ich mal, die sich lautstar so ein bisschen beschweren, sind manchmal auch so ein bisschen mehr Opinionated, wo er sagt, hey, die Qualität stimmt nicht.
So, aber spätestens dann, wenn man mal so 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 halt einfach anders aus.
Also ich glaube tatsächlich, die Agents, die AI-Tools ermöglichen uns schnellere Code-Changes.
Das heißt, heißt viel zeitiger kann man günstiger refaktorn.
Es macht Sinn, das Saubere zu bauen, weil dann einfach der Rest einfacher funktioniert.
Und über die Quantität, die Geschwindigkeit, das brauche man, 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.
Am 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, ne?
Du hast eine Amplifier und wenn der Input schlecht ist, dann ist das Ergebnis schlechter sozusagen oder schneller, noch schlechter sozusagen.
Wenn der Input gut ist, dann wird er jetzt noch schneller, noch besser.
Ich glaube, das, also da muss ich gestehen, dass das ist so auch das, was ich erlebe, ich auch, wenn ich ein bisschen sloppy mir denke, oh, ich mach jetzt mal, probier mal schnell was aus, dann ist das Ergebnis deutlich anders, als wenn ich sage, so, nee, ich mach 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.
Haken dran.
Ja.
Genau, ich wollte, ich wollte noch was dazu, eine Thematik, das fand ich damals sehr spannend.
Jeremy Howard, das ist von FastAIDA, ist es derjenige, der eigentlich das Transfer Learning für die Sprachmodelle damals den Meilenstein erreicht hat, wo es darum geht, hey, ich trainiere jetzt erstmal irgendwie ein Modell, ein neuronales Netz auf einem Wikipedia-Korpus und dann setze ich da irgendwie ein anderes Teil obendrauf, 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, dessen Name habe ich gerade vergessen, aber ich schicke gerne später mal den Link rum.
Und die haben das total gut formuliert.
Der 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, was ich glaube, wird ein riesen Unterschied spürbar, wenn wir jetzt anfangen, diese Agenda zu benutzen, Software zu entwickeln, man hat ein total anderes Lernpensum.
Ja, und manche lehnen sich zurück, so ein bisschen das Vibecoding, wie es halt so gerne definiert wird, und dann lassen die mal passieren und dann, ne?
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, ja, in die Breite, in die Tiefe, da wird es ja auch nochmal spannend.
Ich finde, diese Komponente wird häufig unterschätzt.
Wo man sagt, hey, wir haben ein Performance-Problem, ja, wollen wir es vielleicht einfach mal in Rust schreiben.
Ja, wir können ja kein Rust.
Naja, vielleicht doch.
Genau, und dann lernt man auf einmal.
Also ich glaube, dass das wird unterschätzt und das wird auch nochmal guten Teams, gute Teams von, sag ich mal, durchschnittlichen Teams unterscheiden.
Definitiv.
Ja.
Ja, super spannend.
Also auch so 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 ich mal gespannt, wie viel sich da dann schon wieder verändert hat und auch wo deine Skala ist sozusagen, die du wahrnimmst.
Genau den gleichen Punkt hatte ich auch gerade im Kopf.
Wir sagen mittlerweile, wir müssen uns immer mal in sechs Monaten treffen.
Vielleicht ist auch genau das, was dem Podcast ausmacht, alle sechs Monate gleichen Gäste und gucken, wie sich es weiterentwickelt.
Gerne.
Mal schauen, genau.
Meine Stimme habt ihr.
Cool.
Ja, vielen Dank.
Genau, dann haben wir zum Abschluss noch so zwei Segmente.
Das eine ist so der Reality-Check.
So, welches Tool hat dich zuletzt enttäuscht?
Wo hattest du so What the fuck-Momente und wo warst du total positiv überrascht oder geflasht?
O was glaubst du, ist der heißeste Scheiß?
Ja, ich fange jetzt mal mit dem an, was mich enttäuscht.
Ich benutze schon eine ganze Weile Gemini und Chat-GBT.
Ich weiß auch, dass in der Open Source Welt, wenn man jetzt irgendwie nicht im Enterprise unterwegs ist, wo es sehr aus guten Gründen sehr restriktiv ist, in sich in Richtung Tool-Anbindung.
Aber gefühlt, was sich da in den letzten Monaten bewegt hat, ist für mich so ein bisschen frustrierend.
Also man sagt, hey, keine Ahnung, der Zugriff auf einen GitHub Enterprise.
So eine Thematik.
Genau.
Nicht so einfach, so wie kann ich sagen.
Genau, zu Gyra und den ganzen Tools.
Weil diese Modelle, diese Agenten auch in Chat-GBT, profitiert natürlich unglaublich davon.
Und auch so ein bisschen dieser Trend, und ich, ich verstehe die Publisher, ja.
Ich verstehe alle, die sagen, hey, ihr Cloud jetzt nicht unseren Content.
Aber wenn man so ein Tool benutzt und man sieht so ein bisschen Webfetch, das ist wahrscheinlich dann schon der Moment, wo ich sage, ich suche lieber selber oder frage meinen Cloud-Code in mein Browser aufzumachen.
Also 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 hat 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.
Genau.
Ansonsten, was ich super spannend finde, ich habe mir in der letzten Woche und diese Woche noch ein bisschen weiter, Open Clause ein bisschen weiter angeschaut.
Ja, ich weiß nicht, ob ich schon den Podcast von dem Macher sozusagen angeschaut habe, geht drei Stunden, drei Stunden ein paar zerquetschte.
Kann ich empfehlen, kann man immer mal so ein bisschen weiterhören.
Ja, also für Leute, die sich wissen, OpenClaw am Ende eine sehr einfache Möglichkeit.
Ihr nehmt euch irgendeine virtuelle Maschine oder ein altes MacBook, installiert das da drauf, gibt einen Chat-GBT-API-Key rein und dann darf ihr halt alles machen.
Und ihr könnt dann zu dieser Maschine mit WhatsApp oder was auch immer kommunizieren und sowas wie, hey, welche Termine habe ich?
Oder hier ist ein Foto von einem Restaurant.
Guckt doch mal, ob ich morgen Abend auf weiter irgendwie hingehen kann.
Und der Agent macht dann los.
Und was mich da so ein bisschen, was ich faszinierend fand, der Entwickler selbst, als er den Prototyp gebaut hat, hat Open Claw, so ein 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 ein 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, das ist und das ist der Hatter.
Ja, jetzt irgendwie das mit dem lokalen Modell hat nicht so richtig funktioniert.
Dann habe ich aber ein OpenAPI-Key gefunden und den habe ich benutzt, habe die API bedient und dann konnte ich lesen, was du mir gesagt hast, ja.
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 Assistance, diese Schnittstelle zwischen Mensch, Maschine und dann unseren Aufgaben und Wünschen, ja, 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 ein Stress hatte und wie er bombardiert wurde von irgendwelchen Attacken und Messages und so weiter.
Also sehr, sehr spannend.
Crypto-Dudes.
Genau.
Ja, genau, ich habe den Podcast auch gehört.
Ist auch super spannend.
Und genau, mein Open Claw, den muss ich noch ein bisschen füttern.
Aber auch da, ne, ja, eigentlich das gleiche Thema, was mit den großen Tools nicht funktioniert, ist genau der Hemschuh, wenn du halt einfach nur immer wieder eine ChatGPT-Sitzung oder eine Gemini-Sitzung aufmachst, da fehlt der komplette Kontext, ne?
Wenn du aber deinem Open Claw einfach alles, was du irgendwie in deiner Notizen erpasst als MD-Files mitgibst, dann hat er den kompletten Kontext, ne?
Und wenn du dann irgendwie noch ein Knowledge Graph drauf aufbaust, dann hast du deinen Second Brain irgendwie ausgespeichert und dann kann der so Sachen machen wie, Moment mal, hier, ich habe doch da 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 FFM-Pack wahrscheinlich in Wave umwandelt.
Ja, ja, genau.
Wir müssen eine Eigenwerbung machen, Sebastian.
Wer das nochmal in Tiefe hören will, letzte Folge mit Robert, da ist da 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.
Es gibt, glaube ich, relativ viele Leute, die da gerade ins Rabbit-Hole verschwunden sind.
Schaue ich mir an.
Gut, dann sind wir auch schon fast am Ende.
Wir haben immer am Schluss nochmal, du hast ja schon auch ein paar Predictions geteilt.
Das kommt interessanterweise bei uns im Gespräch eh immer, weil logischerweise wir eine 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.
Ich glaube, die nächsten zwölf Monate vorherzusagen ist sehr, 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, ja.
Also 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 nett 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 eine ganze Menge mehr passieren.
Also konkrete Predictions habe ich nicht.
Ich glaube, wir werden immer mehr mit AI arbeiten.
Ich glaube, die Entwickler und Entwicklerinnen werden alle nachziehen.
Und es wird auch mehr Spaß machen.
Oder anders Spaß machen, genau, einfach schneller Software zu probieren, zu schreiben, mit einer besseren Qualität.
Vielen Dank.
Danke.
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.