Heute sprechen wir über einen neuen AI Agents Benchmark Test
und der hat wirklich erstaunliche Ergebnisse
geliefert. Die einen wird es vielleicht
überraschen, die anderen nicht und für manche wird es auf jeden
Fall ein Warnzeichen sein, also viel Spaß Coding Buddies Dein
Podcast rund um Softwareentwicklung und
aktueller Tech News herzlich Willkommen.
Hello, Hello und Herzlich Willkommen zur neuen Folge vom
Coding Buddies Podcast. Es ist natürlich mal wieder Zeit
für ne neue Folge, so wie jede Woche und zwar mit mir, mit Fabi
und dem Tino. Tino sitzt mir gegenüber,
gleiches Grinsen sehr gut, Tino grüßt dich.
Fabi grüßt dich. Ich hab gedacht, wann sagt das,
wann sagt das, wann ist mein Outfit, wann darf.
Ich was sagen? Was geht ab Fabi?
Was geht ab? Ja, was geht ab?
Ich hab gute Laune ja nicht zu, nicht zu dem, nee, wie sagt man
also einfach deshalb, weil man kriegt das ja in der Folge mal
nicht mit, aber bis wir mal anfangen so ne Folge
aufzunehmen, ja dann dauert es immer schon gern mal so 10
Minuten, einfach weil wir noch so n bisschen.
Rum. Ja, ich finde, wir könnten aus
dem, was wir vorher immer machen, ja, wo wir uns selbst
immer gefühlt Bepissen vor lachen.
Könnten wir eigentlich könnten wir eigentlich auch schon
Podcast folgen machen? Aber kriegen wir.
Genauso viel folgen zusammen, aber mir ist das schon
aufgefallen, dass du in letzter Zeit wieder sehr viel sehr gute
Laune hattest. Freut mich natürlich, ist ja
auch sehr gut. Wir hatten ja vor n paar Wochen
noch so immer dieses Wetterthema und Schnee und kalt und bäh und
das hat ja schon deine Laune so n bisschen getrübt.
Also man kann schon sagen, dass deine Laune n bisschen
korreliert mit dem Wetter draußen oder könnte das sein?
Alter nee, finde ich nee, gar nicht.
Nein, damit fangen wir jetzt nicht an.
OK, ich zeig dir jetzt so ne Schneekugel hier Instagram.
Ja, aber ist auch absolut verständlich, weil das Wetter
wird einfach zunehmend besser, es wird wärmer, man kann wieder
mehr draußen machen und das muss sogar ich als developer und du
als Developer zugeben, ja. Es ist auch cool, mal draußen zu
sein und deswegen, ich glaube, das hat schon, das macht schon
was mit dir, oder? Ich hab irgendwann mal ich mein
Sonne draußen ist immer geil ne so ich hab irgendwann glaub ich
auch meiner Podcast folge gesagt ich find es auch geil wenn es
draußen richtig geiles Wetter ist.
Und ich trotzdem immer mal drin sitze.
Also ist auch schon schon geil, weißt du, wenn du so
Rausdrückst, so Sonnenschein, alles gut.
Stimmt, du hattest gesagt, du freust dich dann für die
anderen, die gerade in der Sonne draußen rumlaufen.
Das ist voll selbstlos, ist Ertig.
Hab ich das hab ich auf jeden Fall gesagt.
Doch, doch, ich bin der Meinung, dass, so ist es abgespeichert.
So kam es bei mir an. Ja, du hast ja heute n ganz
cooles Thema mitgebracht und es kann sein, dass wir da auch n
bisschen brauchen. Für deswegen würde ich mal
sagen, lass uns nicht zu lange rumblödeln, sondern jetzt mal so
zu dem Thema kommen. Ich find das Thema klingt sehr
gut, es ist so n Thema was du quasi so von dir aus mitgebracht
hast. Das heißt ich bin heute eher der
ich diskutier mit dir darüber part, aber du musst halt noch
mal so n bisschen sagen worum es geht, ne?
Lass mich nicht im Dunkeln stellen und die Zuhörerinnen und
Zuhörer auch nicht. OK, Tino, könntest du mal ganz
kurz beschreiben. Nee, ich, ich hab jetzt letztens
mitgekriegt so n bisschen gelesen darüber, dass es so n
ich sag mal n neuen Benchmark Test gibt und zwar über AIS ne
also ich mein es gibt ja ganz viele verschiedene LLMS die man
irgendwie verwenden kann. Und da wird ja auch oft immer
gesagt, also logischerweise wird da geguckt, OK, wie gut
performen die, was sollte man da vielleicht nutzen, was hilft
einem am am besten gerade auch für verschiedene, also für
verschiedene Anwendungsfälle, weil du hast ja auch nicht
vielleicht immer, also wir sind natürlich in unserer Coding
Bubble, das ist ja klar, aber es gibt natürlich auch noch andere
Anwendungsfälle, ne, also andere nutzen ja auch AI nicht nur wir,
auch wenn wir vielleicht am meisten AI benutzen, ich weiß es
nicht, wie ich mich nie 2000 Fenster lehn.
Ist ein so ein Anwendungsfall, so Katzenvideos zu machen, die
auf der Veranda stehen und mit irgendwas rumschießen?
Kennst du diese ey ey Videos? Oh Gott, die sind einfach
überall gewesen, eine Zeit lang, das scheint ein Anwendungsfall
zu sein sowas zu machen. Definitiv ein Anwendungsfall,
wahrscheinlich auch Social Media und so.
Es gibt ja mittlerweile auch leider Gottes Podcasts, die
ausschließlich Ai generiert sind.
Ist auf jeden Fall krass, aber die Anwendungsfälle hatte ich
jetzt gerade nicht unbedingt im Kopf, sondern so glückliche
Anwendungsfälle. Weißt du nicht wo der RAM
einfach nur teurer wird, deswegen fand ich noch mal n
bisschen off topic, hatten wir ja die Woche auf Discord oder
was letzte Woche weiß nicht mehr genau, aber ich.
Fand es so witzig mit der Übersetzung, da haben wir noch n
Screenshot bekommen vom System mit den Eigenschaften und dann
wieviel RAM hat denn das Gerät und dann war das einfach
übersetzt mit Schafbock. Fand ich einfach super witzig.
Ein Gigabyte schafbock, 2 Gigabyte schafbock, ja, wenn man
da ein bisschen drüber nachdenkt, mehr oder weniger,
dann kommt man auf jeden Fall darauf, dass es vielleicht die
Übersetzung sein wird. Das hat bei mir ein bisschen
gedauert. Erst das wir so hä ah okay.
Also bei mir kommt's jetzt an. Okay gut, gut, gut, gut, sehr
gut. Ja, das war mir wichtig, dass
wir das mal aufklären für dich. Aber das war sehr.
Das war auf jeden Fall lustig. Na ja, auf jeden Fall.
Wie gesagt, du kannst ja verschiedene LLMS benutzen und
es sind ja nicht alle genauso wie die anderen, also die haben
ja schon Unterschiede und es wurde ja trotzdem irgendwie
getestet um zu gucken, OK wie gut performt ist so n Ding ne
also zum Beispiel gibt gab es ja auch so Tests, dass bestimmte
Prüfungen auf zum Beispiel in Unis oder so dem diese Tests
oder diese Klausuren Prüfungen wie man sie auch mal nennen mag
wurden ja LLMS gegeben und dann sollten die LMS das lösen, ja
und daran wurde ja zum Beispiel das waren Tests die gemacht
wurden und. Verschiedenste andere oder halt
auch mal in github Issue lösen oder es gibt verschiedene Dinge
ne um dann halt einfach zu gucken, gerade im
Softwareentwicklungsbereich OK, wie gut wird denn jetzt zum
Beispiel ne Coding Aufgabe also erfüllt ne das ist natürlich
auch irgendwie ganz interessant, gerade wenn du es zum Coden
benutzt. Ist es ja wichtig zu sagen, OK,
kommt da jetzt wirklich nur Müll raus mit diesem Assistenten, den
ich da vielleicht nutze? Ich sag jetzt auch bewusst
Assistenten oder kommen da halt auch gute Sachen raus, die ich
verwerten kann, die ich benutzen kann, ne und wenn ich jetzt so n
github issue habe und sage OK code mir das mal.
Das heißt, du gibst dem nen Snapshot von einem Repository
und sagst hier ist zum Beispiel n issue, das muss gelöst werden.
Die AI versucht das Problem zu fixen und dann hast du halt am
Ende grüne Tests und dann war es immer so ja OK war erfolgreich,
passt ne aber das ist nicht. Das stimmt ja, aber das sind
natürlich sehr lokale Probleme, ne, also sehr klein abgesteckt,
also so fein säuberlich getrennt.
Dass du sagen kannst, OK, ja, irgendwie hab ich das Gefühl,
dass das kann man machen. Also das ist ja im Prinzip auch,
gerade wenn du so Einsteigerinnen und Einsteigern
die Mitarbeit Ermöglichst am Anfang und sie vielleicht noch
so anlernst es ist ja genau das auch ne, dass du sagst, ja hier
guck mal, hier ist n wirklich gut abgestecktes Problem, das
ist n guter Entry Point sozusagen und dann schau mal,
dass die Tests am Ende grün sind, so also.
Macht man ja da genauso ne, das ist halt förderlich, weil du
hast halt nicht viel drumherum dann.
Richtig, genau. Und das ist ja auch prinzipiell
gar nicht, wie gesagt, nicht verkehrt ist schön, ist schöner
Vergleich auf jeden Fall, aber es es spiegelt ja nicht wirklich
so n softwareprojekt wieder wie man es vielleicht so eigentlich
kennt. Ne, also wirklich, dass du
sagst. Du hast ne Entwicklung über
Monate oder vielleicht Jahre. Du hast ganz viele Komponenten,
die mehr oder weniger dependent oder Interdependent, also ne
Abhängigkeit haben oder eben nicht und es kann natürlich auch
dazu kommen. Ich mein das kennt man ja, das
kennt ja wahrscheinlich jede Entwicklerin oder jeder
Entwickler, dass er sagt, OK, ich hab hier irgendwie mal was
verändert und komischerweise ich kann es noch nicht ganz
erklären, aber irgendwie tritt da n Problem auf.
Und du denkst im ersten Moment ja, das hat aber damit, es kann
damit nichts zu tun haben. Ich bin mir wirklich sicher,
dass es damit nichts zu tun haben kann, komischerweise dann
aber doch, so weißt du, und deswegen ist es halt nicht
unbedingt ausschlaggebend oder aussagekräftig zu sagen, du
testest ne AI mit einem Test der n einmaligen fix halt testet so
ne sondern. Es ist ja besser zu gucken, OK,
wie ist das Ganze im komplexen Verbund, ne, also wie zum
Beispiel verändert sich auch die Wartbarkeit des Systems dann
durch diesen fix beispielsweise oder durch mehrere Fixes
hintereinander. Ne, ja, das ist halt n guter
Punkt, weil das auch ein Hauptkritikpunkt bei AI Code
ist. Ne oder das Coden mit AI
Unterstützung. Dass man sagt, ja, OK, so kleine
Probleme können ganz gut gelöst werden, dann kriege ich so n
Code Snippet, der funktioniert aber sobald mein Problem
komplexer wird oder mehrere Stellen dafür analysiert und
beachtet werden müssen, dass ich dann irgendwann, das hatten wir
auch auf dem auf Twitch zum Beispiel ganz oft mit mit der
Community das Thema, dass man irgendwie in so ne
Abwärtsspirale reinkommt und die Qualität immer mehr abnimmt, bis
hinzu völlig absurd wird und man sich denkt, so OK, ich kann an
der Stelle jetzt aufhören. Irgendwelche prompts zu senden
sozusagen, weil da kommt nur noch Mist bei rum, das hilft mir
nicht mehr und das ist halt auch glaub ich das, wo man sagen
muss, was unterscheidet echte Projektarbeit, echte
Softwareentwicklung von so kleinen lokalen Problemen, was
du gerade genannt hast, weil diese Kritik haben wir ja auch
selbst, das erfahren wir auch selbst, dass das oft passiert
und auch sehr viele andere. Und es absolut gerechtfertigt zu
sagen, das hat dann nicht so eigentlich mit richtiger
Softwareentwicklung am Ende zu tun.
Ne, bei Twitch hatten wir glaub ich auch ging es auch darum,
dass wie soll ich sagen, die Erfahrung kam, dass zum Beispiel
du kannst dann nen sagen wir du hast Code und die AI.
Soll die den Code refact dann so und dann bist du ja vielleicht
irgendwann mal an einem Punkt wo du sagst okay ey du hast es halt
refact, das ist okay so es passt ne, du bist ja nicht wirklich
permanent 24 7 am Code refact dann so ne, also man sollte es
regelmäßig machen, auf jeden Fall, aber du bist ja nicht
ununterbrochen dabei Code zu refact dann du fängst ja nicht
an ne Funktion zu refact dann um dann hinterher direkt im
Anschluss zu sagen und jetzt refactor ich die noch mal ey,
jetzt refactor ich die noch mal ne also du weißt was ich meine
ne also sicherlich kann man sich jetzt hinstellen und sagen na ja
aber man könnte ja vielleicht noch was finden.
Nein das mein ich jetzt aber nicht, sondern ne du hast halt
wirklich dein Bestes getan, so und gerade da war dann die
Erfahrung, dass AI halt auch wirklich einfach mal sagt, OK,
ich mach aber immer was, also du kannst jedes Mal sagen Refactor
das und AI wird was tun ne das ist zum Beispiel halt auch genau
das Ding und da geht es dann im Endeffekt auch hin.
Und um genau sowas zu testen, um dann wirklich zu evaluieren, wie
gut sind denn LLMS auch wirklich in diesem Bereich?
Ne, also in diesem Kontext auch den, den wir jetzt gerade
angerissen haben. Dafür wurde dann der sogenannte
SWECI Test gemacht. Ne ist so n Benchmark Test, der
genau halt versucht das zu zu checken ne also CI steht hier
wirklich für Continuous Integration SWE Software und es.
Ist ungefähr so aufgebaut, dass du halt 100 Aufgaben hast aus.
Ich glaub 68 Python reports, Tories und die Entwicklung oder
diese diese Test Entwicklung, also diese diese Tests, ne die
Entwicklung der Software. Diese Aufgaben hat ungefähr so
233 Tage Entwicklung gedauert, also wirklich mehrere Monate ne
also da so weiß nicht roundabout 71 Commits pro task task ne um
mal wirklich facts zu nennen hier ne und.
Jeder also die Entwicklung des Tests oder oder.
Also das, was die dann tun muss, ne.
Ah OK, die Bearbeitungsdauer sozusagen durch die Agents dann.
Genau, genau genau, also OK ne. Also beziehungsweise du hast.
Also du hast noch mal ganz kurz so n Test ne wenn du so n Test
fährst mit einer RI, dann hast du im Durchschnitt also ungefähr
100 Aufgaben die gelöst werden müssen.
Ne, es war wurden ungefähr also 68 Repositories genutzt, mit
denen das wirklich passiert, also wo wo diese Tests gelaufen
sind und durchschnittlich hat es halt 233 Tage gedauert für so n
also diesen Test durchzuführen und es gab halt durchschnittlich
71 Kommits pro task ne und dann war es halt so, dass sozusagen
jede Aufgabe. Simuliert im Endeffekt dann ein,
ich sag mal lebenslanges Entwicklungsprojekt.
Also ne ne Geschichte eines Projektes, also eine
Entwicklungsgeschichte wie man es auch immer nennen mag, also
die History eines Projektes ja so und der Benchmark
funktioniert jetzt so, dass du die, dass dieser Prozess der
läuft, der ist. Wieso ne CI loop ne, also du
hast halt quasi immer irgendwie die AI bearbeitet.
Das Problem ja und packt dann quasi die Bearbeitung sozusagen
in in so ne Loop rein, dann wird das quasi getestet, überprüft ob
das passt. Wie auch immer, ne und dann geht
das wieder von vorne los ne und pro Aufgabe gab es immer
ungefähr so 20 Iterationen auf dieser CI loop und es war dann
so vom Ablauf erstmal sind Testzeit fehlgeschlagen ne der
Agent analysiert dann das Problem, dann verändert der
Agent den Code ne also. Dieses klassische es ist
irgendwas fehlgeschlagen, also musst du dir, sagst du dir,
warte mal wieso, was ist jetzt das Problem, ich muss es fixen,
so ne Code wird verändert, CI läuft erneut und dann hast du
entweder halt wieder n grünen stand alles ist gut oder du hast
halt neue Fehler die entstehen können ne und da war es dann
halt auch natürlich so, dass durchaus das simuliert wurde,
dass halt eben bestimmte Fehler auch auftreten, dann an der
Stelle ne, damit du halt wirklich dieses dieses Ich sag
mal echte Projekterlebnis hast. Weißt du?
Ja OK, also es war so n bisschen simuliert das Ganze genau heißt
man hat quasi mit einem Stand gestartet, der nicht
funktioniert sozusagen. Also am Anfang waren die Tests
schon rot ne und dann hat man das immer fixen lassen,
sozusagen und wieder simuliert, dass neue Fehler reinkommen.
Sozusagen OK genau. Und die Aufgabe war halt, und
das war halt wirklich wichtig, was halt eben auch gemessen
wurde, der Agent. Muss jetzt nicht nur einfach
Tests bestehen und sagen, OK das das passt so ne ich hab jetzt
alles grün ist gut oder einen bestimmten Teilbereich der dann
zum Beispiel Grün ist, sondern es ist wichtig, dass halt alle
bestehenden Tests halt eben auch immer noch weiterhin grün
laufen. Ne, dieses typische du
entwickelst irgendwie an einer neuen Aufgabe.
Du hast vielleicht irgendwie rote Tests, du fix die und dann
sollen nicht nur die Tests in dem Kontext in dem du gearbeitet
hast grün sein, sondern wirklich auch alles andere drumherum ne,
also das soll halt eben nicht dieser Effekt auftreten, nicht
am Anfang meinte. Du änderst was und denkst dir so
OK, passt alles und hä, wieso ist das gerade rot?
Ne es kann nicht von meinem fix sein und dann am Ende merkst du
aber OK komischerweise ah OK ne das ist halt eben doch passiert
und genau das soll sozusagen gemessen werden, dass genau das
eben nicht auftritt, ne? Ja gut, ich mein, Wir sprechen
ja hier von Continuous Integration, ne, also in dem
Benchmark ja auch. Und dann sollte es ja ne
Bedingung sein, dass alle Testgrünen sind, bevor du den
Code integrierst in die Codebase.
Also das sollte schon gegeben sein von der von dem Agent,
sozusagen von der Entwicklung. Genau.
Und dann war das Ganze so aufgebaut, dass du halt in
diesem Benchmark 2 Rollen hast. Ne, das heißt du hast dann nen
Architekt. Agent, der sozusagen analysiert
halt eben die CI Fehler und und schreibt dann die Requirements.
Das heißt es wird dann geguckt irgendwas läuft auf der Pipeline
nicht richtig ne und dieser eine Agent von dieser LLM die
getestet wird sagt dann ey Pass auf wir haben nen Fehler da und
da ich schreib jetzt requirements damit das eben
gefixt wird und dann hast du sozusagen den Programm Agent der
wiederum sagt OK ich implementier dann halt den Code
und das soll dann im Endeffekt so n bisschen.
Die Real so reale Software Teams widerspiegeln ne, dass sozusagen
das Analyse nicht gleich Implementierung ist, obwohl ich
da ganz ehrlich bin und sagen muss.
Tino seh ich halt auch anders, weil ich finde gerade im Full
Stack Bereich beispielsweise bist du halt einfach dafür
verantwortlich, dass deine Software läuft.
Ich weiß nicht wie du das siehst, weil ich eigentlich weiß
ich wie du das siehst. Ich find es halt komisch zu
sagen Du hast einmal diese Analyse unabhängig von der
Implementierung so. Aber das wurde jetzt halt mehr
gemacht. Die Frage ist halt, was jetzt
mit Analyse da gemeint ist, wie die das wo der Schnitt da ist.
Ja, das war wahrscheinlich jetzt nicht so detailliert
beschrieben. Die Frage ist Halt, ist es die
Analyse wie ich es jetzt technisch löse oder sind es so
fachliche Sachen? Ne, also so reden wir hier zum
Beispiel von der Rolle PO und Entwickler die da miteinander
kommunizieren oder sind es irgendwie alles Entwickler?
Aber einer sagt jetzt Pass auf wir haben.
An der und der Stelle in der Klasse n Problem, dass das die
Anforderung ist, dass das und das passiert.
Und jetzt implementieren wir das.
Dann bin ich natürlich ganz bei dir, dass das irgendwie alles
Tätigkeit eines Entwicklers ist. Das ist wahrscheinlich auch
nicht so ausführlich beschrieben gewesen, ne?
Ja, also ich glaube ich. Ich meine, wenn man da jetzt
vielleicht noch mal irgendwie sich das im genauen anguckt,
dann kriegt man es wahrscheinlich auch irgendwie
noch raus, aber das Ding ist. Für mich klang es halt auf jeden
Fall so, dass es halt eben so ist, dass du hast halt diesen
einen. Du hast halt diesen
Analysepartner und prinzipiell ist es ja auch irgendwo auf
einer Metaebene, sag ich mal möglich, dass du sagst, du
guckst ob, was halt nicht richtig funktioniert, es muss ja
auch nicht immer unbedingt jetzt, sagen wir mal in der CI
sein, es kann ja, die CI kann ja auch.
Sozusagen stellvertretend für User entdeckt Halt n Problem ne
und das wird sozusagen weitergereicht.
Du meinst an genau an so NPO, das versteh ich, ist auch n
guter Gedankengang von dir, so dass man sagt das könnte ja auch
PO und Entwickler entwicklerinnen sein, sozusagen
diese Rollenverteilung, aber wenn ich mir denk, also aus
dieser Perspektive heraus zu sagen, irgendwas ist rot auf der
Pipeline, dann seh ich das halt einfach beim Entwickler, so
weißt du, deswegen fand ich das so n bisschen komisch vom vom
Naming. Aber genau das ist im Endeffekt
so. Die Situation ne und am Ende
wurde dann halt geguckt und halt es, es wird ja immer so, es gibt
ja so n Maß ne so wo man sagt was ist wichtig, worauf wird
jetzt geachtet ne und es wird jetzt zum Beispiel nicht
unbedingt darauf geachtet zu sagen.
Du hast n einzelnen Fehler und der wird gefixt, sondern es war
halt wichtiger zu sagen was wie wie performt diese
Gesamtsoftware später ne, das heißt wenn früher in diesem
Prozess, in dieser Simulation sag ich jetzt mal zwar perfekt
irgendwelche Fixes gemacht wurden, aber später das System
immer schlimmer wurde, sag ich jetzt mal.
Oder immer mehr Fehler im Nachhinein aufgetreten wurden.
Das galt dann halt als schlecht, das heißt, es war auch
gleichzeitig wiederum nicht schlimm, wenn am Anfang
irgendwie fix ist, noch nicht richtig hundertprozentig gut
umgesetzt wurden, wenn es noch nicht so richtig, noch nicht so
richtig gepasst hat. Weißt du also sagen wir mal, du
hast den ersten Fix und du löst ihn nur zu 50% könnte man ja
jetzt sagen, OK das ist schlecht, ne.
Wenn du aber am Ende sag ich jetzt mal immer weiter das
System verbesserst, sodass du am Ende sagen wir mal Ich nenn
jetzt einfach mal zahlen so n System von 90 von 100%
geschaffen hast. Weißt du also um um das mal so
auf einer Zahlenebene zu verständlich zu machen, dann war
da ist das halt tausendmal besser als wenn du am Anfang
aber so n so n fix 100% machst hinter deinem System aber nur 60
von 100 Punkten bekommt, weißt du ich meine.
Ne. Und da war es dann halt so, dass
so Regressionsfehler nennt sich das ja immer dieses wiederholte
Laufen der Pipeline sozusagen, wenn da dann halt Fehler später
aufgetreten sind. Das wurde halt stärker bestraft
als. Wenn du halt, sagen wir mal
früher mal n Fehler drin hattest, so.
Ja OK, also es geht halt wirklich um die Entwicklung und
Wartbarkeit dahinter und wie stabil das System ist sozusagen
oder die Softwareentwicklung dahinter auch so.
Stichpunkttechnische Schulden oder so, die sich dann
vielleicht aufbauen, ne, ich mein, das kennt man ja.
Ist jedem ein Begriff. Ja, ist auf jeden Fall n ganz
interessanter Aufbau, auch dass halt mehrere Agents da
involviert sind, dass man halt wirklich.
Weil es geht ja ganz oft darum, kann ich jetzt so
Softwareentwicklerinnen und Entwickler ersetzen, ist ja ne
Angst von vielen wird auch viel diskutiert, ist auch so n
bisschen Panikmache und ja sag ich mal es kommt halt gut in den
Medien so was zu sagen ne also das polarisiert Halt und
natürlich muss man so n Test dann auch so aufbauen, dass man
sagt OK wir haben jetzt mehrere Agents, wir ersetzen jetzt so n
Team ne und mal gucken wie sie diese Software entwickeln und
deswegen. Ist gerade so so ne die
Regression dabei zu betrachten sehr plausibel das zu tun und
auch wichtig ne das zu analysieren weil wie verhält es
sich über Zeit wenn ich jetzt einen so n task hab und der wird
ganz gut entwickelt und ich stell mich hin ach guck mal 30
Sekunden ja super fertig das schafft niemals n Entwickler ja
OK klar kannst du so schnell vielleicht nicht coden dann ne
oder kriegst Ding das Ergebnis nicht geliefert.
Aber die das Spannende ist ja wirklich, wie verhält sich es
über Zeit und fährt man so n Projekt gegen die Wand so
wirklich massiv gegen die Wand, dass es halt überhaupt gar nicht
mehr funktioniert und alles n Bach runter geht?
Oder können Sie halt dieses Level halten?
Das ist das spannende jetzt, was man da denn versucht
herauszufinden und ich muss sagen ich find das selbst auch
super spannend ja bin gespannt was das Ergebnis.
Ist da kommen wir gleich drauf. Ich find halt zum Beispiel ich
mein das, das kennst du sicherlich auch.
Wenn du so ein du hast ein Projekt und du sagst jetzt zum
Beispiel, du hast wirklich einen kleinen Task und sagst jetzt AI,
mach das so ne, vielleicht beschreibst du so, es geht jetzt
nicht darum, dass du wirklich sagst, ich gebe jetzt die
Anforderungen aus so einem Ticket da rein, sondern du
beschreibst halt, dass du sagst, ich möchte gerne, dass sich die
Software da da und dahingehend verändert ne so, dann ist es ja
relativ easy, dass du wirklich eine Lösung bekommst, dass die
AI etwas vorschlägt und sagt, OK, hier bitteschön ne, du
testest das aus und sagst vielleicht OK, das funktioniert
schon, das passt schon irgendwie so ne.
Aber wenn du jetzt zum Beispiel an einem an einer anderen Stelle
wieder was ähnliches machst, dann haut der dir wieder ne
Lösung rein und dann hast du aber irgendwann den Punkt, dass
vielleicht einfach Code Dopplungen da sind, wo du
vielleicht aber intuitiv als Entwickler oder Entwicklerin dir
denkst. Na ja, also ich hätte jetzt
schon irgendwo nach einer gewissen Menge an Dopplungen
vielleicht auch mal ne Single Source of Truth eingebaut, das
ganze vielleicht mal refected und so weiter ne.
Kleines Mini Beispiel dazu ist jetzt vielleicht nicht so
hundertprozentig das, aber ich hatte das zum Beispiel mal mit
mit CSS Code ne wo wo man sich dann so denkt so ich finde CSS
bin ich ehrlich ist jetzt nicht mein absolutes Steckenpferd so
man kommt damit halt klar, aber es hilft natürlich auch schon
einfach mal so ein bisschen so von AI so mal was sich geben zu
lassen weißt du und. Dann wird halt in der einen
Seite n Button gestylt und in der nächsten Seite wird wieder n
Button gestylt, der aber genauso aussieht sieht wie der andere,
aber die AI kam niemals darauf zu sagen und das packen wir
jetzt mal nicht Side CSS so allgemein ne so und das sind so
Dinge. Na ja, gut, man muss natürlich
sagen, da gibt es ja auch diesen witzigen Satz und ich find, der
ist halt auch n bisschen zutreffend, bisschen provokant,
aber auch zutreffend, dass CSS so Wright only ist und nicht
mehr gelesen werden kann, dass du das so schreibst, sieht
richtig aus, jut. OK guck ich mir nie wieder an,
was da drin ist, weil es halt auch echt schnell eskalieren
kann, ne, vielleicht denkt sich das ja ja.
Auch. Ja, aber es ist es ist.
Es ist ja nur ein kleines Beispiel.
Es ist ja das, das kannst du halt auch so auf Mappen, auf auf
normalen Code und das sind halt dann auch wieder so Probleme, wo
du gerade wenn du vielleicht noch nicht so richtig Erfahrung
hast, dass du dann in diesen Bereich kommst, wo du denkst,
ey, das funktioniert ja richtig, richtig geil, ja, und dann
kommst du aber genau in diese Hölle oder in diesen, in diese,
dieses Testproblem, was wir jetzt ansprechen, weil.
Es ging ja, wie gesagt mit dieser Regressionsrate, die da
überprüft wurde, wurde er geguckt wie oft n Agent etwas
repariert, ohne dass er etwas anderes halt am Ende wieder
kaputt macht und die Ergebnisse waren halt schon stark, weil die
Mehrheit aller Modelle wirklich genau dieses diese.
Dieses Maß, was ich gerade genannt hab, nur kleiner 25%
erfüllt hat, also nicht mal ein Viertel oder maximal ein Viertel
der also der meisten Modelle. Nein, so nein warte.
Die meisten Modelle haben nur zu.
Wenig Statistik genau also du nimmst ein Modell und die
Wahrscheinlichkeit, dass das Modell später etwas kaputt macht
ist liegt bei 75%. So ist schon sehr hoch, das
meine ich damit ne ein bisschen herausgestochen herausgestochen
hat hier Cloud Opus ne kennt man ja, ist sicherlich vielen
Begriff jetzt sagt wahrscheinlich der eine oder
andere so alter ich hab es schon immer gesagt Opus.
Rockt, so weißt du ja, stimmt, das ist ein Modell, was?
Auch polarisiert also gefühlt jede neue Version und dann
stellst du irgendwann fest. Ja, so geil ist doch nicht und
dann kommt die nächste und dann. Aber jetzt ist richtig, richtig
geil. Ja, es gibt so viele Fans von
Opus, auch jetzt gerade mit der 4 Sechser Version ne die ja ist
ja auch schon wieder ne Weile her, ich muss sagen ja die
Ergebnisse fühlen sich besser an, aber das was wir anfangs
kritisiert haben passiert da genauso.
Ja, ist echt so. Also ich bin ganz ehrlich, so in
letzter Zeit wo ich auch n bisschen mehr mit Opus
gearbeitet hab, muss ich sagen es fühlt sich jetzt nicht
deutlich besser an als irgendein anderes Modell, aber ist normal.
Ja, also. Es ist, die Ergebnisse sind
manchmal passender oder auch irgendwie.
Ja, also geh mal ein besseres Gefühl, aber du kommst halt in
die gleiche Teufelsküche, wenn es sich halt mal wieder n paar
rund. Dreht so ne.
Aber selbst bei opus kannst du halt ne Münze werfen, ne, also
dass n opusmodell trotzdem zu 50% roundabout halt eben später
auch eigene Fixes wieder kaputt macht und das ist halt schon
krass, muss man halt wissen. Ne, das ist n Ding wo man halt.
Also es ist natürlich deutlich besser als 75 wie der
Durchschnitt sag ich mal ne ja, aber 50 ist halt immer noch sehr
hoch. Ja wie du meinst, das ist n
Münzwurf ist halt weiß nicht wie es bei dir ist, aber immer wenn
Münzwurf ist verlier ich komischerweise.
Du musst auf der richtigen Seite stehen.
Ach so, ach so, ja das Richtige wählen vorher meinst du,
logisch, nee, aber das ist halt n Ding, da muss man halt glaub
ich auch n bisschen mit mit Deal ne und das muss man sollte man
auch irgendwie auf dem Schirm haben, gerade wenn man sagt OK
ich vibe Code jetzt mit irgend ne Software zusammen ist halt
irgendwie n Ding gerade wenn du ne gerade wenn du dir ne
Software überlegst wo du sagst oder wo du weißt das hat auch
noch so n bisschen. Wie sagt man Wartungsbedarf?
Ne, also wenn du jetzt eine Software machst und die viele
Software Softwares die Mehrzahl davon wertsoftware Software, die
werden ja später auch benutzt, viel ne und müssen
dementsprechend halt auch angepasst werden, auch mit den
ich sag mal userbedürfnissen angepasst werden, das ist
Wartung am Ende auch ne und auch Erweiterung und solche Sachen
also das da muss man muss man halt wissen.
Ja, aber ich find es jetzt gar nicht so verwunderlich.
Also ich find die Quote ist sehr hoch, das ist schon krass, aber
das eine höhere Quote da ist find ich gar nicht so
verwunderlich, weil du hattest ja auch am Anfang erwähnt, dass
alte Tests immer so lokale Probleme waren oder so kleine
Abgesteckte und dafür funktioniert es ja auch gut ne,
wenn du eben sagst ey ich brauch ne Funktion die das das und das
Macht und die ist so richtig schön autark, dann kriegst du
auch gute Lösungen und die sind auch gut gecoded ja also das
bekommt ja kein richtiger Murks zurück.
Aber das sind halt so lokale Problemlöser, ne.
Also das was du da zurückkriegst ist sehr gut für lokale Probleme
und dann auch so für lokale Optimierung sowas zu sagen wie
hier guck dir die Funktion an, was würdest du optimieren?
Mal abgesehen davon, wenn du sagst was würdest du optimieren
baut der immer irgendwas um weil er das Gefühl hat ich muss
optimieren so weißt du. Aber sie sehen halt nur, denn
diesen kleinen Ausschnitt, denn eventuell den Fehler da drin ne
oder vielleicht nen fehlenden Test und gucken OK was passiert
da, das wird aufgerufen. Gut dann bau ich da drin um so
ne aber es hat nie den Gesamtblick da drauf also so ne
so n Agent guckt gefühlt nicht auf die ganze Software, auch
wenn du ja keine Ahnung was du alles machen kannst.
Du kannst sagen guck dir diese Files an, dafür bezieh das und
das mit ein. Du gibst ihm irgendwie das
Gefühl, das ganze Projekt im Blick zu haben, aber so richtig
weißt du es auch nicht und es fühlt sich auch nicht so an, als
wenn das hat, weil wie gesagt es sehr lokal, immer alles
betrachtet wird. Ne und so implizite
Abhängigkeiten sag ich mal, sind denn auch einfach nicht
berücksichtigt, oft ja oder auch Auswirkungen, was hat das wenn
ich das jetzt mache, ja gut, dann ist der Test grün, aber das
wird mir doch definitiv noch in die Suppe spucken, spielt ja gar
keine Rolle, genau. Und das ist halt n
Riesenproblem, was halt zu systematischen Fehlern einfach
führt, weil halt auch nie zum Beispiel auch nie so ne richtige
Architektur aufgebaut wird. Es wird halt dann in der Suppe
rumgerührt, bis es wieder irgendwann passt, aber auch
überhaupt nicht eingehalten, dass irgendwelche.
Vorgaben da drin sein müssen, dass man irgendeine Architektur
einhalten möchte oder so. Das passiert halt nicht ne und
deswegen verwundert mich das Ergebnis nicht, diese lieblose
Suppe, wo noch reingesprungen wird die ganze Zeit dann
rumgerührt wird. Ja, das ist halt so wie wenn du
keine Ahnung zu Hause n Rohr irgendwie reparierst in deinem
Haus oder so ne und dann dir denkst also und nicht checkst,
dass sich halt der gesamte Wasserdruck verändert ne ja
also. Ich weiß jetzt nicht, ob das n
tatsächlicher Anwendungsfall wäre, aber ja, das ist so.
N Rohr ist kaputt, ne, du bist ja kurzsichtig sagt OK ich
reparier das jetzt aber du. Setz irgendwas ein da.
Genau also du. Du machst es irgendwie, aber du
achtest halt nicht darauf, dass ich vielleicht irgendwie, warum
auch immer, durch deinen Fix der Wasserdruck irgendwie der steigt
stark an und irgendwann hast du n keinen Druckausgleich.
Ja genau, irgendwann hast du ne Leitung die platzt oder was auch
immer, weil du halt irgendwas gemacht hast, was aber später
halt wieder n anderes Problem erzeugt.
Oder was weiß ich du. Na ja, OK.
Weiß nicht, wenn du überall Wasser anmachst, dann hast du
hinterher kommt kein Wasser mehr, weil zu wenig Druck und du
hast ne was auch immer. Ist jetzt nur aus den Haaren
gesogenes Beispiel, aber du hast halt, also es kommt halt durch.
Diesen Test konnte man erkennen, dass diese Weitsichtigkeit für
sowas ne für diese Probleme, die sich irgendwie bedingen können,
halt eben wie du ja auch meintest, so ne, dass das Halt
nicht gegeben ist. Bei vielen NLMS ne und bei
einigen mehr und bei anderen weniger, aber eigentlich bei
allen ist es so. Also ich find es, es ist halt
auf jeden Fall ne coole Art und Weise das zu testen und besser
als zu sagen ey ich geb euch immer so einzelne Task und du
ihr Fixt das und dann denkst du oh Mensch hier guck mal den mal
aber richtig hohe Erfolgsquote ne da find ich ist das schon
viel aussagekräftiger. Jetzt ist das natürlich irgendwo
ja auch begrenzt ne also du hast ja gesagt zum Beispiel 100
Aufgaben. Dann ist es ja nur in Python
gewesen glaub ich. Ne man hat mit Open Source
Repositories gearbeitet. Ja OK das sind jetzt vielleicht
alles so Einschränkungen wo jetzt Leute kommen können und
sagen Na ja, aber hier wenn ich hier aber mit javascript
unterwegs bin dann läuft richtig ja also ja gut mag sein,
vielleicht muss man das auch mal so für andere Sprachen jetzt
sozusagen ausrollen. Aber ich würd das nicht mal
unbedingt so krass auf die Sprache Münzen.
Ne und Python hat sich wahrscheinlich da auch einfach
angeboten, genauso wieder die Nutzung von Open Source
Repositories ne und 100 Aufgaben finde ich ist von der Stichprobe
her, also von der retschieren Anzahl schon auch
aussagekräftig, ne gerade wenn man überlegt.
Wieviel Iterationen denn da drunter wieder gemappt waren und
so und die Laufzeit allein schon ne.
Also da kannst du ja nicht sagen, OK, wir haben jetzt n
Benchmark Test gemacht, ja wie lange?
Ja wir haben jetzt eine so ne Sache nicht, statt einer haben
wir 2 laufen lassen und deswegen können wir jetzt sagen so läuft
immer noch ja also das ist halt so also ich find das ist halt
auf jeden Fall cool umgesetzt gewesen und es bringt halt
zumindestens jetzt an der Stelle und da komme ich jetzt ins Spiel
ja. Ne so gewisse Thesen mit sich,
die auf jeden Fall diskussionspotenzial haben und
ich finde, darüber könnten wir jetzt so im letzten Teil der
Folge, weil es soll ja nicht nur um die Ergebnisse gehen, das ist
ja nicht ne reine News folge, sondern auch wir wollen ja mal
unseren Senf dazu abgeben, wenn wir es nicht schon so nebenbei
mitgemacht haben, ne und zwar möchte ich noch mal auf das
Thema kommen AI. Ersetzt keine Entwickler oder?
Jetzt hast du 2 Lager die einen sagen auf jeden Fall werden wir
ersetzen, die anderen sagen auf keinen Fall, weil alle Projekte
gehen Bach runter, jetzt hast du dieses Ergebnis für mich
persönlich symbolisiert dieses Ergebnis eher, dass die Leute,
die gesagt haben, OK es ist n Tool, aber wir können nicht
ersetzt werden damit, weil dann gehen hier alle Projekte vor die
Hunde, das spielt denen halt natürlich total in den Karten
und ich mein da zähl ich uns beide auch dazu, das heißt es.
Bestätigt ja irgendwo unsere Sicht der Dinge.
Ne und auch wir haben ja ne Folge gemacht über wie sich Open
Source zum Beispiel verändern kann, die Kultur dahinter ja,
dass halt unglaublich viele, also eine Flut an Pull request
kam durch Agents und Geweibecoded n Code, was die
ganzen Maintainer gar nicht mehr händeln konnten und auf die
Barrikaden gegangen sind. Ich finde das spielt jetzt hier,
das zeigt dieses Ergebnis auch, ja du lässt das zwar irgendwie
schnell coden, aber du hast n Riesen.
Wartungsaufwand oder wie siehst du das?
Also, wenn irgendwie ja mit 75 prozentiger Wahrscheinlichkeit
bei den meisten Modellen irgendwann wieder was kaputt
geht, heißt das für mich verdammt noch mal, das wird
anstrengend das zu warten das richtig zu erkennen, rechtzeitig
zu erkennen das zu fixen, ohne dass man komplett in diese
Abwärtsspirale reinkommt. Ja, was ich, was ich halt geil
finde ist, man kann sich jetzt auch hinstellen und sagen, ja
OK, technische Schuld zum Beispiel baut sich auf und
demzufolge passiert sowas ja auch ne das also es es war ja
quasi wurde ja explizit genannt, dass es so ne Art technische
Schuld ist, die sich aufbaut und demzufolge halt auch Fixes am
Ende sozusagen wieder selbst kaputt gemacht werden ne und ich
denk mir so ja klar, normalerweise bauen sich baut
sich auch technische Schuld auf. Wenn normal, also wenn wenn
menschliche Entwickler und Entwicklerinnen an Projekten
arbeiten, OK, gucken wir uns ganz kurz an wieso, weil man
immer oder meistens entsteht sowas durch Zeitdruck.
Ja ich will jetzt aber auch mal wissen, wie zum Beispiel so n
Zeitdruck sich auswirkt ja wenn du zum Beispiel nur noch Code
generieren lässt, ja dann bist du nicht schneller, sondern du
hast einfach nur schneller mehr technische Schuld aufgebaut.
Weißt du nach diesem Test so, das ist für mich die logische
Schlussfolgerung daraus. Und nur weil du mehr Code
erzeugen kannst, beispielsweise heißt das noch lange nicht, dass
es besserer Code ist. Sondern halt.
Vielleicht sei doch auch nicht immer alles ne.
Genau, sondern halt vielleicht eben mehr Wartungsarbeit.
Dadurch entsteht ne die oder technische Schuld sich dadurch
aufbaut und ich fand auch letztens hab ich auch noch mal
so n so n so n kleines Video gesehen, da ging es genau um
diese Aussage, die irgendwann mal getätigt wurde.
Ich will jetzt gar keinen, keine Person benennen, weil ich glaub
es haben n paar Personen gesagt, aber so was wie 90% des gesamten
Codes wird irgendwann nur noch durch AI geschrieben.
Ne wo ich mir so wo ich mir so dachte Boah Alter, das ist schon
krass, aber wenn du jetzt mal überlegst ja, dass die Anzahl an
Code die ein Mensch schreibt stabil bleibt gleich bleibt aber
einfach nur ne Prozent des Verhältniss.
Einfach nur noch mehr viel, viel mehr Code generiert wird.
Natürlich hast du irgendwann 90% Code, der generiert wird, aber
keiner sagt 90% guter Code wird generiert, sondern es kann nur
wenn nur 10% davon denn verwendet wird genau ja, aber
das ist halt das Ding und da muss man halt eben solche
Aussagen auch eben wirklich ich sag mal mit Bedacht genießen ne
und nicht einfach sagen Oh mein Gott Panik.
Und ich find halt, dass. Diese Velocity ne, also dieses
Code Code Code Code und lösen, lösen, lösen auch.
Ja, das zeigt ja dieser Benchmark Test ja auch, dass das
einfach nicht so funktionieren kann und wir sagen ja immer es
ist n gutes Tool was man verwenden kann zum Brainstormen,
zum Code Snippets generieren, aber am Ende wird man nicht so
massiv schneller, es kommt immer auf die Task an wie komplex sie
ist aber es hilft ne also es macht einen schon irgendwie
effektiver. Aber es man wird nicht unendlich
schnell und ich finde, das ist halt genau der Punkt.
Also es zeigt, dass man AI richtig einsetzen soll und nicht
übernehmen lassen soll. Ne, also damit meine ich nicht
dass ersetzen, du kannst ja genauso da nehmen.
Sitzen und sagen ja, OK ja, ja ja, confirmed ja gut, passt
passt fast approved am Ende so ne.
Na ja wär ja theoretisch möglich.
Nein du bist natürlich weiterhin in der Verantwortung, du bist in
der Verantwortung dafür zu sorgen, dass die Codequalität
stimmt, weil es dein Produkt ist.
Ne, du bist als Entwickler weiterhin dafür verantwortlich
und so muss man das auch sehen und ne andere These, die man
daraus ja ziehen kann ist gut. OK, mal angenommen wir lassen
jetzt auch viel Code generieren und zwar in der Art und Weise
wie ich es gerade meinte, also als Unterstützendes und nicht
ersetzendes Tool sag ich mal ne. Dann ist ja irgendwo der Skill
ein Systemverständnis zu haben und zu wissen, wie sieht
Softwarearchitektur aus, wie sieht gute Softwareentwicklung
aus, was muss ich alles berücksichtigen.
Ja, das wird ja immer wichtiger, die Basics werden auch immer
wichtiger, weil ich ja jetzt n Tool an die Hand bekomme, was
schnell ausführen kann, aber ich muss das ja bewerten können und
auch eingreifen können und deswegen ist dieses Verständnis
finde ich, also das zeigt mir auch dieser Benchmark Test oder
das Ergebnis. Dass das einfach noch wichtiger
wird, weil ja auch viele Quereinsteiger, einsteigerinnen,
Einsteiger, auch Leute, die überhaupt überlegen, in die
Softwareentwicklung zu gehen, ja auf uns zukommen und fragen,
lohnt sich das noch? Ja, es lohnt sich auf jeden Fall
noch, aber es lohnt sich noch umso mehr, jetzt in der Zeit
noch mehr die Basics zu verstehen, ja, und auch wirklich
n bisschen back to the roots zu gehen.
Klar, es gibt unglaublich hippe Softwarearchitekturen und
Patterns und Prinzipien und alles richtig, ja, aber auch
wirklich mal Softwareentwicklung mit allen Facetten in den
Grundlagen zu verstehen. Und da will ich jetzt nicht
sagen, so, ja ich hab das hier alles komplett verstanden.
Ja also nee, ich finde man kann nach keine Ahnung 1015 Jahren
Entwicklung immer noch sich denken verdammt das hab ich
komplett nicht mehr auf dem Schirm gehabt oder ey davon hab
ich auch noch nichts gehört so ne.
Aber dass man da auch sich weiterentwickelt und dran
bleibt, ist halt umso wichtiger. Dann also ich denke auch, dass
es nicht unbedingt zwangsläufig sein muss, dass ein Entwickler
oder eine Entwicklerin der heutigen Zeit oder der Zukunft
super viel Code schreibt, also wirklich selber schreibt, aber
das Verständnis was da passiert muss halt da sein, das ist sehr
sehr wichtig und genau deswegen braucht muss man dieses
Verständnis auch aufbauen, Dinge zu tun, einfach nur die ganze
Zeit irgendwas in die AI einzugeben und das was rauskommt
einfach blind zu übernehmen und. Ist halt haben wir glaub ich
auch schon mal gesagt. Genau ne Sache wo man sich sagen
kann OK solche da kann man schon ersetzt werden weil was bringt
es dir wenn du nur durchwinkst so ne und dieses Verständnis
nicht mitbringst so ne und ich meine man sieht halt im
Endeffekt ja NLLM hat nicht so n Gedächtnis das ist jetzt kein
richtiges Denken was da passiert.
Aber und du brauchst halt auf jeden Fall genau aus diesen
Gründen noch n ownership Gefühl für dein System.
Ne, das ist halt einfach wichtig, das muss halt da sein.
Was natürlich spannend ist. Es können natürlich jetzt auch
Leute hervortreten, die sagen, na ja, natürlich, das sind alles
Architekturen, Modelle, Arbeitsweisen, die ja auf uns.
Coderinnen und Codern Gemappt sind ne, also dass quasi
Menschen das danach arbeiten können das ich mein das ist n
Argument, das kannst du immer bringen, ja dass sozusagen die
Maschine. Gar nicht so eigentlich arbeiten
würde und man diese Modelle irgendwie drauf drückt.
Ja zum Beispiel zu sagen in diesen Iterationen mit CI und
so, vielleicht würden ja Agenten unter sich sozusagen gar nicht
so arbeiten, sondern in irgendeinem chaotischen Modell,
aber am Ende kommt was richtig gutes raus, wie auch immer, ne,
also ja vielleicht passen unsere Weltmodelle dazu nicht.
Das bleibt natürlich irgendwo offen.
Das Argument kann man so als Diskussions Totschlagargument
bringen und alle stehen weiterhin im Dunkeln, sozusagen.
Ja gut, kann sein, kann ich nicht widerlegen, aber ich
finde, dass man trotzdem jetzt schon wirklich gute Take aways
da mitnehmen kann. Ne, also aus diesen also
natürlich Liebe, zuhören, Liebe zuhören aus dieser Folge hier,
weil wir es ja für dich besprochen haben, aber auch
allgemein, wenn man den Artikel gesehen hat.
Hast du Bock, das vielleicht noch mal so n bisschen so am zum
Abschluss zusammenzufassen? Ja, also ich find auf jeden Fall
was sehr sehr wichtiges und wo man auf jeden Fall, was man sich
in den Kopf rufen muss. Es ist n definitiven Unterschied
Code zu generieren auf der einen Seite oder n System wirklich
langfristig zu entwickeln und zu warten, das ist halt einfach
wichtig muss man im Kopf haben das ist ne Code Generierung ist
nicht einfach nur OK ich kann ne ne geile Software zwangsläufig
dadurch erstellen. Man muss es halt stabil halten.
Die Codebase muss irgendwie stabil gehalten werden, auch
wenn AI den Code halt schreiben kann.
So und gerade dieses diese langfristige Entwicklung, diese
Regression, die da sozusagen getestet wurde, ne, das ist halt
eben noch ein ungelöstes Problem, offensichtlich.
Was ja nicht heißt, dass es nicht gelöst werden kann.
Aber es gibt ja auch andere Probleme bei AID wahrscheinlich
auch genau zu solchen Ergebnissen eben führen, was ja
auch einfach Probleme sind, die noch nicht gelöst sind, ne, also
wir können gerne mal, falls dich interessiert Liebe zuhören,
lieber zuhören können wir gerne auch über Probleme die AIS hat
mal ne Folge machen, das ist kein Problem und ansonsten ja.
Also bugfixen kann ne Software System main tan hab ich Software
gesagt, kann AI aber system main TAN kann AI halt eben noch nicht
offensichtlich so ne und ja vielleicht ist das halt eben
genau der Unterschied ja heutzutage zwischen ich sag mal
einem so einer LLM und ich sag mal wirklich jemanden oder so
einem einfachen Programmierer sag ich jetzt mal ne oder halt
wirklich. Zu einem, ich sag mal
Informatiker, Software Ingenieur, wie wie man das auch
mal nennt, ne. Also der Unterschied zwischen
ich wende einfach nur dieses Handwerk an ne weil das Handwerk
wird n bisschen auch in die LLM gegeben, aber das Verständnis
wie wir meinten dadurch halt eben ne brauchst du nicht.
Und das ist ja, sag ich mal, in fast jedem Fall so, dass man ja
nicht nur coder ist. Ne, also nicht nur derjenige
ist, der den Code schreibt, sondern halt diese Software auch
entwickelt. Und mit allem drum und dran ne
oder dieses Software Engineering dann ne und das find ich ist n
guter Punkt hier zu abschließen. Da hab ich auch gar nichts mehr
hinzuzufügen, dass man halt wirklich sagt, vielleicht ist
das genau noch der Unterschied den wir zur LLM haben und
weswegen man das irgendwie miteinander verheiraten muss um
gute Systeme entwickeln zu können und nicht in diese
Abwärtsspirale rein zu geraten, ne?
Genau auf jeden Fall cool, dieser Benchmark, dass man sagt,
OK, nicht mehr nur angucken, Fix The Bugs, sondern Main tain the
System, sag ich mal und geile Erkenntnisse da drin.
Richtig cool, dass man das durchgezogen hat.
Ich kann mir auch vorstellen, dass es n sehr sehr teurer
Benchmark ist, das alles so laufen zu lassen, also wieviel
Tokens da verbraucht wohnen will ich gar nicht wissen oder doch
würde mich interessieren, aber es ist auf jeden Fall 10000000.
Oder so. Echt ja, heftig ja gut, aber
irgendwie hatte ich es mir schon fast gedacht.
Also das hat ein bisschen was gekostet.
Ja, um das uns hier so die Zahlen präsentieren zu können,
auf jeden Fall Shampoo dafür. 10 Milliarden. 10 Milliarden, Ach
du meine, na gut, okay dann würde ich sagen, Fabi, haben wir
das Thema durch vielen, vielen Dank, dass du es mitgebracht
hast. War mega interessant und ich
fand wir haben auch eine coole Diskussion dazu geführt, aber
eine Meinung fehlt uns natürlich dabei noch und zwar von dir,
liebe Zuhörer, liebe Zuhörer. Wie ist deine Meinung zu dem
Thema? Wie stehst du zu diesem neuen
Benchmark, wie siehst du AIS und Agents allgemein, wie verwendest
du sie vielleicht? Das würde uns mega mega
interessieren. Schreib uns gerne zum Beispiel
auf der Podcast Mail oder über die Plattform deiner Wahl, wir
werden überall reagieren und antworten ist versprochen und
alle Links findest du wie immer in den Shownotes.
Da findest du auf jeden Fall auch einen kleinen Spendling.
Wenn du sagst, ey Mensch Leute, ich hör mir den Podcast jetzt
echt schon ne Weile an. Richtig richtig cool was ihr
macht, vielen Dank dafür, ich möchte euch so n bisschen was
zurückgeben, dann vielen vielen Dank dafür.
Empfiehl ihnen auch gerne weiter den Podcast das freut uns mega
und hilft uns natürlich auch quasi unser Gelaber hier sag ich
mal noch mehr an die Leute zu tragen.
Und falls es noch nicht gemacht hast, denk dran, auch diesen
Podcast zu abonnieren. Auf der Plattform deiner Wahl.
Und ansonsten hören wir uns alle beim nächsten Mal wieder.
Habt eine schöne Zeit bis dahin, ciao, deine Cody weiß.
Gemeinsam besser.