Revision 716: Agentic Engineering statt Vibe Coding

0:00Dieses Buzzword, was halt gerade so über allem meiner Meinung nach steht, ist halt dieses Agentic Engineering, was halt sozusagen dieses echt gewordene mit AI-Code schreiben und in Production shippen beschreiben soll. Und das Spannende bei einem Agent ist, der hat eine Art Gehirn, also der kann sich Dinge merken. AIs sind ja vor allem darin, sehr gut zu lesen. Und etwas, wo ich das zuvor unterschätzt hatte, was ich jetzt tun kann, ist das Aufsetzen von bestimmten Projekten oder Setups oder Tooling.

1:00Revision 716. Hallo und herzlich willkommen beim Working Draft. Heute sind wir zu zweit am Start aus dem Team. Ich hätte mit mir dabei den Hans. Hallo Hans. Hallo. Und ich bin die Vanessa. Ich bin auch mal wieder da und ich freue mich auch sehr, mal wieder dabei sein zu können. Zeitlich gesehen nicht, dass mich jemand hier von meinen Kindern daran gehindert hätte. Nur meine eigene Zeit. Schön, dass du mal wieder da bist. Es ist ja doch schon ein Moment her, glaube ich, dass die letzte Sendung mit dir war.

1:34Von daher cool, dass du es in deinem Busy Life gerade unterbringen kannst. Vor allem, dass du gesund bist. Der Sommer sind wir hoffentlich alle, bleiben wir hoffentlich alle gesund. Ja, der Chef hat jetzt auch mal gemeint, das ist eigentlich recht witzig, dass in der Anfangszeit von der Elternzeit, also als das Baby da war, war ich noch relativ häufig da. Und auch wenn es eine sehr anstrengende Phase ist oder war in dem Sinne, so ein Baby schläft halt viel und ich hatte ja wie gesagt Elternzeit.

2:06Und es hat alles sich sehr stark geändert, als das kleine Mädchen in die Kita ging und wir auch komplett von diesen Kita-Krankheiten überrumpelt wurden. Und wenn ich dann mal ausnahmsweise mal drei Tage lang keinen Schnupfen, Husten, Mandelentzündung oder sonst was hatte, hatte ich einfach nicht mehr die mentale Kraft, um zu reden. Ich wollte nur noch auf die Couch und Switch spielen. Aber jetzt bin ich da. Ich denke, das ist völlig okay. Zwei Wochen, glaube ich, alle gesund.

2:35Sehr gut. Ich hoffe, das bleibt so. Toi, toi, toi. Genau, ja, jetzt im Sommer kommt dann irgendwann die Sommerkrippe wahrscheinlich bei den Leuten dazu. Ich merke das bei uns in der Kita, da ist jetzt auch gerade schon wieder eine Gruppe geschlossen und morgen sind es hoffentlich wieder alle offen. Aber die Zuhörerinnen und Zuhörer mit Kindern aus oder Kita-Kindern, die kennen das wahrscheinlich. Nichtsdestotrotz wollten wir heute auch mal noch über technische Themen sprechen, glaube ich.

3:02Genau. Und eigentlich hast du uns da ein Thema heute mitgebracht und das ist das Agentic Engineering, mit dem du dich da ein bisschen befasst hast. Ich generell befasse mich auch relativ viel damit, auch auf der Arbeit, versuche es noch so ein bisschen privat auch mich weiter einzulesen. Ich glaube, wir können mal kurz davor absagen, wir sind jetzt beide keine Super-Experten, aber Nutzer, Nutzerinnen von Agentic Engineering und wollen da ein bisschen über unsere Erfahrungen sprechen und wie wir das so aufbauen.

3:34Ja, genau. Also für mich ist halt irgendwie, und das habt ihr ja hier in dem Podcast auch schon wahrgenommen, das Thema AI natürlich allgegenwärtig, wenn es um Software Engineering geht. Und ich glaube, man kommt da irgendwie nicht drum herum. Und dennoch hat sich ja in den letzten gerade zwölf Monaten, aber sagen wir auch mal 24 Monaten, extrem viel getan, was halt so Software Engineering mit AI anbelangt. Irgendwie vor einiger Zeit haben wir noch AI-infused Coding gesagt oder haben wir dann irgendwie einen Co-Pilot genutzt oder so und haben dann den Code, den wir hatten, vielleicht nochmal validiert, uns Test schreiben lassen, automatisiert oder ähnliches oder bessere Auto-Suggestion so ein Stück weit gehabt im Code, um die Art und Weise, wie wir Code schreiben, zu verbessern.

4:21Wir haben vielleicht Vibe-Coding genutzt, um irgendwie mal eine Idee rauszuballern. Wir hatten diese Sendung mit V-Zero, wo es halt anfänglich darum ging bei V-Zero, halt wirklich, du hast einen Prompt, schreibst in einer menschlichen Sprache, was du gerne für eine Applikation bauen willst oder welches Feature du bauen willst und hast am Ende etwas von der AI erhalten. Wir waren am Anfang vielleicht noch nicht auf diesem Niveau, wo wir heute sind.

4:49Vor zwei Jahren, da hat das funktioniert und alle so, wow, cool, ich kann mir bauen, was ich will. Wir haben uns irgendwelche kleinen Skripte, kleine Tools gebaut, die wir früher halt nicht gebaut haben, weil es zu viel Zeit in Anspruch genommen hat. Aber irgendwie sind wir halt jetzt viel, viel weiter gekommen mittlerweile, sodass, ja, manche Menschen vielleicht auch sagen, ey, ich kann mich gar nicht mehr dran erinnern, wann ich das letzte Mal richtig Code geschrieben habe, weil man eher Code orchestriert.

5:15Und genau das wollten wir, oder Tools orchestriert, und das wollten wir heute mal in eine Sendung packen, mal sagen, okay, wie arbeiten wir eigentlich gerade, wie kommen wir eigentlich von einer Idee zu einer Implementierung, die wir dann auch in Production shippen mit AI. Und dieses Buzzword, was halt gerade so über allem meiner Meinung nach steht, ist halt dieses Gentic Engineering, was halt sozusagen dieses echt gewordene mit AI-Code schreiben und in Production shippen beschreiben soll.

5:48Genau, das wäre jetzt so der Inhalt der Sendung, dass wir das einmal klären, wo stehen wir denn da eigentlich und wie machen wir das? Ich glaube, ich würde da gleich auch am Anfang mal so ein bisschen den Mythos rausnehmen wollen aus diesen Begriffen Agentik, Engineering und dich auch fragen, was es genau so ein bisschen bedeutet, weil ich weiß ja, das ist Engineering mit AI und Agents. Aber bedeutet das, dass du selber Agent schreibst oder auswählst?

6:22Oder was bedeutet es eigentlich für dich, wenn du jetzt damit Code schreiben möchtest? Ja, vielleicht fangen wir erst mal damit an zu definieren, was ist eigentlich ein Agent? Also Agent haben wir wahrscheinlich alle schon gehört. Und in der Regel würde ich jetzt mal ein Agent in der AI-Welt so definieren, dass ich sage, okay, das ist Agent. Eine Art Programm, was beispielsweise eine LLM benutzt, aber das ist nur ein Teil davon. Nämlich ein Agent hat auch irgendwie eine Art Möglichkeit, auf gewisse Tools zuzugreifen.

6:55Also beispielsweise einen Browser oder halt die Codebase, die man so da rumliegen hat. Also irgendwie Tool-Use ist so ein ganz, ganz wichtiger Bestandteil von einem Agent. Außerdem ist es so, dass ein Agent halt für sich funktionieren kann. Das heißt, man gibt eine Aufgabe in Form eines Prompts im Endeffekt und sagt, hey, mach doch mal A, B, C. Und dieser Agent kann dann selbstständig loslaufen, kann beispielsweise die, über einen Tool-Use die Code-Base durchsuchen und sich dann eine Art Plan erstellen, also wie etwas implementiert werden kann.

7:31Manchmal ist es dann so, in den Programmiertools, können wir gleich nochmal drauf eingehen, dass dann nochmal ein paar Fragen gestellt werden. Hey, wie meinst du das genau? Meinst du A, B oder C? Und dann werden gewisse Workflows abgearbeitet. Und das Spannende bei einem Agent ist, der hat eine Art Gehirn, also der kann sich Dinge merken. Beispielsweise, wenn in einem Prompt ein bestimmtes Keyword auftaucht, meint der Benutzer immer X, Y oder Z damit.

7:57Oder in einer Codebase wurden folgende Sachen schon implementiert und diese merke ich mir sozusagen, ja. Grundsätzlich kann man halt so Agents für ganz, ganz viele Dinge nutzen, ganz viele machen sich da so dieses Thema Second Brain irgendwie, dass sie halt sagen, okay, auf meiner Festplatte, auf meinem eigenen Computer liegen halt ganz viele Daten und ich versuche die zu orchestrieren mit einer Agentic AI. Und wenn es jetzt um Software Development ganz konkret geht, darüber wollen wir halt heute dann nochmal sprechen, wie wir, Also da wollen wir jetzt nochmal tiefer drauf eingehen, wie man das eigentlich macht.

8:29Und du hattest ja auch gefragt, was ist eigentlich so. Agentic Engineering, ne? Und ich glaube, dieses Orchestrieren von so Agents und sagen, diese Agents, die nutze ich, ganz wichtig, man nutzt die nicht, man schreibt die unbedingt selbst, man schreibt vielleicht, Dinge, die diese Agents machen sollen selbst oder teilweise kleine Unterfunktionen, aber in der Regel verwendet man einfach das, was schon da ist, so, genau, und, Vielleicht ist es auch nochmal gut, darauf einzugehen, wie so ein Einstieg im Software Engineering eigentlich sein könnte.

9:06Also im Normalfall haben wir ja alle irgendwie unsere IDE. Viele sind wahrscheinlich schon umgestiegen oder verwenden in VS Code halt bestimmte Integrationen, um halt einen, Agentic Engineering zu betreiben, um halt irgendeinen LLM anzusprechen oder beziehungsweise halt irgendeinen Agent anzusprechen. Und es gibt aber ja auch einige Tools wie jetzt Cursor oder Cloud Code, natürlich, mit dem man dann halt irgendwie Software schreiben kann heutzutage.

9:43Das fand ich jetzt ganz interessant, dass du gemeint hattest. Vielleicht benutzen ja viele schon gar keine IDE mehr oder haben da eine LLM-Verknüpfung, weil mir das nochmal zeigt, wie viele unterschiedliche Wege es aktuell auch zu Authentic Engineering gibt. Es gibt eben nicht diesen einen Weg. Ich würde dich gleich auch nochmal genau fragen, wie man denn jetzt einen Agent nutzen kann. Aber ich zum Beispiel benutze OpenCode. OpenCode ist ein Open Source und kostenfreies Tool, das ich dann aber mit den Models, so viele Begriffe, dass ich dann aber mit den Models meiner Lieblings-LLM oder meiner Lieblings-AI-Institutionen verknüpfen kann und kann dann da auch so rumwechseln.

10:26Man kann auch sagen, okay, für den Task nehme ich ein teureres Modell, für den Task nehme ich ein günstigeres Modell und lasse mir dort Ideen, Code, Pläne generieren. In der IDE, in VS Code selber, habe ich das tatsächlich relativ clean gehalten. Ich habe eine GitLab Duo-Verknüpfung drinnen. Aber ich habe mir angewöhnt, dass ich meine Tools auch durchaus separiere. Zum Beispiel, wenn ich noch selber komplette Kontrolle haben möchte, selber committe, selber pushe und pulle, mache ich das in meinem normalen Terminal.

11:08Wenn ich OpenCode verwende, ich benutze die CLI-Tool, benutze ich dafür ein anderes Terminal-Tool. Da benutze ich Westterm, glaube ich, heißt das. Damit ich das so für mich auch getrennt habe. Und die Ergebnisse, so ein bisschen schaue ich mir dann in VSCode direkt an, so für mein eigenes Review. Außer ich bin bei dem Modus, wo ich den sogenannten YOLO-Modus betrete. Das mache ich bei bestimmten Tasks. Und zwar sind das Tasks, die ich sonst niemals machen würde.

11:42Also das sind keine Tasks, wo ich sage, hier brauche ich AI-Unterstützung, sondern ich würde es ohne AI gar nicht erst tun. Und das sind ganz bestimmte Refactorings, bei denen vielleicht der Business Value jetzt auch generell mal nicht so gegeben ist, aber wo ich selber trainieren möchte, üben möchte, wie würde das denn genau ablaufen, wenn ich jetzt zu dem Agent sage, ich möchte, dass wir überall bei den View Components die Namen abändern, zu einer neuen Struktur.

12:13Das sind aber tausende an Änderungen, weil das Projekt groß ist. Das können wir nicht so viele Merge Requests aufmachen, sondern wir müssen das splitten. Und ich möchte jetzt, dass du Branches erstellst, wo dann maximal 100 Änderungen pro Branch drin sind, kommittest und pusht. Sobald es Merge-Konflikts geben sollte, fixst du die selber, machst ein Rebase und Force-Pusht. Und das läuft dann natürlich alles so ein bisschen im Dark-Pattern ab, wo ich relativ wenig noch sehe. Also ich kann noch approven.

12:46Aber ja, da wird dann tatsächlich automatisch committed, automatisch gepusht. Läuft ganz gut manchmal. Manchmal läuft es auch nicht so gut. Manchmal war das hups. So habe ich das nicht gemeint. Hupsi, dupsi. Aber genau da bleibe ich dann komplett im Open Code drinnen. Ja, das ist spannend. Also ich habe diesen Toolwechsel oder ich glaube, viele Tools versuchen gerade das zu vermeiden. Also gerade uns User dahin zu pushen, irgendwie ein Tool nur noch zu verwenden, und in dem komplett all diese Dinge zu tun. So wie halt VS Code damals gesagt hat, ey, wir haben hier eine Git-Integration, du brauchst gar nicht mehr raus in dein Terminal.

13:25Habe ich selber auch gemacht. Also ich habe selber auch immer das Terminal noch weiterverwendet. Wenn ich heute mal gucke, wie viel Terminal verwende ich, dann ist es super wenig, muss man einfach sagen, weil ich mir irgendwie Diffs von dem Code, der von einem Agent erstellt wurde, innerhalb der IDE angucke, also ich verwende Cursor, weil ich sage, okay, dann committe ich das direkt dort oder kann halt direkt dort Änderungen machen. Jeglicher Art. Ich kann mir beispielsweise Commit-Messages schön verbose generieren lassen und die dann entsprechend anpassen, wenn ich das brauche.

13:59Das passiert auch anhand der Änderungen, die man selber gemacht hat oder beziehungsweise die die AI gemacht hat innerhalb des Codes beispielsweise. Und ich habe einen Artikel geschrieben, wir haben irgendwie. Vivecoding eine ganze Zeit lang verwendet, den Begriff, und hatten das irgendwie so negativ irgendwie konnotiert, zumindest in meinem Kopf. Und dann kam halt dieser Begriff Agentic Engineering und wie kommt man da eigentlich hin und die Steps, was für mich gerade Agentic Engineering genau bedeutet oder wie ich da von einer Idee in Production komme, da können wir gleich nochmal drüber sprechen.

14:36Ähm, was aber der Fall ist, ist, dass das beispielsweise vor einem Launch passiert ist von einem neuesten Feature von Cursor, ähm, was so das Agentic Window, äh, irgendwie nennen die das, glaube ich, ähm, ist und wo es einfach darum geht, Aufgaben, die da sind, halt noch mehr in Agents zu denken und wegzukommen von diesem, ich denke in Code, ja, weil die ursprüngliche Plattform von Cursor ist ja doch sehr, sehr Code-lastig auch. Man hat immer irgendwie sein Repository vor sich oder ähnliches.

15:10Und diese neue Ansicht ist halt mehr diese Agent-Ansicht, wo man halt mehr innerhalb des Chat-Windows beispielsweise arbeitet, ja, natürlich auch den Code weiterhin sehen kann. Aber das ist halt so ein Stück weit diese Innovation, die ich halt sehe jetzt bei Tools, dass man halt sagt, okay, man möchte wirklich, dass die Benutzer sich mehr auf das Thema Chat und Integration sozusagen, Integrationen. Ja irgendwie fokussiert und dann auch über Projekte hinweg, also nicht nur innerhalb eines Softwareprojekts, sondern vielleicht auch innerhalb von mehreren Softwareprojekten, Daten zusammenziehen kann.

15:50Und das Tolle halt an diesem Agentic Engineering oder grundsätzlich an, Agents ist halt, dass du Dinge verknüpfen kannst. Ich gebe mal ein Beispiel. Du hast vielleicht Notion, in dem du all deine Projekte oder auch dein Privatleben oder das, was du halt gerade irgendwie als relevant erachtest, dokumentierst. Und du möchtest, nehmen wir jetzt mal ein ganz anderes Beispiel, einen Contentplan für Social Media erzeugen. Und dieser Contentplan, der braucht halt innerhalb deiner App bestimmte Funktionalitäten, um Dinge zu dämonen.

16:24Ja, und was du halt tun kannst, ist dann Cursor mit Notion verknüpfen über einen MCP und dann sagen, okay, Cursor, sprich doch mal bitte mit meinem Notion, gib mir mal den letzten Post in meinem Contentplan, pass den so an, dass er zu meiner App passt, so wie die App gerade ist, und passe gleichzeitig die App so an, dass ich genau diese Sache in der App halt darstellen kann als Demo beispielsweise. Und das ist etwas, wo du halt dann zwischen Tools hin und her dich hangeln musst sozusagen und das macht halt dieser Agent dann autonom.

17:02Er kann die Seite in Notion updaten, er kann deinen Code updaten und am Ende kommt ein Ergebnis bei raus, was hoffentlich, wenn du es richtig beschrieben hast, genau das ist, was du halt brauchst, um deinen Contentplan zu erfüllen. So, und jetzt fällt dir auf, okay, ich muss aber meinen Contentplan updaten und idealerweise musst du dann nicht mal raus aus deinem, Cursor-Agent-Window, sondern du machst einfach einen neuen Chat auf und sagst halt, hey, der Contentplan, der funktioniert so nicht, ich brauche irgendwie noch zwei neue Content-Pieces und verteile das mal irgendwie.

17:35Und wenn man dann jetzt noch eine andere Plattform mal dazu nimmt, beispielsweise Manos AI, ist so ein Tool, was jetzt gerade von Meta gekauft wurde, die können dann zum Beispiel sich noch zum MCP, von Instagram connecten, dann kann man auch sagen, analysiere mir vorher mal noch, was eigentlich gut funktioniert in meinem Social Media und dann passt den Contentplan genau dahingehend an. Und diese Art von Tool-Use, also zu sagen, die AI geht halt an eine Instagram-MCP, holt sich die Daten, die gebraucht werden, daraus macht es etwas Neues, plant einen Content-Plan zu bauen, baut diesen Plan, schreibt ihn in ein neues Tool Notion, greift dann auf deinen Code zu, um in deinem Code genau die Änderungen zu machen, die du um ein Content-Piece.

18:23Anzupassen, nimmt sich vielleicht noch die Datenbank, um in der Datenbank mit Superbase beispielsweise zu schauen, hey, sind alle Daten in der Datenbank, wenn nicht, schreibe ich die da rein. Das ist halt Agentic Engineering. Dieses Zusammenbringen von ganz vielen Tools mittels Agents. Am Ende kommt zwar irgendwo Code raus, am Ende kommt auch anderer Content vielleicht irgendwo raus, aber das ist sozusagen so den Use, den man halt heute haben kann oder Oder die Art und Weise, wie man halt heutzutage Dinge zusammenbringen kann.

18:59Diese Revision von Working Draft wird euch präsentiert von Mitwald, Next Level Container Hosting für eure Projekte. Wie euch bestimmt nicht entgangen ist, reden alle überall und ständig über Automatisierung und Self-Hosting. Und das klingt auch immer alles voll super, wenn's denn mal eingerichtet ist und läuft. Nur über diesen Schritt redet fast keiner, weil er meist kompliziert und anstrengend ist. Aber es gibt eine Ausnahme und das ist Mitwald's Container Hosting.

19:20Und das funktioniert so. Erster Schritt, in Mitwald's M-Studio einloggen. Ganz einfach und bequem, direkt im Browser. Zweitens, fünf Minuten für die Konfiguration eures Containers aufwenden. Mehr Zeit braucht ihr nicht, denn ihr könnt die meisten Vorschläge für Entry-Points und Umgebungsvariablen einfach direkt übernehmen. Dritter Schritt, äh, euer Container läuft. Ihr seid fertig. Das war's. Von Nerds für Nerds bringt euch Midwald das Beste, was Container-Hosting zu bieten hat, nämlich eure Eintrittskarte ins Automatisierungs-Wunderland.

19:47Deployt ganz einfach, was ihr wollt, wie ihr wollt. Und alles dazu findet ihr auf midwald.de slash workingdraft. Das war nochmal mittwald.de slash Working Draft. Wir danken Mittwald für die Unterstützung von dieser Revision von Working Draft. So zumindest arbeite ich gerade und das ist jetzt schon so ein bisschen abstrakt gewesen und ich will das aber auch nochmal mit dem, was ich eben gesagt hatte von Vibe Coding nach Argentic Engineering vielleicht nochmal so Step by Step durcharbeiten und vielleicht nochmal mehr auf eine Art Projekt eingehen, wie ich das jetzt beispielsweise bei einem Projekt machen würde, wenn ich eine Aufgabe vor mir hätte und eine Idee vor mir habe. Ja, genau.

20:33Weiß nicht, Alessa, deckt sich das mit dem, wie du auch jetzt das Thema so sehen würdest? Die konkreten Beispiele sind in meinem Use Case anders. Das wäre jetzt nicht Notion, das wäre GitLab, das wäre nicht Instagram, das wäre das andere Repository. Aber es stimmt. Und ich glaube daher, wir hatten das auch in der Vorbesprechung, genannt, dass es ja eigentlich Argentic Engineering ist und nicht Argentic Coding. Denn ich müsste jetzt wirklich raten, wie viel Anteil der AI-Nutzung wirklich dafür ist, Code zu generieren und wie viel in den kompletten Software-Development-Lifecycle eigentlich hineingeht.

21:13Die konkreten Beispiele wären jetzt eine Konversation auf Slack und da. Wenn man dann so merkt, okay, jetzt haben wir so langsam mal so einen Intent, so einen Plan, was wir da eigentlich tun wollen oder wir haben einen Bug verstanden, dann kommt ja der nächste Schritt, da ein Ticket zu erstellen. Und dafür gibt es jetzt speziell bei GitLab einen eigenen Planner-Agent, heißt der und da kann ich die Konversation mehr oder weniger reinschmeißen und.

21:44Dieser, da, jetzt gehe ich nochmal genau darauf an, was da so ein Agent ist. Das ist, was du schon vorgemeint hattest. Tools sind extrem wichtig, aber da ist ein Agent ein vorgefertigter System-Prompt, wo ganz klar drinsteht, wir schreiben unsere Tickets immer so. Wir setzen dann diese Labels. Und da ist immer schon ein Milestone draufgesetzt. Das ist einfach nur, in dem Sinne einfach nur ein System-Prompt, den ich nicht jedes Mal reinkopieren muss.

22:09Dann gibt es die bestimmten Tools wie, ich darf Label setzen, ich darf schon mal jemanden assignen, ich darf einen Milestone setzen, ich darf das Repository dazu lesen und dann gibt es auch noch diese MCP-Server, die würde ich jetzt aber gerade mal außen vor lassen, weil du hast auch gerade schon MCP genannt, aber das sind gerade so viele Begrifflichkeiten und ich glaube, wir wollen darauf jetzt gar nicht so genau fokussieren. Ja, vielleicht trotzdem ganz kurz, was ist das? Also Model Context Protocol, also ist diese Abkürzung und im Endeffekt beschreibt das eigentlich einen Standard, wie zwei AIs miteinander reden.

22:45Und man muss halt, auf der einen Seite hat man halt ein Tool A, wie jetzt, ich habe vorhin mal Superbase genannt, du hast GitLab genannt. GitLab hat halt irgendwie ein MCP, was halt bestimmte Funktionalitäten anbietet, so eine Art Schnittstelle, wenn man so will, zwischen zwei AIs. Und so kann halt die eine AI, nämlich beispielsweise der Agent in deinem Cursor, hingehen und sagen, ich spreche jetzt mal das GitLab-MCP an und sage dem, hey, übrigens, ich will hier gerade eine neue Wiki-Seite schreiben.

23:19Mit folgender Dokumentation. Kannst du das mal eben für mich machen? Und wenn dieses MCP auf der GitLab-Seite das halt kann, dann schreibt das einfach. Und dieser Standard ermöglicht es halt, dass diese beiden zusammen sprechen können. Nur nochmal kurz abstrakt erklärt. Gut erklärt. Vielen Dank. Und dann wird es besonders spannend, wenn das Ganze, die Lösung für dieses Problem nicht in einem Repository liegt, sondern über mehrere Projekte hinweg.

23:47Wenn ich jetzt in dem UI-Component-Repository was anfassen müsste, vielleicht hat es auch noch einen Backend-Teil dazu und am besten denkt die AI nicht unbedingt selbstständig so weit, aber vielleicht steht einfach schon in dem System-Prompt von dem, Agent drinnen immer dran zu denken, dass es hier eine Dokumentation geben muss oder vielleicht ein Update im Change-Log. Und kann dann dementsprechend auch schon mal in dieses Ticket dann reinschreiben, es wird dieses Repository anfassen, dieses Repository anfassen, dann brauchen wir hier eine Dokumentation und dann muss noch das getan werden.

24:19Und das ist schon eine relative Zeiterleichterung für einen relativ redundanten Task, den ich sonst machen müsste, zu schauen, wie das alles selbstständig zusammenspielt. Und an dieser Stelle wurde noch gar kein Code geschrieben, aber wir können jetzt schon mal abschätzen, ist es das jetzt überhaupt wert, das zu machen oder brauchen wir eh eine andere Lösung oder wollen wir eh was ganz anderes machen. Genau, und diese Vorarbeit, das ist ja sozusagen noch, der Start vom, ganzen Software-Development-Lifecycle. Du hast das eben schon angesprochen.

24:50Und ich glaube, das ist halt was, wo wir als Entwicklerinnen und Entwickler uns halt Gedanken machen müssen und auch Projektmanagerinnen und Projektmanager und alle, die halt irgendwie in diesem Software-Development-Lifecycle irgendwie aktiv sind. Wie gehen wir das Ganze an? Und ich bin jetzt gerade hier in meinem eigenen Projekt, wo ich hier so einen AI-Cycling-Coach baue, relativ autonom unterwegs, kann alles so selbst bestimmen und nehme all diese Rollen parallel ein.

25:18Aber auch in Teams ist es ja so, und das hast du ja gerade ganz toll an einem Beispiel gesagt, dass du halt irgendwie dir erstmal überlegen musst, wie fängst du eigentlich mit einer Aufgabe an? Und wie kriegst du die dann in Production und wie kann AI dich eigentlich auf diesem Weg unterstützen? Und was ich in diesem Artikel beschrieben hatte, war halt mein Weg dazu. So klar, ich nehme gerade alle Rollen irgendwie auf einmal ein, aber natürlich kommen auch mal User zu mir und sagen, hey, guck mal, ich habe folgende Idee, kann man das nicht so und so machen?

25:47So, und dann denkt man sich selbst so, ja, das ist sehr spitz der Use Case, aber wenn man das breiter fasst, dann kann man das vielleicht nochmal anders lösen. Ja, das heißt, man begibt sich erstmal in so eine Ideation und guckt erstmal, wie kann ich denn ein neues Feature für ein Produkt erstellen? Und was ich da halt häufig mache, ist wirklich brainstormen gemeinsam mit der AI. So, und das kann jetzt in ChatGPT sein, das kann in Gemini sein, das kann aber halt auch in Cursor im Agent-Mode passieren und das Wichtige dabei ist aber halt, dass dieser Agent halt deinen Kontext kennt, ja, also, was ist deine Marke, was ist dein Tool, wie funktioniert das?

26:26Weil wenn du einfach abstrakt irgendwo ein neues Chatfenster aufmacht und es gibt kein Hirn sozusagen, dass irgendwie diese ganzen Informationen hat, vielleicht kommt da nicht das raus, was du haben möchtest. Und das ist für mich ganz, ganz wichtig. Und da eine Organisation zu finden, wie kriegt man halt auch diese Daten in ein System rein und... Ich bin da auch noch eher am Anfang, aber das Thema Skills ist halt etwas, was halt da ganz, ganz wichtig ist.

26:53Also man kann sich sozusagen kleine Helfer bauen mit diesen, und die nennt man Skills, und diese Skills, die können halt gewisse Informationen beherbergen sozusagen, ja. Und unter bestimmten Umständen werden diese Informationen beispielsweise abgerufen. Es können aber auch Files sein, die einfach irgendwo abgelegt sind, ja, und die dann sozusagen referenziert werden können zu bestimmten Antworten. Ja, in meinem Kontext ist es so, beispielsweise, ich habe so einen Skill, der beschreibt einfach, wie meine Brand von dieser AI Cycling Coach, wie die ist, ja, das habe ich mir auch erstellt, gemeinsam mit AI, ich glaube, ich habe damals Manus AI genutzt und habe gesagt so, hey, guck mal, gerade meine Brand Beschreibung ist folgendes, Persona und so weiter und so fort, ja.

27:43Und das alles habe ich dann in so einen Skill-File gepackt. Und dieser Skill-File ist eine Markdown-Datei, die halt in einem bestimmten Schema einfach gewisse Dinge beschreibt, wie sie sind oder wie sie zu sein haben. Du hast eben von System-Prompts gesprochen. Hey, unsere User-Story soll so und so und so aussehen. Das Ganze kann man halt auch in einen Skill verpacken, der dann halt wiederverwendbar wäre, wo man dann sagt, okay, nutze folgende, also wo man der AI sagt, nutze folgenden Skill und innerhalb dieses Skills, ist dann genau das beschrieben, wie die User-Story zu sein hat oder wie deine Brand funktioniert, wie du, weiß ich nicht, welche Development-Regeln du hast, könnte da auch drinstehen, ja, oder wie du gerne möchtest, dass Tests geschrieben werden und, und, und.

28:35Das kann man alles in so einen Skill reinpacken. Hast du viel mit Skills gearbeitet, deinem täglichen Ablauf, Vanessa? Ja und nein. Ich finde das Schwierige für mich persönlich, in die Argentic Engineering Welt reinzukommen, ist, dass auch die Begrifflichkeiten teilweise gerade erst entstehen, wie auch die Features von den AI-Firmen gebaut werden. Also ich meine, es gibt sehr viel Geld, das gerade in die AI-Welt reinfließt. Es gibt sehr hohen Konkurrenzdruck und die verschiedenen Firmen ballern Features für mich gefühlt raus.

29:16Und aus diesen schnellen Entwicklungen heraus hatte ich dann immer erstmal Angst, was ist denn so eine AgentsMD, brauche ich die, wenn ich jetzt in einem Repository mit anderen Leuten zusammenarbeite, jetzt nicht, ich bin nur in meinem eigenen Projektchen drin, hat vielleicht jemand anders schon eine AgentsMD hier reingelegt. Und wenn ich jetzt meinen Agent starte, wie ist der Agent dann das oder ist das jetzt nicht relevant? Und was sind eigentlich Skills?

29:45Skills ist für mich einer dieser Begriffe gewesen. Ich glaube, das ist was relativ Einfaches und Simples. Aber es sind halt so viele Sachen. Es sind MCPs und dann gibt es Skills und dann gibt es Agents und dann gibt es. So. Persönlich habe ich jetzt Skills sehr sparsam eingesetzt. Was einfach an der Art und Weise liegt, wie ich aktuell jetzt AI oder die Agents verwende. Ich habe für mich selber gesehen, wenn ich zu viel Kontext reinlade, zu viele MCPs sind da, zu viele, ja, wo mit MCPs hat es gar nichts zu tun, sorry.

30:20Wenn ich einfach zu viele Skills habe, ist vielleicht mein Kontext-Window einfach schon sehr befüllt und, ich und die AI und der Agent kann gar nicht mehr so auf den genauen Task fokussieren, was wir eigentlich zusammen machen wollen. Ich sehe es. Und ich muss so Sachen erst so zwei-, dreimal machen, bis ich verstehe, wofür ich jetzt den Skill bräuchte. Und ein konkretes Beispiel ist da, dass ich in einem Repository gearbeitet habe, das in verschiedenen Subleveln an Foldern oder an.

30:56Dateien andere Prettier MCs hatte oder andere ESLint Config Rules. Und wenn ich das jetzt aus dem direkten Ordner heraus, also aus dem Root-Ordner heraus getan habe, hat der Agent zwar den Code ziemlich funktionell richtig geschrieben, aber die Prettier-MC von dem Root-Folder genommen. Während, wenn ich das komplett selber geschrieben hätte, hätte ich das Problem in VS Code nicht gehabt, weil da hätte ich auf Command-Save gedrückt und die richtige Prettier-MC hätte das richtig gelintet. Stimmt, ja.

31:27Also habe ich dann einen Skill geschrieben, in dem wirklich nur drinsteht, wenn du eine Datei in dem Ordner XY bearbeitest. Und da war ich wirklich sehr explizit. Ich habe nicht geschrieben, schau immer nach, ob es da eine andere Prettier MC gibt, weil ich will jetzt ja gar nicht so aufblasen. Sondern habe geschrieben, wenn du jetzt in dem Ordner mit dem Namen XY bist, dann benutze auch die Prettier MC in dem Ordner. Weil da kommen wir an einen Punkt, wo dann eigentlich die AI unterstützen sonst sollte und dann ist man plötzlich doch wieder so, oh Gott, und jetzt habe ich ganz viele Linter-Error und die Pipeline fällt und ich muss da alles nochmal hingehen.

32:03Und wenn ich dann erst den Agents sage, ja, nee, wir haben total viele Linter-Errors, dann kann es wirklich mal länger dauern, als würde ich das manuell machen. Wenn ich dann sage, überprüfe nochmal die ganzen Dateien und lass mal den Linter laufen, da muss ich nämlich schon sehr explizit beschreiben, was genau getan werden sollte. Und solche Anweisungen schreibe ich dann in so einen kleinen Skill rein. Solche Skills muss man ja nicht selber schreiben. Da gibt es auch viele online.

32:27Ich habe jetzt generell so von Reddit-Community und so gehört, dass viele schon meinen, wenn man so viele Skills hat, dann irgendwie funktioniert es dann nicht mehr gut. Es gibt einen Skill, den ich jetzt hier benennen möchte, den ich persönlich, ich fand den erst lustig. Ich stehe ihn aber auch selber so ein bisschen skeptisch gegenüber wegen der, Formulierungen. Und das ist der Boil the Ocean Skill. Sag dir der was, Hans, bist du schon über den gelaufen? Nee, den kann ich nicht, nee.

32:55Und zwar gab es im April mal eine Phase, in denen Engineers das Gefühl hatten, dass die AIs so ein bisschen sassy werden und nicht mehr ihre Aufgaben erledigen wollen. Und es kamen wirklich Antworten wie, also ja, wir müssten jetzt die fünf Dateien dafür anfassen, aber ganz ehrlich, am einfachsten wäre, wenn wir den Bucket jetzt gar nicht fixen. Ja, das wäre jetzt meine menschliche Antwort, aber deswegen bist du ja jetzt da, damit du das für mich fixst.

33:24Und da hat jemand einen Skill geschrieben, der wirklich, dann ist es, also vergiss mal nicht, dass mit AI ja quasi alles unmöglich ist und du kannst ja alles und Zeit ist ja jetzt gar kein Ding mehr und du machst es jetzt gescheit und du hörst nicht damit auf, bis es nicht komplett fertig ist. Du testest es, du lässt es laufen, du testest es wirklich, bis es wirklich stimmt. Ich möchte keine Antwort haben, bis du nicht fertig bist. Und am Ende kann Boy the Ocean. Jetzt war ich natürlich auch so, vielleicht nicht bei The Ocean, vielleicht ganz, ganz schwieriges Thema hier in dem Sinne. Warum?

33:57Wir wollen jetzt nicht, dass Roboter uns rennen. Wir haben schon genug Erderwärmung. Wir müssen jetzt nicht noch AIs dazu bringen und sagen, dass sie den Ocean bollen sollen. Ah, okay. Now I get it. Ja, okay. Aber nicht wörtlich verstehen, bitte so. Aber es gibt da anscheinend schon ein paar Skills, die wirklich auf – also jetzt komme ich wieder zum guten und ehrlich ernsthaften Thema. Es gibt halt ein paar Skills, die wirklich den Agents sagen, Qualität ist der Fokus. Das ist kein Vibe-Coding.

34:30Wir wollen jetzt nicht einfach nur mal versuchen, wie der schnell gehen könnte. Wir wollen das so schreiben, dass wir danach auch noch modular drauf aufbauen können. Ich will nicht, dass du dich nur darauf fokussierst, diesen Buckets zu fixen mit einem Quick-Fix, sondern wir werden für die nächsten Jahre weiter an diesem Repository arbeiten. Also schreibt den Code auch so, dass er modular bleibt und skanierbar bleibt. Und dann stehen da vielleicht auch noch Beispiele drin, wie man das eigentlich macht. Ja.

34:59Ja, also ich glaube, das sind super Anwendungsfälle, die du da auch genannt hast. Und es gibt halt auch so generische Dinge, die halt vielleicht ein Anwendungsfall sein können, wie ich nehme jetzt mal was ganz einfach. Man baut eine Website und man möchte gern, dass die SEO kompatibel ist oder man möchte Accessibility testen. So und dann hat man vielleicht nicht mehr alle Regeln gerade on the top of their brain, ja, sondern du musstest halt irgendwie dann, immer alles einzeln checken, vielleicht nochmal in den Browser gehen oder so und da gibt es beispielsweise Skills, die dann einfach oder wo du einfach sagen kannst, hey, check mal mein Repository auf Accessibility und die echten Accessibility-Rules stehen dann halt innerhalb eines Skills schon drin.

35:39Genau, es gibt auch eine Website der skills.sh, die könnt ihr mal, also .sh, die könnt ihr mal aufrufen, da gibt es halt Viele Skills gelistet, über 600.000 zum jetzigen Zeitpunkt. Und der Top-Skill ist der Find-Skills-Skill. Also ein Skill, der je nach Kontext den besten Skill findet, um eine Aufgabe zu bewältigen. Aber das ist ja super. Das ist ja das, was ich meinte, wenn man zu viele Skills reinlädt, die können sich ja auch teilweise widersprechen.

36:12Und bei dem Vibe-Coding vorher war es ja auch so, dass die AI den Code so weiterschreibt, wie sie ihn halt vorfindet. Jetzt waren wir gerade bei Accessibility. Wenn jetzt also in dem Repository schon Code drin liegt, der sehr viele Diff-Elemente mit On-Clicks, hat, wird vielleicht das Model dann auch Code schreiben mit weiteren Diffs mit On-Clicks. Dann kann ich aber in den Skill reinschreiben, nee, das wollen wir so nicht mehr machen, wir wollen dafür einen nativen Button verwenden, außer es gibt einen extrem guten Grund dagegen, aber sollte es einen guten Grund dagegen geben, dann mach es nicht selbstständig, sondern dann frag mich direkt und schick mir eine Frage rein in meinem Chat-Window.

37:01Und ein Problem, was es geben kann, ist. Diese Skills könnten sich so ein bisschen widersprechen und ich glaube, so die ganze Industrie versucht noch rauszufinden, was denn wirklich so das primärste Ziel ist, was die AI immer befolgen soll und das ist wirklich das Endgoal. Ich glaube sogar, der Goal ist auch so ein Begriff gerade in der AI-Welt. Ich glaube, bei manchen Sachen, da gibt es jetzt so ein Goal und das ist dann wichtiger als der Skill oder als die Agents-MD.

37:29Aber da bin ich auch nicht tief genug drin. Das habe ich auch noch nicht so ganz durchschaut. Das geht mir genauso, ja. Aber vielleicht kann man da nochmal zusammenfassend zu den Skills sagen, es gibt halt irgendwie vorgefertigte Skills, die man reusen kann. Da sollte man mal reinlesen, was diese SkillsMD-Datei dann so beinhaltet, dass man da keinen Quatsch drinstehen hat, sondern das drinstehen hat, was man selber vielleicht gut findet. Es gibt Skillsammlungen, die halt schon super viel abbilden. Vielleicht guckt man da zuerst.

37:58Und wenn man dann aber das Problem nicht lösen kann, Dann gibt es halt Custom Skills, die man sich halt selbst schreibt und die man dann innerhalb einer AI, oder eines Gentic Tools halt reusen kann. Mittlerweile haben auch die allermeisten irgendwie ein System, sei es jetzt Gemini, sei es, ich weiß gar nicht, wie weit da jetzt ChatGPT ist, weil ich das nicht so nutze, aber Anthropic Tools und vor allem die Software Engineering Tools, nenne ich es jetzt mal, oder Gentic Engineering Tools, die haben natürlich Integrationen in irgendeiner Art und Weise, wo man halt Skills einbinden kann.

38:35Wo das Tool sich diese Skills auch merkt, wo es die Skills kennt. Man kann über die Command-Line-Skills in den .skills-Folder im User-Root packen und dann wird das automatisiert abgepickt von irgendwelchen Tools. Also guckt euch das mal an, wenn das relevant sein könnte. Wir haben das beide jetzt gesagt, wir sind da nicht super Experten, wir nutzen das jetzt noch nicht ultrativ. Vielleicht lohnt es sich da auch nochmal eine Folge zu machen, wo wir das nochmal vertiefen, aber vielleicht können wir den Skills Part jetzt nochmal so ein Stück weit upwrappen.

39:11Ich würde nämlich gerne nochmal auf das Thema Agentic Engineering Workflow sozusagen zurückkommen, das, was ich am Anfang auch schon sagte. Ich habe ja diesen Blogartikel geschrieben, From Vibe Coding to Agentic Engineering, und Vibe Coding ist für mich halt dieses Thema, hey, du möchtest irgendwie etwas bauen, indem du einen Prompt schreibst, wartest, bis das Tool fertig ist, sei es jetzt in V0, sei es jetzt irgendwie, weiß nicht, in ChatGPT selbst.

39:41Oder vielleicht doch schon Cloud-Code verwendet oder so und dann guckt man mal, wie sich das Tool verhält, was man gebaut hat und dann schreibt man noch einen Prompt, und ich glaube aber, dass dieser Weg, das haben wir jetzt schon rausgearbeitet, halt gar nicht so unbedingt der beste ist, sondern wir halt eher in so Richtung Agentic Engineering wollen. Wir haben ja eben schon gesagt, dass wir erstmal anfangen müssen im Agentic Engineering irgendwie uns so eine User Story oder Bug Description in einer Art und Weise aufzubauen.

40:10Und was mir da auch noch hilft, jetzt haben wir diesen Ausflug gemacht zu Skills, ist halt wirklich zu sagen, hatte ich ja eben auch schon gesagt, ich definiere, wie meine User Story aussehen soll und was sozusagen die ganzen Informationen sind, die halt wichtig sind. Welchen Kontext brauche ich, damit ich eine gute User-Story erstellen kann? Habe ich bestimmte Personas? Also wie sehen meine User aus? Ich möchte eine detaillierte, funktionelle Beschreibung machen.

40:42Also was sind meine Functional Requirements, meine Non-Functional Requirements? Das kann man alles auslagern in Skills. Was sind vielleicht Edge-Cases, die ich bedacht haben möchte? Oder ich frage einfach die AI, hey, kannst du mir mal die Edge-Cases bedenken? Und dann nehme ich das mit auf, um meine User-Story am Ende, die halt irgendwie so durch den Chat rauskommt, zu beschreiben. Und was sind halt Acceptance-Criteria, damit man am Ende auch sagen kann, hier ist eine coole User-Story.

41:11Und das ist sozusagen mein Blueprint, den ich halt mitgeben kann, um dann in eine Exploration zu starten von einer UI beispielsweise. Was ich da häufig mache, ist, ich verwende ein Tool, ich selbst häufig wie Zero, wo ich dann sage, okay, hier ist mein Repository und dieses Repository nehme ich dann als Basis und da kommt wieder so ein Stück weit dieses Vibe-Coding dann durch. Ich nehme nämlich die beschriebene User-Story, die ich vorher erzeugt habe, packe die beispielsweise in eine Markdown-Datei oder kopiere sie einfach rein.

41:45In das Chat-Window und sage dann der AI, hey, baue mir das mal. Und was ich häufig mache, ist, ich mache beispielsweise Screenshots von anderen Tools, wo mir ein ähnliches Feature gut gefällt oder wo ich sage, so in die Richtung soll es ungefähr gehen. Oder was ich auch noch anhänge häufig, ist, hey, das ist übrigens mein Branding, was ich normalerweise verwende, beispielsweise einfach als Screenshot oder ich pointe zu einer bestimmten Datei.

42:12Genau, wenn ich irgendwelche Layout-Constraints habe, packe ich das mit dazu, und dann geht es eigentlich wieder an Swipe-Coding, nämlich um schnell zu iterieren, das mache ich ganz häufig, versuche ich dieses Feature, was ich dann implementiere, halt wirklich mal von so einer AI entwickeln zu lassen, um dann zu sagen, okay, das möchte ich geändert haben, hier möchte ich was geändert haben. Und das ist häufig mein Ausgangspunkt, um dann zu sagen, jetzt gehe ich den echten Schritt, jetzt wo ich weiß, wie das ungefähr aussehen soll.

42:44Und das ist ja auch eine total tolle Arbeit, die man beispielsweise mit so UX-Menschen zusammen machen kann, wo man sich vielleicht nebeneinander setzt und sagt so, hey, guck mal, jetzt sieht das gerade so aus. Wie wollen wir es denn machen, ja, anstatt das halt in einem Figma zu machen, machst du es vielleicht in einem V0 oder vielleicht in deiner eigenen Codebase geht natürlich auch, ja, und da muss man sich dann überlegen, welche Modelle verwendet man halt um diesen Code aufzubauen initial, und was ich dann mache ist, Der Code, der erzeugt wurde, at the time of writing, es ist jetzt fast auch schon wieder zwei Monate her.

43:24Zweieinhalb, hat sich halt auch schon wieder einiges geändert in der Zeit. Ist es zweieinhalb Monate oder zwei Monate her? Es hat sich wieder einiges geändert und mittlerweile habe ich auch schon wieder meinen Shift ganz stark nach Cursor verlagert, weil Cursor halt super schnell ist mit den neuen Modellen. Die haben immer das neueste Modell, wenn es erscheint. Man kriegt häufig sogar Reductions in Pricing, wenn man halt ein neues Modell verwendet. Und das ist halt ganz cool, um Sachen auszutesten.

43:54Von daher kann man diese UI-Exploration meiner Meinung nach halt auch beispielsweise mit Cursor oder anderen Tools machen. Und dann kommt es aber zur Integration. Ja, das hängt ja wirklich auch darauf ab, was man jetzt privat nutzen möchte, zahlen möchte, was man auf der Arbeit verwendet. Es gibt jetzt auch, ich bin eher so ein bisschen im Cloud-Universum unterwegs, da gibt es jetzt auch Cloud-Figma. Aber genau bei uns, und das würde ich versuchen, alles gar nicht zu überdenken.

44:19Wir könnten jetzt auch irgendwie designt schon mal ein Cloud-Figma vorbereiten. Oder ich treffe mich mit meinen UX-Designern und bekomme da quasi so was Vibe-Gecodetes, auf das wir dann, das wird jetzt natürlich niemals gemerkt. Das ist schon klar. Aber wo man halt diese Diskussionsgrundlage hat. Was ich gerade noch dazu sagen wollte, zu den Tools, ob es jetzt Cursor, Codex, Cloud Code ist. Der Unterschied für mich von so ein bisschen UX-Verhalten von den verschiedenen Tools abgesehen, ist die Art und Weise, wie man Prompts schreibt.

44:52Was ich mich mal reingelesen habe, auch durch mehrere Reddits-Threads, ist, dass bei Codex musst du, oder bei, was sind denn die GPT-Modelle? Ich komme selber schon durcheinander. Codex ist GPT, ja. Ja, danke. Da musst du die Prompts relativ konkret schreiben. Und so ein bisschen, wie würde man das eben einem Junior-Developer so erklären? Du machst genau diesen Schritt, dann machst du diesen Schritt und dann bekommst du auch relativ gute Ergebnisse, wo man nicht mehr so viel iterieren muss.

45:25Und bei Claude kann man das relativ gut, also bei Opus zum Beispiel, bei den Modellen, da ist Son & Opus heißen die, kann man das relativ gut verwenden. Wenn man noch nicht so genau weiß, wie man das eigentlich im Code, in den Dateien anfassen muss, sondern man auch eher nur erst so den Intent hat. Also irgendwie glaube ich, ich muss hier was auf der Seite ändern. Ich weiß aber gar nicht, wo meine Komponente eigentlich dabei ist. Ich weiß nicht mal, welche Datei das ist. findet es auch mal selber raus.

45:56Und dann hat man bei Gesprächen mit Claude so ein Verhalten, dass da sehr viele Rückfragen kommen, dass wenn Codex-Leute das mal benutzen, wieso werde ich hier so viele Sachen gefragt? Ich will mal ein Ergebnis sehen. Aber durch diese ganzen Rückfragen kommt man dann irgendwann dahin, dass Claude verstanden hat, was es eigentlich zu tun gibt und es dann auch tatsächlich im Code umsetzen möchte. Und wenn man keine Lust hat, sich Gedanken zu machen, will man in Claude Code, also Opus Sonnet 4.8 jetzt neuerdings dann.

46:29Irgendwie sein Reasoning betreiben oder möchte man das im neuesten Max-Modell von Codex GPT machen oder, oder, oder kann man auch beispielsweise den Auto-Mode bei Cursor verwenden. Und was Cursor halt auch hat, ist halt so ein Planning-Feature. Und das ist halt etwas, da kommen wir jetzt zum nächsten Punkt, nämlich, das ist genau etwas, was ich ganz stark verwende, ja, wo ich sage, okay, bevor ich jetzt weitergehe, ich habe jetzt meine Iterationen der User-Story gemacht, ich habe jetzt, meine Iterationen im UI gemacht, ich weiß grob, wie das aussehen soll, wie sich das zusammensetzt, habe auch schon mal einen ersten Code.

47:11Aber vielleicht hat der noch gar nicht alles bedacht, was eigentlich bedacht werden muss innerhalb meines komplexen Projekts. Da lagen vielleicht die Skills noch gar nicht drunter, weil es war ja eine Ideation-Phase sozusagen oder eine Exploration-Discovery-Phase, sagt man wahrscheinlich, im Produktdevelopment. So, und da hilft mir dieser Planning-Mode total. Der Planning-Mode, der beschreibt bei Cursor eigentlich, also im Endeffekt wird da eine Markdown-Datei erzeugt, die sagt, was alles gemacht wird und wo diese Änderungen stattfinden und je nachdem, mit welchem Modell man den erzeugt.

47:49Diesen Plan kommen dann natürlich andere Dinge raus. Im Endeffekt ist das aber super zu validieren, ist es das Richtige, genau das, was du möchtest. Und häufig nehme ich dann halt entweder Screenshots oder schon fertigen Code und die User Story und so weiter und so fort, packe das alles zusammen und sage dann, hey, generiere mir mal einen Plan, dann lese ich den Plan durch. Und das ist halt super wichtig, halt dieses Human in the Loop, Review von dem, was die AI jetzt machen soll.

48:18Und dann habe ich einen sehr, sehr konkreten Plan beispielsweise, um etwas zu implementieren. Ich hatte da schon Beispiele, wo ich gesagt habe, hey, bau mir das doch mal so und so, habe das vielleicht nicht richtig spezifiziert und der Plan, Da wäre jetzt was ganz anderes bei rausgekommen, weil ein Begriff halt doppeldeutig sein konnte, ja, also es gibt halt kein Glossary und dann, ich weiß gar nicht mehr, was es genau war, in jedem Fall wurde dann halt an einer Stelle, das.

48:44Wäre das gebaut worden, was ich an einer ganz anderen Stelle hätte haben wollen, so, ja, und, das kann man dann halt spezifizieren, bevor irgendwas gebaut wird, weil wenn dann auf einmal ein Code erzeugt wird, keine Ahnung, 20 Files wurden geändert, hier wurden Dinge gemacht und dann guckst du, klickst du durch und ach, das war ja das gar nicht. Aber stimmt, hier drüben ist ja die Funktionalität. Dann sagst du, hey, bring die da rüber, dann funktioniert wieder irgendwas nicht.

49:08Und das alles kann man vermeiden, indem man halt gut plant. Planung ist das halbe Leben. Im Scrum damals, wer erinnert sich noch, da war das ja auch so, dass man gesagt hat, so ey, 10% deiner Zeit solltest du bitte auf deinen Planungsprozess verwenden. Wir sitzen in Refinements zusammen. Macht das bitte auch mit AI. Habt Refinements mit AI. Das ist genau in diesem Moment euer Job, diese richtige Orchestrierung dessen, was passiert. Und das finde ich halt einen super wichtigen Schritt. Und wenn ich dann confident bin und sage, yo, der Plan, der passt, manchmal lege ich dann den einfach auch nochmal auf Halde, weil ich den jetzt noch gar nicht machen möchte.

49:50Und dann sage ich einfach, okay, lass den Plan mal da liegen und dann komme ich halt eine Woche später wieder zu diesem Plan zurück, lese es nochmal durch. Oder habe es nochmal mit jemandem durchgesprochen oder einen neuen Use Case, passe den Plan an und sage, bring den doch nochmal auf das neueste Level von dem, wie mein Code gerade ist. Und dann gibt es einen Build-Button und dann wechselt es wieder in Agent-Mode und man kann halt einfach die Implementierung sich dann angucken.

50:15Und ich sage mal so, eine Sache, die ich zuletzt habe machen lassen für meinen AI-Agent ist, ich habe eine Web-App und ich möchte gerne eine iOS-App erzeugen mittelfristig. So, das bedeutet, mein Web-Projekt muss sich nochmal ein bisschen verändern. Und es muss halt auch noch ein iOS-Projekt parallel passieren. So, und dafür gibt es natürlich einen super elaborierten Plan, wie das aussehen soll. Da soll noch eine Apple Health Integration mit rein und sowas.

50:42Und da kommen halt am Ende 4531 Editions und 262. Deletions hinzu, ja, und 115 Files. Und das muss ich jetzt natürlich, und dann kommen wir da wieder zum nächsten Schritt, reviewen. Ich kann jetzt nicht einfach sagen, accept all und bam, fertig. Also kann ich schon, aber die Gefahr, dass doch irgendwas bricht, die empfinde ich persönlich noch zu hoch. Wir sind mittlerweile bei den Models echt super weit. Aber das Coole ist. So ein Agent, der sagt mir dann halt auch, wie ich das testen kann.

51:16Der baut da Tests ein, der testet schon mal vielleicht auch selbst und man kann auch instructen, noch mehr zu testen oder End-to-End-Tests zu bauen oder sowas. Aber was mir halt super wichtig ist, ist, wie teste ich das Ganze und dann bekomme ich halt einen coolen Abriss davon und dann gucke ich nicht jeden Pfeil logischerweise jetzt durch und akzeptiere auch einfach viel von dem Code. Aber ich kann mir die Punkte angucken, die halt vielleicht problematisch werden könnten und kann die auch automatisiert testen lassen.

51:46Und das ist halt dann das Nächste. Aber, und jetzt um den Wrap-Up noch zu schaffen, nochmal, dieser ganz, ganz wichtige Review ist sozusagen der Systems Design Review, nämlich wenn du den Plan machst. Ja, wenn du überlegst, wie soll jetzt der Agent etwas implementieren? Zum Beispiel gibt es in diesem Plan-Mode auch ganz häufig halt die irgendwelche, Charts drin. So wird deine Software-Architektur dann aussehen. Wenn man da etwas sieht, okay, das funktioniert so nicht, dann sagt man halt, hey, mach das ein bisschen anders.

52:20Und das, finde ich, ist halt ein super, super wichtiger Punkt, den wir als Software-Engineere halt haben mittlerweile, um zu sagen, okay, so beeinflusse ich, wie der Code erzeugt wird. Nicht nur, wie der Code erzeugt wird, sondern es ist ja auch essentiell, um die Kosten geringer zu halten. Ich glaube, es gab da mal Statistiken, wie viele Pull-Requests geöffnet werden von AI-generierten Code und aber komplett wieder geschlossen werden. Also gar nicht mal in dem Sinne, ich gehe da nochmal rein und ich sage, nee, das ändern, das ändern, weil dann kann es vermehrt anscheinend zu Fehlern kommen, sondern dass man hingeht und sagt, nee, wir müssen nochmal von ganz vorne anfangen. Eigentlich meinte ich dies und das.

53:03Aber in diesem Prozess wurde vielleicht schon mal ein Branch geöffnet, der wurde auf Origin gepusht, es wurde vielleicht den Merge-Request-Pull-Request geöffnet, vielleicht hat sogar ein Human-Reviewer drüber geschaut oder ein Reviewer-Agent hat Tokens ausgegeben, um drüber zu schauen. Nur, dass man dann irgendwann, indem man Code liest, feststellt, oh, das wollten wir in dem Sinne eigentlich gar nicht. Und das wollen wir jetzt verhindern. Also gibt es jetzt diesen Planmodus. Ich selber verwende eben fast gerne für den Planmodus manchmal ein teureres Model und ein Code kann ich dann mit einem günstigen Model generieren lassen. Ja.

53:40Und ich bin da auch schon in die Falle reingetappt, dass ich manchmal einfach ganz super Pläne hatte und dann hatte ich mal einen Plan. Und ich so, ja, ja, wird schon passen, approve, implementiert das. Und dann so, nee, nee, Quatsch, wieso habe ich das nicht durchgelesen, jetzt nochmal durchgelesen sollen. Weil ich so sehr schnell auch angefangen habe, komplexere Intents reinzugeben. An dieser Stelle möchte ich aber mal auch anbringen, dass wenn ich jetzt nicht in dem Modus bin von, ich kann mir jetzt mit einer AI Designs generieren lassen und gebe dann Screenshots rein und lasse die so entwickeln.

54:14Sondern wenn ich wirklich in der bestehenden Codebase bin und mich an Regeln halten muss, beziehungsweise UI-Komponenten verwenden muss, die vielleicht in der Codebase auch jetzt nicht so ganz offensichtlich sind, da sehe ich für mich immer noch die größten Schwächen, wenn ich, plane oder wenn ich den Code generieren lasse mit AI, wenn es wirklich an CSS-Klassen geht, wenn es an Designänderungen geht, wenn ich sagen möchte, ich möchte hier eine Button-Group haben, muss ich irgendwie noch erklären, was ist denn jetzt eigentlich eine Button-Group und haben wir die schon?

54:44Und wir haben eigentlich fünf davon in der Codebase, aber ich möchte diese eine spezielle. Und das ist das, wo ich aktuell noch überlege, wie wir da das verbessern können. Das sind dann oft, wenn ich ein Beispiel sehe. Wie ich möchte, dass man jetzt eine Tabelle, eine Table, horizontal und vertikal scrollen kann. Dann gibt es ja die Möglichkeit auch, dass ich einfach nur die Table Headers, Position Fixed mache und dann scrolle ich drunter weg.

55:14Das funktioniert aber in manchen Bereichen auch nicht gut. Wenn ich einfach schon drei Fixed Table Headers auf der Seite habe, dann kann ich nicht noch einen Fixed Header haben. Oder ich möchte den Effekt vielleicht ändern, dass ich auch links und rechts auf der ganzen Seite dann scrollen kann. Dann kann ich das alles relativ gut erklären und im Wildcoding-Modus mir mal ein POC generieren lassen und der wird funktionieren, manchmal auch mit CSS-only.

55:38Dann sage ich aber, ich möchte das jetzt auf diesem bestehenden Projekt einsetzen. Und CSS funktioniert nun mal so, dass es ja global ist und vererbt wird. Das ist jetzt schon teilweise anders als bei Skriptsprachen. Und dann ist aber halt da oben irgendwie in einem Position sonst was dabei, dass irgendwie die Lösung, die ich davor gewaltcoded hatte, komplett unmöglich macht. Und hier finde ich es weiterhin sehr schwer, dann auch mit AI da reinzugehen und zu sagen, was ist eine bessere Lösung, was können wir denn dann machen?

56:07Was mir nochmal zeigt, wie unfassbar komplex halt nun mal Frontend und CSS-Arbeit ist und dass man da nicht einfach das ganze Internet mal durchforsten kann nach der perfekten Lösung, weil es sehr, sehr individuelle Lösungen oft sind. Die Use Cases, wo es wirklich richtig gut funktioniert, ist, wenn ich ein paar Features habe, und vielleicht sind drei davon hinter einem Feature-Fleck und ich möchte das aber so ein bisschen umstellen im Code und sagen, okay, wir möchten das nur noch hinter zwei Feature-Flecks und das ist so ein bisschen Gruntwork, so ein bisschen, wir möchten diese Feature-Flecks vereinfachen und die beiden Features sollen jetzt in dem Feature-Fleck laufen und die zwei Features in dem Feature-Fleck.

56:44Und da muss ich jetzt nicht mehr selber reingehen und die Code-Zeilen selber so picken und hinzufügen, Sondern da kann ich wirklich sagen. Teste das mal aus, schreib das mal um. Und diese Sachen, die funktionieren wirklich wiederum sehr gut, die wirklich sehr skriptbasiert sind oder wo ich Dateien oder Zeilen umherschiften muss. Und ich habe es versucht mit Tools wie Playwright-MCPs oder auch Skills, das gibt es beides, dass ich sage, ich möchte, dass es so ausschaut.

57:14Hier ist mein Screenshot. Übrigens nur hier noch dazu gesagt, es funktioniert oft ganz gut, dass ich mehrere Screenshots mit reingeben kann. Was ich bei meinen Tools aktuell nicht verwenden kann, ist, dass ich einen Recording, Video Recording, Screen Recording reingeben kann, so wirklich nur Screenshots. Und dann sage ich, und jetzt verwende mal Playwright, mache einen Screenshot davon und schaue, ob das genauso ausschaut. Da beginnen schon die Schwierigkeiten, wie wenn das jetzt bei Page Load nicht vorhanden ist, sondern wenn ich einen Flow durchklicken muss, mich erstmal einloggen muss, um da hinzukommen.

57:45Das ist ein Prozess, der sehr teuer und sehr langwierig werden kann. Da bin ich immer noch auf der Suche nach besseren Lösungen. Da bin ich noch sehr viel am manuell selber die CSS-Klassen testen, im Browser testen und dann rüber kopieren zum VS Code. Ja, wobei ich mir überlege, ist halt das halt auch noch der zukünftige Workflow, weil, also jetzt so der klassische Vergleich ist, du kriegst irgendein Design von jemandem, der ist ein Designer, sagt, das Modul soll so und so aussehen und man muss es dann integrieren.

58:19So und ich fand das, also vor zehn Jahren haben wir schon gesagt, so ey, irgendwie ist das nicht so cool, ein Design so sequenziell abzuarbeiten, sondern gerade mit mobilen Endgeräten und so mussten wir uns halt dann auch Gedanken machen, responsive Design mussten wir uns Gedanken machen, wie kriegen wir es denn eigentlich hin, dass so ein Modul immer funktioniert und dann haben Designer adapted und haben gesagt, okay, wir kriegen das auch hin und die Tools haben nachgezogen und so.

58:44Also, aber im Idealfall sitzt man doch irgendwie zusammen und kriegt es dann gemeinsam hin. Und das, finde ich, ist halt so cool, dass man halt dann sagen kann, okay, komm, wir Vibe-Coden uns mal den Weg dahin. Und wenn wir dann ungefähr das haben, dann kommen halt diese neuen Probleme, wie du eben mit der Tabelle gesagt hast. Und da muss man vielleicht nochmal einen Schritt zurückgehen, dass das dann halt noch nicht genauso funktioniert, wie das im Vibe-Coding war.

59:07Aber grundsätzlich habe ich das Gefühl, dass man halt auch diesen Workflow mit Design zusammen viel vereinfachen kann. Also, dass es halt viel schneller geht, auch da Iterationen zu schaffen. Und das finde ich halt. Ja, grundsätzlich interessant. Was aber du ja auch angesprochen hast, ist das Thema Testing, ja, beispielsweise Playwright. Wie schafft man es, ja, End-to-End-Tests an den Start zu bekommen? Lokal ist das eine Sache, aber das dann halt auch noch gescheit hinzubekommen, in der CI, das ist halt eine andere Sache.

59:45Das habe ich jetzt auch gerade, wo ich einfach nicht zu Potte komme, wo ich einfach nicht mit dem Token Handling nicht irgendwie Lust hatte, mich ausreichend auseinanderzusetzen und da ist halt die AI auch nicht gut drin, das einem abzunehmen häufig. Ja, also zu sagen, okay, das läuft bei mir in der GitHub. Als GitHub Action, bau das mal so, dass diese ganzen Sachen da einfach funktionieren und dann macht er dir einen Vorschlag, hier, mach doch mal da einen Service-User, ja, leg mir den nochmal an, kann ich leider nicht und so und dann kommt man schnell an so Grenzen, wo man da doch wieder viel manuelle Arbeit hat, aber das Ganze davor ist halt so viel besser geworden.

1:00:24Und ich glaube, was man halt nicht vernachlässigen darf, ich glaube, die Arbeit, die wir dadurch machen, wird qualitativ einfach viel, viel besser, als sie früher war. Früher haben wir in User Stories immer alle Use Cases irgendwie durcheinander geworfen, haben so viele Sachen vergessen, wir mussten so viel iterieren und darüber sprechen, weil Dinge nicht funktioniert haben. Heute können wir halt viel mehr on point das formulieren. Also können heißt nicht, dass das immer so ist, aber die AI ist da einfach besser drin als wir Menschen. Und ich glaube, das ist halt ganz, ganz wichtig.

1:00:59Und schreibt mir da auch gerne, wenn ihr das anders seht. Ich glaube, die AI ist, jede Maschine ist viel besser darin als Menschen, Dinge von A bis Z zu bedenken. Und das sehen wir auch, wenn man mal überlegt, wie sich AIs im letzten Jahr, in den letzten zwei Jahren weiterentwickelt haben, wie die Modelle sich entwickelt haben. Fünf Jahre von heute werden Modelle uns halt crazy outperformen. Das tun sie heute schon an verschiedenen Stellen, aber gerade im Software Engineering.

1:01:27Und ich glaube, es ist ganz, ganz wichtig, das halt nicht außer Acht zu lassen. Ja, das birgt Gefahren. Ja, wir müssen Riegel da grundsätzlich bei AI irgendwo davor schieben. Das ist aber eine andere Diskussion. Und ich glaube, wenn wir uns im Software Engineering halt da auf die guten Seiten fokussieren und sagen, okay, wie können wir unsere Arbeit besser machen mit AI, dann ist das gerade trivial. Ja, das ist halt wirklich easy für uns zu tun.

1:01:55Und deswegen möchte ich dafür werben, dass wir alle uns damit halt gut auseinandersetzen so. Das war eine schöne Endrede. Da habe ich gar nichts weiteres dazu zu sagen. Ich wollte nur den einen Punkt aufbringen. AIs sind ja vor allem darin sehr gut zu lesen. Und etwas, wo ich das zuvor unterschätzt hatte, was ich jetzt tun kann, ist das Aufsetzen von bestimmten Projekten oder Setups oder Tooling. Wie, ich muss jetzt was von meinem lokalen Development-Server zum Laufen bringen und dafür brauche ich auf einmal Docker.

1:02:33Die AI lädt mir jetzt nicht Docker runter, das ist gar nicht der Punkt. Aber es gibt eine sehr, sehr lange Dokumentation, wie ich was Bestimmtes aussetzen kann, damit es lokal auch läuft. Das sind Begrifflichkeiten, die mir dann vielleicht nicht ganz so viel sagen. Dann kommt da irgendwas mit Engine X und da muss ich was in meiner Env-Datei ändern. Und vielleicht wurde das auch schon mal auf Slack besprochen, weil da jemand mal gefragt hat, ah, jetzt habe ich die Fehlermeldung, was mache ich da jetzt?

1:02:57Und das war tatsächlich hin und wieder mal. Also alle paar Monate ist mal sowas passiert, wo ich gedacht habe, oh Gott, jetzt habe ich hier zwei, drei Tage damit verwendet, irgendwie das einfach nur lokal aufzusetzen. Das hat mir schon zweimal wirklich viel Zeit gerettet, indem ich halt tatsächlich in OpenCode reingegangen bin und gesagt habe, also ich muss da jetzt lokal was aussetzen, damit ich dann irgendwie mit XY-Repository sprechen kann und mit dem Server und auf dem Staging-Ding und ich habe keine Ahnung, worum es geht.

1:03:23Und aus den verschiedenen Dokumentationen die richtigen, aktuellen. News rauszukriegen, um mir das tatsächlich auf meinem Rechner aufzusetzen, wofür es Rechte hatte und mir dann Bescheid zu sagen, du musst jetzt mal noch an deine Env-Datei gehen und deinen Anthropic-Key hier hinzufügen, damit du das machen kannst. Und da fand ich es wirklich toll. Also ich wollte gerade noch dazu sagen, AI im Engineering heißt jetzt nicht unbedingt nur Code generieren, sondern ich kann mir vielleicht auch wirklich das Projekt in dem Sinne einfacher aussetzen lassen.

1:03:56Ja, das ist ein Megapunkt. Also genau, all diese Arbeit drumherum. Ich glaube, im Engineering ist ja häufig auch, Informationen zusammensuchen ist ja auch so ein Problem, was man hat. Gerade wenn man mit vielen Menschen zusammen arbeitet, so, Sich dabei unterstützen lassen, automatisiert Fragen rausschicken lassen, Reminder rausschicken lassen. Das kann halt alles die AI. Man muss sich damit ein bisschen auseinandersetzen. Und ich glaube, das ist aber halt das, wo es bei einigen Leuten auch scheitert.

1:04:30Die sagen, ja, ich höre das immer, aber keine Ahnung, wo ich da jetzt anfangen soll. So und ich glaube, es ist es halt total wert, einmal diese Lernkurve zu machen und einmal zu sagen, okay, ich setze mich mal damit auseinander. Wie funktioniert es denn, Skills zu nutzen? Was ist dieses MCP-Thema? Und wenn man das halt einmal gemacht hat, wie connecte ich meinen Notion, GitLab, Slack, whatever in meinen Cursor? Cloud-Code oder wie auch immer rein, ja, wenn man das einmal gemacht hat, ich glaube, dann steht man halt ganz gut da und kann halt sehr, sehr viel und kann sehr viel auch von A nach B schieben.

1:05:13Und ein Punkt, einen anderen Punkt, den ich vielleicht noch machen wollen würde, ist so, wir haben vorhin über Kosten gesprochen, ja, AIs sind unheimlich teuer, ich gebe zu viel Geld für die Sachen aus. Ich glaube, man muss auch immer gucken, wo entwickelt sich welches Tool weiter und wo braucht man wirklich welche Subscription? Ja, ich habe auch schon wieder gerade das Gefühl, ich habe so drei Subscriptions, und ganz viel von diesen drei Subscriptions, oder bei einem Tool war jetzt meine Subscription weggefallen und dann dachte ich, oh nein, wie mache ich denn das jetzt?

1:05:45Aber manchmal muss man einfach mal in die anderen Tools reingucken und dann haben die sich so weiterentwickelt, dass du diese Subscription gar nicht mehr brauchst, weil halt dein anderes Tool genau das gleiche auch schon kann. Und ich glaube da, genau Genau, da muss man sich halt immer mit auseinandersetzen. Wenn man jetzt in einer Company arbeitet, ist das vielleicht gar nicht so der Job, dass man sich mit sowas auseinandersetzt, aber ich jetzt persönlich, der ich gerade als Selbstständiger und jemand, der halt so als Founder arbeitet, gerade gucken muss, wo gebe ich eigentlich wie viel Geld aus.

1:06:15Und bei großen Tasks, ich habe iOS App Schreiben ja mal angesprochen, da hat man ja schnell mal ein paar Tokens, die man verbraucht und rucki zucki muss man in den höheren Tarif wechseln, weil On Demand macht einfach keinen Sinn. Haben wir in einer anderen Sendung glaube ich auch schon mal drüber gesprochen, so und das ist halt etwas, wo man sich halt dann einfach, immer mal wieder mit auseinandersetzen muss und auf einmal hat man eine neue Aufgabe und ich glaube diese Weiterentwicklung des Jobs, die sollten wir halt mitmachen wir sollten halt.

1:06:44Im Software Engineering halt auch hingehen und sagen, okay, da gibt es halt jetzt neue Dinge. Es gibt ein anderes Skillset, eine andere Anforderung an meinen Beruf, als das vor drei Jahren war. Und die Leute, die sagen, ja, aber warum, das gibt es ja in anderen Jobs, gab es das ja auch nicht oder so. Auch Ärzte mussten sich immer schon fortbilden, immer weiterentwickeln. Und wenn sie an diesem Punkt stehen geblieben sind oder das Recht hat sich auch weiterentwickelt, nehmen wir Juristinnen und Juristen. Die mussten sich auch immer fortbilden, die mussten immer das neueste Wissen haben und so weiter.

1:07:14Und das ist halt beim Software Engineering auch so. Und ich finde, es macht halt keinen Sinn zu sagen, ja, das ist ja eine ganz andere Profession und jetzt muss ich mich auf einmal damit irgendwie mit ganz anderen Sachen und auf einmal schreibe ich nicht mehr diese und jene CSS-Zeile. Ja, so what? It's your job. Du schreibst ja auch kein CSS mehr für IE6 oder für Netscape, weil das war halt irgendwann nicht mehr notwendig. Und dieses Wissen, wie man dann einen Hack in nur IE6 ausspielt, ist halt verfallen.

1:07:47Und so ist es halt bei anderen Sachen auch. Und ich glaube, das muss man sich halt vor Augen führen. Und da muss man halt wirklich sich auch reinknien und weiterentwickeln und das haben wir früher immer gefordert von allen Leuten, die halt irgendwie in unseren Teams waren. Ich hatte zumindest das Gefühl, dass das so ist. So wollte ich nur einmal nochmal loswerden, weil ich so. Manchmal so ein bisschen sehr negative Vibes so in dem Kontext verspüre, dass alle irgendwie die AI verfluchen und sagen, ich will aber meinen Job so machen, wie ich meinen Job mache. Ich glaube, das bringt uns halt nicht voran.

1:08:20Von Firmenseite, also wirklich von der ganzen Organisation aus. Und dann hoffe ich immer, dass das in jeder Firma dann aber auch gut abläuft. Es gibt halt neue Probleme. Und wir sind ja generell, gerade bei GitLab ist ja sehr viel so positive intent und action for bias. Und wir versuchen auch die Zeit von unseren Kollegen, Kolleginnen immer sehr wertzuschätzen. Aber durch die AIs kommen wir auch an einen Zustand mal hin, dass es mehr Code-to-Reviewing gibt als vorher.

1:08:51Auch von unseren Produkt-Designern, auch von unseren Produkt-Managern. Aber wir stehen da jetzt erstmal positiv dem gegenüber. Die neuen Probleme, die entstehen, ist, ich hatte letztens angebracht, ach guck mal, hier ist irgendwie ein Wort kleingeschrieben, das müsste doch großgeschrieben sein. Und ich dachte mir schon, dass es ganz komische technische Gründe jetzt dafür gibt, dass da nicht einfach nur jemand in einen Translation-Fall reingehen muss und da was hochkapitalisen muss.

1:09:15Und da hat mein PM so ganz selbstständig so, guck mal, ich habe hier so ein Ruby-Code, kannst du review? Und dann ist er so, ich will so, ich will so, ich will so, aber habe gemerkt, dass jetzt halt nur genau dieses explizite Problem gelöst wurde, dass dieses eine Wort geuppercased wurde, beziehungsweise nicht nur dieses eine Wort, sondern jedes Wort wurde jetzt da capitalized. Aber das wollte ich jetzt da auch nicht. Das heißt, beim Review muss ich jetzt auch darauf achten. Ich finde aber, das war was, was ich schon immer fand, dass jeder, der Code Reviewed, nicht nur den Code reviewen sollte, sondern auch den.

1:09:46Also heutzutage ist eigentlich Intent dahinter. Früher hätte ich gesagt, sondern das Feature dahinter. Und dann haben wir das aber auch schon wirklich vor Wochen, vor Monaten wahrscheinlich schon besprochen. Wie gehen wir mit der Situation um? Müssen wir da mal einen Stopp sagen, wenn wir plötzlich merken, wir kriegen doppelt so viele Code-Reviews pro Tag rein? Ist die Qualität gut genug oder müssen wir ständig alles recheckten, weil wir sehen, das ist noch zu sehr Vibe-gecodet?

1:10:09Aber das ist halt, wie gesagt, so ein Organisationsding. Das ist eine neue Aufgabe, die kann man aber durchaus lösen. Ich hocke aktuell nicht da und muss gefühlt ständig so viel reviewen, was ich dann rejecten muss. Irgendwie haben wir das geschafft. Ich habe jetzt die Lösung, kann ich jetzt nicht so in zwei Sätzen noch sagen. Ich weiß sie auch gar nicht so genau. Es waren halt so viele Kleinigkeiten, die da reinkommen, wie zum Beispiel, dass sogar die AI zuerst nochmal reviewed, bevor man es da gehen kann, dass natürlich die Pipelines durchlaufen und so weiter und so fort.

1:10:39Es kommen neue Aufgaben hinzu, wollte ich sagen. Und man muss ihnen so ein bisschen positiv gegenübertreten und sie dann aber auch bewusst lösen. Definitiv, ja. Also große neue Aufgaben vor uns, vielleicht, um jetzt den Deckel drauf zu machen, Dinge, die sich verändern. Ich fände es super spannend, auch nochmal Use Cases vielleicht von Hörerinnen und Hörern zu hören. Vielleicht habt ihr irgendwie bei euch in der Company auch, AI jetzt für Coding eingeführt. Wie macht ihr das? Fände ich super spannend.

1:11:09Vielleicht habt ihr ja mal Lust, hier auch Gast zu sein und dann können wir da mal drüber sprechen. Ich glaube, wir sind alle viel am Exploren. Und je mehr wir da teilen, desto besser ist es, desto mehr lernt man voneinander. Von daher, schreibt uns doch einfach mal, wenn ihr Lust habt. Würde mich auf jeden Fall sehr freuen. Und danke, Vanessa, für den Austausch. Ich finde es sehr spannend, immer wieder in diese ganzen Themen reinzugucken und auch mal zu hören, wie läuft es eigentlich bei einer Riesenorganisation wie eurer.

1:11:36Genau, wir versuchen alles in den Shownotes zu verlinken. Wir hoffen, dass das in einem Monat noch aktuell ist und dass nicht die Skills HSH schon von der neuen Skills-Seite erneuert wurde. Ansonsten, Hans, vielen Dank, dass du mit deinem Blogartikel und der Idee generell gekommen bist. Hat mir sehr viel Spaß gemacht. Dann machen wir den Deckel drauf und hören uns wieder nächste Woche. Ciao, ciao. Ciao.