Mit Coding Agents arbeiten: Was im Projektalltag funktioniert und was nicht (Sebastian Springer)

Sebastian Aber das ist tatsächlich genau der Punkt, der mich auch immer stresst. Und ich bin ein sehr ungeduldiger Mensch. Ich mache dann auch immer Sachen parallel. Und blöderweise kommen die dann immer gleichzeitig zurück. Und dann hast du drei Häufchen Arbeit auf dem Tisch liegen oder fünf Häufchen Arbeit auf dem Tisch liegen, zwischen denen du hin und her switchen musst. Und ganz ehrlich, das stresst mich unheimlich, weil die Agenten, die sitzen um mich rum und warten auf Input. Und ich bin dann der Flaschenhals, der alles langsam macht.

Hendrik Zum Abschluss des heutigen Konferenztages geht es nochmal um vielleicht die wichtigste Frage, nämlich, was funktioniert mit Coding Agents eigentlich wirklich und was nicht? Denn seien wir jetzt mal ehrlich, die meisten Demos, die zeigen ja perfekte Welten, saubere Code-Basen, klare Anforderungen, Agents, die wie von Zauberhand komplexe Features implementieren. Aber die Realität, das haben wir auch heute schon gehört, die sieht dann schon mal auch anders aus. Echte Projekte mit gewachsenen Strukturen, unklaren Requirements, KI-Tools, die manchmal genial sind und manchmal auch völlig daneben liegen. Wann also kann man einem Agenten vertrauen und wo muss man selbst das Heft in die Hand nehmen? Unser letzter Speaker hier auf der Konferenz ist ein bekanntes Gesicht und genau der richtige Mann, um diese Fragen zu beantworten. Sebastian Springer ist Software-Architekt bei Rohde & Schwarz und arbeitet täglich an KI-gestützter Entwicklung. Er entwickelt praktische Workflows für Coding-Agents und Automatisierung und muss als Technical Educator KI-Konzepte so vermitteln, dass Entwickler sie auch sofort nutzen können. Diese Doppelrolle gibt ihm also den perfekten Blick, nämlich kennt er die technischen Möglichkeiten und auch die praktischen Hürden. Viele kennen ihn natürlich auch von unseren Büchern und auch von diversen Rheinwerk-Konferenzen und dpunkt-Konferenzen. Deshalb freue ich mich, dass er heute auch wieder hier ist beim Coding mit KI. Hallo, herzlich willkommen, lieber Basti.

Sebastian Einen wunderschönen guten Nachmittag. Hast du mal die Messlatte richtig hochgehängt?

Hendrik Ja, Mensch. Ehre, wem Ehre gebührt.

Sebastian Vielen herzlichen Dank. Eigentlich wollte ich so ein richtig grumpy Ding hinten rausjagen. Diese KI wird sich einfach nicht durchsetzen. Vergesst alles, was ihr gehört habt. Funktioniert einfach nicht. Ist leider nicht so. Also funktioniert tatsächlich. Und genau das schauen wir uns jetzt dann an.

Hendrik Super. Dann viel Spaß mit diesem Vortrag von Sebastian Springer und wenn ihr Fragen habt, stellt sie gerne im Chat. Sebastian, die Bühne gehört dir. Vielen Dank.

Sebastian Ein Wort der Warnung vorweg. Ihr werdet mit ganz viel eigener Meinung konfrontiert werden. Ich habe mittlerweile ein bisschen Erfahrung mit agentischer Entwicklung. Ich habe mit GitHub Copilot angefangen, als GitHub Copilot noch cool war, also richtig cool war. Jetzt ist es ja eher so ein Trauerspiel und habe sehr, sehr viel ausprobiert. Ganz viel in Spielprojekten, wo man sich denkt, boah, supergeil, funktioniert ja alles. Und dann machst du es plötzlich im Projektalltag und dann funktioniert überhaupt nichts mehr. Ja, ich meine, habt ihr schon mal probiert, von einem Coding-Agent irgendwas mit UI bauen zu lassen oder CSS oder irgend sowas? Ich scheitere da regelmäßig, aber da kommen wir noch dazu. Keine Sorge. Gut, also wir schauen uns an, was funktioniert bei mir in der täglichen Arbeit, was funktioniert nicht. Gerne reingrätschen, gerne eure Fragen, eure eigenen Erfahrungen mitteilen. Ich habe festgestellt, das hilft ungemein. Also redet über das, was ihr tut und redet über eure Probleme und meistens findet sich dann in der Gruppe von Gleichgesinnten auch eine richtig gute Lösung dafür. Ja, der Hendrik hat mich eigentlich schon vorgestellt. Recht viel mehr steht auf dieser Folie auch nicht drauf. Auch das hat der Hendrik schon gesagt. Eigentlich hätten wir uns absprechen müssen. Das ist ja quasi mein Co-Speaker hier schon. Also grundsätzlich ist es tatsächlich so, man schaut sich so einen Coding-Agent auf der grünen Wiese an, komm jetzt bauen wir mal eine Webseite oder komm bauen wir mal ein neues Spotify oder machen wir ein Ticketsystem oder weiß der Teufel was und das funktioniert alles erstaunlich gut. Ja und dann schlägt die Realität zu und dann ist es dann plötzlich nicht mehr so gut. Warum? Wir arbeiten meistens mit Tickets und die Tickets müssen erstmal so aufbereitet werden, damit gearbeitet werden kann. Wenn ich jetzt ein Ticket eins zu eins kopiere in meinen Prompt rein und sage, ja jetzt mach mal, ich habe des Öfteren jetzt schon ausprobiert und ohne Nacharbeiten funktioniert es in den seltensten Fällen, außer man konzentriert sich wirklich drauf, um für einen Agent zu spezifizieren. Für einen Entwickler, mit dem man die ganze Zeit zusammenarbeitet, ist es deutlich einfacher. Man kennt sich, man weiß, wie die Gegenseite tickt, und die AI weiß das in den meisten Fällen nicht. Deswegen müssen wir da allein schon ein bisschen unter die Arme greifen. Dann arbeiten wir nicht auf der grünen Wiese, sondern meistens mit einer mehr oder weniger großen, manchmal auch hässlichen Code-Basis mit Dingen, die sind gewachsen. Geh da nicht hin, das sind die dunklen Ecken. Die fasst man nicht an. Da sind schon Leute verschwunden. Dann Bugfixes. Ja klar, kann ich den irgendwie fixen, aber woher kommt der Bug? Wie ist der entstanden? War das vielleicht mal ein Feature, das sich gegen uns gewendet hat? Auch da muss man echt ein bisschen aufpassen. Und die Paradedisziplin von AIs, das Refactoring, weil es ja so einfach ist, sollten nichts kaputt machen, keine APIs ändern und ja, da muss man ein bisschen aufpassen. Und die Abstimmung mit den menschlichen Counterparts ist ja da auch noch. Also da haben wir so ein bisschen die Schwierigkeiten und das, was einem die Tutorials nicht sagen. Und genau dafür muss man sich sein Werkzeug zurechtlegen, das richtige Werkzeug erst mal finden, die Workflows so einschleifen, dass sie einem nicht im Weg stehen. Und ich habe tatsächlich jetzt in der Vorbereitung auf diesen Vortrag ganz viele Anti-Patterns einfach nochmal ausprobiert, weil ich mir dachte, naja, so falsch kann das nicht sein. Aber oh doch, es ist falsch. Also seid gespannt. Ich plaudere da so ein bisschen aus dem Nähkästchen. Wir fangen mal an mit den Modellen. Natürlich, Fable haben sie uns jetzt gestrichen, aber hey, wir haben ja immer noch den Opus 4.8 und wir haben immer noch GPT-5.5 und wie sie alle heißen. Ja, die Dinger sind super und die können auch jede Menge Probleme lösen. Auf der anderen Seite schaffen sie wieder einen Haufen Probleme, weil ich zum Beispiel nutze nicht immer die neuesten und besten und tollsten Modelle. Erstens, weil es ins Geld geht und in die Tokens geht. Und zweitens finde ich, gerade die neuesten Modelle sind teilweise sehr mitteilsam und so sieht der Code auch teilweise aus. Also die besten Ergebnisse erzielt bei mir im Moment ein ganz einfaches GPT-5.4, also eine Generation älter und das funktioniert völlig solide. Also man muss auch so ein bisschen ausprobieren, schauen, wie arbeitet man selbst damit, wie interpretiert das Modell die Prompts, wie mitteilungsbedürftig ist es, wie schaut die Ausgabe aus, wenn man sich zum Beispiel was erklären lässt. Da finde ich die Opus-Modelle zum Beispiel wieder viel besser, weil die viel schöner strukturieren. Auch da kann man mit einem entsprechenden Prompt helfen. Aber wenn das Modell das von sich aus schon mitbringt, warum nehmen wir es dann nicht mit? Also auch da, das Modell ist nur die halbe Miete. Wie gehe ich mit dem Modell um und was habe ich für einen Harness, also für eine Entwicklungsumgebung? Und wie unterstützt mich diese Entwicklungsumgebung? Ist extrem wichtig und genau da werden wir auch nochmal einen eingehenden Blick drauf werfen, was für Elemente von so einer Entwicklungsumgebung helfen uns denn wirklich. Ja, genau das schauen wir uns jetzt an. So, Coding Agents da gibt es ja auch wie Sand am Meer. Und ich habe etliche ausprobiert und bin jetzt im Moment bei Cursor hängen geblieben. Ich bin schon etwas länger bei Cursor hängen geblieben, auch da, wo es noch cool war, wo es noch nicht zu SpaceX gehört hat, wo es noch nicht von Elon gekauft wurde, weil es einfach eine sehr schöne, runde Sache ist. Und grundsätzlich hat es ja mal angefangen mit der Autocompletion. Also GitHub Copilot zu den Ursprungszeiten war eine bessere, magischere Autocompletion. Dann irgendwann kam dann das Chatfenster und jetzt erklär mir mal diese Funktion. Ja, die Funktion zählt zwei Werte zusammen und gibt den berechneten Wert zurück. Ja, das ist mächtig, das kann sehr viel, aber hat noch nichts mit einem Coding-Agent zu tun, weil ich könnte theoretisch das Ganze auch mit einem Chat-GPT oder Ähnlichem schaffen. Wo es wirklich interessant wird, ist mit einem Agent, der in das Ökosystem eingebettet ist, mit dem ich kommunizieren kann, der selbst planen kann, der auf Ressourcen zugreifen kann, der selbst Entscheidungen trifft bis hin zum Force-Push, wo es wirklich gruselig wird. Warum sage ich das? Ich habe mit einem Agent auch schon Commit-Historien Kosmetik betrieben. Das mache ich meistens zum Wachwerden, weil danach bist du wach, wenn das Ding in deiner Git-Historie rumackert und zum Schluss von dir verlangt, hey, und jetzt mach mal bitte einen Git-Force-Push, damit auch die History umgeschrieben wird. Beziehungsweise, ihr kennt ja wahrscheinlich den YOLO-Mode. Wo das Modell dann alles darf und der macht halt dann einfach munter vor sich hin den Force-Push in euer Repo und das finde ich tatsächlich schon ein bisschen grenzwertig. Gleiches, was für Git gilt, gilt natürlich auch für Ticketsystemen, für Filesystemen, für alles, wo man halt nicht unbedingt ein autonomes Ding alles Mögliche machen lassen möchte, weil sonst plötzlich irgendwelche Dateien fehlen oder irgendwelche Mailpost-Fächer ausgeleert sind oder Sonstiges. Ihr kennt ja die Geschichten. Was macht ein Agent aus? Ich gehe bei der Arbeit mit dem Agent eher, also, ich beschreibe, was ich erreichen möchte. Ich sage dem Agent nicht, jetzt schreibe ein If-Statement, dann schreibe eine Schleife und dann mache hier ein Input-Element hin, sondern ich beschreibe, was ich erreichen möchte und warum ich es erreichen möchte, einfach um das Ganze abstrakt zu halten, und um dem Agent auch ein bisschen Freiheit zu geben, um das Ziel bestmöglich zu erreichen. Und dann braucht das Ding natürlich Werkzeuge, um das Ökosystem zu kennen, um die Code-Basis zu kennen, um die Git-Historie oder Versionskontroll-Historie zu kennen, um, wenn ich im Web unterwegs bin, meinen Frontend fernzusteuern, Tests auszuführen und so weiter. Also ich brauche eine ganze Latte von Werkzeugen, weil diese Werkzeuge auch das Ergebnis deutlich besser machen als ohne. Und in den meisten Fällen lohnt es sich, in Schleifen zu arbeiten. Also nicht der erste Wurf und dann fertig, sondern der Agent dreht Schleifen, refined, kostet natürlich wieder einen Haufen Tokens, aber das Ergebnis ist dann meistens besser. Das kann ich mit entsprechenden Reasoning-Modellen und, entsprechenden Anweisungen hinterlegen und dann arbeitet das Ding und ich kann gemütlich einen Kaffee trinken gehen und wenn ich dann wieder zurück bin, ist der Agent fertig und alles ist wunderbar. In der Realität wartet der Agent dann bei mir immer auf eine Eingabe. Willst du bla bla bla Git-Historie oder sonst irgendwas und dann muss ich ihm trotzdem beim Coden zuschauen. Apropos, jetzt mal interaktive Umfrage, wie viele Aufgaben, also wenn ihr agentisch arbeitet, wie viele Aufgaben lasst ihr von so einem Agent parallel abarbeiten? Eins, zwei, viele und wenn viele, dann wie viele? Ja, genau. Und, der Agent trifft Entscheidungen in einem bestimmten vorgegebenen Rahmen. Also bei mir darf er nicht voll autonom arbeiten, weil ich bin ein ziemliches Weichei, wenn es um sowas geht. Ich habe ganz viele Gespräche in letzter Zeit gehabt mit ganz, ganz vielen Entwicklern, sowohl älteren Semestern, also Senior-Entwicklern als auch mit jüngeren Leuten, Studenten. Wird uns KI irgendwann ersetzen? Weiß man nicht. Ich meine, wir müssen im Hier und Jetzt leben und aktuell ist ein Agent nur so gut wie die Entität, die ihn führt, und wenn ihr so einen Agent sehr gut führt, dann kommt da auch eine saubere Architektur raus. Und es ist aber bedingt kein Ersatz für Entwickler. Viele Firmen meinen, es ist ein Ersatz für Entwickler. Irgendwann werden die aber wahrscheinlich auch aufwachen, wenn sie sich selber den Ast abschneiden. Das sind alles Themen für die Glaskugel, für mich im Moment in meiner Realität. Ihr seht, ich bin vorsichtig, weil es gibt Leute, die setzen eiskalt nur noch auf agentische Entwicklung. Da bin ich kein Freund davon, gerade wenn es um längerfristige, stabile Produkte geht. Für mich ist es ein Werkzeug, ein mittlerweile unverzichtbares Werkzeug, ein Werkzeug, das mich gefühlt schneller macht, wenn ich es richtig benutze, und ein Tool, das Fehler macht. Und zwar schnell und viel. Und da muss man eben aufpassen. Dann, Grundsatzdiskussion, habe ich lieber einen CLI-Agent, den ich als Hacker von der Kommandozeile aus bediene, weil es cool aussieht, oder in einer realistischeren Umgebung, den ich einfach für das Batch-Processing nutze, für eine alternative Eingabeart und Weise, wenn ich jetzt zum Beispiel meinen CLI-Agent an ein Ticketing-System dranhänge und mit dem, Agent nur noch über Tickets kommuniziere, die dann sehr gut verpackt sind. Wenn ich irgendwas automatisieren möchte, irgendwelches Batch Processing, hier Beispiel, nimm diese 200 Dateien und baue die nach folgendem Schema um, dann lasse ich das Ding über Nacht laufen und dann ist es gut, bei 200 Dateien brauchen wir noch nicht über Nacht reden, aber das kann dann einfach dauern und wenn es fertig ist, ist es fertig. Die andere Sache ist ... Der Hendrik wollte was sagen.

Hendrik Ja, aber nur ganz kurz. Wir haben erste Ergebnisse. Also ich habe hier eine Antwort. Da hat jemand noch keine Erfahrung im Parallelen abarbeiten. Und da kommt die zweite Antwort, dass jemand da auch noch keine Erfahrung hat. Und der Ingo sagt, selten mehr als eins. Ansonsten ist mir der Kontextwechsel bei der Überprüfung zu viel.

Sebastian Ja, guter Mann. Ingo, guter Mann. Das ist nämlich genau der Punkt.

Hendrik Ihr müsst entschuldigen, wir haben immer so einen leichten Zeitversatz, deswegen purzeln solche Ergebnisse immer so ein bisschen zeitverzögert.

Sebastian Aber das ist tatsächlich genau der Punkt, der mich auch immer stresst. Und ich bin ein sehr ungeduldiger Mensch. Ich mache dann auch immer Sachen parallel. Und blöderweise kommen die dann immer gleichzeitig zurück. Und dann hast du drei Häufchen Arbeit auf dem Tisch liegen oder fünf Häufchen Arbeit auf dem Tisch liegen, zwischen denen du hin und her switchen musst. Und ganz ehrlich, das stresst mich unheimlich, weil die Agenten, die sitzen um mich rum und warten auf Input. Und ich bin dann der Flaschenhals, der alles langsam macht.

Hendrik Ja, das möchte man nicht sein, das stimmt. Ich will jetzt auch nicht der Flaschenhals sein, der alles langsam macht, deshalb ziehe ich mich wieder zurück. Bis dann.

Sebastian So, genau. Das ist tatsächlich hier meine favorisierte Arbeitsumgebung. Ich arbeite sehr gern mit IDE-Agenten, weil die vermitteln mir das Gefühl, dass ich noch Kontrolle über den Prozess hätte. Ich sehe den Code, ich kann in den Code eingreifen. Ich habe mein Prompt-Interface. Blöderweise wird das immer größer. Also der Code-Anteil von meinem Screen, der wird immer kleiner, weil ich mich echt schon langsam sehr dran gewöhne, intensiv zu prompten, Iterationen zu drehen und im Nachhinein dann den Code zu reviewen. Aber das Gefühl, das integriert zu haben, ist für mich einfach die rundere Sache. Und deswegen persönlich Präferenz, gib mir entweder eine CLI oder so einen IDE-Agent, ich nehme immer den IDE-Agent. Zumindest für die nächsten zwei Wochen. Gut, dann fangen wir mal mit den Dingen an, die ich für wichtig halte und das eine oder das erste sind Rule Files. Rule Files sind im weitesten Sinne eine Erweiterung für Prompts. So ein Prompt ist, ich habe eine Aufgabe und die löst du mir jetzt bitte. Eine Rule-File ist was Epischeres, was Dauerhafteres, das ihr in den Raum stellt und das Verhalten von einem Agent beeinflusst. So eine Rule-File umreißt das Verhalten von einem Agenten. Das ist im weitesten Sinne so etwas wie ein System-Prompt. Also, dass das Modell in eine bestimmte Richtung dreht, bestimmte Grenzen setzt. Das Problem ist, das sind weiche Grenzen. Also, mehr Empfehlungen, weil der Agent kann sich daran halten, kann sich aber auch darüber hinwegsetzen. Ihr könnt damit beeinflussen, wie das Ding denkt, wie es arbeitet, was bevorzugt wird, was vermieden wird und wie Entscheidungen getroffen werden. Wir haben im Team eine Rule-File, die fürs Projekt zentral abgelegt ist und jeder darf diese Rule-File editieren. Jeder ist dazu eingeladen, diese Rule-File zu verbessern und immer wenn irgendwas nervt oder irgendwas zu verbessern ist, kommt das in die Rule-File rein. Diese Rule-Files, Agent-Files, die folgen einem Standard, der ist hier verlinkt, den könnt ihr euch dann im Nachgang anschauen. Es gibt mehrere Coding-Agenten, die sich daran halten und bei denen, die sich nicht daran halten, gibt es sehr ähnliche Konzepte. Hat sich durchgesetzt, hat sich als gut bewährt, deswegen schaut euch das auf jeden Fall an. Was steht in so einer Rule-File drin? Architekturregeln, allgemeingültige Regeln. Eine React-Komponente sieht immer so und so aus. Wenn ich eine Funktion, ein Modul, eine Klasse, ein was auch immer schreibe, dann möchte ich, dass das immer so aussieht. Blueprints, Stilregeln. Wie sind meine Variablen gestaltet? Also jetzt, weiß ich nicht, keine Abkürzungen oder sonst irgendwas. Testregeln. Also wie gehe ich mit Tests um? Wie schauen meine Tests aus? Wie sind sie strukturiert? Welchen Patterns folgen die? Sprache und Ton. Ihr könnt in so einer Rulefile dem Agenten sagen, was ihr für einen Kommunikationsstil erwartet. Also kurzes, analytisches Antworten, was auch immer. Das hilft recht gut. Also, ich habe da teilweise auch reingeschrieben, halt dich bitte kurz, mich interessiert das außenrum nicht, komm auf den Punkt. Dann alles, was Konventionen angeht, alles, wo ihr sagt, das sind Regeln, die für uns als Entwickler gelten, die gelten bitte auch für die AI. Führ keine neuen Patterns ein. Halt dich an die bestehende Code-Basis. Alles, was man halt so in einem länger laufenden Projekt haben möchte, kommt in so eine Rule-File rein. Wir hatten aber auch schon den Fall, da haben genau diese Regeln auch wieder zurückgeschossen, und, da haben wir dann auch explizit gesagt, so und jetzt vergiss mal, was in dem Rule-File steht und prob dich komplett aus, dann kam das Modell mit einer sehr guten, sehr innovativen Idee um die Ecke und hat tatsächlich unser Problem deutlich schicker gelöst als mit unserer sehr strikten Regel. Was nicht reingehört sind, Sachen, die ihr einmalig braucht, irgendwelche Details, irgendwas Temporäres. Ihr müsst da immer so ein bisschen aufpassen, weil alles, was ihr dem Modell zur Verfügung stellt, verstopft den Kontext. Moderne Modelle haben einen riesengroßen Kontext, die haben eine Million oder teilweise zehn Millionen Tokens an Kontext, die können damit schon umgehen. Das Problem ist, je voller der Kontext läuft, desto schlechter werden die Antworten. Es gibt auch Erklärungen, warum das so ist, dass der Anfang des Kontexts sehr gut ist und das Ende des Kontexts sehr gut ist und in der Mitte flacht er dann ab. Es gibt auch wissenschaftliche Auswertungen und ganz viele Messungen darüber. Da suchmaschint einfach drüber nach bzw. fragt die AI eurer Wahl. Der Sascha schreibt gerade, er hat noch nie mit Rule Files gearbeitet. Anstatt jedes Mal migriere mir die Komponente in eine Vue 3 Komponente mit Composition API und Script Setup Pattern, kann man diesen Prompt einmal speichern und den immer wieder abfeuern. Aber natürlich kann man sowas auch in den Rule-File mit reinpacken. Wenn du gerade in der Migration bist, dann hilft das natürlich hervorragend. Dann sagst du bloß noch, okay, jetzt kümmere dich um diese Komponente und dann wird die Rule-File berücksichtigt und dann sparst du dir genau dieses Ich-wiederhole-mich-immer-und-immer-wieder. Ja, gute Beispiele, schlechte Beispiele. LLMs arbeiten generell sehr, sehr gut mit Beispielen. Also je mehr Beispiele ihr, da müsst ihr auch wieder aufpassen, weil je mehr Beispiele ihr macht, desto mehr wird euer Kontext voll. Ein paar sinnvolle, stellvertretende Beispiele, die Prinzipien zeigen und nicht konkrete Lösungen, helfen extrem gut. Also Sascha, in deinem Fall, wie sieht deine perfekte Komponente aus? Liegt in der Rulefile und dann hält sich das Modell in den meisten Fällen auch dran. Wie ausführlich? Nicht so ausführlich sollte die Rulefile sein, weil vermüllt euch den Kontext. Klar, prägnant. Man hat mir gesagt, ich soll nicht so höflich sein. Ich sage trotzdem immer bitte und danke zu meinem Modell, weil irgendwann übernehmen die Maschinen die Herrschaft und da muss man freundlich sein. Aber seid bei diesen Rule Files wirklich auf den Punkt, weil alles, was ihr drumherum schreibt, verwäscht wieder die Aussagekraft eurer Regeln. Und gerade bei solchen Regeln müsst ihr sehr präzise arbeiten. Wenn ihr feststellt, dass eure Regeln nicht ziehen, dann war sie entweder nicht gut formuliert oder zu wenig Beispiele. Also da kann man noch nachsteuern und das ist einfach ein Entwicklungsprozess. Das ist kein, ich schreibe jetzt die Rule-File und fertig, sondern es ist ein Prozess. Und je länger ihr daran arbeitet, desto mehr hängt ihr an euren Rule-Files. Ja, also immer wenn euch irgendwas nervt, dann schmeißt es in die Rulefile. Immer wenn ihr euch wiederholt oder wenn ihr, also ich meine, der Sascha hat das perfekte Beispiel gebracht, immer wenn euch irgendwas nervt, immer wenn es, wenn es sich wiederholt, in die Rule File rein und gut ist. Dann haben wir Skills. Skills ist der Fancy Shit, weil Skills werden getauscht wie Panini-Bilder auf dem Schulhof. Wir haben mittlerweile einen Skill Marketplace. Skills sind auch wieder so eine Art Standard. Auf AgentSkills.io findet ihr da mehr Informationen. Das sind im Prinzip kleine Bausteine. Das können fast so eine Art Prompt-Template sein. Ihr könnt aber auch Executables oder Skripte in die Skills mit reinpacken, Python-Skills, TypeScript-Skills. Die können dann auch Code aus, oder die führen dann Code aus, und das sind kleine Hilfs-Skripte, die euer Agent ranzieht, um Probleme zu lösen. So ein Skill hat eine Beschreibung, damit das Modell weiß, wann es einsetzen soll, und so könnt ihr ganz viele verschiedene Skills in eure IDE mit reinpacken, in euren Agent mit reinpacken, und ja, die werden dann genutzt. Ja, bei Unterscheidung zwischen Rules und Skills, Rules sind Prinzipien, die sind allgemeingültiger, die stehen für allgemeine Anweisungen, für allgemeine Regeln, nicht für die konkreten Umsetzungsschritte. Die Skills auf der anderen Seite, die sind sehr konkret, sehr codenah, sehr greifbar, und kleine Häppchen, kleine zielgerichtete Häppchen. Wenn ihr mal so ein bisschen im Internet recherchiert, ihr findet zu allem Skills. Also mir ist es mittlerweile schon fast ein bisschen zu viel, aber es ist jedem selbst überlassen. Schaut euch da einfach mal ein bisschen um. Auch da ist es so ein bisschen so, ihr müsst ein bisschen aufpassen, dass ihr euren Agent nicht überfrachtet. Wenn ihr 400 Skills installiert habt, irgendwann ist es zu viel und dann fängt euer Agent an, ja, für den Bereich könnte ich jetzt diesen Skill benutzen oder diesen Skill und dann wird es wieder ein bisschen flaky. Deswegen meiner Meinung nach ein paar, eine Handvoll Skills, die eure Probleme tagtäglich lösen, die zielgerichtet sind, da fährt man tatsächlich am besten. Ja, teilen, drüber reden, ihr kommt im Moment eh nicht dran vorbei. Dann das nächste Thema, MCP. MCP ist wie Skills, nur nicht mehr ganz so cool. MCP ist grundsätzlich erstmal ein Protokoll, um LLMs mit der Außenwelt zu verbinden. In dem Kontext ist in den meisten Fällen von Tools die Rede. Also Funktionen, die ein LLM aufrufen kann, die bestimmte Funktionalität zur Verfügung stellen. Jeder, der auch nur ein bisschen was auf sich hält, bietet mittlerweile einen MCP-Server an. So einen MCP-Server könnt ihr auch selber schreiben. Das ist im Prinzip ein entweder lokal laufender Server oder ein Remote über HTTP angebundener Server, den das LLM kennt, den das LLM anrufen kann und dieser Server führt eine Funktion aus und stellt das Ergebnis oder den Seiteneffekt dieser Funktion dem LLM zur Verfügung. Ihr findet mehr Informationen unter Contextprotocol.io, da ist der Standard und alles, was ihr wissen müsst dazu. Ja, hilft auch wieder, um Halluzinationen zu reduzieren, hilft dabei, euer Ökosystem anzubinden und ist ganz hilfreich in vielen Fällen. Ich habe eine kleine Auswahl an MCP-Servern, dass ihr einfach so einen Eindruck mal kriegt, was es denn gibt. Es gibt einen GitHub-MCP-Server, es gibt auch einen GitLab-MCP-Server. Grundsätzlich stellt dieser MCP-Server die Schnittstelle eurer Git-Plattform zur Verfügung. Ihr könnt Branches aufmachen, Pull-Requests stellen und so weiter. Und das macht euer LLM automatisiert mit den Privilegien, die ihr diesem Ding gebt. Also da müsst ihr ein bisschen aufpassen. Dann Ticketsystem. Ich weiß, nicht jeder mag Atlassian-Produkte, aber das ist halt jetzt hier stellvertretend. Die bieten auch einen MCP-Server für Jira und Confluence und da kann man auf Tickets zugreifen und wunderbare Dinge machen. Und da kann man auch Dinge automatisieren lassen, die man selber nicht machen möchte. Also zum Beispiel, jetzt setzt den Status dieses Tickets automatisch auf weiß der Teufel was – und dann kümmert sich euer Agent. File-System. Es gibt einen MCP-Server für euer lokales Dateisystem. Auch da müsst ihr wieder ein bisschen vorsichtig sein, weil es gibt auch die Möglichkeit, Dateien zu löschen, Verzeichnisse zu löschen. Da müsst ihr bitte ein bisschen vorsichtig sein, weil ansonsten ist euer System zwar sehr leer und hat sehr viel Speicherplatz, aber ihr habt nicht mehr sehr viel Freude mit eurem System. Okay. Browser. Google hat zum Beispiel den Chrome Developer Tools MCP Server. Mit dem kann man wunderbare Sachen machen. Da müsst ihr bloß ein bisschen aufpassen, weil manche Agents drehen sehr gerne Schleifen und die probieren sehr gerne Dinge aus. Und ich bin schon sehr, sehr viele Tokens in so einem Browser-MCP-Loop losgeworden, weil der die Webseite einfach wunderschön fand und überall hingeklickt hat. Also auch da haltet das Ding so ein bisschen im Zaum. Frage vom Thomas. Haben wir den Skill Marketplace selbst gebaut oder als Buy-In-Lösung? Wir haben es selbst gebaut. Wir haben da einfach ein Git-Repo dafür gemacht und da kann sich jeder bedienen. Also die pragmatische Lösung. So, dann Aufgaben zuschneiden. Das finde ich tatsächlich extrem wichtig. Ich bin jemand, der gerne Kontrolle über das hat, was passiert, aus zwei Gründen. Wenn die Aufgabe jetzt groß wird, habe ich sehr viel zu lesen, sehr viel zu verstehen. Wenn ich meine Aufgaben kleiner schneide, muss ich nicht so viel arbeiten, also kurzfristig nicht so viel arbeiten. Wir hatten auch andere Aspekte, und zwar kleine Aufgaben haben kleinen Kontext. Ich gebe nicht zu viel Freiheitsgrade, ich lasse dem Modell nicht zu viel Raum, um sich kreativ zu entfalten, weil Kreativität manchmal halt nicht so geil ist. Kleine Aufgaben, ich bin explizit und das Ding macht nicht zu viele Schritte auf einmal, also das ist wirklich so, dass ... Das, das ist das Gebot der Stunde. Macht kleine Aufgaben, wenn euch eure Nerven wichtig sind. Okay, ich gehe da jetzt sehr viel drauf ein; unterm Strich: schaut, dass ihr kleine Aufgaben macht. Was ist für mich eine gute Aufgabenbeschreibung? Was will ich für ein Ziel erreichen? Wie soll der Zustand meines Systems am Ende sein? Was brauche ich für Kontext? Und da habe ich einen Kollegen, der ist wunderbar. Der ist ein Kontext-Engineer vor dem Herrn und zwar nicht das, was man auf LinkedIn findet, sondern der schleift den Kontext für die Aufgaben so perfekt, dass das Modell alle Informationen hat, die es braucht und die Aufgaben auf den Punkt erledigt. Woran merkt man das? Im Tokenverbrauch. Also der ist wirklich next level und also der hat wirklich den Kontext verstanden und kann es extrem gut nutzen. Und ich schaue mir da immer so ein bisschen was davon ab. Das heißt, ich versuche auch dem Modell zu sagen, okay, bewege dich in diesem Verzeichnis, nimm diese Datei, nimm diesen Abschnitt dieser Datei. Je mehr Zeit ihr in die Vorbereitung investiert, desto weniger böse Überraschungen kriegt ihr. Wie ich zum Beispiel, wo ich jetzt noch die letzten Tage Anti-Patterns ausprobiert habe, da hat mir das Modell meine API-Beschreibung, die ich aus dem Backend als Referenz rüberkopiert habe, kurzerhand einfach geändert. Also ich hatte so ein OpenAPI-Dokument, REST-Beschreibung und das Modell meinte, eigentlich könnte ich ja die Server-API noch so ein bisschen optimieren, weil ich brauche da ein paar Informationen. Ja, das war nicht Ziel der Übung, weil Ziel der Übung war einfach nur dem Modell die Dokumentation zur Verfügung zu stellen, was denn alles da ist und was denn vom Backend kommt, aber nicht zu sagen, okay, jetzt schreibt bitte das Backend. Ja, auch wieder schlechtes Prompting. Das hätte ich lösen können, indem ich gesagt hätte, pass auf, nimm das Ding als Referenz und lass um Himmels Willen die Finger davon. Hat dann der Folge Prompt gelöst, hat mich aber wieder zigtausend Tokens gekostet. So, und dann will ich natürlich dann auch festlegen, woran erkenne ich, dass die Aufgabe zufriedenstellend gelöst ist. Es gibt Tests dafür, alle anderen Tests laufen weiter, es ist dokumentiert und so weiter. Sowas kann natürlich auch wieder ein Stück weit in die Rule File eingehen, weil das ist in den meisten, also diese non-funktionalen Anforderungen sind in der Regel die gleichen. Da müsst ihr euch einfach rantasten. So, was wollen wir da nicht? Wir wollen nicht die Geschichte unseres Projekts, wir wollen nicht die Ticket-Historie inklusive aller Kommentare und sonst noch was. Ein Wunschzettel a la, ja, und wenn du schon mal dabei bist, dann refactor auch noch das. Und übrigens, das würde auch noch mal zu tun sein. Zu viele Dateien auf einmal zu referenzieren, ist auch nicht hilfreich, weil wenn ihr sehr viele Referenzen reinkippt, dann ist erstmal der Kontext voller. Und zweitens habe ich festgestellt, wenn da viele Dateien drin sind, dann tobt sich der Agent auch sehr gerne an vielen Dateien aus. Also versucht euch wirklich auf das Relevante zu beschränken. Ja, also Refactor mir mal das Ding ist eher schlecht. Wenn ihr sagt, hier, ich habe Authentifizierung und jetzt mach mal hier Validate Token und baue das um nach diesen und jenen Kriterien, die API soll so und so aussehen, dann kriegt ihr ein recht gutes, recht überprüfbares Ergebnis und ihr braucht nicht das smarteste, teuerste Modell, sondern ihr könnt da auch ein, zwei Stufen runtergehen und ein kostengünstiges, doofes, leichtgewichtiges Modell nutzen. Also je expliziter ihr seid, desto weniger muss das Modell für euch smart sein. Ist auch gut für den Geldbeutel. Wenn ihr das Ganze in den Workflow, in den Sequenz gießt, ist es einfach hilfreich. Ich habe festgestellt, wenn ich die Leine nicht kurz halte, dann flippt mein Agent aus und je höher-tierig, also je höher-levelig das Modell ist, desto mehr flippt es aus. Deswegen Grenzen setzen. Und mit Grenzen setzen bin ich mittlerweile sehr gut und sehr vorsichtig, weil ich eng das Modell lieber mehr ein, als dass ich zu viel Freiraum lasse. Ich habe heute wieder einen Anti-Pattern ausprobiert. Das hat mich 8 Millionen Tokens gekostet. Ich habe gesagt, so, und jetzt bauen wir das Ding mal um. Also groben Umriss, was ich haben wollte und dann let's go. Also, ja, das ist erstmal für mich ungewöhnlich lange gelaufen. Also, ich glaube, so 10 Minuten, Viertelstunde. Ja, da war auch Tests, Ausführungen und so weiter dabei. Aber ich werde dann immer schon ein bisschen nervös, weil ich mir denke, boah, wo läuft er denn jetzt schon wieder? Was macht er denn da hinten? Das geht ihm doch überhaupt nichts an. Deswegen Grenzen setzen. Das ist gut. Gut für die Nerven. Ja, und ich bin einfach ein Kontrollfreak, wenn es um LLMs geht. Ich habe immer so diese Horror-Stories im Kopf. Ja, der Agent löscht das Dateisystem oder löscht den Posteingang oder weiß der Teufel was. Ich traue diesen Dingen halt nicht. Und ja, ich lasse ihn auch ab und zu mal forced pushen und die History umschreiben. So, ein Thema, das dank GitHub Microsoft jetzt immer zunehmend wichtiger wird, ist Kostenkontrolle. Die wenigsten unter euch werden Unlimited Tokens noch haben und die, die es haben, lehnt euch zurück und genießt das Schicksal der anderen Leute. Warum ist es wichtig? Weil immer mehr Anbieter auf den Trichter kommen werden, sie wollen Geld verdienen. Anthropic macht so, du hast das Abo, du hast ein Kontingent, super, aber wenn du das Kontingent nicht hättest, dann würde dich das so und so viel Geld kosten. Das ist so der erste Schritt in Richtung, übrigens, es kann empfindlich teuer werden. GitHub oder Microsoft Copilot hat es vorgemacht, die haben von diesem Kontingentmodell, Abo-Modell, Anfrage-basierten Modell auf härteren Limits umgeschaltet. Mittlerweile, ich habe nebenbei so ein GitHub Copilot Pro Abo noch am Laufen, das kannst du quasi nicht nutzen, weil es um einen Tag aufgebraucht ist. Und deswegen wird Kostenkontrolle einfach zunehmend wichtiger. Je größer und vager eure Prompts sind, desto teurer wird es. Je unklarer eure Ziele sind, desto mehr Schleifen dreht ihr, desto mehr Tokens kostet. Je größer euer Kontext ist, desto teurer werden die Requests. Ihr müsst da so ein bisschen unterscheiden zwischen Input-Tokens, die günstig sind oder Cached-Input-Tokens, die noch günstiger sind und Output-Tokens, die richtig teuer sind, also teilweise pro Million Output-Tokens 30 bis 50 Dollar. Also kann schon ins Geld gehen. Kleine Aufgaben, haben wir darüber gesprochen. Und ihr wisst, dass ich ein Fan von gesteuertem Kontext bin. Auch das ist sehr, sehr gut für Kostensparen. Ein super Satz. Kontext ist wie RAM. Und ihr wisst, RAM ist vergoldet mittlerweile. Und je weniger ihr braucht, desto billiger wird es. Ich habe schon teilweise diese Thinking-Schleifen einfach unterbrochen, weil ich mir dachte, um Gottes Willen, was macht das Ding jetzt schon wieder? Je mehr ihr diese Iteration reduziert, desto günstiger wird es wieder, also kleiner Kontext, kleine Aufgaben, mehr Kontrolle ist günstiger. Wenn ihr nicht aufs Geld schauen müsst, haut die Tokens raus, solange es noch geht. Das ist ein Thema, das bei uns sehr viel diskutiert wird. Wer übernimmt die Verantwortung? Das habe ich auch in letzter Zeit mit ganz vielen Leuten besprochen. Reviewt ihr euren Code noch? Lasst ihr AI euren Code reviewen? Ich habe von Leuten gehört, die sagen, der Agent baut den Code, dann ein anderer Agent überprüft den. Wir haben E-Tests, also go. Ich finde das ein bisschen gruselig. Also bei uns ist es anders. Bei uns übernehmen die Leute Verantwortung für das, was ihre Agents gebaut haben. Klar bauen wir Dinge mit AI, aber die letzte Instanz ist immer noch menschlich und das Produkt, das die Ladentheke verlässt, da stehen Menschen dahinter und die übernehmen die Verantwortung. Und wenn dann irgendwas schief geht, dann stehen die auch dafür gerade und fixen die Probleme. Da gibt es ganz, ganz viele Diskussionen. Also wenn wir jetzt noch ein bisschen mehr Zeit hätten, ich könnte euch da Geschichten über Open-Source-Projekte erzählen. Das ist so herrlich. Die reichen von pragmatischen Ansätzen wie im Linux-Kernel, macht was ihr wollt, aber ihr bleibt persönlich in der Verantwortung, bis hin zu anderen Projekten, die sagen, wir reden nicht über AI. AI gibt es nicht und wenn du in diesem Projekt arbeiten willst, dann keine AI. Also von pragmatisch bis realitätsfremd. Dann auch ganz oft, was ich schon ganz oft gehört habe, AI nimmt mir mein Hobby weg. Ich darf nicht mehr Code schreiben. Das ist zu einem bestimmten Grad richtig. Es ändert sich viel. Also wir schreiben nicht mehr Lines of Code, sondern wir bauen Konzepte und lassen die AI die Konzepte ausprogrammieren. Es ändert sich einfach. Und es hat sich in der Softwareentwicklung schon immer geändert. Es ändert sich jetzt ein bisschen schneller. Aber das halten wir nicht auf. So. Und jetzt noch ein paar Sachen zum Nachdenken für euch. So als kleiner Schluss, als kleiner Absacker. Wie viel Kontrolle geben wir ab? Was darf die AI? Was müssen wir noch selber machen? Was heißt Qualität? Also hauen wir wirklich AI-Code raus, weil es günstiger ist, das Ding neu zu bauen oder von der AI die Bugs fixen zu lassen oder bauen wir noch qualitativ hochwertigen Code und, in letzter Instanz prüfen wir den Code der AI, der extrem schnell rausgehauen wird oder prüft die AI die AI und machen wir dann Safety Net. Also da ist auch sehr, sehr viel Varianz mit drin. Das sind so die Sachen, die schwirren mir im Hinterkopf, und ja, damit sind wir am Ende.

Hendrik Ja, dann würde ich sagen Basti, es gibt keine weiteren Fragen mehr hier im Chat. Ich danke dir vielmals, dass du hier wieder dabei warst, und ja, wir werden uns ja auf alle Fälle wiedersehen, von daher freue ich mich darauf!