Der nachfolgende Text wurden mit KI erstellt und kann Fehler enthalten. Fehler gefunden? Bei GitHub editieren
So, dann herzlich willkommen zu einer weiteren Episode von Software-Architektur im Stream.
Diesmal wieder mal mit Ingo.
Hallo Ingo, schön, dass du da bist.
Hi.
Genau, und heute geht es um das Thema mit der AI-Produktivität.
Ingo, willst du dich erstmal kurz vorstellen?
Ja, also ich jetzt mittlerweile, wahrscheinlich sind es eher 20 Jahre.
Ich sage immer noch 15, aber ich glaube, es ist ein Understatement.
Background im Bereich IT, kunterbunt von jahrelange Entwickler, aber halt auch Projektmanagement, CTO, lange als Architekt gearbeitet.
Also wirklich sehr kunterbunt und habe mich irgendwann vor drei Jahren, vier Jahren, jetzt mittlerweile schon mehr und mehr auf das Thema Gen AI fokussiert.
Also ich war ganz vorne mit dabei als Beta-Tester von GitHub Copilot.
Und das Thema hat mich einfach extrem fasziniert, was dort funktioniert und was nicht.
Und aktuell bin ich hauptsächlich bei IONOS tätig als Trainer dort und auch als Architekt.
Und da ist halt eben auch eine Frage, okay, wenn wir den Entwicklern und Ingenieuren quasi KI näher bringen für ihr tägliches Handwerkszeug, was bringt das eigentlich?
Und so bin ich auf die Suche gegangen und habe ein bisschen geforscht, okay, was sagt die Wissenschaft dazu?
Und das sind sozusagen die Erkenntnisse, die ich gefunden habe, die ich halt eben heute auch mit deiner Community teilen möchte.
Genau, vielen Dank dafür.
Das ist halt eine von den Sachen, die ich halt tatsächlich irgendwie im hohen Maße spannend fand.
Also eben mal dieser Frage, werden wir jetzt schneller oder langsamer, dem halt ernsthaft mit wissenschaftlichen Methoden näher zu kommen.
Hinweis sozusagen vorab, es gibt eine Folge zum Thema Produktivität.
Da packe ich halt auch in die Links.
Da habe ich selber mal irgendwie darüber gesprochen, wie man Produktivität messen kann von Entwicklern, was das irgendwie alles bedeutet.
Einen größeren Teil davon werden wir heute, glaube ich, irgendwie ignorieren.
Also ich glaube, das ist halt eine sehr gute Ergänzung und wirft nochmal ein ganz anderes Licht da drauf.
Und ich habe mir noch aufgeschrieben, eigentlich müsste man jetzt, glaube ich, für eine Produktivität so richtig, um die halt richtig zu bewerten, halt sagen, okay, so viel investiere ich halt in AI.
Da bringe ich halt Folgendes raus.
Was bedeutet, Kosten spielen eine Rolle?
Das werden wir auf gar keinen Fall angucken.
Und das war so ein bisschen das, was ich halt am Anfang loswerden wollte.
Hast du eigentlich eine Definition von Produktivität, wenn wir gerade bei dem Thema sind?
Das ist superschwer.
Also das ist so wie Proteinland-Produkt, Wohlstand einer Gesellschaft.
Ich glaube, das ist einfach extrem schwer zu messen und irgendwie über eine Metrik abzubilden.
Was hier in den Studien gemacht wird, ist halt auch sehr, sehr unterschiedlich.
Da geht es von Selbsteinschätzung bis halt auf das Messen von Komits.
Also sehr, sehr divers.
Ich würde sagen, Produktivität ist am Ende, wenn es dem Business gut geht.
Also es ist schon irgendwie so eine Effizienzmetrik.
Also die zielt schon darauf ab, dass irgendwo mehr Umsätze oder höhere Gewinne gemacht werden.
Also quasi der Output sich steigert.
Und das kann halt sehr unterschiedlich sein.
Wenn wir über Architektur reden, dann ist es ja oft so, dass es um Qualitätsmetriken geht.
Also da kann das natürlich auch sein, dass der Code einfach eleganter, besser ist, besser zu warten.
Dann kann das auch alles dazu führen, dass ja über einen längeren Zeitraum dann der Output größer ist.
Also von daher gibt es da extrem viele Aspekte, die reinspielen.
Ich würde behaupten, wenn man im Kern auf die Frage guckt, ist es ja so ein bisschen eine betriebswirtschaftliche Frage.
Und das ist nach meinem Empfinden.
Ich habe jetzt nicht eine betriebswirtschaftliche Ausbildung, aber so etwas wie, ich setze halt Material ein, ich bekomme dafür halt irgendwas raus.
Und wenn ich halt für dasselbe Material mehr rausbekomme, dann ist es halt besser.
Warum entwickeln wir Software?
Um halt Geld zu verdienen.
Was halt bedeutet, dass wir Features haben, die wir halt für die Leute irgendwie bezahlen oder denen halt die Arbeit einfacher machen.
Das ist halt das, was rauskommt, was wir reinsetzen.
Das sind halt Entwickler, in die wir Zeit investieren.
Und das bedeutet, wenn wir halt für dieselbe Zeit mehr bessere Dinge bauen, die Menschen besser unterstützen, dann sind wir eigentlich produktiver.
Ich glaube, eine von den Sachen, die wir diskutieren müssen, ist eben genau die Produktivitätsdefinition, die die verschiedenen Studien zugrunde legt.
Hier ist halt auch schon nicht die Frage von Apollo 7.3.2.1.
Bedeutet größer Output denn, dass es wirklich produktiver ist?
Wenn der Code schlecht ist, dann bekommt man mehr Arbeit.
Also Output ist, ja genau, also da können wir jetzt auf Landsoft Code als Produktivitätsindikator kommen.
Und ich würde sagen, das ist ja eher das, was die Kunden, wo die Kunden bereit sind, Geld für zu bezahlen.
Und das ist natürlich auch eine extrem weitere Definition.
Aber ich bin halt nicht bereit, ein System für ein System zu bezahlen, was für mich kaputt geht.
Oder wo irgendwie ein neues Feature, was ich gerne hätte als Businesssoftware, ein halbes Jahr dauert.
So bin ich vielleicht eher nicht bereit, das zu bezahlen.
Und bei Software, wo es halt eben schneller geht, besser die Handhabbarkeit, Usability und alles besser ist, dann bin ich eher bereit.
Also das ist ein schwammiger Begriff, aber ich glaube, wenn man es so ein bisschen auf diese wirtschaftliche und Kundenperspektive ummünzt, dann wird es vielleicht ein bisschen greifbar.
Also mir fallen dazu zwei Sachen ein.
Die eine Sache ist halt dieser Produktivität.
Ich habe tatsächlich Talks darüber gehalten.
Die erste Frage, die ich gestellt habe in dem Talk, also wirklich auf der ersten Folie, ist Landsoft Code ein guter Produktivitätsindikator?
Und ich habe, glaube ich, noch nie jemanden erlebt, der sagt, ja.
Was mich halt in der AI-Diskussion irritiert, weil da wird Landsoft Code tatsächlich teilweise nicht in Übereinstimmung damit, was halt die Zuschauer in meinem Talks irgendwie da intuitiv gesagt haben.
Und ich glaube, das ist halt irgendwie auch klar.
Und das andere ist halt, ich weiß gar nicht, wo ich den Satz aufgeschnappt habe, Code is a liability.
Also Code ist halt eigentlich nicht etwas, was mir hilft, was also wertvoll ist.
Das, was wertvoll ist, sind die Features.
Und das ist, glaube ich, so ein wichtiger Punkt.
Wenn ich also die Features realisieren könnte ohne Code, ganz ohne Code, dann wäre ich halt besser davor.
Der Code ist halt nur das, was ich halt haben muss, um die Features bedauerlicherweise zu bauen.
Und durch Wartung wird es dann irgendwie tatsächlich eben unangenehm, mit dem Code umzukommen.
Outcome ist die bessere Metrik.
Passt da irgendwie auch rein, was halt eher so ein Virtual D-System ist.
Wir wollten über die Probleme der Studien sprechen.
Das war genau noch etwas, was wir vorher diskutieren wollten.
Genau, also eine Sache, die wir sehen werden gleich, die Studien, die wir uns anschauen, die haben ein bisschen so einen Zeitversatz.
Das heißt, die sind jetzt nicht von gestern und vorgestern.
Weil so eine Studie, die braucht halt ein bisschen Zeit.
Also das kann gerne mal ein Jahr dauern.
Die geht dann ins Review.
Als erstes wird die abgegeben, dann geht die ins Review.
Das dauert ein paar Monate.
Dann wird die nochmal überprüft.
Dann wird die auf Konferenzen eingereicht und wird dann irgendwann final abgenommen.
Also das kann dann so ein Jahr dauern, bis so eine Studie rauskommt, nachdem die erfasst wurde.
Wir wissen alle, ein Jahr, gerade vor einem Jahr, war die Welt halt eben doch noch relativ anders.
Wir werden uns heute auch Studien von vor einem Jahr angucken und dann gucken, welche Schlüsse wir daraus ziehen können.
Ich habe auch ein paar mitgebracht von diesem Jahr.
Und das Zweite ist halt, dass die Studien auch alle untereinander nicht sehr gut vergleichbar sind, weil die nämlich genau das, was wir besprochen haben, Produktivität extrem unterschiedlich messen.
Die einen sagen halt, wir fragen halt die Entwickler, wie produktiv sie sich selbst einschätzen.
Das werden wir gleich sehen, haben wir gleich zu reden.
Und andere Metriken neben Machine Learning Modelle, die an menschlichen Output, also quasi Menschen haben beurteilt, wie gut der Code ist und wie schnell die gearbeitet haben, die Entwickler.
Und das wurde dann in Machine Learning Modelle übersetzt und die haben dann die Bewertung vorgenommen.
Und da sieht man schon, dass der Ansatz, Produktivität zu bewerten, da extrem stark auseinandergeht.
Gut.
Und damit sind wir, glaube ich, im Vergleich sozusagen los.
Du hast ja netterweise, das verlinke ich auch noch mal, so einen Medium-Blogpost geschrieben, wo du dich halt durch die Studien durchlangelst.
Das heißt, da kann man das auch irgendwie alles nachlesen und nachschauen noch mal.
Das Erste, was wir haben, ist diese Metristudie von 2025.
Ja, und das war ja der Startpunkt, glaube ich, von uns beiden.
Das war so das, wo wir angefangen haben, darüber zu diskutieren, ich glaube, letztes Jahr bei den IT-Tagen und gesagt haben, okay, wie passt das eigentlich mit der Realität zusammen, dass die Entwickler, also wie schätzen Entwickler ihren Output mit KI-Systemen ein?
Und da sehen wir hier oben die grünen Gnubbel.
Das sind quasi die Einschätzungen, die Durchschnittseinschätzungen.
Und wir sehen hier erstmal Experten, wie schätzen Experten die Dealsgewinne von KI ein?
Also sehr hoch.
Dann als nächstes kommen Machine Learning Experten, also das Erste waren Business Experten, Machine Learning Experten.
Dann die Entwickler, die mussten sich quasi selber einschätzen vor der Studie, was sie denken, wie viele Produktivdealsgewinne sie durch KI haben.
Und dann mussten sie sich selbst noch mal einschätzen, nachdem die Studie durch war.
Und ihr seht schon, das hat sich ja alles irgendwo so in dem gleichen Rahmen, und die Machine Learning Experten, die leben ja auch davon.
Die müssen optimistisch sein.
Die hatten 40 Prozent, also für diejenigen, die den Podcast dann hören.
Die hatten so 40 und die Selbsteinschätzung vor der Studie und nach der Studie bei den Entwicklern, die war so rund plus 20 Prozent.
Die haben gedacht, sie werden ein Fünftel schneller dadurch.
Und das ist, glaube ich, das, was ich noch mal unterstreichen wollte.
Die Definition von Produktivität ist hier höhere Geschwindigkeit beim Lösen von irgendwelchen Issues.
So war das, wenn ich mich recht entsinne.
Die sollten bewerten, wie schnell sie die Probleme lösen können.
Und es wurden Hunderte von kleinen Tasks genommen, also die alle so im Rahmen von zwei Stunden lagen, damit die vergleichbar sind.
Das heißt, es wurden nicht alle Issues aus dem Backlog genommen, sondern speziell die heraus, die vergleichbar sind, von der Komplexität.
Und dann wurden alle Issue-Bearbeitungen mit einem Screen-Recording mitgeschnitten.
Einmal mussten die Entwickler per Handschreiben und einmal mussten sie KI nutzen.
Das war dann so ein 50-50-Split und man hat dann am Ende sich die Video-Recordings angeschaut.
Das ist wirklich ein wahnsinniger Aufwand.
Das muss ein wahnsinniger Aufwand gewesen sein.
Man hat sich jedenfalls die Videos angeschaut und wirklich mal mit der Stoppuhr daneben gesessen, wie lange haben die einzelnen Aspekte gedauert.
Und dort hat man gesehen, dass die Issues von ähnlicher Komplexität und tatsächlich muss man hier sagen, man sieht es hier oben, hier steht 246 Tasks, also es waren eine ganze Menge Aufgaben, aber es waren nur 16 Entwickler, also nicht sehr statistisch evident hier das Ganze, aber es gibt uns eine Richtung.
Und hier sieht man, bei den Aufzeichnungen kam dann raus, die Produktivitätsgewinne waren gar nicht plus, sondern minus 20%.
Der rote Punkt ist hier das, was tatsächlich gemessen wurde.
Ich sage mal, was meine Zusammenfassung der Studie ist und dann bin ich gespannt, was du dazu sagst.
Also die eine Sache ist halt, was ich halt aus dieser Studie lerne, ist halt nicht die subjektive Einschätzung und die objektive Sache sind zwei unterschiedliche Dinge.
Also nicht plus 20% schneller, Selbsteinschätzung tatsächlich 20% langsamer.
Das ist etwas, was ich aus der Studie gelernt habe.
Das andere ist halt, die Menschen werden langsamer, da muss man aber dazu sagen, es steht da oben auch, das sind halt Menschen, die auf genau, da ist übrigens ein guter Kommentar von Apollo7321, wir EntwicklerInnen waren schon immer extrem schlecht im Schätzen.
Ich lasse das jetzt mal unkommentiert.
Der andere Punkt ist halt, also die Menschen, die da betrachtet worden sind, das waren Open-Source-Projekte und Leute, die halt irgendwie Erfahrung haben.
Also hier steht, dass sie fünf Jahre Erfahrung mit diesen Projekten haben.
Und für mich ist so ein bisschen das informelle, oder wie soll ich sagen, wundert es mich, dass die nicht schneller werden durch andere Werkzeuge.
Nein, weil die sind wahrscheinlich schon extrem schnell, die Code-Basis ist sehr detailliert und dann ist es halt erklärlich, dass sie nicht schneller werden.
Das wäre für mich das andere Ergebnis.
Das sagt, beantwortet eigentlich nicht die Frage, ob man durch AI im Schnitt schneller wird.
Man wird eigentlich nur schneller, weil man halt irgendwie, oder man wird langsamer, wenn man erfahren ist, mit den Werkzeugen, die damals zur Verfügung standen, was irgendwie Co-Pilot oder sowas ist.
Also ich muss sagen, ich habe die Studie gelesen, sagen wir mal Mitte 2025.
Da bin ich schon ein halbes Jahr bei uns durchs Unternehmen gerannt und habe allen gesagt, wie cool Programmieren mit AI ist und dass sie das unbedingt ausprobieren und habe das quasi gezeigt, wie man das macht.
Ich habe erst mal einen ganz schönen Schock gekriegt, als ich die Studie gelesen habe und dachte, um Gottes Willen, jetzt habe ich allen alles erzählt und vielleicht habe ich jetzt irgendwie die Produktivität gesenkt vom Unternehmen.
Und dann habe ich mir die Studie ein bisschen genauer angeguckt, das werden wir gleich auch auf den nächsten Slide machen, und es war ein Entwickler mit dabei.
Man sieht ja hier, das ist quasi nur das Quartier, glaube ich.
Also ein Entwickler war mit dabei, der Tag irgendwo hier oben, der war wirklich besser.
Das war der Entwickler, der am meisten Erfahrung hatte.
Der hatte 50 Stunden Erfahrung mit Cursor schon, das war das Tool, das die eingesetzt haben damals.
Und alle anderen Entwickler hatten eine halbe Stunde Schulung zu dem Tool und mussten dann damit loslegen.
Und da sieht man, man wird besser über die Zeit, wenn man expost ist, aber auch wenn man es lernt und die Eigenheiten lernt.
Und das hat natürlich mir wieder in die Karten gespielt und deshalb ist dann die Studie doch in mein Kartendeck reingewandert oder in mein Slide-Deck reingewandert.
Das bedeutet, man müsste eigentlich sagen, erfahrene Entwickler, die in dem Projekt erfahren sind und denen man nicht die Chance gegeben hat, sich an die Tools zu zwingen, erstmal zu gewöhnen.
Genau.
Und dann guckt die Studie hier auch noch ein bisschen tiefer rein.
Ein Hinweis, den ich gerne loswerden möchte, sozusagen aus meiner Perspektive.
Das bei The Waver hat auch die Motivation für eben genau diese Episode.
Weil insbesondere diese Studie, da habe ich halt Diskussionen gelesen, die ich ehrlich gesagt erschreckend fand.
Wenn man sich die Studie anguckt und man guckt sich nur die Zusammenfassung an, steht da im Prinzip das drin.
Ich muss gestehen, dass die nicht ausführlich mit den Tools arbeiten konnten, das war mir jetzt irgendwie neu.
Aber wenn man nur die Zusammenfassung liest, sieht man, das sind halt erfahrene Entwickler.
Und insbesondere steht in der Zusammenfassung auch, das ist keine allgemeine Studie, die den Anspruch hat, allgemeingültig zu sein.
Und die Diskussion, die dann losging, war, ja, also AI führt doch gar nicht zu Produktivitätsgewinn.
Und das ist halt wirklich erschreckend, dass dann eben zu einer relevanten Sache so eine dermaßen verkürzte Diskussion losgeht.
Und das ist der Grund, weswegen ich eben so dankbar bin, dass du, Ingo, die zur Verfügung gestellt hast, das nochmal ein bisschen detaillierter aufzudröseln.
Weil nicht unabhängig, ob man jetzt sagt, AI ist das Beste ever oder es hat eine Erfolgskatastrophe.
Studien lesen und tatsächlich zu versuchen, zu verstehen, was da drin steht und das irgendwie auch kritisch zu betrachten, ist erstmal der erste Schritt, um sich überhaupt vernünftig mit dem Thema auseinanderzusetzen.
Ja, und man sieht hier auch ganz gut, Empirie ist halt immer nur so ein kleines Zoom, das ist so ein Mikroskop.
Also man guckt sich einen ganz speziellen Aspekt der Realität an und will den dann am Ende bewerten.
Und hier ist es halt eben Senior Softwareentwickler und das ist, glaube ich, auch das steht auch im Medium-Artikel, wenn wir heute nicht so viel drauf eingehen.
Das ist sozusagen die Königsdisziplin oder eine der Königsdisziplinen, wo KI einfach gerade noch scheitert und der Mensch einfach noch deutlich besser ist.
Architektur zum Beispiel, Softwarearchitektur und Systeme über längere Zeit im Gleichgewicht zu behalten, ist noch eine andere Königsdisziplin, wo einfach KI noch nicht so viel hilft aktuell.
Ja, auch keine Ahnung, ob sich das dann irgendwann ändert.
Jetzt hast du die Slides weggemacht.
Also gerade, weil wir miteinander reden.
Jetzt haben wir die nächste Slide.
Hier ist noch der Hinweis.
Jakob bei YouTube hat geschrieben, für mich hängt es sehr davon ab, um was entwickelt werde ich Beobachter in mir selbst, dass ich manchmal produktiver bin, manchmal unproduktiver.
Ich entwickle mit der Zeit ein Gefühl dafür.
Vielleicht auch ein guter Hinweis und das war auch etwas, was mir, was durch meinen Kopf ging, als du es noch mal erzählt hast, war auch etwas, was ich ehrlich gesagt in der Studie nicht in dem Detail gesehen hatte.
Das sind ja auch kürzere Aufgaben gewesen in dieser Metristudie und das bedeutet, dass es dann Filter gibt.
Es sind nicht langwierige, größere Sachen und vielleicht spielt das auch eine Rolle.
Aber wir messen natürlich auch die langfristigen Auswirkungen in der Studie.
Da haben wir nachher noch eine andere.
Was macht Programmieren mit KI mit meiner Code-Basis über ein paar Wochen, Monate hinweg.
Wenn wir jetzt erst mal hier reinzoomen, eins der Probleme für die Fehlerentschätzung war halt, dass neue Aufgaben dazukommen.
Man sieht es hier in lila.
Das sind die aufgezeichneten Aufgaben, die per Hand programmiert wurden und die grünen sind die Aufgaben, die mit KI erledigt wurden.
Und bei lila dauert natürlich irgendwie aktives Coden länger.
Und bei grün, also bei mit KI, braucht man weniger, um das aktiv zu coden, weil darum geht es ja genau.
Man sagt natürlich sprachlich, was man will und kriegt den Code dann quasi rausgepustet.
Das macht also Sinn.
Da hat man tatsächlich diese Produktivitätsgewinne.
Und in anderen Bereichen halt eben auch lesen und forschen.
Und man hat aber neue Zeitfresser sozusagen, die mit dazukommen.
Zum Beispiel, dass man sich den Output angucken muss.
Und das Prompting der KI-Dauerzeit, je weniger man Erfahrung damit hat, desto länger dauert das auch.
Oder das Warten auf KI-Output.
Das sind alles Aspekte, die vergleichen wir vielleicht mit unserem Gehirn gar nicht so, wenn wir jetzt sagen, sind wir schneller oder nicht schneller.
Es kommen einfach neue Herausforderungen dazu.
Genau.
Und ich hatte dich darum gebeten, die Folie insbesondere nochmal aufzunehmen, weil ich darüber gestolpert war in deinem Medium-Artikel.
Weil mein Executive Summary daraus ist halt, also einmal, ich investiere Zeit auf andere Sachen.
Und das wirkt so ein bisschen so, als würden die, wie soll ich sagen, es führt zu der Frage, ob es überhaupt Zeitgewinn gibt, was was anderes ist als der Output.
Und es ist nochmal ein guter Reminder, wenn ich nicht AI benutze, verbringe ich 35 Prozent mit aktivem Coden, steht hier.
Das heißt also, zwei Drittel der Zeit verbringe ich gerade nicht damit.
Das heißt, wenn ich Coden beschleunige, dann bedeutet das nur, dass ich 35 Prozent überhaupt beschleunige, also den Zeitanteil.
Was mir jetzt irgendwie auffällt, ist, also da sind halt auch nicht, ich fand es nicht, sind Idle und Overhead, sind das auch Meetings oder sowas?
Mich wundert halt gerade, dass die Menschen offensichtlich 90 Prozent der Zeit vorm Rechner sitzen und tatsächlich aktiv irgendwas tun.
Passt nicht zu dieser Geschichte mit, ich bin so genervt, weil ich anschaue und erinnere mich an Meetings bin.
Ich habe die Frage oft gekriegt.
Ich habe keine zufriedenstellende Antwort aufgefunden.
Ich würde sagen, man geht öfters zur Kaffeemaschine mit KI, das merke ich bei mir selber, ist ja auch nicht immer gut, aber ich denke, das hängt halt mit diesem Warten hier zusammen.
Aber wie gesagt, in der Studie, ich habe keine gute Antwort aufgefunden.
Das ist der Anteil über das Screen Recording.
Das heißt, wenn ein Entwickler vor dem Rechner sitzt und nicht AI benutzt, ist es so, dass die 35 Prozent der Zeit nur aktiv codet.
Das ist die Aussage.
Das ist ein guter Reminder.
Wenn wir das beschleunigen, ist die Frage, was hinten eigentlich rauskommt.
Hier ist noch so eine Frage, ich weiß nicht, ob du dazu eine Meinung hast.
Ich weiß nicht, ob das die Studien auch sagen.
Die Frage ist natürlich, macht man Reviews immer so gründlich, wie man sollte oder lässt das nach der Zeit sogar weiter nach, weil man einen guten Vibe hat?
Ja, ich war gestern bei OOP und Heise im Stream, da kam eine ähnliche Frage und ich würde das mit dem Code Review so ein bisschen aufgeteilter sehen.
Ich glaube nicht, dass es Sinn macht, für jeden Anwendungsfall immer komplett sich jede Zeit den Code durchzulesen.
Ich denke, es gibt viele Anwendungsfälle und viele Use Cases, wo es Fälle gibt, in der Realität, wo es einfach erzwungen wird.
Man kann das hier nicht vergleichen, ob ich jetzt die Homepage für den Backshop meiner Freundin schreibe oder ob ich an einem Software für ein Atomkraftwerk arbeite.
Da ist auch ein bisschen gesunder Menschenverstand und entsprechend die Regulierung drumherum, die dann vorgibt, ich muss halt andere Praktiken anwenden und deshalb würde ich das gar nicht so manchmal ist das voll in Ordnung, die Reviews der KI zu übergeben, meiner Meinung nach und manchmal würde ich das auf gar keinen Fall machen.
Ich glaube, das ist auch eine Frage von Druck, nicht?
Und das ist so ein bisschen ein Problem, was wir in der Zwischenveränderung ja eh haben, dass halt irgendwie häufig sehr viel Druck gemacht wird und dann leider die Qualität und dann wird es halt mit den Reviews auch nachlassen.
Und vielleicht noch ein Hinweis in eigener Sache.
Also ich habe gerade bei Mastodon und bei LinkedIn eine Umfrage gemacht mit der Aussage, hey Microsoft, Apple bringen halt Leute dazu, stärker AI zu benutzen.
Erwartest du, dass die Betriebssysteme besser oder schlechter dadurch werden oder unverändert?
Und da zeichnet sich so eine 60-Prozent-Marke ab, die hat sagen, sie glauben, dass es halt schlechter wird.
Was ich halt relativ lustig fand, nicht?
Also weil das sagt halt eigentlich, dass die Teilnehmer in der Studie sagen, wenn andere Leute AI benutzen, dann wird die Qualität der Produkte tendenziell schlechter.
Das fand ich halt ganz lustig.
So was ist hier noch als Kommentar?
Hier ist die Aussage von Xikuru.
Es ist ja oft so, dass die KI sehr viele Klassen und Zahlen selbst für kleine Anfragen ändert.
Ein Merchandise Request mit 5000 Änderungen kann ich mir nicht mehr ansehen.
Das ist auch ein bisschen das Problem.
Ja, ganz klar.
Also das sieht man ja auch so ein bisschen auf dem Slide.
Da ändert sich was.
Also es ist jetzt nicht so, dass es die gleiche Welt wie vorher ist und wir haben jetzt halt eben KI, sondern wir haben hier wirklich eine fundamentale Änderung im Markt und aber auch in der Art, wie wir als Softwareingenieure arbeiten.
Und ich glaube, da sehe ich auch keinem was Neues.
Und dass da ein Pull-Request auf einmal anders aussieht und vielleicht durchschnittlich mehr Zeilen hat, das gehört jetzt einfach zum Spiel dazu und wir müssen lernen, damit umzugehen.
Gut, weiter geht’s.
Nächste Folie.
Das sind jetzt die gleichen Entwickler nochmal, die wir auf der ersten Folie gesehen haben mit dem Minus 20 Prozent.
Das sind diese hier, diese 16 Entwickler mit den 250 Tasks.
Und die wurden quasi ein Dreivierteljahr später nochmal in die Studie reingerufen.
Also es waren nur noch zehn über von den 16.
Sechs wollten nicht mehr.
Und hier sieht man auch, und das unterstützt ja meine Hypothese so ein bisschen, dass halt Lernen was bringt.
Es ist jetzt nicht so, dass die 10x sind, was halt euch die Gurus auf YouTube und LinkedIn erzählen, sondern diese haben es geschafft, 20 Prozent effektiver zu werden, auch in ihrer Code-Basis, genau wie vorher mit den gleichen KI-Tools.
Klar, das war dann ein stärkeres Modell hier zu dem Zeitpunkt.
Davor war es, glaube ich, Sonne 3.5 und hier war es dann 4 irgendwas.
Aber hier sieht man, hier wurden wirklich die Produktivitätsgewinne und nicht nur in den Aufzeichnungen, nicht in der Selbsteinschätzung.
Und neue Entwickler haben sie mit dazu geholt.
Hier 47 neue Entwickler in die Studie, die dann gemessen wurden, die halt, weil sie nicht konstant mit der KI gearbeitet haben, ja einfach noch nicht so produktiv, noch nicht so fit waren dort drinnen.
Und dazu kam noch, Ihnen ist aufgefallen bei der Studie, das haben sie mit reingeschrieben, dass die Zahlen wahrscheinlich alle höher sein müssten, weil sie einen Großteil an Leuten in der Studie hatten, die einfach KI-Verweigerer waren.
Also quasi, wo die Antwort auf die Frage, bist du produktiver, schon gefallen ist, bevor die Studie stattgefunden hat.
Also es scheint da so eine leichte Verzerrung ins Negative zu geben.
Also das sind ja jetzt die objektiven Zahlen.
Das heißt, also diese plus 20 Prozent, die jetzt die Menschen halt haben, die jetzt tatsächlich dann in der späteren Phase weitergemacht haben mit diesen Tools.
Das sind ja die objektiven Zahlen, nehme ich an.
Also das heißt, die Ergebnisse von dem Screen Recording.
Wieso sollte da ein negativer Bias der Menschen eine signifikante Rolle spielen?
Also das haben sie hier angeschrieben, man sieht es hier, in den Grünen ist das beschrieben.
Also ich habe es mir jetzt nicht genau durchgelesen, was das dazu geführt hat.
Ich kann mir gut vorstellen, dass die es dann halt eben manipuliert haben und dann extrem, also mit Absicht lange gebraucht haben oder gewartet haben an gewissen Stellen, um hier das Ergebnis nach unten negativ zu beeinflussen.
Aber ich habe nur den Presseartikel dazu gelesen und halt eben das Kommentar hatte ich gerade wieder gesehen, hier auf dem Slide, da ist mir das wieder eingefallen.
Okay, super.
Gut, dann werden wir damit, glaube ich, fertig.
Also nicht bedeutet halt, die Leute haben dann irgendwann tatsächlich diese plus 20 Prozent und neue Menschen sind jetzt irgendwie fast neutral.
Also wenn man sich leicht positiver war, das würde ich jetzt behaupten, ist halt Messunggenauigkeit.
Das heißt also, die Studie mit den neuen Sachen sagt halt, dass das eben tatsächlich sich verbessert hat und mit neuen Werkzeugen verbessert ist.
Genau, super.
Und das sind dieselben Leute, die ja die Studie veröffentlicht haben und so weiter.
Genau, genau, genau.
Das ist das Meta, das ist ein unabhängiges und Non-Profit-Institut aus Kalifornien.
Ich habe das nochmal nachgeguckt und ja, die machen eigentlich ganz gute Arbeit, außer dann auf der nächsten Folie.
Das war ein Blogpost von diesem Jahr und den fand ich aus unterschiedlichen Aspekten wie Eberhardt interessant.
Ich fand das nämlich aus dem Aspekt interessant oder vielleicht, ich erkläre es mal kurz, was man hier sieht.
Also diese Punkte, diese Karos hier, die zeigen die Einschätzung eines Entwicklers und eines technischen Staff.
Also hier waren auch DevOps-Ingenieure und technische Projektmanager mit dabei.
Die eigene Einschätzung, wie viel schneller sie durch KI geworden sind.
Und dann wurde hier, und das ist der grüne Punkt für diese Aufgaben quasi, die KI gefragt und dann wurden die Transkripte genommen von der KI.
Also die schreibt ja immer so Logs weg, wenn man mit KI-Agenten kommuniziert.
Die wurden genommen und die wurden ausgewertet.
Und dann wurde ein LLM gefragt.
Also LLM is the Judge ist so der offizielle Begriff.
Okay, wie viel schneller war der Mensch jetzt, indem er hier die KI genutzt hat?
Wie lange hätte der gebraucht, um das gleich zu machen, wenn er es manuell gemacht hätte?
Und bei dieser Auswertung kam halt eben raus, dass die halt bis zu zehnmal schneller hier gerade die, die es viel nutzen.
Man sieht hier hinterher die tägliche Nutzung hier mit über elf Stunden am Tag und nur eine Stunde am Tag ist halt eben der Produktivitätsgewinn nicht ganz so groß.
Ich fand die Studie interessant, weil die Idee, ein LLM zu nehmen, um das zu beurteilen, wie viel schneller die waren gegenüber manueller Arbeit, das war eine Zwangsentscheidung, weil sie haben keine Leute mehr gefunden, die ohne KI-Systeme gearbeitet haben.
Und deshalb mussten sie halt auf irgendwas anderes zurückgreifen in der Studie.
Und jetzt Ewa, hat es Kritik dazu?
Ich muss gestehen, ich fand das offensichtlich absurd und auch erschreckend, weil die zentrale Frage ist ja eben, gibt es ein Speed-up?
Und wenn man halt die eine Sache misst, also feststellt, so lange dauert es mit dem Einsatz der AI, und dann die Frage, wie lange dauert es, ohne den Einsatz der AI nicht misst, sondern halt irgendwie ermittelt durch irgendetwas, ist das meiner Ansicht nach wissenschaftlich nicht haltbar.
Und wie du ja richtig sagst, das ist halt irgendwie auch ein Blogpost.
Also sprich, das ist halt keine echte wissenschaftliche Veröffentlichung in dem Sinne.
Also in dem Sinne, dass es halt irgendwie in einem Journal oder so stehen würde.
Ich meine, die beiden anderen METR-Sachen sind bei arXiv wichtig.
Ich glaube, die sind mittlerweile auch auf Konferenzen angenommen.
Also die sind mittlerweile auch durch peer-reviewed.
Genau, das wäre nämlich jetzt der nächste Punkt.
Also ich habe das so verstanden, dass arXiv halt preprint ist.
Das heißt also, es sind Sachen, die halt noch nicht peer-reviewed sind.
Peer-reviewed bedeutet halt, dass andere Wissenschaftler hinten drauf gucken und halt Anmerkungen machen.
Und typischerweise führt das dazu, dass die Studien nochmal angepasst werden.
Eine vernünftige wissenschaftliche Praxis ist halt, Dinge peer-reviewing zu lassen.
Das wäre also tatsächlich eine richtige Veröffentlichung.
arXiv entspricht dem Standard nicht.
Nach meinem Empfinden ist es aber so, dass die jetzt nicht einfach alles unbesehen nehmen.
Also da gibt es halt schon ein bisschen Reviews.
Aber bei richtigen wissenschaftlichen Journals gibt es halt auch so einen Vorfilter, also wo der Editor sich erst mal überlegt, ob er es rausschickt zu einem Review oder eben auch nicht.
Und das bedeutet, diese dritte Sache von METR ist halt einfach so, dass sie halt gar keinem Standard entspricht.
Also wir könnten morgen einen ähnlichen Blogpost schreiben.
Wir können auch beliebige Dinge behaupten.
Das können wir halt einfach tun.
Die anderen Sachen sind halt da irgendwie anders.
Und vielleicht noch ein Hinweis.
Ich glaube, das ist auch bei der nächsten Studie halt relevant.
Also vernünftige wissenschaftliche Studien sind halt so, dass sie die Daten mitliefern, damit man sich die Daten anschließend angucken kann.
Und das müsste bei diesen jetzt irgendwie der Fall sein.
Wir haben da, glaube ich, gleich noch ein Gegenbeispiel.
Ja, noch kurz eine Frage, die irgendwie aus dem Chat kam.
Geht es um ein Speed-up beim Erledigen der Aufgaben?
Ja, genau.
Also es geht um ein Speed-up bei dem Erledigen der Aufgaben.
Das hatten wir vorhin diskutiert, wo diese METR-Studien hat.
Alle sagen, dass da irgendwelche Tickets gelöst werden.
Und da geht es halt genau um den Speed-up.
Genau, hier kann man sich auch bei den Blogposts den LLM As a Judge Prompt mitgeliefert.
Also man kann das quasi dann einfach selber ausführen und sich selbst damit auch durchtesten mal und gucken, wie viel produktiver man im Rahmen dem, was ein LLM bewertet, ist.
Ich halte das auch für extrem schwierig, weil ein LLM hat ja Trainingsdaten, die quasi ja schon lange zurückliegen.
Und das kann das überhaupt nicht beurteilen, was jetzt die Aufgabe heute bedeuten wird.
Also ich halte das auch in vielerlei Hinsicht schwierig, das so zu bewerten.
Aber es gibt eine Tendenz und das ist ja schon mal.
Also man kann ja zumindest sagen, dass hier offensichtlich mit der gleichen Bewertungsmethode ein Unterschied zwischen dem Staff G und dem A ist.
Da gibt es ja irgendwie einen Unterschied.
Und dann kann man halt eben gucken, woher kommt der.
Der kann natürlich auch einfach an komplett falschen Datenerhebungen liegen.
Aber damit kann man ja dann anfangen zu arbeiten.
Also ich kann es ja noch mal wiederholen.
Ich halte das für wirklich absurden Unsinn.
Also ich kann nicht sagen, ich habe halt ein Datum.
Ich berechne mit irgendeinem nicht klaren Verfahren ein zweites Datum und ich behandle das zweite Datum so, als sei es ein Messwert.
Das ist absurd.
LLMs sind nicht Systeme, die Dinge allgemein vorhersagen können oder auswerten können.
Ich weiß nicht, wie man auf so eine Idee kommen kann.
Ich halte das für echt einfach Unsinn.
Also ich hoffe, dass wenn man das versucht in einem Journal zu publizieren, dass einem das um die Ohren geschlagen wird.
Also ich habe jetzt heute keine weiteren LLM Research Studien dabei, aber es gibt einige, die auch durch Journals durchgehen, die aber mehr Hand und Fuß haben, als das hier.
Das ist überhaupt keine Frage.
Hier ist noch eine Frage von dem Rainer 2345.
Der sagt, was sagt ihr zu der Anmerkung von Dino Strowatz aus der Woche, dass er sich nicht mehr in der Lage sieht, mit den vier doppelten PRs aufgrund von CVs umzugehen?
Das ist ein Thema, was wir hier nicht diskutieren.
Das ist was anderes.
Das sind so Code Reviews und Sicherheitsanalyse.
Es gibt da, wie heißt der, Daniel Sternberg oder so?
Der Mensch, der Curl baut.
Da habe ich einmal gelernt, dass er vor einem Jahr noch gesagt hat, das sind alles Scheiß-Reports, die aus den Security-Sachen herauskommen.
Jetzt sagt er, wir gucken sie uns zumindest an und es sind kleinere Vulnerabilities, die daraus kommen.
Daniel Sternberg sagt gerade.
Da kommen mittlerweile Security-Reports, die zumindest im Medium Probleme aufdecken, aber keine schwerwiegenden.
Die sind offensichtlich auch total überbeschäftigt mit Security-Reports.
Das ist tatsächlich ein großes Problem.
So wirkt es auf jeden Fall.
Auf der anderen Seite ist mein Gefühl, dass der Hype um dieses Mythos übertrieben ist.
Ich habe zumindest noch nicht davon gehört, dass da krasse Vulnerabilities herausgekommen sind.
Das ist nicht eine KI-Superwaffe, die dazu führt, dass man beliebige Systeme hacken kann.
Das ist ein weiteres Sicherheitstool.
Ja, ich denke schon, dass da gerade extrem was passiert.
Gerade bei CVs.
Ich sehe das überall.
Ich denke, es ist eine neue Welt, wie wir vorher diese Aufwaffnung von beiden Seiten hatten.
Die Attacker sind ein bisschen besser geworden und dann mussten die Verteidiger auch ein bisschen besser werden.
Man hat immer dieses Arms-Race.
Das beschleunigt sich gerade, so wie sich vieles andere auch beschleunigt.
Aber das ist vielleicht eines der ersten Bereiche, wo man diese extreme Beschleunigung sieht.
Wir haben vielleicht noch nicht die richtigen Waffen gerade, um umgegenzuschießen.
Mit vielen PRs, die reinkommen, die vielleicht gar nicht mal CVI-bezogen sind, sondern einfach nur, weil mehr Leute mitspielen wollen in Open-Source-Projekten und es jetzt eben auch können.
Vielleicht noch nicht in der Qualität, wie wir es bräuchten, aber es passiert ja.
Oder ob es über CVI ist.
Wie gehe ich mit diesen PRs um?
Das ist ja auch gesellschaftlich ein Riesenthema gerade.
Bei Entwicklern der Gesamtgesellschaft ist es noch nicht so angekommen.
Manche sagen, machen wir gar nicht.
Ist uns vollkommen egal.
Andere sagen, ja, ist doch super.
Dann habe ich jetzt endlich Leute, die mitarbeiten, die mich unterstützen bei der Open-Source.
Ich muss nicht mehr das alles alleine machen.
Die Wahrheit ist wahrscheinlich irgendwo in der Mitte, wie immer.
Der Daniel Sternberg von Curl hat eben tatsächlich gesagt, dass er überarbeitet ist.
Das ist auch gerade der Hinweis von dem Apollo.
Das ist auch etwas, was ich in dem Blogpost tatsächlich gelesen habe, wo er mir gesagt hat, ich habe schon immer wahnsinnig viel gearbeitet.
Das ist meine Mission.
Aber jetzt sagt meine Frau, dass es ein bisschen sehr viel ist.
Wir haben am 19.
Also in drei Wochen macht Ralf eine Episode mit dem Martin Lippert über das Thema AI-Vampire, wo es auch darum geht, was bedeutet das eigentlich für unsere Arbeit als TechnikerInnen und wie es da um uns steht und was das bedeutet.
Ich glaube, was der Daniel da sagt, ist ein Hinweis, dass tatsächlich alles nicht so schön ist.
Ja, und hier kommt ja auch das Konter mit dem überarbeitet sein.
Das merke ich bei mir auch.
Meine Frau hat das auch zu mir gesagt.
Ich habe es noch keinen erlebt, der gesagt hat, hey, ich bin doppelt so produktiv mit KI, aber ich arbeite nur noch halb so viel.
Die Logik wäre aber sehr andersrum.
Ich bin doppelt so produktiv und arbeite viermal so viel.
Ja, und das ist ein ganz hervorragender Punkt, den man eigentlich auch noch mal einbauen kann, in die Frage, was ist eigentlich Produktivität?
Es kann bedeuten, dass ich weniger Zeit mehr erreiche.
Und das ist halt auch noch diese Geschichte mit der Nachhaltigkeit.
Ich kann halt Menschen unter Druck setzen und dafür sorgen, dass wir kurzzeitig mehr Output generieren.
Definition von Output.
Nachhaltigkeit steht halt auf ein anderes Thema.
Ich finde es immer noch lustig, dass Extreme Programming damals vor der Jahrtausendwende gesagt hat, wir wollen ein Sustainable Pace, also eine nachhaltige Geschwindigkeit und eine 40-Stunden-Woche.
Ja, wie du magst.
Nächste Studie?
Hier hatte ich noch mal kurz zusammengefasst.
Jetzt kommt der Standford-Bereich.
Also eine Standford-Studie, die wir leider nur so ein bisschen über das betrachten können, was uns übermittelt wurde.
Weil bei der Standford-Studie darf nicht jeder teilnehmen.
Oder die darf nicht jeder einsehen.
Die darf man nur einsehen, wenn man dort mitmacht und versucht, ein deutsches Unternehmen da zu bewegen, bei einer amerikanischen Studie mitzumachen.
Das wird schwierig.
Als Einzelperson bin ich zu klein.
Von daher sehen wir nur das, was ab und zu über die Medien durchsickert von dieser Studie.
Und was halt wiederum bedeutet, um es nochmal klar zu sagen, das ist halt nicht richtige wissenschaftliche Praxis.
Richtige wissenschaftliche Praxis wäre halt, dass das Ding peer-reviewed ist, offen ist, in einem Journal publiziert ist, sodass man auf die Daten natürlich zugreifen kann.
Und das ist trotzdem etwas, was irgendwie spannend ist, sich mal anzugucken.
Genau.
Also was veröffentlicht ist, ist Ihre Methode hier zur Bewertung von dem Output sozusagen.
Also Ihre eigene Methode, Produktivität zu bewerten.
Und das sieht man hier.
Also wir haben einen Ingenieur, der schreibt Code.
Und dann gibt es 15 Experten hier oben im Panel, die bewerten, wie gut ist der Code.
Und das sind dann nach, ich hätte hier unten die Kriterien mal aufgefasst, also Komplexität, Interfaces, Datenstruktur, Quotienten, also so die Klassiker.
Und dann geben Sie dem Output, also dem Code, eine Produktivitätskennzahl.
Und daneben müsste man dann halt eben auch noch, okay, wie schnell war das?
Ist das skalierbar?
Also nimmt noch Hard Facts mit dazu.
Und das vergleicht man mit, oder das gibt man sozusagen in ein ML, Machine Learning Modell rein und sagt, okay, das sind sozusagen, das ist der Input, das ist der Output.
Und jetzt bitte simuliere das doch mal.
Und das hat hier das KI-Modell simuliert, das quasi, was Sie hier trainiert haben.
Wie gesagt, die Methodik dazu, dieses Modell zu machen, die ist offen, die ist peer-reviewed, da kann man drauf zugreifen.
Aber die Daten, die durch diese Methodik erhoben wurden, die sind halt nicht offen.
Und da können wir jetzt nur reingucken in dem, was die Mitarbeiter sozusagen ab und zu mal veröffentlicht haben.
Lass uns hier nochmal kurz verweilen.
Also was dieses Modell jetzt tut ist, ich gebe dem, also so würde ich das zusammenfassen, ich gebe dem halt irgendwelchen Code darauf und sage halt, dieses System, das ist halt gut skalierbarer, also fast scalable und affordable, also es ist halt schneller, skalierbarer und irgendwie so wirtschaftlich.
Das bezieht sich auf die Methodik.
Also die Methodik ist schnell und skaliert und ist halt günstig.
Deshalb werden hier nicht immer Experten eingesetzt.
Das war jetzt nicht ganz klar von mir.
Ich habe also jetzt Maschinen-Learning-Modell, in dem ich halt irgendwie Code vorlege und der sagt halt, das ist wartbarer Code oder nicht wartbarer Code.
Genau.
Und das Maschinen-Learning-Modell stimmt hier mit 85-prozentiger Wahrscheinlichkeit, korreliert das mit dem Output der Experten.
Und da sagen sie, okay, das reicht uns dazu, weil wir können nicht die ganze Zeit 15 Experten, die über 300 Teams reviewen und beurteilen, nicht finanzieren.
Da ist halt für mich erstmal die Frage, also eigentlich hat man ja gesagt, dass Entwickler dann besonders gut davorstehen, wenn sie halt Code bauen, der hat sozusagen für die Firma Geld verdient und das möglichst schnell und möglichst viel Geld.
Das hier ist jetzt was anderes.
Also auch die Geschwindigkeit, wie schnell dieser Code erstellt wird, aber das ist jetzt sozusagen noch so eine Hard-Facts, die hier mit reingreifen.
Aber in den Soft-Facts geht es quasi erstmal darum, wie qualitativ hochwertig wird dieser Code wahrgenommen, im Sinne von Wartbarkeit.
Und da ist halt für mich die, also im Sinne von Metriken.
Und Metriken sind ja eigentlich nur sozusagen Proxy für Wartbarkeit.
Also nachdem ich Wartbarkeit nicht direkt messen kann, nur indem ich halt Code ändern lasse, nehme ich halt Metriken, um halt darauf zu schließen, wie leicht der Codeänderbar ist, aber durch Menschen.
Und ich könnte mich ja jetzt irgendwie hinstellen und könnte halt sagen, wenn ich sozusagen so ein, ich sag jetzt mal AI-Ultra wäre, das ist halt völlig irrelevant, weil wir haben ja AIs und AIs können auch mit Codebasen umgehen, die halt nicht wartbar sind.
Deswegen ist Code-Wartbarkeit eigentlich kein ernsthaftes Argument für irgendetwas.
Also nicht, ich spiele Avocadus Diaboli, ich bin definiert nicht dieser Meinung.
Aber ich finde das halt so ein bisschen komisch, weil ich eigentlich, also weil das halt in Frage stellt, ob diese Metriken im Rahmen von AI-Coding noch eine Rolle spielen.
Ja, also wir haben später noch, vielleicht schaffen wir es noch bis dahin, noch eine Studie, die zeigt schon, dass die, wenn man jetzt mit unterschiedlichen Methoden die Qualität des Codes misst für Menschen, dass die auch Auswirkungen auf die Effektivität von KI hat.
Also es gibt da eine Korrelation.
Ich kann jetzt nicht sagen, wie groß die ist, aber es gibt da einen Zusammenhang.
Und bis jetzt gibt es halt noch kein wirklich gutes System.
Ich habe mich da mal an einem versucht, aber es gibt noch kein wirklich gutes System, was nur auf die Aspekte für KI eingeht, die meisten sind eher so ein Mix.
Und im Endeffekt spiegelt das natürlich auch die Realität wieder.
Also es gibt ja, ich glaube, es sind die wenigsten Systeme, die es jetzt in der freien Wildbahn gibt, die wirklich nur mit KI geschrieben werden, wo Menschen gar nichts mehr machen, sondern es ist ja in der Regel immer noch ein Mix.
Das könnte sich natürlich irgendwann ändern und dann werden solche Metriken, die du erwähnt hast, natürlich relevant dafür.
Okay, also das ist das, wie die halt vorgehen in der Studie.
Genau, und jetzt ist die Frage, was kommt dabei raus?
Und wir sehen hier auch, wir haben hier so ein Knowledge Cut-off von einem Jahr in etwa.
Das waren sozusagen die letzten Daten, die Sie Ende letzten Jahres irgendwie veröffentlicht haben.
Und wir sehen hier am Anfang der Erhebung ist die Produktivität erstmal ein bisschen gesunken.
Man sieht hier, das sind minus 5, plus 5, plus 10 Prozent.
Und danach sozusagen von Juli 2023 bis 2025, also so eine Zwei-Jahres-Spanne hier, ist die jetzt im Schnitt so auf 10 Prozent, plus 10 Prozent gegangen.
Genau, das ist sozusagen das, was das Team herausgefunden hat.
Und unten hat man hier sozusagen die Baseline, das, was bei Null ist.
Das ist sozusagen die Einschätzung, wie lange Menschen für den Code gebraucht hätten mit ihrem Machine Learning-Modell und mit der Vorstudie dafür, um das vergleichen zu können, eine Relation zu setzen.
Da ist noch ein Kommentar, auch wieder von Apollo 7 3 2 1.
Ich denke, Code-Quality ist weiterhin wichtig, weil die Reviewer ihn nach wie vor verstehen müssen.
YOLO-Mode ist, glaube ich, nicht gangbar.
Also einfach das LM-Generieren, das nehme ich an.
LM-Code basiert ja nur auf Wahrscheinlichkeiten.
Ja, aber das ist ja bei Machine-Learning-Modellen genauso der Fall.
Also die werden ja auch, also man muss ja nicht unbedingt das verstehen, was in der Machine-Learning-Modell passiert und vor sich geht, um beurteilen zu können, dass die Outputs korrekt sind bei gewissen Inputs.
Also ja, aber wie gesagt, das ist halt nicht auf jeden Fall anwendbar in meinen Augen.
Also ich finde den Punkt, auf den ihr ja hinweist, ist, LMs müssen halt qualitativ hochwertigen Codes liefern, weil der irgendwie gereviewt werden muss durch Menschen.
Das finde ich einen nachvollziehbaren Punkt.
Und ich würde jetzt behaupten, dass halt in vielen Fällen das halt auch tatsächlich immer noch notwendig ist und genauso umgesetzt wird.
Aber es gibt halt meiner Meinung nach keine inhärente Notwendigkeit, dass jeder Code gereviewt werden muss.
Also das ist irgendwie so ein Branchen-Ding.
Wahrscheinlich auch, weil wir uns damit als Entwickler besser fühlen, weil wir noch gebraucht werden, um den Code zu reviewen.
Aber es gibt ja keine physikalische Notwendigkeit, dass wir Menschen jetzt Codereviewen müssen, weil wir für immer besser sein werden im Codereview als ein KI-Modell.
Das ist natürlich die Frage.
Okay, ich gebe ja jetzt meinem Sohn, wenn der in der Schule ist, einen Test ab, dann sage ich ja nicht, gib dir mal selbst eine Note danach und gucke mal, wie gut du das gemacht hast.
Also da ist ja auch vielleicht so eine moralische Zwiespalt da drin.
Aber ich denke, wenn das statistisch besser ist als der Mensch, dann werden wir weniger Codereview machen als Entwickler.
Das denke ich schon.
Ja, es ist noch ein anderer Aspekt.
Also das ist so ein Gedanke, den ich bei Mastodon mal von Tim Zörner aufgeschnappt habe.
Der meiste Code da draußen ist durchschnittlich.
Der ist nicht super.
Um nicht zu sagen, dass sehr viel von dem Code, der tatsächlich Unternehmen am Laufen hält, deutlich untercode-durchschnittlich ist.
Und der Punkt, den Tim nach meinem Empfinden gemacht hat, ist, es reicht ja aus, wenn wir so gut sind, wie der Code in der Produktion ist, weil diese Qualität ist offensichtlich akzeptabel.
Und das ist auf einer gewissen Ebene nihilistisch, weil es im Prinzip sagt, die Qualitätsdiskussion, die wir uns schon lange liefern, wo es ja solche Extrempositionen gibt, die sagen, wir müssen immer ganz krasse Qualität liefern, weil der Code wartbar sein muss und so weiter.
Das stellt diese Meinung ja in Abrede.
Aber es ist in gewisser Weise nachvollziehbar, dass man eben nur so weit kommen muss, dass AI sozusagen Code produziert, so wie der typische Code, der in der Produktion ist.
Und das ist oft nicht so schön.
Ich denke, das ist jetzt eigentlich für uns eine Riesenchance als Disziplin, besseren Code zu schreiben, weil halt dieser Benchmark, der Durchschnittscode quasi, uns so sehr günstig zur Verfügung gestellt wird.
Und wir können uns halt darum kümmern, dass der jetzt accessible ist, dass der gut dokumentiert ist und dass der gut verständlich ist, erweiterbar ist, die Architekturmetriken anwendet, Fitnessfunctions, also die ganzen Sachen.
Wir können uns jetzt eigentlich auf die Sachen konzentrieren, wo wir vielleicht vorher keine Zeit hatten.
Das hat natürlich immer zwei Seiten.
Du hast im Prinzip recht.
Eine Sache, die wichtig ist, ist, dass wir diskutieren.
Was in dieser AI-Diskussion eine Rolle spielt, ist, dass jetzt eben gesagt wird, wenn das System sehr gut strukturiert ist und toll aussieht, dann ist es auch für AI nutzbar und einfach erweiterbar.
Was ich also für Borderline pervers halte, weil das bedeutet, wenn wir Entwicklerinnen haben, nicht Menschen, die möglicherweise tatsächlich ernsthaft nahezu darunter leiden, dass sie sich mit scheiß Code rumschlagen müssen, das ist akzeptabel.
Aber wenn wir eine AI haben, die nur Produktivität verbessern kann, dann investieren wir jetzt tatsächlich in Codequalität.
Das finde ich extrem schwierig und das kommt dabei heraus.
Das andere, was wir hier beobachten, ist dieser AI-Slop.
Das heißt, es gehen Sachen in Produktion, die qualitativ natürlich nicht besser sind, sondern schlimmer.
Der meiste Code ist durchschnittlich, aber auch nur Glue-Code, um bestehende Komponenten zu verbinden.
Vielleicht ist das auch gut.
Die Meta-Studie hat er neu untersucht, Greenfield und Brownfield.
Ich glaube, das ist jetzt wenig überraschend, aber Code, der neu produziert wird.
Das sind halt alles Enterprise-Projekte, also das ist jetzt auch nicht die Homepage vom Backshop.
Man sieht hier, neue Projekte profitieren natürlich bedeutend höher und auch Projekte mit einer geringeren Komplexität.
Also Sachen, die quasi schon mal existiert haben, die wenig Code benötigen, um zu funktionieren, die lassen sich natürlich bedeutend besser umsetzen.
Das ist glaube ich, Common Sense, oder?
Müssen wir jetzt nicht weiter darauf eingehen?
Ja, also eine Frage, die sich vielleicht an dieser Stelle lohnt zu stellen, ist, wir hatten ja am Mittwoch die Episode mit Yadu und Tobias, wo sie berichtet haben über ihre Erfahrungen mit Agent-Decoding.
Da war es ja genauso, dass sie ein Legacy-System haben, offensichtlich sehr schlecht strukturiert.
Und wo sie berichtet haben aus einer modulweisen Migration, wo ein Teil der Aufgabe war, die Module zu verstehen und dann zu migrieren.
Das ist also nicht so braun, wie es wird.
Im Brownfield existieren ja Code.
Da war die Aussage, dass sie insbesondere dort – das ist keine Studie, das hat Yadu insbesondere dargestellt, aber sie hatten eine starke empirische Evidenz, die gesagt hat, früher haben wir ungefähr eine Woche gebraucht, um ein Modul zu verstehen und daran zu gehen, das zu ändern.
Jetzt brauchen wir so einen Tag.
Was ja massiv ist.
Wir haben bisher nur zweistellige Prozentzahlen gesehen an Produktivitätssteigerungen, noch nicht mal einen Faktor von zwei.
Und da gibt es jetzt diesen empirischen Hinweis, dass gerade im Umgang mit Brownfield es viel schneller wird.
Wie erklärst du dir das?
Ich habe da natürlich viele Erklärungsansätze, die man sich jetzt evident angucken kann.
Wir haben das ja gesehen, die Wahrnehmung ist sehr unterschiedlich zu dem, was eigentlich gemessen wurde.
Was schon daran liegt, dass man sich selbst anders wahrnimmt und vielleicht andere Aspekte in den Vordergrund rutschen, die man jetzt erstmal ausblendet, weil alles so toll ist.
Tolle neue Welt.
So merke ich mir das bei mir selbst.
Ich habe gestern zum Beispiel noch bis 23 Uhr gesessen und was gemacht, weil es für mich nicht sich anfühlt gerade wie Arbeit, weil ich mir denke, ich muss dem Agenten ab und zu mal was geben.
Dann gucke ich mir das kurz an, was er gemacht hat und dann füttere ich den wieder, damit ich die Aufgabe fertig kriege.
Früher hätte ich vielleicht auch bis 23 Uhr gesessen, aber ich wäre ja viel fertiger gewesen.
Jetzt fühlt es sich an wie eine andere Art des Arbeitens.
Ich denke gar nicht, dass man das so richtig vergleicht.
Es ist wirklich schwierig, das miteinander zu vergleichen, wie wir letztes Jahr programmiert haben und wie es heute ist.
Es ist wirklich sehr unterschiedlich.
Ich finde es extrem schwer, in so eine Metrik wie zum Beispiel, ich bin jetzt fünfmal schneller, zu gießen.
Okay.
Noch Dinge aus den Studien, die wir diskutieren sollten?
Ich weiß nicht.
Wir haben noch ganz viel.
Wir haben hier noch Code Health von dem Adam Tornel.
Das ist vielleicht noch ein Aspekt, der hier in der Studie herauskam.
Hier wurde Code genommen und der wurde gerefactored, der wurde ins Refactoring geschickt.
Hier sieht man, wenn der Code mit höherer Code Health, also mit einer höheren Qualität, reinkommt.
Das wurde hier mit dem Code Health-Tool, das Adam auch entwickelt, gemessen.
Dann sieht man hier ganz klar, dass die Break-Rate, also die Wahrscheinlichkeit, dass etwas kaputt geht, runtergeht.
Das korreliert extrem stark mit der Gesundheit des Codes.
Je healthier der ist, desto besser der strukturiert ist.
Du hast ja auch eine Episode mit ihm dazu gemacht.
In seiner Software sieht man das immer so als rote Gnubbel, ob etwas gut ist oder nicht.
Das korreliert sehr stark damit, wie wahrscheinlich die KI beim Refactoring etwas kaputt macht.
Das deutet extrem stark darauf hin, dass ein aktuell guter Hebel dafür ist, wenn man seine Software quasi für KI fit machen will, jetzt ein guter Moment ist, diese klassischen Code Health-Metriken zum Beispiel anzuwenden.
Da gibt es auch Sonar Cube.
Ich hatte auch so ein kleines Agent-Scoring gebaut.
Das kann man alles nehmen.
Das sind objektive Maßstäbe.
Das ist auch sehr gut für KI, weil wenn man subjektive Maßstäbe sind, dann wird es halt schwammig.
Objektive Maßstäbe sind immer ein guter Feedback-Mechanismus für KI-Agenten.
Dann kann man sowas sehr gut einsetzen, um seine eigene Qualität zu erhöhen.
Das ist nicht alles.
Ich glaube trotzdem, sowas wie, macht das Datenmodell überhaupt noch Sinn?
Das ist halt weiterhin schwer für KI zu beurteilen, weil Domänenwissen ein sehr spezieller Use-Case.
Das vielleicht noch so als Abschluss.
Genau.
Vielleicht zwei, drei Hinweise.
Du hattest ja gesagt, ich hatte eine Episode mit ihm gemacht.
Das war zu Behavioral Code Analysis.
Da geht es also darum, wie das Team mit dem Code umgeht, wie man das sozusagen mit Metriken erfasst.
Das ist, glaube ich, ein anderes Thema.
Er hat auch dieses Your Code is a Crime Scene geschrieben, dieses Buch.
Der Hinweis wäre, diese Studie beantwortet dann offensichtlich die Frage, ob die Metriken irgendeine Relevanz haben.
Haben sie, weil auch AI mit Metriken irgendwie besser aussieht bezüglich der wissenschaftlichen Praxis.
Ich bin da ein Tool-Hersteller.
Diese Studie, ich weiß nicht, wie du es sehen würdest, sagt in gewisser Weise, die Tools, die hergestellt werden, sind auch sinnvoll für AI.
Da wäre ich immer ein bisschen vorsichtig.
Adam ist ein schlauer Mensch.
Er hat auch ganz viele tolle Sachen gemacht.
Your Code is a Crime Scene ist super.
Behavioral Code Analysis finde ich super.
Aber es ist halt so ein bisschen die Frage, ob das reaktiv ist, sein kann.
Es gibt ja noch andere Veröffentlichungen in dem Bereich, also Corona-Lilienthal.
Die hat natürlich auch ein Beratungsunternehmen.
Wir müssen alle irgendwie überleben.
Da kann man uns wahrscheinlich alle irgendwie Doppelmoral unterstellen.
Aber auch mit Neil Ford hatte ich mich unterhalten letztens.
Der schreibt an einem Buch, das heißt Architecture Metrics oder sowas, so in etwa.
Die haben mehrere Metriken, die sie anwenden, um Architektur zu bewerten.
Dieses Buch, das wird jetzt, ich glaube, im Herbst erscheinen, das ist speziell für KI auch.
Also es funktioniert auch für Menschen.
Es war angefangen mit dem Hintergrund für Menschen, aber die haben es dann irgendwann umgemünzt und es geht jetzt mehr in die Richtung für KI.
Wie kriegen wir die Metriken für KI hin?
Und das ist sozusagen Architekturbewertung für KI-Systeme.
Das ist auch super spannend.
Neil ist bei ThoughtWorks einer von den Menschen, die er da sozusagen anfordert.
Er hat dieses Buch über langlebige Softwarearchitektur geschrieben.
Wir haben auch schon mal gesprochen, interessanterweise hat er sie promoviert über Psychologie und wie er Menschenstrukturen bilden, um mit Systemen umgehen zu können.
Also da kommt es ja aus dem Hintergrund.
Was haben wir noch?
Sollen wir noch ein paar Minuten machen?
Ja, genau.
Ich glaube, wir haben noch zwei Sachen, wenn ich es richtig sehe und das können wir dann glaube ich nochmal…
Das war hier eine Studie, die hat Dave Farley mit vorangebracht.
Da war ich auch kurz mit eingeschrieben Anfang letzten Jahres.
Es wurden eigentlich viele Sachen geguckt, aber am Ende die Studie, als sie dann rauskam, wurde sehr auf einen Maintenance-Aspekt bezogen.
Es wurde dann in der Studie geguckt, wenn ein Mensch ein Stückchen Code editiert und danach kommt ein anderer Mensch und der muss weiter daran arbeiten.
Wie gut funktioniert das?
Das war die Orangengruppe, diese Orangenbalken.
Dann hat man einen Menschen genommen mit KI-Systemen, der Code bearbeitet hat und der andere Mensch musste dann diesen Code weiter bearbeiten.
Ich bin ausgestiegen aus der Studie, weil ich gesagt habe, ich verstehe das ja gar nicht.
Das ist überhaupt nicht die Premiere-Sprache, mit der ich mich auskenne.
Ich kann das gar nicht weiter entwickeln.
Aber das Finding war am Ende, man sieht es hier auf der rechten Seite so ein bisschen, es ist relativ nah beieinander.
Hier sieht man das manuelle Bearbeitete und mit Code Bearbeitete.
Die überschneiden sich sehr stark.
Die Maintenance von Code, der mit KI gebaut wurde und dann von Menschen weiterentwickelt wird, ist relativ nah an dem, was Menschen gebaut haben und Menschen weiterentwickelt haben.
Das heißt, was viele sagen, dass es da einen Rieseneinbruch in der Maintainability gibt.
Keine Ahnung, wie es über Zeit aussieht.
Das ist jetzt wirklich nur einmal kurz daran gearbeitet und dann nochmal kurz daran gearbeitet an der Aufgabe.
Aber die Datenlage hier, die gibt keine Evidenz dafür, dass es da irgendwie Probleme mit dem Code gibt.
Also wenn ich es richtig sehe, ist es ja eher so, der Median für die Completion Time ist einmal bei den Menschen mit AI-Unterstützung 140 Minuten, bei den anderen sieht es so aus wie 170 oder so was.
Das bedeutet also, wenn der Original-Code AI unterstützt ist, ist er anschließend schneller änderbar.
Aber da ist ja ein großer Fehler bei dem, was du ja schon sagst.
Also was dann rauskam, weshalb hier die menschliche Kontrollgruppe, also die Leute, die sich wirklich hier lange in der Code-Basis auskannten und sehr seniorisch waren, die waren wirklich besser.
Das war keine statistische Signifikanz, aber man konnte sehen, dass da eine Tendenz da war, dass Menschen mit sehr viel Erfahrung tatsächlich besser maintainbaren Code schreiben als AI-Systeme.
Aber immer halt eine Momentaufnahme aufhalten.
Ich wollte es nur angesprochen haben, weshalb hier diese leichte Steigung da ist.
Es kam nicht durch die mittleren oder Junior-Entwickler.
Und hier, das war noch eine andere Studie, die ganz kurz noch machen.
Hier hat man geguckt, sechs Monate, also hier hat man Git-Code-Basen halt eben untersucht.
So konnte man das auch in die Vergangenheit machen.
Man hat hier bei minus sechs Monaten angefangen auf null.
Und null war der Moment, wo KI eingeführt wurde.
Und dann guckt man dann auf bis sechs, plus sechs Monate.
Also wie haben die Teams dann damit gearbeitet, abgeschnitten.
Man hat sich hier dann quasi die Git-History angeschaut.
Und was man sieht, ist erstmal, hier zum Beispiel beim ersten Graphen, dass erstmal über 40 Prozent mehr Commits im ersten Monat nach der Einführung von KI passieren.
Das ist dann aber auch irgendwann wieder weg.
Also man kommt dann wieder auf so ein Normalmaß.
Gleiches mit Lines-Edit, also wie viele Zeilen Code hinzugefügt werden.
So das scheint auch, zumindest ist hier in dieser Studie, eben dann wieder auf Normalmaß sich runterzuregeln.
Und was interessant ist, was sich nämlich nicht runtergeregelt hat, sind die Warnings aus der statischen Code-Analyse.
Also das ist ja noch ein weiterer Indikator.
Wer mit KI arbeitet, sollte statische Code-Analyse unbedingt einsetzen.
Es ist ja die beste Werbung für statische Code-Analyse, dass das Ding jetzt endlich mal ständig feuert und die KI hier quasi nacharbeiten muss.
Das zeigt ja, dass es hier sinnvoll ist.
Aber auch was man trotz statischer Code-Analyse nicht in den Griff gekriegt hat, zum Ende ist halt hier die Komplexität.
Das heißt, die wird weiterhin erhöht.
Das liegt an Sachen, dass klar die Funktionen größer werden, mehr werden, insgesamt aber auch mehr Entropie sozusagen in die Systeme reingerät.
Also es wird weniger beherrschbar.
Es gibt kein mentales Modell mehr, was das irgendwie zusammenhält, sondern Modul A ist vielleicht auf eine leicht andere Art entstanden als Modul B und auf einmal passt das nicht mehr so gut zusammen.
Da gibt es gerade noch kein Allheilmittel und das zeigt die Studie hier auch.
Aber das, was wir gerade vorhin besprochen haben und auch noch mit dem Vade gesagt haben, dass bei einem Handover von einer Aufgabe anschließend die Aufgabe nicht signifikant langsamer erfüllt wird.
Hier ist ja die Aussage, wenn ich AI einführe, werden sofort die Metriken deutlich schlechter.
Das müsste ja eigentlich dazu führen, dass es dann schwieriger wird, die Software zu ändern.
Ist da ein Widerspruch oder habe ich was nicht verstanden?
Da ist definitiv ein Widerspruch.
Ich führe den jetzt mal darauf zurück, dass Dave Farley in der Studie nur von einem Punkt zum nächsten gemessen wurde.
Das hier wirklich eine Betrachtung ist über sechs Monate.
Also das sind ja dann nicht eine Aufgabe und ich arbeite in dem Code weiter, sondern das ist ja dann hundertmale passiert.
Da steigert sich das noch.
Also auch nicht exponentiell, aber man sieht schon, da ist eine gewisse Tendenz.
Die schwarzen Knubbel bedeuten, dass es signifikant ist.
Die nicht ausgefüllten Punkte bedeuten, es ist keine signifikante.
Man kann es nicht signifikant nachweisen, dass es hier einen statistischen Unterschied gibt, nur bei den schwarzen.
Also mit dem entsprechenden statistischen Unterschied.
Dave Farley ist der Co-Autor von dem Continuous Delivery Buch und hat vor kurzem so ein Software-Hecto-Buch geschrieben, vor einem Jahr oder zwei.
Ich erinnere mich an den Titel gerade nicht.
Was sagt uns das alles oder was ist dein Take-away?
Also das, was mich extrem beruhigt hat.
Ich war vor zwei Jahren schon sehr FOMO-getrieben, würde ich sagen, also Neudeutsch.
Ich hatte schon echt Angst um meinen Job, um meine Zukunft.
Und ich glaube, diese Studien, die haben mich da sehr geerdet und sehr beruhigt.
Deshalb gucke ich mir gerne wissenschaftliche Studien an.
Also A, weil man hat ja doch immer noch die Hoffnung, dass da sauberer gearbeitet wird als jetzt der LinkedIn-Experte.
Das vielleicht tut standardmäßig.
Und auf der anderen Seite halt zu sehen, okay, alle anderen kochen halt auch nur mit Wasser.
Und es gibt 10x Produktivitätsgewinn, die sind halt Stand heute vielleicht in manchen Edge-Cases realisierbar, aber im Großen und Ganzen im Schnitt nicht.
Und auf der anderen Seite zeigt das natürlich auch, wo liegen noch gerade die Probleme.
Also wenn ich jetzt irgendwo arbeite, wenn ich meine Trainings zum Beispiel gestalte, wo lege ich meinen Finger in die Wunde, wo gehe ich genau darauf ein, um da einfach noch sinnvolle Aussagen zu treffen und zu gucken, worauf fokussiere ich mich.
Und wir werden halt zum Beispiel jetzt in den Trainings Code Complexity mit einführen und zu verstehen, okay, was macht Code komplexer, wie kriegen wir Code auf einen höheren Qualitätslevel.
Einfach nur, weil die Studien gezeigt haben, okay, das ist ein extrem wichtiger Aspekt.
Gut, dann würde ich sagen, vielen Dank, dass du dir die Mühe gemacht hast.
Wie gesagt, weitere Informationen gibt es halt in dem Medium-Artikel, den ich verlinke und von Ingo.
Und außerdem sind wir beide bei dem Tech Writers Summit.
Da kann man uns also auch noch live sehen.
Teilnahme ist kostenlos.
Wenn man auf unserer Webseite klickt, kann man sich ein Ticket teilen.
Die nächste Episode gibt es keine, aller Voraussicht nach.
Die nächste geplante Episode, die ich momentan absehen kann, ist halt diese AI Vampire Methode Episode mit dem Martin Lippert und dem Ralf am 19.
Vielleicht machen wir auch irgendwas davor nochmal, werden wir sehen.
Vielen Dank und schönes Wochenende.
Ciao.
Hier ein Hinweis in eigener Sache.
Softwarearchitektur im Stream ist live vor Ort.
Mehr Infos dazu und einen speziellen Rabattcode für unsere Community findest du auf unserer Website software-architektur.tv.
Sei dabei, stell Fragen und komm auch gern auf uns zu.