Willkommen Daniel zu unserer dritten Folge Secrets Not Included. Wir möchten heute über AI-Agentic Coding sprechen. Ich finde eigentlich ein spannendes Thema, weil es sich ja in den letzten Jahren so ein bisschen entwickelt hat vom KI-Agenten, äh Assistenten, nicht Agenten, der mehr oder weniger sinnvolle Ergänzungen gebracht hat.

Genau.

über Vibe Coding hin zu Agentic Coding. Ich finde, das ist so ein bisschen die Evolution. Wie siehst du das denn?

Ja, also ich habe immer ein lachendes und ein weinendes Auge bei dem Thema, weil das Thema hatten wir, glaube ich auf LinkedIn hatte ich das schon ein paar Mal, was genau Programmieren betrifft, was Softwareentwicklung betrifft und da fällt es schon schwer, Sachen zu unterscheiden. Und wenn man jetzt noch guckt, wo ist das Ganze hergekommen, also mich triggert das Thema Vibecoding dabei, deswegen habe ich ja gerade angefangen, KI unterstützt dich definitiv und da sind wir auch hergekommen und ich habe es noch nicht oft genug genutzt, beziehungsweise bei mir kommt das jetzt auch immer mehr auf und ich fange gerade an, damit rumzuspielen mit Agentic Coding. Ich habe aber definitiv einiges an Wissenslücken oder irgendwie brodelt, macht auch jeder gerade so sein eigenes Süppchen. Es wird irgendwie, ich habe nirgendwo groß was gelesen, dass Leute teilen, wie sie ihr Setup haben oder wie sie das nutzen. Jeder versucht da so sein eigenes Süppchen zu kochen ein bisschen. Das finde ich schade. Und vielleicht hast du noch ein paar Ideen.

Es ist sehr wenig im Moment, was direkt geteilt wird, was gut funktioniert, was Best Practices sind und so.

Ja.

Das stimmt schon. Ich finde aber, es ist erstmal wichtig zu verstehen, wo der Unterschied, also für mich zumindest persönlich, zwischen Vibe Coding und Agentic Coding ist.

Mhm.

Weil in meiner Gedankenwelt ist Vibe Coding etwas, ich sage sehr unspezifisch eigentlich, was ich haben möchte und Die Agenten laufen los und erstellen etwas. Relativ ungesteuert, sehr MVP-mäßig und gar nicht so hart auf... Qualität, Sicherheit gepolt, sondern es läuft erst mal irgendetwas. Also das ist für mich Vibe-Coding-mäßig, also quasi erstell mir eine performante Website, die verkaufen soll und das ist noch das Thema so ungefähr. Und ich finde, Agentic Coding ist sehr viel spezifischer, sehr viel runtergebrochener. Ich habe mein System, meine Frameworks dort stehen und dann gebe ich quasi die Aufgabe, die ich sonst selber bearbeiten würde, diesem Agent oder dem System, das sich dann den Agents bedient und die arbeiten dann diese Lösung aus. Also so ein bisschen, ich gebe den Auftrag weiter, so als würde ich ein Junior-Dev oder irgendjemand aus dem Team, wir haben über die Aufgabe gesprochen und dann geht es jetzt quasi an den Agenten und der bearbeitet sie dann. Meine Erfahrung ist auch auf jeden Fall, Man sollte immer erst diesen Planungsmodus benutzen. Also nie direkt eingehen und sagen, okay, jetzt bau das.

Ja. Jetzt nochmal zu deinem Beispiel.

Vielleicht, ja.

Was du beschreibst, sind eigentlich unterschiedliche Projektrollen. Also bevor es das Thema KI gab, gab es den Product Owner, sagen wir mal. Und das ist das, was auch Vibe Coding das beschreibt. Es wurden unspezifische Anforderungen ins Team weitergegeben und gesagt, wir brauchen Feature XY oder ich möchte gerne eine Internetseite haben mit dies, das und jenem. Und mit Agentic Coding habe ich vielmehr den Eindruck, dass das in Richtung Lead Development geht. Der eine sagt gerne, was er hätte und auf dem anderen oder in dem anderen Bereich, gerade bei Agentic Coding, ist das eher schon, dass ich ganz klar sage, wie möchte ich was haben. Da geht es nicht darum, ich möchte eine Internetseite haben, sondern ich möchte mit dieser Technologie in diesem Design Pattern zum Beispiel, also dass ich anfange, Regeln vorzugeben und das unterscheidet sich halt wie damals oder früher klassisch auch, Product Owner und halt Lead Developer. Also ich glaube, das sind so die zwei großen Unterschiede.

Ich weiß nicht, für mich ist Vibe Coding irgendwo eigentlich zwischen Product Owner und Stakeholder. Also von der Genauigkeit.

Mhm.

Ich finde ein Product Owner oder in der Projektrolle hatte man eigentlich eine sehr genaue Vorstellung schon, in welche Richtung soll das gehen. Nicht technisch, aber von der Produktidee. Und von dem Weg auch, auf den man sich machen möchte oder auf den man sich schon gemacht hat. Und ich weiß nicht, also so ein bisschen dazwischen ist mein Gefühl, hängt aber sicherlich auch einfach von der Charakteristik des Product Owners, den man da hat. stark ab. Und was jetzt natürlich bedeutet, wenn wir mit diesem Agentic Coding arbeiten oder allgemein mit KI Support, wie auch immer geartet und in welchem Umfang, dass man viel, viel mehr Dinge aufschreibt, fällt mir ganz stark auf. Wir definieren auf einmal in Markdown-Dateien was heißt auf einmal, aber wir definieren in Markdown-Dateien sehr spezifisch auf einmal den Projektaufbau.

Das, wo man

und sehr spezifisch, welchen Code-Style wir wo verwenden, was man früher sehr implizit irgendwie im Team hatte. Ja, so diese stillen Konventionen irgendwie, das Wissen, okay, wir besetzen zum Beispiel auf PSR 12 oder, oder, oder. Und wir bevorzugen bestimmte Patterns eigentlich im Team, um Probleme zu lösen. Und das schreibt man auf einmal auf, weil der Agent das sonst gar nicht weiß oder gar nicht so erfasst, weil der natürlich nicht vor dem Programmieren überall immer wieder durchschaut und sagt, ah ja, das hier ist ein Symfony-Projekt und hey, hier in diesem Team wird dieses Pattern häufig benutzt. Also das ist alles sehr viel spezifischer, sehr viel textlastiger geworden. Sehr viel mehr natürliche Sprache.

Ja, früher haben wir das mehr in Tickets gemacht, glaube ich. Also wir hätten es viel mehr machen müssen, wenn man das vergleicht. Also die Definition of Ready bei vielen Tickets war nicht erreicht, weil genau solche Infos fehlten, weil die im Team irgendwo existierten. Jeder wusste das oder es gab Absprachen. wenn man ehrlich gewesen wäre, hätte solche Sachen dann ins Ticket gemusst. Also es tut man allen Projektbeteiligenden leid, wo ich das nicht gemacht habe früher. Es hätte ins Ticket gemusst, um das vergleichen zu können. Dann wäre das, oder ist jetzt genauso der Stand, Wenn du ein Ticket vernünftig ausgearbeitet hast, hast du eigentlich schon sehr gute Vorlage, um das der KI zu geben. Also als Entwickler natürlich werde ich dann hingehen und das noch anreichern mit Testfällen, sagen, welche Testfälle sollen wie funktionieren, sollen nicht funktionieren. Vielleicht schreibe ich die Testfälle auch selber, um das zu definieren, um sicherzustellen, dass Edge-Cases abgearbeitet werden.

Mhm.

Aber grundlegend ist da schon sehr viel Ähnlichkeit zwischen einem vernünftigen Ticket und der Spec oder der Anforderung, die ich jetzt in Markdown mittlerweile schreibe.

Ja, aber in dem Ticket, also das Ticket kannst du ja weiter benutzen, also wenn ich mir zum Beispiel OpenCode AI anschaue, das kann ich auch mit GitLab benutzen auf unterschiedliche Art und Weise, aber da kann ich ja meine Tickets benutzen, also das muss ich ja gar nicht in Markdown-Fall schreiben, aber was ich ins Markdown-Fall ja schreiben muss, sind diese Rahmenbedingungen. die Framework-Bedingungen und alles, was sich da abspielt, damit das Wissen immer präsent ist, immer wieder im Kontext ist, den man ja auch erstaunlicherweise sehr, sehr häufig lehren muss. Das ist ja irgendwie schon ein bisschen komisch. Also ein Junior-Dev habe ich beigebracht, hey, das Wissen, Das sind hier so diese Rahmenbedingungen, das ist quasi der Kontext, den habe ich ja nicht jeden Morgen resettet und das neu reingekippt.

Also mir hat man sowas gesagt in der Ausbildung, dass ich mich übers Wochenende resettet habe.

Ja, vielleicht nach dem Wochenende oder so, oder nach Phasen in der Berufsschule oder whatever, aber das eigentlich... sollte es so gewesen sein, dass dieses Wissen, was einmal vorhanden war, im Projekt- oder im Produkt-Kontext, ja nicht direkt am nächsten Tag wieder weg war. Und was ich halt beobachte, ist, man muss diesen Kontext in der Zusammenarbeit mit der KI sehr viel häufiger quasi nach jeder Aufgabe lehren. Das finde ich eigentlich auch ganz interessant. Ganz interessant, dass sich sonst halt auch die Ergebnisse verschlechtern. Das ist etwas, was ich sehr spannend finde, weil wir ja als Menschen irgendwie anders funktionieren.

Ja.

Wenn wir mehr Wissen und mehr Erfahrung ansammeln, werden ja nicht automatisch unsere Ergebnisse schlechter, die wir liefern.

Ja, aber wir haben auch, sagen wir mal, ein beschränktes Fenster an Kontext, würde ich jetzt mal ganz simpel sagen. Also es gibt Metriken, oder habe ich zumindest auch gelesen, dass auch Entwickler nicht alles überblicken.

Natürlich nicht.

Also Lines of Codes gibt es einfach ein gewisses Limit, was man erreichen kann, wo du dann auch Sachen nicht mehr im Kopf hast. Also das ist das eine. Da hast du auch schnell den Kontext oder dein Kontext Limit erreicht. Und also das ist das eine. Da will ich jetzt nicht sagen, dass der eine mehr oder andere weniger hat, aber bei KI habe ich jetzt auch einen Artikel gelesen, dass es sinnvoll ist, also je nach Model, so um die 50 Prozent meine ich waren das. Wenn du 50 Prozent erreichst vom Kontext oder genutzten Kontext, geht die Qualität wohl massiv nach unten. Also damit passiert genau das, was du gerade beschrieben hast, dass man dann Kontext immer resetten sollte. meine, du willst gerade auch auf die Agents MD so ein bisschen hinaus. Eine Möglichkeit ist ja so, oder der erste Berührungspunkt für mich war es zum Beispiel mit KI, genau dieses, ich möchte nicht immer wieder erwähnen, mit nutze diesen PSR, in diesem Ordner sollen die Dokumente, also die die Dokumentationen liegen, in diesem Ordner liegen die Source-Dateien. Solche Sachen möchte man nicht immer wieder schreiben. Und dann war es so der erste Moment, ne, und egal welche KI man nutzt. Also es gibt die AgentsMD, die kristallisiert sich, glaube ich, gerade so ein bisschen als Standard raus, dass man da vieles unterbringt. Oder zum Beispiel OpenAI sagt, dass er vernünftige Umlaute benutzen soll und den Schreibstil per Ich oder per Du. Also da kann man ganz viel unterbringen, was man im Projekt braucht.

Ja, genau. Also die Agents-MD ist ja eins der Dinge. Also ich glaube, das ist eigentlich der allgemeine Name, der sich so rauskristallisiert. Cloud-MD gibt es auch noch, das ist dann wieder spezifischer. Das ist so ein bisschen wie die Evolution bei Docker Compose. Wir haben früher überall immer Docker Compose-YAML geschrieben.

Vielen Dank.

Und jetzt haben wir zum Beispiel einfach gesagt, ah, wir wollen gar nicht Docker mehr so da drin haben, sondern es ist ja eigentlich ein Container und da gibt es halt die Compose-JAML. Genauso, dass Docker-File jetzt Container-File heißt. Und Dann gibt es, glaube ich, auch noch Context-MD, was wieder das Gleiche ist wie Agent-MD und Cloud-MD, wobei da bin ich mir gar nicht so sicher mit der Context-MD. Also ich finde, da ist noch sehr viel Bewegung und Ungenauigkeit und Veränderung drin. Also man merkt, das entwickelt sich und... es gibt noch keinen allgemeinen Standard. Man hat sich irgendwie geeinigt darauf, es gibt eine Markdown-Datei und die wird halt gelesen und hoffentlich beachtet.

Aber die meisten Agenten, also bei allem, was auf der Konsole läuft, habe ich jetzt den Init-Befehl gesehen und die erstellen so eine Datei.

Ja.

Also CloudCode macht dann, glaube ich, seine CloudMD. Codex hat AgentsMD erstellt. Also die wissen da schon, was die nutzen. Mhm.

Ja, du kannst aber ja auch bestehende Dateien noch reinholen, sowas wie eine Contribution MD oder Index MD, wenn du da die Informationen drin hast, dann kannst du die auch mitgeben, zumindest bei den meisten, glaube ich, also mit denen ich gearbeitet habe.

Genau.

Keine Hand ins Feuer legen und jetzt behaupten, no, das geht überall. Aber von dem, was ich mir angeschaut habe oder anschaue an Systemen, das sind ja vorwiegende Systeme, wo ich meine Modelle irgendwo selber hinlegen kann, entweder lokal oder auf dem Server und dann nutzen kann. Ich bin ja nicht so der Freund davon, meine Daten durch die Weltgeschichte zu schicken. Oder vielmehr die Projekt- und Kundendaten da irgendwo durch die Weltgeschichte schicken, immer so mit der mit dem Gedanken dahinter, okay, wir filtern zwar eigentlich alles raus, es sollten keine persönlichen Daten da drin liegen und keine zu spezifischen Sachen. Ach ja, und dann erstellt ihr halt trotzdem mal jemand ein Ticket, wo auf einmal Namen, E-Mail-Adressen, keine Ahnung was genannt sind. Und wenn wir jetzt darüber nachdenken zu sagen, ah ja, wir machen mal so eine Pipeline und dann probiert,

Mhm.

oder wir testen mal, ob dann so ein Agent nicht einfach die Tickets selbstständig triagiert und abarbeitet. Dann kommen wir natürlich ganz schnell in die Bredouille, dass wir schützenswerte Daten durch die Weltgeschichte durchführen. an Anbieter übermitteln und ja, ich, better safe than sorry, ne, an der Stelle so ein bisschen, lieber selber hosten und sagen, okay, dann haben wir vielleicht jetzt einfach ein anderes Modell, als da laufen würde, aber das macht auch die Aufgabe, es gibt ja gute Modelle, die man nutzen kann an der Stelle und ähm, man ist ja gar nicht darauf angewiesen, die Daten Richtung Google oder OpenAI oder Ähnliches zu schicken. Man kann ohne Probleme ja hingehen und sagen, okay, wir laden uns Modelle runter und wir betreiben die selber mit Olama und Ähnlichem und dann ist die Performance halt im Zweifelsfall einen Tacken schlechter, was für das Ausprobieren erst mal aus meiner Sicht völlig okay ist.

Mhm.

Ich finde, das ist jetzt nicht unbedingt etwas, was wir so richtig aktiv einsetzen. Also da bin ich eher beim assistierten Programmieren. weil ich auch immer noch, also ich finde, das ist sehr aufwendig, ja, erst diesen Planungsmodus durchlaufen zu lassen, dann schaue ich die Ergebnisse an und review, die, dann lasse ich das Ganze nochmal durchlaufen und, ähm, schaue mir dann auch wieder die Ergebnisse an, mache dann irgendwie die Code Review tatsächlich und, ähm, Also der Workflow fühlt sich einfach noch nicht so richtig gut an, was man jetzt irgendwie zweimal reviewer und dann wahrscheinlich noch eine Schleife nochmal dran hänge. Ich hatte nämlich jetzt auch den Fall, da hat der Agent eigentlich eine total, also eine Straightforward-Aufgabe aus meiner Sicht bekommen. Da sollte einfach im Secret-Management was umgeschrieben werden, Dateinamen vereinheitlicht werden. Wir hatten irgendwie historisch gewachsen, wie das manchmal so ist, einige mit Bindestrich-Dateinamen und einige mit Underscore. So, das Klassische.

Ja, easy. Ja.

Und dann war halt die Aufgabe, hey, okay, vereinheitliche das bitte, es soll jetzt immer mit Underscore sein. Ja, easy going, search and replace, würde man denken. Naja, das End vom Lead ist, in der einen Datei haben wir jetzt alles mit Underscore. Im Make-File steht jetzt alles mit Bindestrich. Ja, da ist irgendwo was in der Kommunikation, glaube ich, schief gelaufen. Ja.

Aber das ist genau der Punkt, an dem ich auch immer wieder hänge. Also wo man sagt, das sind einfache Aufgaben, also bisschen weitere Aufgaben als so ein Refactoring mit der IDE, wo man drauf drückt und Methoden Namen ändert und dann läuft das Ding los und macht Sachen, wo du sagst, Alter, das verstehe ich nicht. Wie kommst du da drauf? Und das ist finde ich noch immer wieder schwer, also das einzufangen. Ich habe letztens noch den Tipp bekommen, also ich habe es noch nicht exzessiv benutzt, aber Specs-Driven Development, wo du wirklich noch genauer hingehst und wirklich Specs definierst und sagst, das sind die Sachen, da ist Logik.

Mhm.

Das hat sich sehr interessant angehört und Ich wollte es auch ausprobieren, bin bis jetzt noch nicht ausgiebig dazu gekommen. Also ich denke mal, das werden wir bestimmt in der nächsten Folge irgendwann mal angehen. Das war nämlich sehr interessant. Aber für mich war es, also zumindest bis jetzt, ist mein Arbeitsstil so gewesen, dass ich zum Beispiel... gefühlte Code-Reviews wie früher auch mache.

Hm. Hm.

Also, dass ich zum Beispiel sage, ich habe einen Quelltext vor mir und sehe, oh mein Gott, eine Eindrückung ist, also, ach, was habe ich, Eindrückung, keine Ahnung, da wird irgendwie ein String exploded, weil wir brauchen die ersten zwei Zeichen, aber du brauchst keinen Explode, sondern lies einfach die ersten zwei Zeichen. Solche Sachen. Dann ist das jetzt so, dass ich hingehe und einfach mal einen schnellen Kommentar dran schmeiße, so ein To-Do. früher eigentlich für mich, mittlerweile mache ich das nur noch für die KI, weil ich dann durchgucke und sage, guck mal, da ist was, da ist was, da ist was, weil ansonsten prompte ich mich ja tot, wenn ich sage, in Datei XY aufzeile, so und so, hast du das, das habe ich schneller selbst geschrieben, den Code als den Prompt geschrieben und bis jetzt bin ich, also das ist so der Modus, in dem ich gerade bin, wo ich viele Kommentare reinschreibe und dann sage ich, guck mal, in der Datei habe ich Kommentare geschrieben,

Ja.

Oder was schlägst du vor, wie würdest du das ändern? Dann sind wir in diesem Planungsmodus, von dem du gesprochen hast. Dann sagt er einmal, okay, dann mache ich das so und so. Dann sagt er einmal Daumen hoch. Er produziert das. Ich gucke einmal kurz drauf. Sage ja, passt oder passt nicht. Und dann kommt das ins Projekt. Mhm.

Spannender Ansatz. Ich mache das tatsächlich anders. Also ich schreibe mehr in Tickets. Und meine Feststellung ist tatsächlich bei so Standardaufgaben, die es eigentlich wie Sand am Meer gibt, ja, keine Ahnung, wir brauchen ein neues Inhaltselement und das soll dann wie eine Lightbox funktionieren oder irgendwie so ein Mist. Gibt es eine Million Mal als fertige Lösung nichts Besonderes. Und das funktioniert über die Tickets erstaunlich gut. Die Ergebnisse sind auch auch sehr passend. Also da sind dann wirklich nur so Kleinigkeiten und ich stelle aber fest, bei sehr spezifischen Dingen ist er manchmal einfach verwirrt. Also irgendwie so, wie wenn man morgens um vier auf einmal anfängt, irgendwas zu programmieren, ohne Kaffee, noch halb schlafend und denkt, jetzt produziere ich den geilsten Code der Welt. So kommt mir das manchmal auch so vor. Also ich weiß nicht so genau. Vielleicht liegt das auch an meinem Schreibstil bei so Aufgaben, dass der einfach nicht verständlich ist.

Also ich habe auch mit dem geredet, aber nicht nett.

Ich habe auch bei einigen gelesen, dass sie jetzt mehr mit ihrem Computer reden. und darüber tatsächlich quasi die Aufgaben definieren, was ich auch sehr spannend finde. Eigentlich finde ich das sympathischer, aber ich meine jetzt wirklich mit dem Agent quasi die Aufgaben sprechend zu definieren, das finde ich eigentlich fast sympathischer, als die Sachen runterzuschreiben. Ja, ich sage jetzt mal, labern kann ich ganz gut, manchmal. Da finde ich Schreiben und gleichzeitig Denken und Definieren fast schwieriger. als wenn ich dem System erzähle, was ich möchte. Ich glaube, das muss ich vielleicht auch noch mal intensiver ausprobieren und sagen, okay, ich schreibe quasi die Spezifikationen meiner Tickets oder meiner Aufgaben, indem ich dem Computer oder der KI das erzähle, die transkriptet das dann in das Ticket vielleicht rein und dann wird das Ticket abgearbeitet. Vielleicht ist das ein Workflow, den ich mal ausprobieren sollte. Wenn ich so jetzt darüber nachdenke, während ich darüber erzähle.

Oh mein Gott, wie viele Metaebenen haben wir gleich?

Weiß ich nicht, aber ich habe jetzt auch festgestellt, in einem Projekt, in einem Produkt, das ich baue, bin ich jetzt tatsächlich hingegangen und habe mittlerweile das dritte Modell eingeführt, weil ich festgestellt habe, dass sehr spezifische Modelle viel, viel geiler funktionieren als unspezifisch. Ich habe ja zum Beispiel ein kleines visuelles Modell, das die Texterkennung macht bei Dateien und diesen Text dann halt rausschreibt, dass ein anderes Modell klassifiziert dann den Text und welche Inhalte da drin sind.

Mhm.

Und ein drittes Modell verwende ich dann, um bestimmte Texte zu generieren, weil die einen bestimmten Sprachstil und eine gewisse Genauigkeit haben und deswegen einfach nochmal extra feingetunt sind. Ähm, Und die Gesamtzeit, das ist das eigentlich Witzigste daran, die Gesamtzeit, die ich jetzt an KI-Minuten irgendwie verbrauche für diese Aufgabe, also abarbeiten über drei Schritte mit nochmal Q und so weiter und so fort, ist geringer, als wenn ich das in ein großes Modell, das alle Fähigkeiten hat, schmeiße. Also das ist sehr, sehr spannend. Ich finde auch Modelle, die speziell auf PHP-Programmierung abgestimmt sind, funktionieren meistens noch besser als Modelle, die nur auf Programmierung abgestimmt sind.

Welche meinst du genau? Also mir fallen da gar keine Namen ein.

Wow, muss ich jetzt nachschauen.

Okay, also ich habe zum Beispiel...

Ich bin da total schlecht im Namen. Also ich liefere dir das gerne nochmal nach. Ich muss zugeben, ich habe jetzt den Modellnamen einfach leider nicht vorher rausgeschrieben.

Aber wir sind Experten auf dem Gebiet. Mhm.

Aber zum Beispiel halt DevStrawl ist etwas, was ich gerne zum Testen nutze in Projekten, wo Verschiedenes vorkommt. JavaScript und PHP in einem Projekt, dann bin ich immer ein bisschen faul und sage, ja, jetzt benutze das einfach mal, was ich hier habe. Nimm ein Ding, liefere mir das Ergebnis,

Mhm.

Ähm, gerade wenn ich auch so ein bisschen zwischen den Aufgaben hin und her wechsle, was ja irgendwie vorkommt, dann habe ich hier HTML-Dateien, da JavaScript, hier PHP und dann doch wieder irgendwie so ein Container und Markdown und hast du nicht gesehen? Ähm, und Dann aber, wenn ich halt sage, ah ja, ich mache jetzt halt nur spezifische PHP-Sachen, zum Beispiel, ich weiß, GitLab liefert da auch in deren KI-Produkten extra Modelle und ich glaube, meine Lieblings-IDE hier, das gute alte PHP-Store macht das auch sehr spezifisch. Ich setze das halt nur nicht mit Agents gerade an, weil da fehlt mir einfach so dieser Ansatz, wie wie gehe ich hin und mache das so spezifisch, dass das sagt jetzt, ah, ich habe hier PHP-Dateien und jetzt nehme ich ein anderes Modell dafür. Ich bin jetzt aber auch ehrlich gesagt noch nicht so durchgestiegen, wie zum Beispiel diese Language-Server-Protokoll-Integration bei OpenCode funktioniert. Also wie viel Einfluss das zum Beispiel hat, da bin ich einfach noch dran, das rauszufinden.

Was meinst du damit genau? Weil ich habe OpenCode jetzt auch diese Woche angefangen zu nutzen, außer dass ich sehr begeistert bin davon, bin ich glaube ich noch gar nicht so tief drin wie du.

Ich weiß gar nicht, ob ich tief drin bin, ja. Ich probiere halt rum und und gehe halt auch begeistert durch die Dokumentation durch, ja, so ganz altmodisch und sage, oh, ich habe eine Dokumentation und da steht ein Feature drin und jetzt, wie probiere ich das denn jetzt aus, ja, also OpenCode kommt ja irgendwie mit dieser Language-Server-Protokoll-Integration und kommt mit, also hat halt zum Beispiel auch für PHP oder für TypeScript mit eslint und so Sachen, Integration, um das halt zu nutzen. Aber welche Auswirkung das so hat, wenn ich die zum Beispiel ausschalte, ob das das jetzt schlechter macht, besser macht, da bin ich noch nicht hinter. Also das ist etwas, wo ich sage, Da muss ich nochmal mehr rein. Was macht dieser Language Server Protokoll?

Und ist das nur gefühlte Verbesserung? Weil bei mir war das so, ich habe vorher Codex genutzt und dann Open den neuen benutzt. Und das ist natürlich so, es fühlt sich alles neu an, alles toll, aber eigentlich das gleiche Modell dahinter. Also ich habe OpenAI weiter genutzt, weil ich genau diesen Effekt nicht haben wollte. Trotzdem habe ich das Gefühl gehabt, das Model macht viel bessere Sachen. Also das ist so diese gefühlte Wahrheit erstmal. Das ist...

Ja, ich möchte eigentlich halt auch noch den mal unser GitLab via MCP anbinden, dass ich nicht unbedingt sagen muss, ich habe jetzt eine Pipeline, wo Open Code drin läuft und selbstständig da zyklusmäßig arbeitet.

Sachen besser werden. Aber jetzt, wenn du sagst, muss ich mal ausprobieren, diese ganzen Plugins. Vielleicht hilft das ja.

Oder vielleicht wäre es auch noch eine Idee, das über andere Systeme zu automatisieren. Egal, zu viele Ideen. Aber eigentlich möchte ich halt auch, dass das GitLab per MCP angebunden ist, damit ich da lokal besser mit interagieren kann. Dass ich meinen Open Code in dem Fall ja lokal laufen lassen kann und irgendwie noch mit dem GitLab mehr interagiere.

Mhm.

automatisiert. Aber das sind halt alles noch so Sachen, wo ich sage, das probiere ich gerade aus, das ruckelt noch so vor sich hin, also es ist noch nicht so, dass ich sage, ich habe jetzt den Workflow, wo ich sage, ah, perfekt, wir haben damit gehe ich jetzt hin, ich arbeite nur noch in meiner CLI, ich mache gar nichts mehr anderes auf. Und die KI, wenn ich da eine Aufgabe gebe, dann programmiert die das, ich review nur noch und eigentlich bin ich der glücklichste Mensch auf der Erde, weil ich nie wieder wirklich arbeite oder so. Weil ich auch sagen muss, ich mag einfach programmieren selber zu sehr.

Ja.

Das ist vielleicht auch ein Problem, dass ich mich sehr wohl fühle in diesem ganzen, ach, ich schreibe, ich programmiere das mal eben. Das ist ja so ein Prozess. Ich fühle mich da furchtbar wohl drin. Aber ich finde es spannend, was heute möglich ist. Und es gibt ja noch tausend Konfigurationen irgendwie, wo ich mit Regeln arbeiten kann, nochmal unterschiedliche Tools anbinden kann. Und das ist halt einfach nochmal ein... sehr, sehr mächtiges Ding, was man irgendwie hat, wo man sich auch, also was man komplett lernen muss. Also es ist ja nicht mehr irgendwie, dass man jetzt sagt, das ist ganz klassisches DevSecOps oder DevOps oder Dev oder Ops oder so, sondern es ist ja wirklich eine fast eigene Disziplin zu sagen, hier, das ist gutes Agentic Coding. Also ich finde das eine sehr, sehr steile Lernkurve, wobei sich so viel so schnell verändert.

Mhm.

Und eigentlich würde ich gerne viel mehr darüber lesen, was sind die Best Practices, die andere nutzen und zwar in realen Projekten. Also nicht in Projekten, die ich jetzt gerade auf der grünen Wiese angefangen habe, sondern wirklich in bestehenden Projekten hingehen und das als Tooling einzuführen. Und weil er bestehen, also ich finde, bestehende Projekte sind immer eine ganz andere Herausforderung, als zu sagen, wir fangen jetzt neu mit einem Projekt an. Ja, in einem neuen Projekt starte ich auf der grünen Wiese, da kann ich von Anfang an natürlich alles so definieren, dass das total schön ist, dass alles aufgeschrieben ist, dass alles explizit da ist und klar, das Innet zum Beispiel von OpenCode ist natürlich echt nice, das schreibt viele Dinge nieder, ähm, Und das ist auch echt hilfreich. Aber ich frage mich, ob es da nicht noch bessere Wege gibt, zu besseren Ergebnissen zu führen. Und da vermisse ich das gerade.

Mm. Mm.

Also im Moment ist ja sowieso die Stimmung entweder völlig gegen KI, Oder völlig überzogen, hey, das kann das alles und ich finde, das Mittelmaß fehlt. Also ich finde es auch ganz spannend, dass mittlerweile hingegangen wird und gezielt KI-Systeme gestört werden mit Prompts, die quasi auf einer Seite integriert sind. Ja, so, und der Mittelweg, wie bekommt man das Ding jetzt wirklich in der realen Welt produktiv, sodass es sich auch gut anfühlt, dass man einen vernünftigen Workflow hat? Da würde ich wirklich gerne mehr drüber lesen oder auch hören. Also gerne einfach auch Podcast. Kommt zu uns in den Podcast und erzählt uns, zeigt uns, wie das richtig geht.

Oh ja.

Feel free. Aber ich finde es immer ein bisschen... bin so ein bisschen skeptisch mittlerweile bei den Leuten, die immer schreiben, ja, das funktioniert alles, ihr macht das nur nicht richtig. Okay, dann zeigt mir, was ich falsch mache. Bitte. Ja.

Ja, also es gibt, glaube ich, viele Technologien, die entweder, wo wir selber noch nicht von gehört haben. Also es fing mit der AgentsMD an. Irgendwann hat man mitgekriegt, das ist so das Ding. Jetzt habe ich hier von GitHub SpecKit, heißt das Ding, auch gelesen. Finde ich super interessant, wo man halt so genauer Specs definieren kann. Wir haben gemerkt, dass wir zum Beispiel unsere Arbeitsweise komplett ändern.

Vielen Dank.

Also ich genauso. Es gibt mittlerweile immer zu jedem Feature, was ich mache, eine Markdown-Datei, weil ich dieses Ping-Pong, so wie du es beschrieben hast, mit ich spreche mit dem Computer, das habe ich bis jetzt, finde ich eine coole Idee, aber bis jetzt hat sich das, oder habe ich da... das so gehabt, dass ich den Spec erstmal definiert habe in der Markdown-Datei, dann KI gefragt habe, hast du alles, brauchst du noch was, was fehlt, dann habe ich mir das nochmal durchgelesen, habe meinen Senf dazugegeben, weil ich gesagt habe, guck mal, das könnte ein Problem sein, die Entity braucht noch diese Felder, zum Beispiel mit PlantUML habe ich super Erfahrungen gemacht, Datenbank-Entities definieren. Mit einem Kollegen zusammen, er macht Frontend, ich mache Backend. Wir saßen zusammen und haben diskutiert, für dieses Feature brauchen wir zum Beispiel, weiß ich nicht, fünf Input-Felder mit diesem, das und jedem. Die plant-UML-Datei angepasst, Felder reingepackt und nachher dann zu den Specs das dazugenommen und gesagt, erstell mir PHP-Entities basierend auf diesem Diagramm zum Beispiel. Super easy, was hinten rauspurzelt, mit Zugriffen, mit allem drum und dran, mit API-Plattformen. Hast du dann ganz schnell, sagen wir mal, eine rudimentäre API. Auf der grünen Wiese alles super, geht schnell.

Ja.

Später im Projekt war es dann aber so, natürlich die guten Entwickler vernachlässigen sowas nicht. Irgendwann war die Dokumentation nicht mehr so wie die Programmierung. Und es war super easy zu sagen, guck mal, da sind die Entities, pass mal das Diagramm wieder an. Und dann konnte ich mit dem Diagramm weiterarbeiten mit dem Kollegen und sagen, guck mal, das ist jetzt der Stand. Dann haben wir da wieder drin rumgefummelt. Dann habe ich gesagt, ihr packt das mal wieder zurück. Und dann wurde da ganz schnell ein Schuh draus. Also am Anfang Markdowns definieren, Code generieren, von einer anderen KI, also ich lasse gerne auch eine andere KI dann nochmal drüber laufen, reviewen.

Ja.

Guck mal, was deine Konkurrenz besser oder schlechter macht. Dann schaue ich nochmal drüber und erst dann ist das für mich eigentlich fertig. Also ich bin schon schneller geworden, aber so arbeitstechnisch hat sich viel verändert in den letzten halben, dreiviertel Jahren für mich.

Aber die Frage, die sich mir eigentlich stellt, ist, werden wir nicht alle von Softwareentwicklern zu Softwarearchitekten damit? Ja, wir bewegen uns ja immer mehr in Definitionen und in Architektur. Ich finde, wir bewegen uns, also die Disziplin verändert sich aus meiner Sicht mehr hin zu einem Senior-Architekten, der Coding-Erfahrung hat, ja, nicht jemand, der einfach irgendwo hingekommen ist und jetzt Software-Architekt ist, sondern jemand, der auch vorher programmiert hat und selber programmieren kann. Und ich finde, wir entwickeln uns etwas in diese Richtung, dass wir weggehen tatsächlich von dieser reinen Entwicklerrolle, wo man ja auch immer so ein bisschen Architektur auf einem gewissen Level mitgemacht hat, hin zu einer sehr architekturlastigen Rolle mit Programmierungserfahrung, die auch Code-Reviews macht.

Ja.

Ja, so, okay. Finden wir das gut?

Die Antwort passt nicht für ein Podcast, aber ja. Also, ja, also irgendwie sowas in die Richtung definitiv. Also, es verändert sich extrem. Und ich bin Wenn du mich morgens fragst, ja, abends, nein. Also ich weiß es nicht. Ich bin auch so, ich weiß nicht, wo die Reise hingeht. Also es gibt viele Sachen, die finde ich gut. Also ganz grob gesagt, KI macht mich nicht schneller, sondern nimmt mir Arbeiten ab. Lieblingsbeispiel sind so Übersetzungen in einem Projekt. Du hast E-Mails, die müssen übersetzt werden in drei Sprachen oder Kunde kommt zwei Stunden später an, ach, da sind noch ein paar andere Sprachen dazugekommen, kannst du mal eben. Ja, dann nehme ich die CSV-Datei, schmeiße die KI an den Kopf und gehe mir einen Kaffee holen, dann ist das fertig, wenn ich wiederkomme. Das ist cool. Es gibt...

Aber macht es dann, also ja, ich verstehe das, dass ich grundsätzlich finde ich das ja auch cool. Aber ich stelle mir halt so die Frage, also ich kann jetzt halt schlecht zehnmal am Tag Kaffee trinken gehen. Also das verkraftet meinen Kreislauf nicht so gut. Dann wäre ich ein bisschen zu himmlich Richtung Abend. Die Frage ist ja immer, die ich mir stelle, was mache ich denn aus dieser Zeit, die ich eigentlich gewinnen müsste? Und das fühlt sich im Moment nicht so gut an, weißt du?

mehr Architektur. Mhm.

Ich sage mir jetzt mal, häufig erwische ich mich, sage ich jetzt mal, dabei, dass ich diese Zeit einfach nicht sinnvoll genutzt bekomme. Ich habe dann so diese, ich sage jetzt mal 20, 30 Minuten oder so, vielleicht sind meine Aufgaben auch zu klein geschnitten, aber wo dann die KI rödelt, ich dann diesen Planungsmodus zu Ende habe und sage, ah ja, jetzt schaue ich mir das an und dann läuft die weiter, aber gleichzeitig bin ich zu schlechter drin, sage ich jetzt mal, zu sagen, okay, ich mache jetzt auf dem zweiten Bildschirm ein anderes Projekt, lasse da auch ein Agent laufen und der macht eine andere Aufgabe.

Nein. Echt? Nee.

Also das ist Ich habe bei einigen Leuten gelesen, die machen das so. Aber den Kontext-Switch bekomme ich jetzt ehrlich gesagt nicht hin. Ich müsste dann auch ehrlicherweise einen zweiten Rechner nutzen, weil dann brauche ich doch mal irgendwie leistungsstärkere Systeme, um das machen zu können. Also ich... Ja, die Arbeit verändert sich. Ja, ich mag es teilweise. Besonders an Tagen, wo ich aus unterschiedlichsten Gründen ein Schlafdefizit habe. Aber es fühlt sich halt nicht so an, als wäre es tatsächlich eine Produktivitätssteigerung. Und das finde ich schade, wenn ich ein neues Werkzeug benutze. Dann... möchte ich da auch immer irgendwie schneller, mehr Effizienz reinbringen, mehr schaffen können, bessere Ergebnisse liefern. Und ich finde, das fühlt sich noch nicht immer so an. Da fand ich den Sprung mit der Integration von KI als smartere Codeergänzung, als smarteres Autocomplete, fand ich den Sprung in der Produktivität viel spürbarer und viel messbarer.

Vielen Dank.

Also da bin ich wirklich mit schneller gewordenen Und ich finde, das habe ich jetzt beim Einsatz von Agenten einfach noch gar nicht so das Gefühl.

Das, was du gerade beschrieben hast, das passiert mir auch. Ich schaffe es nicht in dieser Hyperfokus-Phase, sage ich mal. Beim Programmieren war das so, du warst irgendwann ganz tief in dem drin, was du gerade gemacht hast. Du hast in Methoden, Abhängigkeiten und Zuständigkeiten gedacht und hast gesagt, guck mal, ich habe jetzt hier zum fünften Mal diesen Fall geschaffen. Ich möchte das Design-Pattern benutzen. Da ist es noch Security-technisch was zu berücksichtigen. Und da war ich dann drin oder in solchen Phasen konnte man schon mal so zwei, drei Stunden irgendwie so verschwinden lassen.

Ja.

Hast du nichts mitgekriegt. Und ich war auch hoch fokussiert. Einen Tag später hättest du mich fragen können. Ich wusste alles. Jetzt mit KI passiert genau das. Ich lasse die Sachen generieren. Ich habe nicht gemessen, ob das schneller ist. Also jetzt zeitmäßig... 5 Minuten.

ist ja auch nur so ein Bauchgefühl. Ich sitze da jetzt auch mit der Stoppuhr und sage, na, das hätte ich in der gleichen Zeit programmiert. So nicht verstehen. Das ist jetzt so eine gefühlte Wahrheit.

Ja. Also mir fehlt das. Aber... Also wenn ich mit KI was generiere, bin ich nicht mehr so tief drin in dem Thema. Ich mache zwar die Reviews, aber... das, was ich vorher beim Schreiben die Tiefe erreicht habe, muss ich jetzt später mir das zurückerarbeiten, wenn ich die Reviews mache, weil dann sehe ich den Code und frage, warum ist die Methode da? Hat das, also das brauche ich immer noch, weil ich möchte immer noch wissen, zum Beispiel die Dateien, die ich ablege, liegen die irgendwo im Public, sind die öffentlich zugänglich oder sind der S3-Bucket einfach so nicht gesichert?

Ja. Ja.

Das sind ja Sachen, die kann die KI bauen. Aber ich habe dann, also ich weiß es nicht, kein anderer weiß es. Das finde ich problematisch. Und gerade das, was du beschrieben hattest, dieses, dadurch, dass ich nicht das programmiere, verliere ich schnell den Fokus. Und bin dann so alle 20 Minuten mit, okay, jetzt haben wir das gemacht. Machst du das Nächste und das Nächste. Also das fehlt mir gerade noch so, dass ich da irgendwie einen Modus finde, wo ich kontinuierlich tief in ein Thema einsteige. wo ich das dann auch nachher wirklich abgeschlossen markieren kann. Also ich kratze oben an vielen Themen, kann mich nachträglich hinsetzen oder wenn ich Reviews mache, setze ich mich hin und erarbeite das wieder zurück. Also die Zeit, die ich vorne spare, brauche ich länger.

Ja.

Deswegen ist so gefühlt das gleiche Thema oder die Zeit, der gleiche Aufwand, weiß ich nicht.

Ja, weißt du, mich erinnert das so ein bisschen an Uniklausuren früher.

Hm.

Schauen Sie sich den Code an und sagen Sie, welcher Compilerfehler auftritt.

Boah.

Ich finde, die Kategorie ist das jetzt. Nach der Klausur wusste ich auch nicht mehr, was war denn jetzt dieser Code, der da steht. Und, also das ist halt so dieses Ding. Ich finde, das ist es irgendwie. Das beschreibt es für mich so ein bisschen. Aber vielleicht brauche ich auch einfach so einen schrottigen Workflow wieder so ein bisschen mit, ich habe 15 Minuten Pause, in der Zeit kann ich den Agent anschmeißen, dann habe ich eine halbe Stunde Besprechung und dann wieder. Ja, also vielleicht, in der Zeit,

Aber dann komme ich wieder zurück aus der Besprechung und weiß gar nicht mehr, was mit dem Agent war und was ich ihm gesagt habe. Hm.

Naja, das kann man ja, wenn es so eine Besprechung ist, wo man nicht in, also so ein Videocall ist, dann kann man das ja auf dem einen Bildschirm laufen lassen und sieht ja, was passiert, weißt du? Vielleicht ist das auch so ein Arbeitsmodus, in den ich wieder zurück muss. Nicht, dass ich das möchte. Ja, bitte. Also, das soll jetzt keine Aufforderung dazu sein, dass das in den Modus wieder zurückgehen soll. Aber ich finde, so ein bisschen... die Arbeitstiefe hat das irgendwie für mich.

Ja, also...

Irgendwo zwischen komischer Frage in der Klausur und eigentlich programmiert man zwischen Besprechungen. Also programmiert. Wo man genau wusste, wenn man so einen Tag mit Besprechungen hat, wo irgendwie sechs Stunden Besprechungen geplant sind, die zwei Stunden sind eh für die Töne. Da machst du keine einzige Aufgabe wirklich. Ja.

Das war Smalltalk. Also das hatten wir sogar. Bei einem Kunden hatten wir das echt, wo wir gesagt haben, die Stunde dazwischen, es ist keine Pause, aber das ist Smalltalk. Und dann haben wir uns hingesetzt und keine Ahnung.

Ja, ganz schlimm finde ich dann, wenn dann irgendjemand auf die Idee gekommen ist, ihr müsst alles auf Tickets buchen.

Jeder hat so sein Herz ausgeschüttet. Oh ja.

Und ich dachte mir so, ja, fuck. Wo buche ich das denn jetzt hin? Aber gut. Jetzt. Ja.

Ja, aber zu dem Thema zurück, was ich mag an dem Programmieren oder wo KI mich besser macht. Das ist ja so, die Headline schlechthin, damit kriegst du auf LinkedIn aktuell immer noch gut Reichweite generiert. KI macht mich besser. Also gerade dieses, ich habe nur vier Stunden nachts geschlafen. Also

Definitiv, ja.

die Tickets vorbereite, ist das so ein Pingpong. Und natürlich habe ich schon eine Idee, wie ich etwas bauen will. Aber ich bin ja hin und her. Und es ist mir schon ein paar Mal passiert, wo dann so zurückkam, willst du A oder B? Wo ich sage, hm, Stimmt, B gibt es auch noch. Hatte ich vorher schon instinktiv ausgeschlossen, weil es hat nie gepasst und habe mittlerweile die Lösung vergessen. Aber in diesem Fall hat B, dann habe ich darüber nachgedacht, geguckt, habe gesagt, okay, passt immer noch nicht, aber ich hätte es gar nicht auf dem Schirm gehabt. Und wenn mich nachträglich jemand gefragt hätte, hätte ich gesagt, cool, ich habe A und B evaluiert. Also die Entscheidung war bewusster.

Ja, definitiv. Ach so, ich schon. Aber wir haben auch Induktion jetzt.

mir passiert leider oft oder öfter, dass man gewisse Sachen schon auswendig kann. Hast du fünfmal auf die Herdplatte gefasst, machst das beim sechsten Mal instinktiv nicht mehr und Okay. Und viele Sachen mache ich mittlerweile unbewusst, wo ich dann sage, die Lösung nehmen wir und dann ist es das Gleiche, wenn ein Junior oder ein neuer Team ist. Dann kommen die Fragen, warum machst du das? Darum haben wir schon immer so gemacht. Das ist so die schlechteste Antwort.

War die letzten Male auch gut.

Ja, ja, genau.

Was ich tatsächlich auch gerne zwischendrin mache, ist, gerade bei komplexeren Algorithmen irgendwo oder komplexeren Funktionsabläufen, die KI einfach mal fragen, kann man das effizienter machen?

Mhm.

Und da kommen erstaunlich häufig echt schöne Lösungen bei rum. Also das darf man gar nicht so unterschätzen, wenn man so sehr in bestimmten erlernten Abläufen ist. Da ist es total schön, einfach mal einen Schritt zurückzugehen und zu sagen, wie sieht denn jemand anderes aus? aufgrund des trainierten Wissens der Allgemeinheit, das und gibt es da vielleicht einfach einen besseren Ablauf. So, und ich glaube, wir können festhalten, wir finden das eigentlich relativ spannend. Uns fehlen so ein bisschen Best Practices. Ja, und da...

Einfach, weil es noch nicht alt genug ist. Hm.

Ja, und es ist auf jeden Fall ein Thema, das sich entwickelt. Ich bin auch gespannt, wo die Reise damit hingeht.

Ich auch. Ich glaube, ich werde mich da nochmal hinsetzen und gerade so dieses GitHub-Spec-Kit und andere Sachen mal ausprobieren und ich glaube, wir machen eine Folge mal genau über solche Sachen. Dass wir da so ein bisschen mal, ein bisschen tiefer zeigen, was wir nutzen, wie wir nutzen, was wir damit gelernt oder gesehen haben.

Ja, und vielleicht auch, wie wir das Ganze absichern. Ich finde, das darf man nicht vergessen. Immer. So, so, so. Dieses selbstständige Schreiben lassen, dieses Gottvertrauen, dass jetzt nichts schief geht nach dem Planen und dass er das tatsächlich macht. Manchmal wünsche ich mir da dass das besser abgesichert ist. Oder dass ich vielleicht lerne, wie ich es besser absichern kann. Oder schon, dass das System das selber besser abgesichert ist. Ich weiß es nicht. Ich finde, die ganzen Sicherheitssachen, die werden mir auch zu wenig diskutiert an der Stelle.

Ja, die sind ja hinderlich, deswegen die passen auf keine tollen Slides.

Gut, das war jetzt das Schlusswort. Und dann hören wir uns in zwei Wochen wieder.

Ja, bis in zwei Wochen.

Und lassen uns überraschen, welches Thema es dann wird.

Wir sehen uns.

Das war die dritte Folge Secrets Not Included. Vielen Dank fürs Einschalten. Und folgt uns, dass ihr nichts verpasst. Ciao.