Sebastian: Aber das ist tatsächlich genau der Punkt, der mich auch immer stresst.
Sebastian: Und ich bin ein sehr ungeduldiger Mensch. Ich mache dann auch immer Sachen parallel.
Sebastian: Und blöderweise kommen die dann immer gleichzeitig zurück. Und dann hast du
Sebastian: drei Häufchen Arbeit auf dem Tisch liegen oder fünf Häufchen Arbeit auf dem
Sebastian: Tisch liegen, zwischen denen du hin und her switchen musst.
Sebastian: Und ganz ehrlich, das stresst mich unheimlich, weil die Agenten,
Sebastian: die sitzen um mich rum und warten auf Input.
Sebastian: Und ich bin dann der Flaschenhals, der alles langsam macht.
Hendrik: Zum Abschluss des heutigen Konferenztages geht es nochmal um vielleicht die
Hendrik: wichtigste Frage, nämlich, was funktioniert mit Coding Agents eigentlich wirklich und was nicht?
Hendrik: Denn seien wir jetzt mal ehrlich, die meisten Demos, die zeigen ja perfekte
Hendrik: Welten, saubere Code-Basen, klare Anforderungen, Agents, die wie von Zauberhand
Hendrik: komplexe Features implementieren.
Hendrik: Aber die Realität, das haben wir auch heute schon gehört, die sieht dann schon mal auch anders aus.
Hendrik: Echte Projekte mit gewachsenen Strukturen, unklaren Requirements,
Hendrik: KI-Tools, die manchmal genial sind und manchmal auch völlig daneben liegen.
Hendrik: Wann also kann man einem Agenten vertrauen und wo muss man selbst das Heft in die Hand nehmen?
Hendrik: Unser letzter Speaker hier auf der Konferenz ist ein bekanntes Gesicht und genau
Hendrik: der richtige Mann, um diese Fragen zu beantworten.
Hendrik: Sebastian Springer ist Software-Architekt bei Rohde & Schwarz und arbeitet täglich
Hendrik: an KI-gestützter Entwicklung.
Hendrik: Er entwickelt praktische Workflows für Coding-Agents und Automatisierung und
Hendrik: muss als Technical Educator KI-Konzepte so vermitteln, dass Entwickler sie auch sofort nutzen können.
Hendrik: Diese Doppelrolle gibt ihm also den perfekten Blick, nämlich kennt er die technischen
Hendrik: Möglichkeiten und auch die praktischen Hürden.
Hendrik: Viele kennen ihn natürlich auch von unseren Büchern und auch von diversen Rheinwerk-Konferenzen
Hendrik: und dpunkt-Konferenzen. Deshalb
Hendrik: freue ich mich, dass er heute auch wieder hier ist beim Coding mit KI.
Hendrik: 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.
Sebastian: Diese KI wird sich einfach nicht durchsetzen. Vergesst alles,
Sebastian: was ihr gehört habt. Funktioniert einfach nicht.
Sebastian: 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
Hendrik: Fragen habt, stellt sie gerne im Chat. Sebastian, die Bühne gehört dir. Vielen Dank.
Sebastian: Ein Wort der Warnung vorweg.
Sebastian: Ihr werdet mit ganz viel eigener Meinung konfrontiert werden.
Sebastian: Ich habe mittlerweile ein bisschen Erfahrung mit agentischer Entwicklung.
Sebastian: Ich habe mit GitHub Copilot angefangen, als GitHub Copilot noch cool war, also richtig cool war.
Sebastian: Jetzt ist es ja eher so ein Trauerspiel und habe sehr, sehr viel ausprobiert.
Sebastian: Ganz viel in Spielprojekten, wo man sich denkt, boah, supergeil, funktioniert ja alles.
Sebastian: Und dann machst du es plötzlich im Projektalltag und dann funktioniert überhaupt
Sebastian: nichts mehr. Ja, ich meine, habt ihr schon mal probiert, von einem Coding-Agent
Sebastian: irgendwas mit UI bauen zu lassen oder CSS oder irgend sowas?
Sebastian: Ich scheitere da regelmäßig, aber da kommen wir noch dazu. Keine Sorge.
Sebastian: Gut, also wir schauen uns an, was funktioniert bei mir in der täglichen Arbeit,
Sebastian: was funktioniert nicht.
Sebastian: Gerne reingrätschen, gerne eure Fragen, eure eigenen Erfahrungen mitteilen.
Sebastian: Ich habe festgestellt, das hilft ungemein. Also redet über das,
Sebastian: was ihr tut und redet über eure Probleme und meistens findet sich dann in der
Sebastian: Gruppe von Gleichgesinnten auch eine richtig gute Lösung dafür.
Sebastian: Ja, der Hendrik hat mich eigentlich schon vorgestellt. Recht viel mehr steht
Sebastian: auf dieser Folie auch nicht drauf.
Sebastian: Auch das hat der Hendrik schon gesagt. Eigentlich hätten wir uns absprechen
Sebastian: müssen. Das ist ja quasi mein Co-Speaker hier schon.
Sebastian: Also grundsätzlich ist es tatsächlich
Sebastian: so, man schaut sich so einen Coding-Agent auf der grünen Wiese an,
Sebastian: komm jetzt bauen wir mal eine Webseite oder komm bauen wir mal ein neues Spotify
Sebastian: oder machen wir ein Ticketsystem oder weiß der Teufel was und das funktioniert alles erstaunlich gut.
Sebastian: Ja und dann schlägt die Realität zu und dann ist es dann plötzlich nicht mehr so gut. Warum?
Sebastian: Wir arbeiten meistens mit Tickets und die Tickets müssen erstmal so aufbereitet
Sebastian: werden, damit gearbeitet werden kann.
Sebastian: Wenn ich jetzt ein Ticket eins zu eins kopiere in meinen Prompt rein und sage, ja jetzt mach mal,
Sebastian: ich habe des Öfteren jetzt schon ausprobiert und ohne Nacharbeiten funktioniert
Sebastian: es in den seltensten Fällen, außer man konzentriert sich wirklich drauf,
Sebastian: um für einen Agent zu spezifizieren.
Sebastian: Für einen Entwickler, mit dem man die ganze Zeit zusammenarbeitet,
Sebastian: ist es deutlich einfacher. Man kennt sich, man weiß, wie die Gegenseite tickt,
Sebastian: und die AI weiß das in den meisten Fällen nicht.
Sebastian: Deswegen müssen wir da allein schon ein bisschen unter die Arme greifen.
Sebastian: Dann arbeiten wir nicht auf der grünen Wiese, sondern meistens mit einer mehr
Sebastian: oder weniger großen, manchmal auch hässlichen Code-Basis mit Dingen, die sind gewachsen.
Sebastian: Geh da nicht hin, das sind die dunklen Ecken. Die fasst man nicht an.
Sebastian: Da sind schon Leute verschwunden.
Sebastian: Dann Bugfixes. Ja klar, kann ich den irgendwie fixen, aber woher kommt der Bug?
Sebastian: Wie ist der entstanden? War das vielleicht mal ein Feature, das sich gegen uns gewendet hat?
Sebastian: Auch da muss man echt ein bisschen aufpassen.
Sebastian: Und die Paradedisziplin von AIs, das Refactoring, weil es ja so einfach ist,
Sebastian: sollten nichts kaputt machen, keine APIs ändern und ja, da muss man ein bisschen aufpassen.
Sebastian: Und die Abstimmung mit den menschlichen Counterparts ist ja da auch noch.
Sebastian: Also da haben wir so ein bisschen die Schwierigkeiten und das,
Sebastian: was einem die Tutorials nicht sagen.
Sebastian: Und genau dafür muss man sich sein Werkzeug zurechtlegen, das richtige Werkzeug
Sebastian: erst mal finden, die Workflows so einschleifen, dass sie einem nicht im Weg stehen.
Sebastian: Und ich habe tatsächlich jetzt in der Vorbereitung auf diesen Vortrag ganz viele
Sebastian: Anti-Patterns einfach nochmal ausprobiert, weil ich mir dachte,
Sebastian: naja, so falsch kann das nicht sein.
Sebastian: Aber oh doch, es ist falsch. Also seid gespannt. Ich plaudere da so ein bisschen aus dem Nähkästchen.
Sebastian: Wir fangen mal an mit den Modellen. Natürlich, Fable haben sie uns jetzt gestrichen,
Sebastian: aber hey, wir haben ja immer noch
Sebastian: den Opus 4.8 und wir haben immer noch GPT-5.5 und wie sie alle heißen.
Sebastian: Ja, die Dinger sind super und die können auch jede Menge Probleme lösen.
Sebastian: Auf der anderen Seite schaffen sie wieder einen Haufen Probleme,
Sebastian: weil ich zum Beispiel nutze nicht immer die neuesten und besten und tollsten
Sebastian: Modelle. Erstens, weil es ins Geld geht und in die Tokens geht.
Sebastian: Und zweitens finde ich, gerade die neuesten Modelle sind teilweise sehr mitteilsam
Sebastian: und so sieht der Code auch teilweise aus.
Sebastian: Also die besten Ergebnisse erzielt bei mir im Moment ein ganz einfaches GPT-5.4,
Sebastian: also eine Generation älter und das funktioniert völlig solide.
Sebastian: Also man muss auch so ein bisschen ausprobieren, schauen, wie arbeitet man selbst
Sebastian: damit, wie interpretiert das Modell die Prompts, wie mitteilungsbedürftig ist es,
Sebastian: wie schaut die Ausgabe aus, wenn man sich zum Beispiel was erklären lässt.
Sebastian: Da finde ich die Opus-Modelle zum Beispiel wieder viel besser,
Sebastian: weil die viel schöner strukturieren.
Sebastian: Auch da kann man mit einem entsprechenden Prompt helfen.
Sebastian: Aber wenn das Modell das von sich aus schon mitbringt, warum nehmen wir es dann nicht mit?
Sebastian: Also auch da, das Modell ist nur die halbe Miete.
Sebastian: Wie gehe ich mit dem Modell um und was habe ich für einen Harness,
Sebastian: also für eine Entwicklungsumgebung? Und wie unterstützt mich diese Entwicklungsumgebung?
Sebastian: Ist extrem wichtig und genau da werden wir auch nochmal einen eingehenden Blick
Sebastian: drauf werfen, was für Elemente von so einer Entwicklungsumgebung helfen uns denn wirklich.
Sebastian: Ja, genau das schauen wir uns jetzt an.
Sebastian: So, Coding Agents da gibt es ja auch wie Sand am Meer.
Sebastian: Und ich habe etliche ausprobiert und bin jetzt im Moment bei Cursor hängen geblieben.
Sebastian: Ich bin schon etwas länger bei Cursor hängen geblieben, auch da,
Sebastian: wo es noch cool war, wo es noch nicht zu SpaceX gehört hat, wo es noch nicht
Sebastian: von Elon gekauft wurde, weil es einfach eine sehr schöne, runde Sache ist.
Sebastian: Und grundsätzlich hat es ja mal angefangen mit der Autocompletion.
Sebastian: Also GitHub Copilot zu den Ursprungszeiten war eine bessere,
Sebastian: magischere Autocompletion.
Sebastian: Dann irgendwann kam dann das Chatfenster und jetzt erklär mir mal diese Funktion.
Sebastian: Ja, die Funktion zählt zwei Werte zusammen und gibt den berechneten Wert zurück.
Sebastian: Ja, das ist mächtig, das kann sehr viel, aber hat noch nichts mit einem Coding-Agent
Sebastian: zu tun, weil ich könnte theoretisch das Ganze auch mit einem Chat-GPT oder Ähnlichem schaffen.
Sebastian: Wo es wirklich interessant wird, ist mit einem Agent, der in das Ökosystem eingebettet
Sebastian: ist, mit dem ich kommunizieren kann, der selbst planen kann,
Sebastian: der auf Ressourcen zugreifen kann,
Sebastian: der selbst Entscheidungen trifft bis hin zum Force-Push,
Sebastian: wo es wirklich gruselig wird.
Sebastian: Warum sage ich das? Ich habe mit einem Agent auch schon Commit-Historien Kosmetik betrieben.
Sebastian: Das mache ich meistens zum Wachwerden, weil danach bist du wach,
Sebastian: wenn das Ding in deiner Git-Historie rumackert und zum Schluss von dir verlangt,
Sebastian: hey, und jetzt mach mal bitte einen Git-Force-Push, damit auch die History umgeschrieben wird.
Sebastian: Beziehungsweise, ihr kennt ja wahrscheinlich den YOLO-Mode.
Sebastian: Wo das Modell dann alles darf und der macht halt dann einfach munter vor sich
Sebastian: hin den Force-Push in euer Repo und das finde ich tatsächlich schon ein bisschen grenzwertig.
Sebastian: Gleiches, was für Git gilt, gilt natürlich auch für Ticketsystemen,
Sebastian: für Filesystemen, für alles, wo man halt nicht unbedingt ein autonomes Ding
Sebastian: alles Mögliche machen lassen möchte, weil sonst plötzlich irgendwelche Dateien
Sebastian: fehlen oder irgendwelche Mailpost-Fächer ausgeleert sind oder Sonstiges.
Sebastian: Ihr kennt ja die Geschichten.
Sebastian: Was macht ein Agent aus?
Sebastian: Ich gehe bei der Arbeit mit dem Agent eher, also,
Sebastian: ich beschreibe, was ich erreichen möchte. Ich sage dem Agent nicht,
Sebastian: jetzt schreibe ein If-Statement, dann schreibe eine Schleife und dann mache
Sebastian: hier ein Input-Element hin, sondern ich beschreibe, was ich erreichen möchte
Sebastian: und warum ich es erreichen möchte, einfach um das Ganze abstrakt zu halten,
Sebastian: und um dem Agent auch ein bisschen Freiheit zu geben, um das Ziel bestmöglich zu erreichen.
Sebastian: Und dann braucht das Ding natürlich Werkzeuge, um das Ökosystem zu kennen,
Sebastian: um die Code-Basis zu kennen, um die Git-Historie oder Versionskontroll-Historie
Sebastian: zu kennen, um, wenn ich im Web unterwegs bin,
Sebastian: meinen Frontend fernzusteuern, Tests auszuführen und so weiter.
Sebastian: Also ich brauche eine ganze Latte von Werkzeugen, weil diese Werkzeuge auch
Sebastian: das Ergebnis deutlich besser machen als ohne.
Sebastian: Und in den meisten Fällen lohnt es sich, in Schleifen zu arbeiten.
Sebastian: Also nicht der erste Wurf und dann fertig, sondern der Agent dreht Schleifen,
Sebastian: refined, kostet natürlich wieder einen Haufen Tokens, aber das Ergebnis ist dann meistens besser.
Sebastian: Das kann ich mit entsprechenden Reasoning-Modellen und,
Sebastian: entsprechenden Anweisungen hinterlegen und dann arbeitet das Ding und ich kann
Sebastian: gemütlich einen Kaffee trinken gehen und wenn ich dann wieder zurück bin,
Sebastian: ist der Agent fertig und alles ist wunderbar.
Sebastian: In der Realität wartet der Agent dann bei mir immer auf eine Eingabe.
Sebastian: Willst du bla bla bla Git-Historie oder sonst irgendwas und dann muss ich ihm
Sebastian: trotzdem beim Coden zuschauen.
Sebastian: Apropos, jetzt mal interaktive Umfrage, wie viele Aufgaben, also wenn ihr agentisch
Sebastian: arbeitet, wie viele Aufgaben lasst ihr von so einem Agent parallel abarbeiten?
Sebastian: Eins, zwei, viele und wenn viele, dann wie viele?
Sebastian: Ja, genau. Und,
Sebastian: der Agent trifft Entscheidungen in einem bestimmten vorgegebenen Rahmen.
Sebastian: Also bei mir darf er nicht voll autonom arbeiten, weil ich bin ein ziemliches
Sebastian: Weichei, wenn es um sowas geht.
Sebastian: Ich habe ganz viele Gespräche in letzter Zeit gehabt mit ganz,
Sebastian: ganz vielen Entwicklern, sowohl älteren Semestern, also Senior-Entwicklern als
Sebastian: auch mit jüngeren Leuten, Studenten.
Sebastian: Wird uns KI irgendwann ersetzen? Weiß man nicht.
Sebastian: Ich meine, wir müssen im Hier und Jetzt leben und aktuell ist ein Agent nur
Sebastian: so gut wie die Entität, die ihn führt,
Sebastian: und wenn ihr so einen Agent sehr gut führt, dann kommt da auch eine saubere Architektur raus.
Sebastian: Und es ist aber bedingt kein Ersatz für Entwickler. Viele Firmen meinen,
Sebastian: es ist ein Ersatz für Entwickler. Irgendwann werden die aber wahrscheinlich
Sebastian: auch aufwachen, wenn sie sich selber den Ast abschneiden.
Sebastian: Das sind alles Themen für die Glaskugel, für mich im Moment in meiner Realität.
Sebastian: Ihr seht, ich bin vorsichtig, weil es gibt Leute, die setzen eiskalt nur noch
Sebastian: auf agentische Entwicklung.
Sebastian: Da bin ich kein Freund davon, gerade wenn es um längerfristige, stabile Produkte geht.
Sebastian: Für mich ist es ein Werkzeug, ein mittlerweile unverzichtbares Werkzeug,
Sebastian: ein Werkzeug, das mich gefühlt schneller macht, wenn ich es richtig benutze,
Sebastian: und ein Tool, das Fehler macht.
Sebastian: Und zwar schnell und viel. Und da muss man eben aufpassen.
Sebastian: Dann, Grundsatzdiskussion, habe ich lieber einen CLI-Agent,
Sebastian: den ich als Hacker von der Kommandozeile aus bediene, weil es cool aussieht,
Sebastian: oder in einer realistischeren Umgebung, den ich einfach für das Batch-Processing
Sebastian: nutze, für eine alternative Eingabeart und Weise, wenn ich jetzt zum Beispiel
Sebastian: meinen CLI-Agent an ein Ticketing-System dranhänge und mit dem,
Sebastian: Agent nur noch über Tickets kommuniziere, die dann sehr gut verpackt sind.
Sebastian: Wenn ich irgendwas automatisieren möchte, irgendwelches Batch Processing,
Sebastian: hier Beispiel, nimm diese 200 Dateien und baue die nach folgendem Schema um,
Sebastian: dann lasse ich das Ding über Nacht laufen und dann ist es gut,
Sebastian: bei 200 Dateien brauchen wir noch nicht über Nacht reden,
Sebastian: aber das kann dann einfach dauern und wenn es fertig ist, ist es fertig.
Sebastian: Die andere Sache ist ...
Sebastian: Der Hendrik wollte was sagen.
Hendrik: Ja, aber nur ganz kurz. Wir haben erste Ergebnisse.
Hendrik: Also ich habe hier eine Antwort. Da hat jemand noch keine Erfahrung im Parallelen abarbeiten.
Hendrik: Und da kommt die zweite Antwort, dass jemand da auch noch keine Erfahrung hat.
Hendrik: 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.
Sebastian: Das ist nämlich genau der Punkt.
Hendrik: Ihr müsst entschuldigen, wir haben immer so einen leichten Zeitversatz,
Hendrik: deswegen purzeln solche Ergebnisse immer so ein bisschen zeitverzögert.
Sebastian: Aber das ist tatsächlich genau der Punkt, der mich auch immer stresst.
Sebastian: Und ich bin ein sehr ungeduldiger Mensch. Ich mache dann auch immer Sachen parallel.
Sebastian: Und blöderweise kommen die dann immer gleichzeitig zurück. Und dann hast du
Sebastian: drei Häufchen Arbeit auf dem Tisch liegen oder fünf Häufchen Arbeit auf dem
Sebastian: Tisch liegen, zwischen denen du hin und her switchen musst.
Sebastian: Und ganz ehrlich, das stresst mich unheimlich, weil die Agenten,
Sebastian: die sitzen um mich rum und warten auf Input.
Sebastian: 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
Hendrik: 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.
Sebastian: Ich arbeite sehr gern mit IDE-Agenten, weil die vermitteln mir das Gefühl,
Sebastian: dass ich noch Kontrolle über den Prozess hätte. Ich sehe den Code,
Sebastian: ich kann in den Code eingreifen.
Sebastian: Ich habe mein Prompt-Interface.
Sebastian: Blöderweise wird das immer größer. Also der Code-Anteil von meinem Screen,
Sebastian: der wird immer kleiner, weil ich mich echt schon langsam sehr dran gewöhne,
Sebastian: intensiv zu prompten, Iterationen zu drehen und im Nachhinein dann den Code zu reviewen.
Sebastian: Aber das Gefühl, das integriert zu haben, ist für mich einfach die rundere Sache.
Sebastian: Und deswegen persönlich Präferenz, gib mir entweder eine CLI oder so einen IDE-Agent,
Sebastian: ich nehme immer den IDE-Agent.
Sebastian: Zumindest für die nächsten zwei Wochen. Gut, dann fangen wir mal mit den Dingen
Sebastian: an, die ich für wichtig halte und das eine oder das erste sind Rule Files.
Sebastian: Rule Files sind
Sebastian: im weitesten Sinne eine Erweiterung für Prompts. So ein Prompt ist,
Sebastian: ich habe eine Aufgabe und die löst du mir jetzt bitte.
Sebastian: Eine Rule-File ist was Epischeres, was Dauerhafteres, das ihr in den Raum stellt
Sebastian: und das Verhalten von einem Agent beeinflusst.
Sebastian: So eine Rule-File umreißt das Verhalten von einem Agenten.
Sebastian: Das ist im weitesten Sinne so etwas wie ein System-Prompt. Also,
Sebastian: dass das Modell in eine bestimmte Richtung dreht, bestimmte Grenzen setzt.
Sebastian: Das Problem ist, das sind weiche Grenzen. Also, mehr Empfehlungen,
Sebastian: weil der Agent kann sich daran halten, kann sich aber auch darüber hinwegsetzen.
Sebastian: Ihr könnt damit beeinflussen, wie das Ding denkt, wie es arbeitet,
Sebastian: was bevorzugt wird, was vermieden wird und wie Entscheidungen getroffen werden.
Sebastian: Wir haben im Team eine Rule-File, die fürs Projekt zentral abgelegt ist und
Sebastian: jeder darf diese Rule-File editieren.
Sebastian: Jeder ist dazu eingeladen, diese Rule-File zu verbessern und immer wenn irgendwas
Sebastian: nervt oder irgendwas zu verbessern ist, kommt das in die Rule-File rein.
Sebastian: Diese Rule-Files, Agent-Files, die folgen einem Standard, der ist hier verlinkt,
Sebastian: den könnt ihr euch dann im Nachgang anschauen.
Sebastian: Es gibt mehrere Coding-Agenten, die sich daran halten und bei denen,
Sebastian: die sich nicht daran halten, gibt es sehr ähnliche Konzepte.
Sebastian: Hat sich durchgesetzt, hat sich als gut bewährt, deswegen schaut euch das auf jeden Fall an.
Sebastian: Was steht in so einer Rule-File drin?
Sebastian: Architekturregeln, allgemeingültige Regeln.
Sebastian: Eine React-Komponente sieht immer so und so aus.
Sebastian: Wenn ich eine Funktion, ein Modul, eine Klasse, ein was auch immer schreibe,
Sebastian: dann möchte ich, dass das immer so aussieht. Blueprints, Stilregeln.
Sebastian: Wie sind meine Variablen gestaltet? Also jetzt, weiß ich nicht,
Sebastian: keine Abkürzungen oder sonst irgendwas.
Sebastian: Testregeln. Also wie gehe ich mit Tests um? Wie schauen meine Tests aus?
Sebastian: Wie sind sie strukturiert? Welchen Patterns folgen die?
Sebastian: Sprache und Ton. Ihr könnt in so einer Rulefile dem Agenten sagen,
Sebastian: was ihr für einen Kommunikationsstil erwartet.
Sebastian: Also kurzes, analytisches Antworten, was auch immer.
Sebastian: Das hilft recht gut. Also, ich habe da teilweise auch reingeschrieben,
Sebastian: halt dich bitte kurz, mich interessiert das außenrum nicht, komm auf den Punkt.
Sebastian: Dann alles, was Konventionen angeht, alles, wo ihr sagt, das sind Regeln,
Sebastian: die für uns als Entwickler gelten, die gelten bitte auch für die AI.
Sebastian: Führ keine neuen Patterns ein. Halt dich an die bestehende Code-Basis.
Sebastian: Alles, was man halt so in einem länger laufenden Projekt haben möchte,
Sebastian: kommt in so eine Rule-File rein.
Sebastian: Wir hatten aber auch schon den Fall, da haben genau diese Regeln auch wieder zurückgeschossen, und,
Sebastian: da haben wir dann auch explizit gesagt, so und jetzt vergiss mal,
Sebastian: was in dem Rule-File steht und prob dich komplett aus, dann kam das Modell mit
Sebastian: einer sehr guten, sehr innovativen Idee um die Ecke und hat tatsächlich unser
Sebastian: Problem deutlich schicker gelöst als
Sebastian: mit unserer sehr strikten Regel.
Sebastian: Was nicht reingehört sind, Sachen, die ihr einmalig braucht,
Sebastian: irgendwelche Details, irgendwas Temporäres.
Sebastian: Ihr müsst da immer so ein bisschen aufpassen, weil alles, was ihr dem Modell
Sebastian: zur Verfügung stellt, verstopft den Kontext.
Sebastian: Moderne Modelle haben einen riesengroßen Kontext, die haben eine Million oder
Sebastian: teilweise zehn Millionen Tokens an Kontext, die können damit schon umgehen.
Sebastian: Das Problem ist, je voller der Kontext läuft, desto schlechter werden die Antworten.
Sebastian: Es gibt auch Erklärungen, warum das so ist, dass der Anfang des Kontexts sehr
Sebastian: gut ist und das Ende des Kontexts sehr gut ist und in der Mitte flacht er dann ab.
Sebastian: Es gibt auch wissenschaftliche Auswertungen und ganz viele Messungen darüber.
Sebastian: Da suchmaschint einfach drüber nach bzw.
Sebastian: fragt die AI eurer Wahl.
Sebastian: Der Sascha schreibt gerade, er hat noch nie mit Rule Files gearbeitet.
Sebastian: Anstatt jedes Mal migriere mir die Komponente in eine Vue 3 Komponente mit
Sebastian: Composition API und Script Setup Pattern,
Sebastian: kann man diesen Prompt einmal speichern und den immer wieder abfeuern.
Sebastian: Aber natürlich kann man sowas auch in den Rule-File mit reinpacken.
Sebastian: Wenn du gerade in der Migration bist, dann hilft das natürlich hervorragend.
Sebastian: Dann sagst du bloß noch, okay, jetzt kümmere dich um diese Komponente und dann
Sebastian: wird die Rule-File berücksichtigt und dann
Sebastian: sparst du dir genau dieses Ich-wiederhole-mich-immer-und-immer-wieder.
Sebastian: Ja, gute Beispiele, schlechte Beispiele. LLMs arbeiten generell sehr,
Sebastian: sehr gut mit Beispielen.
Sebastian: Also je mehr Beispiele ihr, da müsst ihr auch wieder aufpassen,
Sebastian: weil je mehr Beispiele ihr macht, desto mehr wird euer Kontext voll.
Sebastian: Ein paar sinnvolle, stellvertretende Beispiele, die Prinzipien zeigen und nicht
Sebastian: konkrete Lösungen, helfen extrem gut. Also Sascha, in deinem Fall,
Sebastian: wie sieht deine perfekte Komponente aus?
Sebastian: Liegt in der Rulefile und dann hält sich das Modell in den meisten Fällen auch dran.
Sebastian: Wie ausführlich? Nicht so ausführlich sollte die Rulefile sein,
Sebastian: weil vermüllt euch den Kontext.
Sebastian: Klar, prägnant. Man hat mir gesagt, ich soll nicht so höflich sein.
Sebastian: Ich sage trotzdem immer bitte und danke zu meinem Modell, weil irgendwann übernehmen
Sebastian: die Maschinen die Herrschaft und da muss man freundlich sein.
Sebastian: Aber seid bei diesen Rule Files wirklich auf den Punkt, weil alles,
Sebastian: was ihr drumherum schreibt, verwäscht wieder die Aussagekraft eurer Regeln.
Sebastian: Und gerade bei solchen Regeln müsst ihr sehr präzise arbeiten.
Sebastian: Wenn ihr feststellt, dass eure Regeln nicht ziehen, dann war sie entweder nicht
Sebastian: gut formuliert oder zu wenig Beispiele.
Sebastian: Also da kann man noch nachsteuern und das ist einfach ein Entwicklungsprozess.
Sebastian: Das ist kein, ich schreibe jetzt die Rule-File und fertig, sondern es ist ein Prozess.
Sebastian: Und je länger ihr daran arbeitet, desto mehr hängt ihr an euren Rule-Files.
Sebastian: Ja, also immer wenn euch irgendwas nervt, dann schmeißt es in die Rulefile.
Sebastian: Immer wenn ihr euch wiederholt oder wenn ihr, also ich meine,
Sebastian: der Sascha hat das perfekte Beispiel gebracht, immer wenn euch irgendwas nervt,
Sebastian: immer wenn es, wenn es sich wiederholt, in die Rule File rein und gut ist.
Sebastian: Dann haben wir Skills. Skills ist der Fancy Shit, weil Skills werden getauscht
Sebastian: wie Panini-Bilder auf dem Schulhof.
Sebastian: Wir haben mittlerweile einen Skill Marketplace.
Sebastian: Skills sind auch wieder so eine Art Standard. Auf AgentSkills.io findet ihr da mehr Informationen.
Sebastian: Das sind im Prinzip kleine Bausteine.
Sebastian: Das können fast so eine Art Prompt-Template sein.
Sebastian: Ihr könnt aber auch Executables oder Skripte in die Skills mit reinpacken,
Sebastian: Python-Skills, TypeScript-Skills.
Sebastian: Die können dann auch Code aus, oder die führen dann Code aus,
Sebastian: und das sind kleine Hilfs-Skripte, die euer Agent ranzieht, um Probleme zu lösen.
Sebastian: So ein Skill hat eine Beschreibung, damit das Modell weiß, wann es einsetzen
Sebastian: soll, und so könnt ihr ganz viele verschiedene Skills in eure IDE mit reinpacken,
Sebastian: in euren Agent mit reinpacken, und ja, die werden dann genutzt.
Sebastian: Ja,
Sebastian: bei Unterscheidung zwischen Rules und Skills, Rules sind Prinzipien,
Sebastian: die sind allgemeingültiger, die stehen
Sebastian: für allgemeine Anweisungen, für allgemeine Regeln, nicht für die konkreten Umsetzungsschritte.
Sebastian: Die Skills auf der anderen Seite, die sind sehr konkret, sehr codenah, sehr greifbar,
Sebastian: und kleine Häppchen, kleine zielgerichtete Häppchen.
Sebastian: Wenn ihr mal so ein bisschen im Internet recherchiert, ihr findet zu allem Skills.
Sebastian: Also mir ist es mittlerweile schon fast ein bisschen zu viel,
Sebastian: aber es ist jedem selbst überlassen.
Sebastian: Schaut euch da einfach mal ein bisschen um.
Sebastian: Auch da ist es so ein bisschen so, ihr müsst ein bisschen aufpassen,
Sebastian: dass ihr euren Agent nicht überfrachtet.
Sebastian: Wenn ihr 400 Skills installiert habt, irgendwann ist es zu viel und dann fängt euer Agent an, ja,
Sebastian: für den Bereich könnte ich jetzt diesen Skill benutzen oder diesen Skill und
Sebastian: dann wird es wieder ein bisschen flaky.
Sebastian: Deswegen meiner Meinung nach ein paar, eine Handvoll Skills,
Sebastian: die eure Probleme tagtäglich lösen, die zielgerichtet sind, da fährt man tatsächlich am besten.
Sebastian: Ja, teilen, drüber reden, ihr kommt im Moment eh nicht dran vorbei.
Sebastian: Dann das nächste Thema, MCP. MCP ist wie Skills, nur nicht mehr ganz so cool.
Sebastian: MCP ist grundsätzlich erstmal ein Protokoll, um LLMs mit der Außenwelt zu verbinden.
Sebastian: In dem Kontext ist in den meisten Fällen von Tools die Rede.
Sebastian: Also Funktionen, die ein LLM aufrufen kann, die bestimmte Funktionalität zur Verfügung stellen.
Sebastian: Jeder, der auch nur ein bisschen was auf sich hält, bietet mittlerweile einen
Sebastian: MCP-Server an. So einen MCP-Server könnt ihr auch selber schreiben.
Sebastian: Das ist im Prinzip ein entweder lokal laufender Server oder ein Remote über
Sebastian: HTTP angebundener Server,
Sebastian: den das LLM kennt, den das LLM anrufen kann und dieser Server führt eine Funktion
Sebastian: aus und stellt das Ergebnis oder den Seiteneffekt dieser Funktion dem LLM zur Verfügung.
Sebastian: Ihr findet mehr Informationen unter
Sebastian: Contextprotocol.io, da ist der Standard und alles, was ihr wissen müsst dazu.
Sebastian: Ja, hilft auch wieder, um Halluzinationen zu reduzieren, hilft dabei,
Sebastian: euer Ökosystem anzubinden und ist ganz hilfreich in vielen Fällen.
Sebastian: Ich habe eine kleine Auswahl an MCP-Servern, dass ihr einfach so einen Eindruck
Sebastian: mal kriegt, was es denn gibt.
Sebastian: Es gibt einen GitHub-MCP-Server, es gibt auch einen GitLab-MCP-Server.
Sebastian: Grundsätzlich stellt dieser MCP-Server die Schnittstelle eurer Git-Plattform
Sebastian: zur Verfügung. Ihr könnt Branches aufmachen, Pull-Requests stellen und so weiter.
Sebastian: Und das macht euer LLM automatisiert mit den Privilegien, die ihr diesem Ding gebt.
Sebastian: Also da müsst ihr ein bisschen aufpassen. Dann Ticketsystem.
Sebastian: Ich weiß, nicht jeder mag Atlassian-Produkte, aber das ist halt jetzt hier stellvertretend.
Sebastian: Die bieten auch einen MCP-Server für Jira und Confluence und da kann man auf
Sebastian: Tickets zugreifen und wunderbare Dinge machen.
Sebastian: Und da kann man auch Dinge automatisieren lassen, die man selber nicht machen möchte.
Sebastian: Also zum Beispiel, jetzt setzt den Status dieses Tickets automatisch auf weiß
Sebastian: der Teufel was – und dann kümmert sich euer Agent.
Sebastian: File-System. Es gibt einen MCP-Server für euer lokales Dateisystem.
Sebastian: Auch da müsst ihr wieder ein bisschen vorsichtig sein, weil es gibt auch die
Sebastian: Möglichkeit, Dateien zu löschen, Verzeichnisse zu löschen.
Sebastian: Da müsst ihr bitte ein bisschen vorsichtig sein, weil ansonsten ist euer System
Sebastian: zwar sehr leer und hat sehr viel Speicherplatz, aber ihr habt nicht mehr sehr
Sebastian: viel Freude mit eurem System. Okay.
Sebastian: Browser. Google hat zum Beispiel den Chrome Developer Tools MCP Server.
Sebastian: Mit dem kann man wunderbare Sachen machen. Da müsst ihr bloß ein bisschen aufpassen,
Sebastian: weil manche Agents drehen sehr gerne Schleifen und die probieren sehr gerne Dinge aus.
Sebastian: Und ich bin schon sehr, sehr viele Tokens in so einem Browser-MCP-Loop losgeworden,
Sebastian: weil der die Webseite einfach wunderschön fand und überall hingeklickt hat.
Sebastian: Also auch da haltet das Ding so ein bisschen im Zaum.
Sebastian: Frage vom Thomas. Haben wir den Skill Marketplace selbst gebaut oder als Buy-In-Lösung?
Sebastian: Wir haben es selbst gebaut. Wir haben da einfach ein Git-Repo dafür gemacht
Sebastian: und da kann sich jeder bedienen.
Sebastian: Also die pragmatische Lösung.
Sebastian: So, dann Aufgaben zuschneiden. Das finde ich tatsächlich extrem wichtig.
Sebastian: Ich bin jemand, der gerne Kontrolle über das hat, was passiert,
Sebastian: aus zwei Gründen. Wenn die Aufgabe
Sebastian: jetzt groß wird, habe ich sehr viel zu lesen, sehr viel zu verstehen.
Sebastian: Wenn ich meine Aufgaben kleiner schneide, muss ich nicht so viel arbeiten,
Sebastian: also kurzfristig nicht so viel arbeiten.
Sebastian: Wir hatten auch andere Aspekte, und zwar kleine Aufgaben haben kleinen Kontext.
Sebastian: Ich gebe nicht zu viel Freiheitsgrade, ich lasse dem Modell nicht zu viel Raum,
Sebastian: um sich kreativ zu entfalten, weil Kreativität manchmal halt nicht so geil ist.
Sebastian: Kleine Aufgaben, ich bin explizit und das Ding macht nicht zu viele Schritte
Sebastian: auf einmal, also das ist wirklich so, dass ...
Sebastian: Das, das ist das Gebot der Stunde. Macht kleine Aufgaben, wenn euch eure Nerven wichtig sind.
Sebastian: Okay, ich gehe da jetzt sehr viel drauf ein; unterm Strich: schaut, dass ihr kleine Aufgaben macht.
Sebastian: Was ist für mich eine gute Aufgabenbeschreibung? Was will ich für ein Ziel erreichen?
Sebastian: Wie soll der Zustand meines Systems am Ende sein?
Sebastian: Was brauche ich für Kontext? Und da habe ich einen Kollegen, der ist wunderbar.
Sebastian: Der ist ein Kontext-Engineer vor dem Herrn und zwar nicht das, was man auf LinkedIn
Sebastian: findet, sondern der schleift den Kontext für die Aufgaben so perfekt,
Sebastian: dass das Modell alle Informationen hat, die es braucht und die Aufgaben auf den Punkt erledigt.
Sebastian: Woran merkt man das? Im Tokenverbrauch.
Sebastian: Also der ist wirklich next level und also der hat wirklich den Kontext verstanden
Sebastian: und kann es extrem gut nutzen.
Sebastian: Und ich schaue mir da immer so ein bisschen was davon ab. Das heißt,
Sebastian: ich versuche auch dem Modell zu sagen, okay, bewege dich in diesem Verzeichnis,
Sebastian: nimm diese Datei, nimm diesen Abschnitt dieser Datei.
Sebastian: Je mehr Zeit ihr in die Vorbereitung investiert, desto weniger böse Überraschungen kriegt ihr.
Sebastian: Wie ich zum Beispiel, wo ich jetzt noch die letzten Tage Anti-Patterns ausprobiert
Sebastian: habe, da hat mir das Modell meine API-Beschreibung, die ich aus dem Backend
Sebastian: als Referenz rüberkopiert habe, kurzerhand einfach geändert.
Sebastian: Also ich hatte so ein OpenAPI-Dokument, REST-Beschreibung und das Modell meinte,
Sebastian: eigentlich könnte ich ja die Server-API noch so ein bisschen optimieren,
Sebastian: weil ich brauche da ein paar Informationen.
Sebastian: Ja, das war nicht Ziel der Übung, weil Ziel der Übung war einfach nur dem Modell
Sebastian: die Dokumentation zur Verfügung zu stellen, was denn alles da ist und was denn
Sebastian: vom Backend kommt, aber nicht zu sagen, okay, jetzt schreibt bitte das Backend.
Sebastian: Ja, auch wieder schlechtes Prompting.
Sebastian: Das hätte ich lösen können, indem ich gesagt hätte, pass auf,
Sebastian: nimm das Ding als Referenz und lass um Himmels Willen die Finger davon.
Sebastian: Hat dann der Folge Prompt gelöst, hat mich aber wieder zigtausend Tokens gekostet.
Sebastian: So, und dann will ich natürlich dann auch festlegen, woran erkenne ich,
Sebastian: dass die Aufgabe zufriedenstellend gelöst ist.
Sebastian: Es gibt Tests dafür, alle anderen Tests laufen weiter, es ist dokumentiert und so weiter.
Sebastian: Sowas kann natürlich auch wieder ein Stück weit in die Rule File eingehen,
Sebastian: weil das ist in den meisten, also diese non-funktionalen Anforderungen sind
Sebastian: in der Regel die gleichen. Da müsst ihr euch einfach rantasten.
Sebastian: So, was wollen wir da nicht? Wir wollen nicht die Geschichte unseres Projekts,
Sebastian: wir wollen nicht die Ticket-Historie inklusive aller Kommentare und sonst noch was.
Sebastian: Ein Wunschzettel a la, ja, und wenn du schon mal dabei bist,
Sebastian: dann refactor auch noch das. Und übrigens, das würde auch noch mal zu tun sein.
Sebastian: Zu viele Dateien auf einmal zu referenzieren, ist auch nicht hilfreich,
Sebastian: weil wenn ihr sehr viele Referenzen reinkippt, dann ist erstmal der Kontext voller.
Sebastian: Und zweitens habe ich festgestellt, wenn da viele Dateien drin sind,
Sebastian: dann tobt sich der Agent auch sehr gerne an vielen Dateien aus.
Sebastian: Also versucht euch wirklich auf das Relevante zu beschränken.
Sebastian: Ja, also Refactor mir mal das Ding ist eher schlecht.
Sebastian: Wenn ihr sagt, hier, ich habe Authentifizierung und jetzt mach mal hier Validate
Sebastian: Token und baue das um nach diesen und jenen Kriterien, die API soll so und so
Sebastian: aussehen, dann kriegt ihr ein recht gutes, recht
Sebastian: überprüfbares Ergebnis und ihr braucht nicht das smarteste, teuerste Modell,
Sebastian: sondern ihr könnt da auch ein, zwei Stufen runtergehen und ein
Sebastian: kostengünstiges, doofes, leichtgewichtiges Modell nutzen.
Sebastian: Also je expliziter ihr seid, desto weniger muss das Modell für euch smart sein.
Sebastian: Ist auch gut für den Geldbeutel.
Sebastian: Wenn ihr das Ganze in den Workflow, in den Sequenz gießt, ist es einfach hilfreich.
Sebastian: Ich habe festgestellt, wenn ich die Leine nicht kurz halte, dann flippt mein
Sebastian: Agent aus und je höher-tierig, also je höher-levelig das Modell ist,
Sebastian: desto mehr flippt es aus.
Sebastian: Deswegen Grenzen setzen. Und mit Grenzen setzen bin ich mittlerweile sehr gut
Sebastian: und sehr vorsichtig, weil ich eng das Modell lieber mehr ein,
Sebastian: als dass ich zu viel Freiraum lasse.
Sebastian: Ich habe heute wieder einen Anti-Pattern ausprobiert. Das hat mich 8 Millionen Tokens gekostet.
Sebastian: Ich habe gesagt, so, und jetzt bauen wir das Ding mal um.
Sebastian: Also groben Umriss, was ich haben wollte und dann let's go.
Sebastian: Also, ja, das ist erstmal für mich ungewöhnlich lange gelaufen.
Sebastian: Also, ich glaube, so 10 Minuten, Viertelstunde.
Sebastian: Ja, da war auch Tests, Ausführungen und so weiter dabei. Aber ich werde dann
Sebastian: immer schon ein bisschen nervös, weil ich mir denke, boah, wo läuft er denn
Sebastian: jetzt schon wieder? Was macht er denn da hinten? Das geht ihm doch überhaupt nichts an.
Sebastian: Deswegen Grenzen setzen. Das ist gut. Gut für die Nerven.
Sebastian: Ja, und ich bin einfach ein Kontrollfreak, wenn es um LLMs geht. Ich habe immer so
Sebastian: diese Horror-Stories im Kopf.
Sebastian: Ja, der Agent löscht das Dateisystem oder löscht den Posteingang oder weiß der
Sebastian: Teufel was. Ich traue diesen Dingen halt nicht.
Sebastian: Und ja, ich lasse ihn auch ab und zu mal forced pushen und die History umschreiben.
Sebastian: So, ein Thema, das dank GitHub Microsoft jetzt immer zunehmend wichtiger wird, ist Kostenkontrolle.
Sebastian: Die wenigsten unter euch werden Unlimited Tokens noch haben und die,
Sebastian: die es haben, lehnt euch zurück und genießt das Schicksal der anderen Leute.
Sebastian: Warum ist es wichtig? Weil immer mehr Anbieter auf den Trichter kommen werden,
Sebastian: sie wollen Geld verdienen.
Sebastian: Anthropic macht so, du hast das Abo, du hast ein Kontingent, super,
Sebastian: aber wenn du das Kontingent nicht hättest, dann würde dich das so und so viel Geld kosten.
Sebastian: Das ist so der erste Schritt in Richtung, übrigens, es kann empfindlich teuer werden.
Sebastian: GitHub oder Microsoft Copilot hat es vorgemacht, die haben von diesem Kontingentmodell,
Sebastian: Abo-Modell, Anfrage-basierten Modell auf härteren Limits umgeschaltet.
Sebastian: Mittlerweile, ich habe nebenbei so ein GitHub Copilot Pro Abo noch am Laufen,
Sebastian: das kannst du quasi nicht nutzen, weil es um einen Tag aufgebraucht ist.
Sebastian: Und deswegen wird Kostenkontrolle einfach zunehmend wichtiger.
Sebastian: Je größer und vager eure Prompts sind, desto teurer wird es.
Sebastian: Je unklarer eure Ziele sind, desto mehr Schleifen dreht ihr,
Sebastian: desto mehr Tokens kostet.
Sebastian: Je größer euer Kontext ist, desto teurer werden die Requests.
Sebastian: Ihr müsst da so ein bisschen unterscheiden zwischen Input-Tokens,
Sebastian: die günstig sind oder Cached-Input-Tokens, die noch günstiger sind und Output-Tokens,
Sebastian: die richtig teuer sind, also teilweise
Sebastian: pro Million Output-Tokens 30 bis 50 Dollar.
Sebastian: Also kann schon ins Geld gehen.
Sebastian: Kleine Aufgaben, haben wir darüber gesprochen.
Sebastian: Und ihr wisst, dass ich ein Fan von gesteuertem Kontext bin.
Sebastian: Auch das ist sehr, sehr gut für Kostensparen.
Sebastian: Ein super Satz. Kontext ist wie RAM. Und ihr wisst, RAM ist vergoldet mittlerweile.
Sebastian: Und je weniger ihr braucht, desto billiger wird es.
Sebastian: Ich habe schon teilweise diese Thinking-Schleifen einfach unterbrochen, weil
Sebastian: ich mir dachte, um Gottes Willen, was macht das Ding jetzt schon wieder? Je mehr
Sebastian: ihr diese Iteration reduziert, desto günstiger wird es wieder,
Sebastian: also kleiner Kontext, kleine Aufgaben, mehr Kontrolle ist günstiger.
Sebastian: Wenn ihr nicht aufs Geld schauen müsst, haut die Tokens raus, solange es noch geht.
Sebastian: Das ist ein Thema, das bei uns sehr viel diskutiert wird. Wer übernimmt die
Sebastian: Verantwortung? Das habe ich auch in letzter Zeit mit ganz vielen Leuten besprochen.
Sebastian: Reviewt ihr euren Code noch? Lasst ihr AI euren Code reviewen?
Sebastian: Ich habe von Leuten gehört, die sagen, der Agent baut den Code,
Sebastian: dann ein anderer Agent überprüft den. Wir haben E-Tests, also go.
Sebastian: Ich finde das ein bisschen gruselig. Also bei uns ist es anders.
Sebastian: Bei uns übernehmen die Leute Verantwortung für das, was ihre Agents gebaut haben.
Sebastian: Klar bauen wir Dinge mit AI, aber die letzte Instanz ist immer noch menschlich und das Produkt, das
Sebastian: die Ladentheke verlässt, da stehen Menschen dahinter und die übernehmen die
Sebastian: Verantwortung. Und wenn dann irgendwas schief geht, dann stehen die auch dafür
Sebastian: gerade und fixen die Probleme.
Sebastian: Da gibt es ganz, ganz viele Diskussionen. Also wenn wir jetzt noch ein bisschen
Sebastian: mehr Zeit hätten, ich könnte euch
Sebastian: da Geschichten über Open-Source-Projekte erzählen. Das ist so herrlich.
Sebastian: Die reichen von pragmatischen Ansätzen wie im Linux-Kernel, macht was ihr wollt,
Sebastian: aber ihr bleibt persönlich in der Verantwortung, bis hin zu anderen Projekten,
Sebastian: die sagen, wir reden nicht über AI.
Sebastian: AI gibt es nicht und wenn du in diesem Projekt arbeiten willst, dann keine AI.
Sebastian: Also von pragmatisch bis realitätsfremd.
Sebastian: Dann auch ganz oft, was ich schon ganz oft gehört habe, AI nimmt mir mein Hobby
Sebastian: weg. Ich darf nicht mehr Code schreiben.
Sebastian: Das ist zu einem bestimmten Grad richtig.
Sebastian: Es ändert sich viel. Also wir schreiben nicht mehr Lines of Code,
Sebastian: sondern wir bauen Konzepte und lassen die AI die Konzepte ausprogrammieren.
Sebastian: Es ändert sich einfach. Und es hat sich in der Softwareentwicklung schon immer
Sebastian: geändert. Es ändert sich jetzt ein bisschen schneller.
Sebastian: Aber das halten wir nicht auf. So. Und jetzt noch ein paar Sachen zum Nachdenken
Sebastian: für euch. So als kleiner Schluss, als kleiner Absacker.
Sebastian: Wie viel Kontrolle geben wir ab? Was darf die AI? Was müssen wir noch selber machen?
Sebastian: Was heißt Qualität? Also hauen wir wirklich AI-Code raus,
Sebastian: weil es günstiger ist, das Ding neu zu bauen oder von der AI die Bugs fixen
Sebastian: zu lassen oder bauen wir noch qualitativ hochwertigen Code und,
Sebastian: in letzter Instanz prüfen wir den Code der AI, der extrem schnell rausgehauen
Sebastian: wird oder prüft die AI die AI und machen wir dann Safety Net.
Sebastian: Also da ist auch sehr, sehr viel Varianz mit drin. Das sind so die Sachen, die
Sebastian: schwirren mir im Hinterkopf,
Sebastian: und ja, damit sind wir am Ende.
Hendrik: Ja, dann würde ich sagen Basti, es gibt keine weiteren Fragen mehr hier im Chat.
Hendrik: Ich danke dir vielmals, dass du hier wieder dabei warst, und ja, wir werden uns
Hendrik: ja auf alle Fälle wiedersehen, von daher freue ich mich darauf!