# AI Productivity in Software Engineering: Data-Driven Strategies

**Podcast:** Software Architektur im Stream
**Published:** 2026-05-29

## Transcript

Hier ein Hinweis in eigener Sache.
Softwarearchitektur im Stream ist live vor Ort.
Wir sind beim TechRider Summit im Juni in Köln dabei.
Mehr Infos dazu und einen speziellen Rabattcode für unsere Community findest du auf unserer Website.
Sei dabei, stell Fragen und komm auch gerne auf uns zu.
So, dann herzlich willkommen zu einer weiteren Episode von Software-Harchitektur im Stream.
Diesmal wieder mal mit Ingo.
Hallo Ingo, schön, dass du da bist.
Hi.
Und heute geht es um das Thema mit der AI-Produktivität.
Ingo, willst du dich erstmal kurz vorstellen?
Ja, also ich habe 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, also 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 Jonas 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 mit, werden wir jetzt schneller oder langsamer, die man 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 EntwicklerInnen, was das irgendwie alles bedeutet.
Einen größeren Teil davon werden wir heute, glaube ich, irgendwie ignorieren.
Also ich glaube, das ist 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 halt 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 super schwer.
Also das ist so wie Bruttoinlandsprodukt, Wohlstand einer Gesellschaft.
Ich glaube, das ist einfach...
einfach extrem schwer zu messen und irgendwie über eine Metrik abzubilden.
Was hier in den Studien gemacht wird, ist halt auch sehr unterschiedlich.
Da geht es von Selbsteinschätzung bis halt auf das Messen von Commits.
Also sehr, sehr divers.
Ich würde sagen, Produktivität ist am Ende, wenn es dem...
Business gut geht, ja.
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.
Genau, und ich finde das halt gut, dass du damit irgendwie, also ich würde behaupten, wenn man im Kern auf die Frage halt guckt, das ist ja so ein bisschen eine betriebswirtschaftliche Frage und das ist halt nach meinem Empfinden, ich habe jetzt nicht eine betriebswirtschaftliche Ausbildung, aber sowas wie, ich setze halt Material ein, ich bekomme dafür halt irgendwas raus und wenn ich halt für dasselbe Material mir rausbekomme, dann ist es halt besser.
Warum entwickeln wir Software?
Um halt Geld zu verdienen.
Was halt bedeutet, dass wir halt Features haben, die halt für die Leute irgendwie bezahlen oder denen halt die Arbeit einfacher machen.
Das ist halt das, was rauskommt, was wir reinsetzen.
Es sind halt Entwickler, in die Zeit investieren.
Und das bedeutet, wenn wir halt für dieselbe Zeit mehr, bessere Dinge bauen, die halt 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ät.
die Produktivitätsdefinition, die hat in verschiedenen Studien zugrunde liegt.
Hier ist halt auch schon nicht die Frage von Apollo 7321, 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 Land of 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 weite Definition.
Ich bin halt nicht bereit, ein System zu bezahlen, was ständig kaputt geht.
Oder wo irgendwie ein neues Feature, was ich gerne hätte als Business Software, ein halbes Jahr dauert.
So bin ich dann 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.
Das ist ein schwammiger Begriff, aber ich glaube auch so.
Wenn man es so ein bisschen auf diese wirtschaftliche und Kundenperspektive ummünzt, dann wird es vielleicht ein bisschen greifbar.
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 halt, ist Lines of 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 werden da plötzlich Lines of Code tatsächlich teilweise ein Produktivitätsindikator.
Und das kriege ich nicht in Übereinstimmung damit.
was die Zuschauer in meinem Talks-MV da intuitiv gesagt haben.
Und ich glaube, das ist halt irgendwie auch klar.
Und das andere ist halt, ich weiß gar nicht, wie 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, also was halt eher so ein Bachelor-Listings ist.
Gut, wollen wir in die...
Achso, genau.
Wir wollten über die Probleme der Studien sprechen.
Das war genau noch das, 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.
Wenn es heute auch Studien von vor einem Jahr angucken und dann gucken, welche Schlüsse wir dann 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, werden 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 auseinander geht.
Gut.
Und damit sind wir, glaube ich, gleich sozusagen loslegen.
Du hast ja netterweise, das verlinke ich auch nochmal, so einen Medium-Blog-Burs geschrieben, wo du dich halt durch die Studien sozusagen durchlangelst.
Das heißt, da kann man das auch irgendwie alles nachlesen und nachschauen nochmal.
Und, achso, das sollte ich jetzt, genau.
Das Erste, was wir haben, ist diese METRE-Studie 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 haben wir gesagt, wie passt das eigentlich mit der Realität zusammen?
Wie schätzen Entwickler ihren Output mit KI-System ein?
Und da sehen wir hier oben die grünen Gnubbel.
Das sind quasi die...
Einschätzung, die Durchschnittseinschätzung.
Und wir sehen hier erstmal Experten, wie schätzen Experten die Produktivitätsgewinne 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 viel Produktivitätsgewinne sie durch KI haben.
Und dann mussten sie sich selbst nochmal einschätzen, nachdem die Studie durch war.
Ihr seht schon, das hat sich ja alles irgendwo so in dem gleichen Rahmen.
Also die waren natürlich super optimistisch.
Die Ökonomen 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.
Ja, genau.
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.
Also die haben gedacht, sie werden ein Fünftel schneller dadurch.
Und das ist glaube ich das, was ich nochmal unterstreichen wollte.
Also die Definition von Produktivität ist hier höhere Geschwindigkeit beim Lösen von irgendwelchen Issues.
So war das, wenn ich mich recht entsinne.
Genau, genau.
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 in etwa von der Komplexität.
Und dann wurden alle Issue-Bearbeitungen mit einem Screen-Recording mitgeschnitten.
Und einmal mussten die Entwickler per Hand schreiben und einmal mussten sie KI nutzen.
Das war dann so ein 50-50-Split und man hat dann am Ende sich die Videorecordings angeschaut und das ist wirklich ein wahnsinniger Aufwand gewesen sein.
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 Prozent.
Also 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 halt zwei unterschiedliche Dinge.
Also nicht plus 20 Prozent schneller, Selbsteinschätzung tatsächlich 20 Prozent 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 Apollo 7, 3, 2, 1, wir EntwicklerInnen waren schon immer extrem schlecht im Schätzen.
Ja, ich lasse das jetzt mal kommentiert.
Und 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 halt fünf Jahre Erfahrung mit diesen Projekten haben.
Genau.
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, kennen die Code-Basis sehr detailliert.
Und dann ist es halt erklärlich, dass sie halt nicht schneller werden.
Das wäre halt für mich das andere Ergebnis.
Also irgendwie, das beantwortet eigentlich nicht die Frage, ob man durch AI im Schnitt besser, 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.
Ja, also ich muss sagen, ich habe die Studie gelesen, sagen wir mal, vielleicht so Mitte 2025.
Da bin ich schon ein halbes Jahr bei uns durchs Unternehmen gerannt und habe allen gesagt, wie cool Programmieren mit KI ist und dass sie das unbedingt ausprobieren.
Und habe das quasi gezeigt, wie man das macht.
Ich habe erstmal 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 zwar ein Entwickler mit dabei, der war, 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 waren gerade erst, der hatte eine halbe Stunde Schulung zu dem Tool und mussten dann damit loslegen.
Und da sieht man, man wird besser über die Zeit und wenn man halt exposed ist, aber auch wenn man das halt eben lernt und die Eigenheiten lernt.
Und das hat natürlich mir wieder in die Karten gespielt und deshalb ist dann die Studie dann doch in meinen.
Kartendeck reingewandert oder in mein Slide-Deck reingewandert.
Okay, das bedeutet, man müsste eigentlich sagen, erfahrene Entwickler, die halt in dem Projekt erfahren sind und denen man nicht die Chance gegeben hat, sich an die Tour zu gewöhnen.
Genau.
Ja, und dann guckt die Studie hier auch noch ein bisschen tiefer ein.
Ein Hinweis, den ich halt gerne loswerden möchte, sozusagen aus meiner Perspektive.
Das, by the way, 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.
Weil das, was, also wenn man sich die Studie anguckt und man guckt sich halt nur die Zusammenfassung an, steht da im Prinzip das drin.
Und also ich muss gestehen, die Sache mit, dass die halt nicht ausführlich mit den Tools arbeiten konnten, das war mir jetzt irgendwie neu.
Aber wenn man nur die Zusammenfassung liest.
sieht man halt, das sind halt erfahrene Entwickler.
Und insbesondere steht in der Zusammenfassung auch, das ist keine allgemeine Studie, die den Anspruch hat, allgemein irgendwie verwehrt, sozusagen 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 halt in so 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ösen, weil nicht unabhängig, ob man jetzt sagt, AI ist halt das Beste ever oder es hat eine Vollkatastrophe.
Studien lesen und halt tatsächlich zu versuchen, zu verstehen, was da drin steht und das irgendwie auch kritisch zu betrachten, ist halt 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, aber 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 sozusagen.
Über längere Zeitung Gleichgewicht zu behalten ist noch eine andere Königsdisziplin, wo einfach KI noch nicht so viel hilft aktuell.
Keine Ahnung, ob sich das dann irgendwann ändert.
Jetzt hast du die Slides weggemacht.
Genau, ich dachte nur gerade, weil wir miteinander reden.
Aber jetzt haben wir die nächste Slide.
Also hier ist noch der Hinweis, was hat Jakob bei YouTube geschrieben?
Für mich hängt es sehr davon ab.
Um was entwickelt wird, ich beobachte an mir selbst, dass ich manchmal produktiver bin, manchmal unproduktiver.
Ich entwickle mit der Zeit ein Gefühl dafür.
Das ist vielleicht auch ein guter Hinweis und das war auch etwas, was mir, was durch meinen Kopf ging, als du es nochmal erzählt hast, war auch etwas, was ich ehrlich gesagt in der Studie nicht in dem Detail gesehen hatte.
Das sind ja auch kurze Aufgaben gewesen in dieser Metris-Studie und das bedeutet halt, dass es da einen Filter gibt, also es sind nicht langwierige, größere Sachen und vielleicht spielt das halt auch eine Rolle, keine Ahnung.
Aber wir messen natürlich auch nicht die langfristigen Auswirkungen in der Studie, da haben wir nachher noch eine andere, also quasi was macht.
Programmieren mit KI mit meiner Code-Basis über ein paar Wochen, Monate hinweg.
Genau, wenn wir jetzt erstmal hier reinzoomen, eins der Probleme für die Fehler in Schä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 mit KI, braucht man weniger, um das aktiv zu quoten, 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.
Also 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, wie 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 haben wir gar nicht, die vergleichen wir vielleicht in 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 darum, also dich darum gebeten, die Folie insbesondere nochmal aufzunehmen, weil ich halt darüber gestolpert war in deinem Medium-Artikel, weil mein Executive Summary daraus ist halt, also einmal, ich investiere jetzt halt auf andere Sachen und das wirkt so ein bisschen so, als würden die, ja wie soll ich sagen, es führt zu der Frage, ob es überhaupt sozusagen Zeitgewinn gibt, was was anderes ist als der Output.
Und das ist nochmal ein guter Reminder, wenn ich nicht AI benutze, verbringe ich 35 Prozent, mit aktiven 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 weiß nicht, sind Idle und Overhead, sind das auch Meetings oder sowas?
Also mich wundert halt gerade, dass die Menschen offensichtlich 90% 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 in irgendwelchen 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.
Merke ich bei mir selber, ist ja auch nicht immer gut.
Aber ich denke, das hängt halt mit diesem Warten hier zusammen.
Wie gesagt, in der Studie, ich habe keine gute Antwort darauf gefunden.
Wobei das steht da, also nicht, das ist der Anteil über das Screen Recording.
Das heißt, wenn eine Entwicklerin vor dem Rechner sitzt und nicht AI benutzt, ist es so, dass sie 35 Prozent der Zeit nur aktiv codet.
Genau.
Das ist die Aussage.
Und das ist nochmal ein guter Reminder.
Wenn wir das halt irgendwie beschleunigen, ist die Frage, was halt hinten eigentlich rauskommt.
Ja.
Achso, 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, also 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.
Also ich glaube nicht, dass es Sinn macht, für jeden Anwendungsfall immer komplett sich jede Zeile Code durchzulesen.
Ich denke, es gibt viele Anwendungsfälle und viele Use Cases, wo 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 Backshot meiner Freundin schreibe oder ob ich ...
an einem Software für ein Atomkraftwerk arbeite.
Da ist auch so ein bisschen gesunder Menschenverstand und entsprechend die Regulierung drumherum, Regulatorik drumherum, die dann vorgibt, ich muss halt andere Praktiken anwenden.
Und deshalb würde ich das gar nicht so...
Manchmal ist es 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 Zollverentwicklung ja eh haben, dass halt irgendwie häufig sehr viel Druck gemacht wird und dann leidet 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, also 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 halt 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 halt, 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?
Ja.
So, sorry.
So, hier ist die Aussage von Sekuro.
Es ist ja oft so, dass die KI sehr viele Klassen und Zahlen selbst für kleine Anfragen ändert.
Ein Merge-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 Software-Ingenieure arbeiten.
Und ich glaube, da erzähle 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 aber die 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, so eine 3.5 und hier war es dann 4 irgendwas.
Aber hier sieht man, okay, 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, einfach noch nicht so produktiv, noch nicht so.
fit waren dort drin.
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.
Weil...
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.
Ihr seht es hier in den Grünen, ist das beschrieben.
Also ich habe es mir jetzt nicht genau durchgelesen, was 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 mir das Ergebnis nach unten negativ zu beeinflussen.
Aber ich habe nur den Presseartikel dazu gelesen und das Kommentar hatte ich gerade wieder gesehen hier auf dem Slide, dass mir das wieder eingefallen ist.
Okay, super.
Gut, dann wird damit, glaube ich, 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 positiv, aber das würde ich jetzt behaupten, ist halt Messungengenauigkeit.
Das heißt also, die Studie mit den neuen Sachen sagt halt, dass das eben tatsächlich sich verbessert hat und mit den neuen Werkzeugen besser ist.
Genau, super.
Und das sind dieselben Leute, die halt die Studie veröffentlicht haben und so weiter.
Genau, genau, genau.
Das ist das Meta, das ist ein, Ja, ein unabhängiges und Non-Profit-Institut aus Kalifornien.
Ich hatte 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 Eberhard interessant.
Ich fand es nämlich aus dem Aspekt interessant.
Oder vielleicht, ich erkläre es mal kurz, was man hier sieht.
Diese Punkte, diese Karos hier, die zeigen die Einschätzung eines Entwicklers, eines technischen, 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 da 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.
LLMS 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 gleiche 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 hinter ist so die...
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 vielleicht Eberhards Kritik dazu.
Ja, also ich muss halt gestehen, ich fand das offensichtlich absurd und halt 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 und so lange dauert es halt mit dem Einsatz der AI und dann halt 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 Metresachen sind bei Archives, richtig?
Ja, ja.
Ich glaube, die sind mittlerweile auch auf Konferenzen angenommen.
Also die sind mittlerweile auch durchgepeer-reviewed.
Genau, das wäre nämlich jetzt der nächste Punkt.
Also ich habe das so verstanden, dass Archive-Side-Preprint ist.
Das heißt also, das sind Sachen, die halt noch nicht peer-reviewed sind.
Peer-reviewed bedeutet halt, dass andere Wissenschaftler eben darauf 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-reviewen zu lassen.
Das wäre also tatsächlich eine richtige Veröffentlichung.
Archive 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 erstmal überlegt, ob er es rausschickt zu einem Review oder eben auch nicht.
Und das bedeutet, diese dritte Sache von Metre ist halt einfach so, dass sie halt gar keinem Standard entspricht.
Also nicht die Blogposts könnten wir morgen, wir könnten morgen einen ähnlichen Blogpost schreiben, wir können ja 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 gleich auch bei der nächsten Studie halt relevant.
Also vernünftige wissenschaftliche Studien sind halt so, dass sie die Daten mitliefern, damit man sich halt die Daten anschließend angucken kann.
Und das ist, müsste bei diesen jetzt irgendwie der Fall sein.
Wir haben da glaube ich gleich noch ein Gegenbeispiel.
Noch kurz eine Frage, also die irgendwie aus dem Chat kam.
Geht es um einen Speed-Up beim Erledigen der Aufgaben.
Ja, genau.
Also es geht um ein Speed-up bei dem Erledigen der Aufgaben, wo, das hatten wir vorhin diskutiert, wo halt diese Mitri-Studien halt alle sagen, das hat irgendwelche Tickets gelöst werden.
Und da geht es halt genau um den Speed-up.
Genau, hier kann man sich auch bei dem Blogpost ist der 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.
Das heißt, man kann das überhaupt nicht beurteilen, was jetzt die Aufgabe heute bedeuten wird.
Also ich halte das auch in vieler 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 hier ein Unterschied zwischen dem Stuff G und dem A ist.
Also da gibt es ja irgendwie einen Unterschied.
Und dann kann man halt eben gucken, okay, woher kommt der?
Der kann natürlich auch einfach an einer komplett falschen Datenerhebung oder so liegen.
Aber damit kann man ja dann anfangen zu arbeiten.
Also ich kann es ja nochmal wiederholen.
Ich halte das halt 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 halt ein Messwert.
Das ist absurd.
Und LMs sind nicht Systeme, die halt Dinge allgemein vorhersagen können oder halt irgendwie auswerten können.
weiß nicht, wie man auf so eine Idee kommen kann.
Ich halte das halt für echt sehr, also einfach Unsinn.
Also ich hoffe, dass wenn man das halt versucht in einem Journal zu publizieren, dass einem das von die Ohren geschlagen wird.
Also wir haben jetzt heute keine weiteren LLM-Sage-Studien dabei, aber es gibt einige, also die auch durch Journals durchgehen, die aber mehr Hand und Fuß haben als das hier, also überhaupt keine Frage.
Okay, also dann ist das halt irgendwie so.
Hier ist noch eine Frage von dem Rainer2345.
Der sagt, was sagt ihr zu der Anmerkung von Dinos Torwart aus der Woche, dass er sich nicht mehr in der Lage sieht, mit den vielen 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 denn der?
Daniel Sternberg oder so?
Der Mensch, der Curl baut.
Und da habe ich einmal gelernt, dass er von einem Jahr noch gesagt hat, das sind halt alles Scheiß-Reports, die rauskommen aus den Security-Sachen.
Jetzt sagt er, wir gucken sie uns zumindest an und es sind kleinere Wunderabilities, die da rauskommen.
Daniel Sternberg sagt, er hat gerade.
Genau.
Da kommen mittlerweile Security Reports ja zumindest so Medium Probleme aufzudecken, aber keine schwerwiegenden.
Und die sind halt offensichtlich auch irgendwie total überbeschäftigt mit Security Reports.
Das ist also tatsächlich ein großes Problem.
So wirkt es auf jeden Fall.
Ja, ist halt eins.
Auf der anderen Seite ist mein Gefühl, dass der Hype um dieses Mythos halt übertrieben ist, Also ich habe zumindest jetzt noch nicht davon gehört, dass da irgendwie krasse Vulnerabilities rausgekommen sind.
Von daher glaube ich halt nicht, dass das ein, also das ist nicht so eine KI-Superwaffe, die jetzt irgendwie dazu führt, dass man da beliebige Systeme hacken kann.
Das ist halt ein weiteres Sicherheitstool.
Ja, ich denke schon, dass da gerade extrem was passiert.
Also gerade bei CVs, ich sehe das ja auch, also ich sehe das überall.
Ich denke halt, ja, es ist eine neue Welt.
Also so wie wir vorher halt eben auch diese Aufwaffnung von beiden Seiten hatten.
Also die Attacker sind ein bisschen besser geworden und dann mussten die Verteidiger halt eben auch ein bisschen besser werden.
Und man hat immer so dieses Arms Race.
Das beschleunigt sich gerade, so wie sich vieles andere auch beschleunigt.
Aber du hast es vielleicht eines der ersten Bereiche, wo man diese extreme Beschleunigung sieht.
Und wir haben vielleicht noch nicht die richtigen Waffen gerade, um gegenzuschießen.
Und also jetzt mit vielen PRs, die reinkommen, jetzt vielleicht gar nicht mal CVE-bezogen sind, sondern einfach nur, weil mehr Leute mitspielen wollen in Open-Source-Projekten und es jetzt halt eben auch können.
Vielleicht noch nicht in der Qualität, wie wir es bräuchten, aber es passiert ja oder es über CVEs ist, also wie gehe ich mit diesen PRs um?
Und das ist ja auch gesellschaftlich ein Riesenthema gerade, also bei Entwicklern, der Gesamtgesellschaft vielleicht noch nicht so angekommen, wo manche sagen, ja, machen wir gar nicht, ist uns vollkommen egal.
Und andere sagen, ja, ist doch super.
Dann habe ich jetzt endlich Leute, die mitarbeiten, die mich unterstützen bei der Open Source und ich muss nicht mehr das alles alleine machen.
Und die Wahrheit ist wahrscheinlich irgendwo in der Mitte, wie immer.
Also der Daniel Sternberg von Curl hat eben tatsächlich gesagt, dass er überarbeitet ist.
Da ist auch gerade der Hinweis von dem Apollo.
Das ist auch etwas, was in dem Blog post.
drin, also wo ich den Blogpost tatsächlich gelesen habe, wo er mir gesagt hat, ich habe schon immer wahnsinnig viel gearbeitet, das ist halt meine Mission, aber jetzt sagt meine Frau, dass es halt 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 halt irgendwie auch darum geht, was bedeutet das eigentlich für unsere Arbeit als TechnikerInnen und ist da halt sozusagen um uns steht und was das halt irgendwie bedeutet.
Und ich glaube, das, was halt der Daniel da irgendwie sagt, ist halt ein Hinweis auf, dass das eben tatsächlich alles nicht so schön ist.
Ja, und hier kommt ja auch das Konter mit dem überarbeitet sein.
Also das merke ich bei mir auch und meine Frau hat das auch zu mir gesagt.
Oh du, und das Gleiche.
Jetzt aber auch mal gut.
Also 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.
So ist ja die Logik schwer.
Ich wäre aber eher andersrum.
Ich bin doppelt so produktiv und arbeite viermal so viel auf einmal.
Ja, und das, by the way, ist ein ganz hervorragender Punkt, den man eigentlich auch nochmal einbauen kann in die Frage, was ist eigentlich Produktivität?
Also es kann halt bedeuten, dass ich weniger Zeit mehr erreiche.
Und das ist halt auch noch diese Geschichte mit der Nachhaltigkeit.
Also ich kann halt Menschen unter Druck setzen und dafür sorgen, dass sie halt kurzzeitig mehr Output generieren für irgendeine Definition von Output.
Nachhaltigkeit steht halt auf einer anderen, auf einer anderen, ist halt ein anderes Thema und ich finde es halt immer noch lustig, dass Extreme Programming damals vor der Jahrtausend, wenn er halt gesagt hat, wir wollen halt ein Sustainable Pace, also eine nachhaltige Geschwindigkeit und eine 40-Stunden-Woche.
Ja, wie dem auch sei.
Ja, gut.
Nächste Studie oder haben wir noch was?
Genau, hier hatte ich nochmal kurz zusammengefasst.
Jetzt kommt der Stanford-Bereich und Also eine Stanford-Studie, die wir leider nur so ein bisschen über das betrachten können, was uns übermittelt wurde, weil bei der Stanford-Studie, da darf nicht jeder teilnehmen, die darf nicht jeder einsehen.
Die darf man nur einsehen, wenn man dort mitmacht und versucht, ein deutsches Unternehmen dazu bewegen, bei einer amerikanischen Studie mitzumachen.
Das wird schwierig.
Als Einzelperson bin ich zu klein.
Und von daher sehen wir dort nur das, was halt ab und zu mal über die Medien halt eben 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 und dass man auf die Daten natürlich zugreifen kann.
Und das ist halt nicht erstmal so, ist trotzdem etwas, was halt 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 halt 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, Cohesion, also so die Klassiker.
Und dann geben sie dem Output, also dem Code, eine Produktivitätskennzahl und daneben misst man dann halt eben auch noch, okay, wie schnell war das, ist das skalierbar?
Nimm 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 ist sozusagen der Input, das ist der Output und jetzt bitte simulier 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 sozusagen 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 da steht halt fast scalable und affordable, also es ist halt schneller, skalierbarer und irgendwie, also wirtschaftlich effizienter.
Genau, 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 weiß ich nicht ganz klar von mir.
Genau, okay.
Das heißt, aber anyways, ich habe also jetzt Machine Learning Modell, in dem ich halt irgendwie Code vorlege und der sagt halt, das ist wartbarer Code oder nicht wartbarer Code.
Genau.
Und das Machine 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, können wir ja 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.
Das versettet hier eher, also auch die Geschwindigkeit, wie schnell dieser Code erstellt wird, aber...
Das ist jetzt sozusagen noch so ein 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 das ist halt für mich die, also im Sinne von Metrigen.
Und Metrigen 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 halt auch mit Code-Basen umgehen, die halt nicht wartbar sind.
Deswegen ist Code Wartbarkeit eigentlich kein ernsthaftes Argument für irgendetwas.
Also nicht, ich spiele Avocatus Diaboli, die finde ich 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 irgendeine Rolle spielen.
Ja, also man...
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 dir 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.
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.
Gut.
Okay, also das ist das, wie die halt vorgehen in der Studie.
Das wäre jetzt die Frage.
Genau.
Und jetzt ist die Frage, okay, was kommt dabei raus?
Und wir sehen hier auch, wir haben hier so ein Knowledge Cut-Off vor 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, 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, CodeQualität 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-Kode 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 einem 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 er ja hinweist, ist, LLMs müssen halt quasi hochwertigen Code liefern, weil der halt irgendwie gereviewt werden muss durch Menschen.
Finde ich einen nachvollziehbaren Punkt.
Und ich würde ja jetzt behaupten, dass halt in vielen Fällen, dass halt auch tatsächlich immer noch notwendig ist und genauso umgesetzt wird.
Aber es gibt halt, meiner Meinung nach, gibt es keine inhärente Notwendigkeit, dass jeder Code gereviewt werden muss.
Also das ist irgendwie so ein Branchending.
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 Code reviewen müssen, weil wir für immer besser sein werden im Code reviewer als ein KI-Modell.
Das ist natürlich die Frage, okay, ich gebe ja jetzt meinem Sohn, wenn er in der Schule ist, einen Test abgibt, dann sage ich ja nicht, gib dir mal selbst eine Note danach und gucke mal, wie gut du das gemacht hast.
Da ist auch vielleicht so ein moralischer Zwiespalt da drin.
Aber ich denke, wenn das statistisch besser ist als der Mensch, dann werden wir weniger Code Review machen als Entwickler.
Ich denke schon.
Ja, es ist noch ein anderer Aspekt.
Das ist ein Gedanke, den ich bei Masuda mal von dem Zöllner aufgeschnappt habe.
Der meiste Code da draußen ist halt durchschnittlich.
Der ist nicht super.
Um nicht zu sagen, dass halt sehr viel von dem Code, der tatsächlich irgendwie Unternehmen am Laufen hält, deutlich untercodedurchschnittlich ist.
Und eine von, also den Punkt, den Tim da nach meinem Empfinden macht, ist halt, es reicht ja aus, wenn wir halt 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 halt im Prinzip sagt, okay, also die Qualitätsdiskussion, die wir uns ja schon lange liefern, nicht, also wo es ja irgendwie solche extremen Positionen gibt, die halt irgendwie sagen, wir müssen halt immer ganz krasse Qualität liefern, weil halt 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 Produktion ist und das hat wir oft nicht so schön.
Ja, und ich denke, das ist jetzt eigentlich für uns eine Riesentraubung, als Disziplin besseren Code zu schreiben, weil halt dieser Benchmark, dieser Durchschnittscode quasi uns so jetzt sehr günstig zur Verfügung gestellt wird und wir können uns halt darum kümmern, dass der jetzt accessible ist und 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.
Also ich hatte natürlich immer zwei Seiten, so eine Sache.
Ich würde halt unterstreichen, also nicht, du hast im Prinzip recht, ich würde jetzt erst, eine Sache, die halt irgendwie da, der glaube ich wichtig ist, ist halt auch, dass wir diskutieren oder was halt in dieser AI-Diskussion halt irgendwie eine Rolle spielt, ist halt, dass die, dass halt jetzt Mitarbeiter, eben gesagt wird, also wenn das System sehr gut strukturiert ist und irgendwie toll aussieht, dann ist es halt auch für AI nutzbar und einfach erweiterbar.
Was ich also für Borderline-Verwerbs halte, weil das halt irgendwie bedeutet, also wenn wir Entwicklerinnen haben, nicht Menschen, die halt möglicherweise tatsächlich ernsthaft nahezu darunter leiden, dass sie sich halt mit Scheißcode rumschlagen müssen, das ist akzeptabel.
Aber wenn wir eine AI haben, die halt nur Produktivität verbessern kann, dann investieren wir jetzt tatsächlich in Code-Qualität.
Das finde ich halt extrem schwierig.
Und das kommt dabei halt raus.
Und das andere, was wir hier beobachten, ist halt, dass halt dieser AI-Slop, das heißt, es gehen halt Sachen in Produktion, die halt eben qualitativ natürlich nicht besser sind, sondern schlimmer.
Und von daher, ja, keine Ahnung.
Achso, Ralf hat hier noch einen Punkt.
Ja, der meiste Code ist durchschnittlich, die meiste Projekte benötigen, aber auch nur Glue-Code, um bestehende Komponenten zu verbinden.
Ja, vielleicht ist das auch gut.
Ja, anyways.
Ja, genau.
Die Metastudie hat er noch hier untersucht, Greenfield und Brownfield.
Und ich glaube, das ist jetzt wenig überraschend, aber halt Code, der neu produziert wird.
Und das sind halt alles Enterprise-Projekte, also das jetzt auch nicht.
die Homepage von Backshop.
Man sieht hier halt, 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.
Ich weiß nicht, das ist jetzt, glaube ich, Common Sense, oder müssen wir jetzt nicht weiter darauf eingehen?
Ja, also eine Frage, die sich vielleicht an dieser Stelle dann halt lohnt zu stellen, ist, wir hatten ja am Mittwoch die Episode mit Jado und Tobias, wo sie halt berichtet haben über ihre Erfahrung mit Agentic Coding.
Da war es ja genauso, dass sie halt ein Legacy-System haben, offensichtlich halt sehr schlecht strukturiert.
Und wo sie berichtet haben aus einer modulweisen Migration, wo halt ein Teil der Aufgabe halt war, die Module zu verstehen und dann zu migrieren.
Das ist also nicht so braun, wie es halt wird.
Also eben Brownfield existierender Code.
Da war die Aussage, dass sie halt insbesondere dort, also das ist keine Studie, das hat er halt, ja, du insbesondere, glaube ich, auch dargestellt, aber sie hatten halt eine starke empirische Evidenz, die halt gesagt hat, okay, also früher haben wir halt irgendwie ungefähr eine Woche gebraucht, um halt so ein Modul zu verstehen und halt daran zu gehen, das halt zu ändern.
Jetzt brauchen wir halt eher so so einen Tag.
Was ja massiv ist.
Wir haben bisher nur zweistellige Prozentzahlen gesehen an Produktivitätssteigerung.
Noch nicht mal einen Faktor von zwei.
Und da gibt es jetzt diesen empirischen Hinweis, dass es gerade im Umgang mit Brownfield viel, viel schneller wird.
Wie erklärst du dir das?
Also ich habe da natürlich viele Erklärungsansätze.
Das müsste man sich jetzt evident angucken.
Wir haben das ja gesehen, die Wahrnehmung ist ja unterschiedlich.
Zu dem, was eigentlich gemessen wurde, was schon daran liegt, dass man einfach sich selbst anders wahrnimmt und vielleicht andere Aspekte jetzt in den Vordergrund rutschen, die man jetzt erstmal ausblendet, weil alles so toll ist.
Tolle neue Welt.
Also so merke ich es 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 halt dem Agenten ab und zu mal was geben, dann gucke ich mir das kurz an, was er gemacht hat.
fütter 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.
Und jetzt fühlt es sich eine andere Art des Arbeitens.
Ich denke gar nicht, dass es, ja, dass man das so richtig, also das ist wirklich schwierig, das zu vergleichen miteinander, wie wir früher programmiert haben, also früher, letztes Jahr programmiert haben und wie es heute ist.
Es ist wirklich sehr, sehr unterschiedlich und extrem schwer.
Ich finde es extrem schwer, in so eine Metrik wie zum Beispiel, ich bin jetzt fünfmal schneller zu gießen.
Noch Dinge aus den Studien, die wir diskutieren sollten?
Ich weiß nicht.
Wir haben noch ganz viel.
Wir haben hier noch Good Health von dem Adam Tunnel.
Also hier vielleicht noch, das ist vielleicht noch ein Aspekt, der hier in der Studie herauskam.
Hier sieht man also, hier wurde Code genommen und der wurde gerefactort, der wurde ins Refactoring geschickt und hier sieht man halt, wenn der Code mit höherer Code Health, also mit einer höheren Qualität reinkommt, das wurde hier mit dem Code Health Tool, was Adam auch entwickelt, gemessen, dann sieht man hier ganz klar, dass die Break Rate, also die Wahrscheinlichkeit, dass was kaputt geht, die geht halt runter, 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 ja dann immer so als rote Knubbel, ob etwas gut ist oder nicht.
Das korreliert halt sehr, sehr stark damit, wie wahrscheinlich die KI beim Refactoring was kaputt macht.
Und das deutet extrem stark darauf hin, dass halt ein aktuell guter Hebel dafür ist, wenn man seine Software quasi für KI fit machen will, jetzt ein guter Moment ist, diese solche klassischen Code-Helts-Metriken zum Beispiel anzuwenden.
Und da gibt es ja auch Sona Cube.
Ich hatte auch so einen kleinen 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.
Und dann kann man sowas sehr, 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.
Domänenwissen, ein sehr spezieller Use Case.
Ja, das vielleicht noch so als Abschluss.
Genau, also vielleicht zwei, drei Hinweise sozusagen.
Also du hattest ja gesagt, ich hatte eine Episode mit ihm gemacht, das war halt zu Behavioral Code Analysis.
Da geht es also darum, wie man halt, wie das Team mit dem Code umgeht, wie man das sozusagen mit Metrigen erfasst.
Das ist, glaube ich, ein anderes Thema.
Er hat halt auch dieses Your Code is Crime Scene geschrieben, dieses Buch.
Hinweis wäre, also, Diese Studie beantwortet dann offensichtlich die Frage, ob die Metrien halt irgendeine Relevanz haben.
Haben sie?
Weil nicht also auch AI mit Metrien da halt irgendwie besser aussieht.
Bezüglich der wissenschaftlichen Praxis, ich bin da halt so ein bisschen, wie soll ich sagen, also es ist halt ein Tool-Hersteller.
Und diese Studie, ich weiß nicht, wie du es sehen würdest, sagt ja in gewisser Weise, die Tools, die hergestellt werden, sind auch sinnvoll für AI.
Da wäre ich immer ein bisschen...
Vorsichtig.
Also der Adam ist ein schlauer Mensch, der hat auch ganz viele ganz tolle Sachen gemacht.
Also ihr Code des Crime-Scenes ist super, Behavioral-Code-Analysis finde ich super.
Aber es ist halt so ein bisschen die Frage, ob das halt aktiv ist, sein kann.
Es gibt ja noch andere Veröffentlichungen in dem Bereich.
Also Corona Lilienthal, gut, die hat natürlich auch ein Beratungsunternehmen und die Sachen, ja, wir müssen alle irgendwie überleben.
Also 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 Architectural Metrics oder sowas in etwa.
Die haben mehrere Metriken, die sie anwenden, um Architektur zu bewerten.
Und 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 wirklich für KI.
Wie kriegen wir die Metriken für KI hin?
Und das sozusagen Architekturbewertung für KI-Systeme.
Das ist auch super spannend.
Neil ist bei ThoughtWorks einer von den Menschen, der da sozusagen antwortet.
Und Carola, wie du ja schon sagtest, ist halt bei WPS und hat dieses Buch über langlebige Softwarearchitektur geschrieben.
Wir haben auch schon mal gesprochen, interessanterweise hat sie promoviert über Psychologie und wer hat Menschen Strukturen bilden, um halt sozusagen mit Systemen umgehen zu können.
Also da kommt sie aus dem Hintergrund.
Genau, 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.
Das war 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.
Und das war sozusagen hier die orange Gruppe, diese orangen Balken.
Und dann hat man halt einen Menschen genommen mit KI-Systemen, der Code bearbeitet hat und der andere Mensch musste dann diesen Code weiter bearbeiten.
Und ich bin ausgestiegen aus der Studie, weil ich gesagt habe, ich verstehe das ja gar nicht.
Das ist überhaupt nicht die Prämiersprache, mit der ich mich auskenne.
Ich kann das gar nicht weiterentwickeln.
Aber was halt das Finding war am Ende, man sieht es hier auf der rechten Seite so ein bisschen, das ist relativ nah beieinander.
Also hier sieht man das manuelle Bearbeitete und mit Code Bearbeitete, die überschneiden sich sehr stark.
Also die Maintenance eigentlich 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.
Also das heißt, das, was viele sagen, es da irgendwie so 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 überhaupt, wenn ich es richtig sehe, ist es ja eher so, also der...
Der Median für die Completion-Time ist halt einmal bei den Menschen mit AI Unterstützung 140 Minuten, bei den anderen sieht es so aus wie 170 oder sowas.
Das bedeutet also, wenn der Original-Code AI unterstützt ist, ist er anschließend schneller änderbar.
Aber da ist ja irgendwie ein großer Fehler bei, wie du ja schon sagst.
Das scheint ja das Ergebnis zu sein.
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.
Also da konnte man das nicht, 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 KI-Systeme.
Immer halt eine Momentaufnahmeaufhalt ein.
Ja, genau.
Ich wollte es nur angesprochen haben, weshalb hier diese leichte Steigung da ist.
Also das kam nicht durch die mittleren oder Juniorentwickler.
Und dann haben wir...
Genau, und hier, das war noch eine andere Studie, lass uns die ganz kurz noch machen.
Hier hat man geguckt, sechs Monate, also hier hat man...
Git-Codebasen halt eben untersucht, deshalb 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 bei dem 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 Added, also wie viele Zahlen Code hinzugefügt werden.
Also das scheint auch, zumindest hier in dieser Studie, dann wieder auf ein 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 ein...
Das ist ja noch ein weiterer Indikator, wer mit KI arbeitet, sollte statische Code-Analyse unbedingt einsetzen, weil 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, bis zum Ende ist halt hier die Komplexität, das heißt, die wird weiterhin erhöht.
Das liegt an Sachen, 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.
Und diese Komplexität, da gibt es gerade noch kein Heilmittel und das zeigt halt eben die Studie hier auch.
Aber das, was wir gerade vorhin gesprochen haben, unter anderem mit dem Friday, sagt ja, dass bei so 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 Mietrigen deutlich schlechter.
Müsste ja eigentlich dazu führen, dass es dann schwieriger wird, die Software zu ändern.
Ist da ein Widerspruch oder habe ich fast nicht verstanden?
Nee, da ist definitiv ein Widerspruch.
Ich führe den jetzt mal darauf zurück, dass Dave Farley, also in der Studie hier, also es war nicht, Dave Farley ist Mitautor, da gibt es auch noch mehr, in der Studie wirklich nur von einem Punkt zum nächsten, das gemessen wurde.
Und 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 hundert Male passiert.
Und da steigert sich das scheinbar noch.
Also auch nicht exponentiell, aber man sieht schon, da ist eine gewisse Tendenz da.
Und die schwarzen Knubbel bedeuten, dass es signifikant ist.
Die nicht ausgefüllten Punkte bedeutet, es ist keine signifikante.
Ja, man kann das nicht signifikant nachweisen, dass es hier einen statistischen Unterschied gibt, nur bei den Schwarzen.
Genau, also mit dem entsprechenden statistischen P-Wert.
Genau, Dave Fadis ist der Co-Autor von dem Continuous Delivery Buch und hat auch vor kurzem so ein Zoff-Hertig-Turbuch geschrieben, also vor einem Jahr oder zwei Jahren, den Titel gerade nicht.
Ja.
Gut.
Was sagt uns das alles oder was ist dein Take-away sozusagen?
Also das, was mich extrem beruhigt hat, ich war vor zwei Jahren schon sehr FOMO-getrieben, würde ich sagen, so neudeutsch.
Also ich hatte schon echt Angst um meinen Job und 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 auch zu sehen, okay, alle anderen kochen halt auch nur mit Wasser.
Und es gibt da keinen, es gibt 10x Produktivitätsgewinn, die sind halt Stand heute.
Vielleicht in manchen Edge-Cases realisierbar, aber im Großen und Ganzen im Schnitt, nee.
Und auf der anderen Seite zeigt das natürlich auch, okay, 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 ein höherer Qualitätslevel?
Einfach nur, weil die Studien gezeigt haben, okay, das ist ein extrem wichtiger Aspekt.
Gut, dann würde ich sagen, vielen Dank.
Vielen Dank, dass du dir die Mühe gemacht hast.
Wie gesagt, weitere Informationen gibt es halt in dem Medium-Artikel, den ich verlinke, von Ingo.
Und außerdem...
sind wir halt beide bei dem TechRiders Summit.
Da kann man uns also auch noch live sehen.
Die Teilnahme ist kostenlos.
Wenn man auf unsere Webseite es gibt, kann man da sich ein Ticket halt klicken.
Das wäre es, glaube ich, soweit.
Ach so, und die nächste Episode, nächste Woche gibt es keine, aller Voraussicht nach.
Die nächste geplante Episode, die ich womit 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.
www.software-architektur.tv Sei dabei, stell Fragen und komm auch gerne auf uns zu.