Der nachfolgende Text wurden mit KI erstellt und kann Fehler enthalten. Fehler gefunden? Bei GitHub editieren
Ja, hallo und herzlich willkommen zu einer weiteren Folge von Software-Architektur im Stream.
Thema ist heute zwischen KI-Hype und KI-Vampiren, wie wir den Einsatz von KI im Alltag erleben.
Zu Gast habe ich heute Martin Lippert hier.
Martin, möchtest du dich mal kurz vorstellen?
Ja, hi, vielen Dank für die Einladung erst mal.
Ich freue mich sehr, hier zu sein.
Ich bin Martin Lippert.
Ich komme aus Hamburg und arbeite für das Spring Engineering Team, also das Team, was Spring Framework, Spring Boot macht.
Mein Spezialgebiet dabei sind die Tools.
Also ich mache halt hauptsächlich diese Spring Tools für die IDE-Extensions oder für Cloud-Coding allerdings, natürlich, und beschäftige mich damit hauptsächlich, bevor ich im Spring Team aktiv war.
Also bin ich jetzt auch schon 16 Jahre, glaube ich, Teil des Teams.
Davor war ich in einer agilen Softwareentwicklung zu Hause, habe it-agile mitgegründet, eine kleine Beratungsfirma auch hier aus Hamburg und interessiere mich sozusagen eigentlich von Kindertagen an quasi für Softwareentwicklung und für Programmierung.
Und deswegen liegt mir das Thema auch nach wie vor sehr im Herzen und ich bin immer noch begeisterter Softwareentwickler, eigentlich noch jeden Tag.
Ja, sehr gut.
Da fallen mir auch gleich zwei so bisschen freche Fragen ein.
Wann hast du das letzte Mal Code erzeugt und wann hast du das letzte Mal Code selbst geschrieben, wenn du sagst, du bist begeisterter Softwareentwickler?
Ich versuche das tatsächlich immer zu machen.
Also ich habe gestern gerade Code erzeugt, heute noch nicht.
Gestern gerade an was gearbeitet und ich habe da auch Code selbst geschrieben, wobei man jetzt sagen kann, also man kann darüber diskutieren, ab wann fängt denn selbstgeschrieben an?
Also wenn ich jetzt den Output von der KI noch verfeinere und verändere, also selber per Hand, ist das denn auch schon noch, zählt das als Code selbst geschrieben oder schon nicht mehr?
Das habe ich auf jeden Fall gemacht und das versuche ich auch immer noch wieder zu machen.
Und von Grund auf schon ein bisschen länger her, würde ich sagen.
Aber das heißt, du setzt die KI tatsächlich ein, ich glaube es macht mittlerweile fast jeder, aber hast trotzdem noch deine IDE offen und gehst manchmal in den Code-Editor rein, um was von Hand zu machen.
Ja, ich persönlich finde das total herrlich.
Also ich finde es total herrlich, die KI zu benutzen auf der einen Seite.
Da können wir auch gleich noch darüber reden, warum und wieso, weshalb.
Aber ich finde es total nett, in der IDE zu sehen, was passiert.
Also gerade so die Diffs, welche Veränderungen werden gemacht, wie sieht das eigentlich aus?
Und selber dieses Gefühl zu behalten, was passiert da eigentlich?
Und zwar gar nicht so sehr im Kleinen, was passiert jetzt genau, was macht die KI hier genau?
Sondern eher, wie sind die Methoden, wie wird das Feature genau gebaut?
Was ruft jetzt was auf, was wird wo durch die Gegend geschoben?
Und dafür finde ich eine IDE nach wie vor extrem nützlich.
Ich bin vielleicht auch ein bisschen voreingenommen, weil ich natürlich an IDEs arbeite und damit schon sehr lange mich mit dem Thema beschäftige.
Deswegen ist es natürlich auch so ein bisschen mein Baby.
Aber ich finde es nach wie vor extrem nützlich, um einfach den Überblick zu behalten, was passiert hier eigentlich mit meinem System, mit meiner Software, mit meinem Projekt, wenn die KI jetzt sozusagen Änderungen erzeugt, Code erzeugt und so weiter.
Das ist total spannend, weil mir ist das mittlerweile ziemlich egal geworden.
Aber bevor wir da drauf kommen, du hast auch einen Vortrag auf der BetCon in Berlin, richtig?
Ja, freut mich sehr drauf.
Im September auf der BetCon, eine kleine, total schöne Konferenz, finde ich.
Und da werde ich auch einen Talk machen zu diesem Thema, ein bisschen verwandt unter dem Stichwort Cognitive Debt. Über den Begriff werden wir bestimmt noch sprechen heute.
Und dann meinen kleinen Vortrag, freue ich mich sehr drauf.
Und das hier ist sozusagen quasi gleich meine Vorbereitung für den Vortrag.
Ja, perfekt.
Also ich habe hier in dem Chat auch einen Rabattcode gerade reingeschmissen.
Die BetCon ist, ich war selbst leider noch nie da, aber ich glaube, das ist eine ganz, ganz nette, coole Konferenz.
Ja, ich war schon mal da, ist total nett, finde ich super.
Also ist wirklich so communityartig organisiert und ich finde es total nett.
Hat nicht diesen extremen kommerziellen Anstrich, was so viele andere große Konferenzen haben, sondern ist ein bisschen kleiner, ein bisschen feiner, communityartig, eng mit den Leuten zusammen.
Toll, also ich mag es.
Das heißt, da kann man sich auch mal beim Mittagessen abpassen und direkt ein paar Worte wechseln.
Sehr gerne, sehr gerne.
Sehr cool.
Jetzt hast du schon gesagt, du hast, du verstehst immer noch gerne, was da passiert.
Ich habe mich so ein bisschen mit der KI vorbereitet und habe gemerkt, wow, es gibt so viele Studien, die können wir alle gar nicht ansprechen und so viel Sichtweisen auf dieses Thema.
Was macht KI mit uns?
Und was ich ganz spannend fand, war so ein Bogen, den mir Claude genannt hat, dass wir die Digitalisierung hatten.
Claude sprach 2010er Jahre.
Die zeitlichen Grenzen sind aufgelöst worden.
Man ist ständig erreichbar.
Man hat ständig irgendwie das Smartphone in der Hand und checkt E-Mails oder sowas.
Und wenn ein Kollege auch noch irgendwie spätabends was postet, dann reagiert man teilweise.
Dann kam mit Corona das Homeoffice.
Jeder ist zu Hause oder die meisten, also die Entwickler, die ich so kenne, arbeiten alle von zu Hause.
Und damit verschwimmt auch irgendwie so ein bisschen der berufliche Bereich und der private Bereich.
Und jetzt haben wir Gen AI.
Und was mir am meisten auffällt, dieser KI-Vampire, dass KI die Arbeit verdichtet.
Dass ich auf einmal viel mehr, aber auch die kognitive Leistung viel höher ist.
Und das ist ja jetzt das, wo du sagst, wenn du sagst, ja, du arbeitest mit KI, aber du verstehst doch ganz gern noch, was die KI da macht.
Das heißt, du machst noch Code Reviews.
Ich bin auf der anderen Seite und sage, ich komme gar nicht nach mit den Code Reviews.
Das muss ich irgendwie anders lösen, das Problem.
Und es wird so viel erzeugt.
Man hat so viele Entscheidungen den Tag über, dass ich sogar so weit gehe und sage, ich weiß nicht, ob ich das auf Dauer acht Stunden am Tag in dieser Geschwindigkeit durchhalte.
Wie siehst du das?
Kann ich total nachvollziehen.
Ich glaube, es gibt ja sozusagen dieses Versprechen mit der KI, mit der KI wird man zehnmal so produktiv wie vorher.
Und man kann zehnmal so viele Sachen machen, zehnmal so schnell Sachen machen und ähnliches.
Das hat ja lustigerweise nicht zur Folge, so erlebe ich das jedenfalls, dass man jetzt morgens eine Stunde gemütlich mit der KI was macht und den restlichen Tag dann frei hat.
Weil man hat ja sozusagen morgens schon alles geschafft, was man sonst den ganzen Tag überschaffen würde vielleicht oder in den nächsten zwei Tagen vielleicht.
Sondern dass man stattdessen eher zehnmal so viel schaffen muss, zehnmal so viel schaffen will vielleicht ja auch.
Schaffen muss die Erwartungshaltung, ne?
Ja, das kann ja so oder so sein.
In einigen Firmen ist es vielleicht so, in anderen Firmen ist es so.
Es geistert ja immer.
Also ich habe das Gefühl, es wird immer stärker zu diesem schaffen muss und nicht so sehr schaffen kann oder schaffen will.
Weil ja immer diese ominöse Konkurrenz macht das.
Die anderen machen das, dann müssen wir das auch so schnell machen.
Das ist halt, glaube ich, tatsächlich ein reales Problem für Firmen heutzutage.
Die sagen, okay, die andere Firma, meine direkte Konkurrenz, ist jetzt auf einmal in der Lage, ich sage jetzt mal, zehnmal so viel Sachen zu machen, zehnmal so schnell Sachen zu machen.
Ob das jetzt alles immer sinnvoll ist, was die machen oder nicht, sei mal hingestellt.
Das ist ja nochmal ein separates Thema, was man diskutieren kann.
Aber dieser allgemeine Eindruck, oh, die anderen benutzen das, die anderen sind zehnmal so schnell, ich muss eigentlich auch zehnmal so schnell werden oder sei es fünfmal so schnell oder zwanzimal so schnell, keine Ahnung, jetzt muss ich eigentlich zehnmal so schnell festhalten.
Die anderen werden auch so schnell, um mitzuhalten in meinem Business, in meinem Geschäft, in meinem Firma, mit meinem Produkt am Markt, muss ich das eigentlich auch machen.
Das heißt, glaube ich, der Druck und die Wahrnehmung wird da immer höher hin zu, ja, klar, ich habe jetzt dieses Werkzeug in der Hand, ich kann das benutzen.
Ich muss das eigentlich benutzen, weil sonst werde ich abgehängt.
Und eigentlich muss ich es auch in einer relativ hohen Taktfrequenz benutzen, weil sonst werde ich auch abgehängt, weil die Entwicklung eben so schnell ist und man damit deutlich viel schneller sein kann als ohne oder deutlich viel schneller sein kann als ich mache das nur die Hälfte der Zeit.
Deswegen finde ich das schon, diese Erwartungshaltung ist, glaube ich, schon da, egal, ob sie jetzt von außen kommt oder ich mir selber auferlege.
Und ich glaube, die wird auch eher, mein Gefühl ist, die wird eher schlimmer werden im Laufe der Zeit.
Und das wird eher sozusagen nicht wieder in sich zusammenfallen, dass man irgendwann denkt, na ja, nee, ach nee, das war auch Käse mit der Gen-AI, braucht keiner mehr und so.
Das ist, glaube ich, schon gekommen, um zu bleiben.
Ja, das ist ja auch so ein Ding, auch so von Social Media, durch Social Media kriegt man ja viel mehr mit, was irgendwie so passiert und merkt da, man hat gefühlt eine höhere Schlagzahl, dass da kommt ein neues Feature raus und da kommt ein neues Feature raus.
Und man bringt das gar nicht so unbedingt zusammen, dass die eine Firma endlich nach langer Zeit wieder ein Feature rausgebracht hat, sondern dass das eben, ja, es kommen halt lauter neue Features raus.
Man ist gerade spannend, du hattest dieses Ten Times gerade erwähnt und wieder vorsichtig zurückgenommen.
Und ich hatte eine Studie gefunden, beziehungsweise die KI hat da zwei Studien versucht zu finden.
Eine Studie, die letztes Jahr das analysiert hat, ob wir wirklich schneller werden.
Das Ergebnis war, die Entwickler sind gemessen 19% langsamer, fühlen sich aber 20% schneller.
Das Spannende fand ich, dass man diese Studie dieses Jahr wiederholen wollte und anscheinend man keine Entwickler mehr gefunden hatte, die ohne KI arbeiten wollen.
Und somit ist diese Frage auch hinfällig geworden.
Und das merke ich bei so vielen Studien, dass die Studien momentan auch so schnell veraltern.
Also wie lang ist das her, dass viele Leute gesagt haben, da gab es doch, war das nicht das Curl-Projekt, wo der Entwickler gesagt hat, er wird so mit AI-Slog überhäuft in den Pull-Requests.
Und ein Jahr später hat er seine Meinung revidiert und hat gesagt, ja, die Pull-Requests haben jetzt Qualität, aber es ist einfach zu viel.
Ja, ich sehe das auch.
Ich glaube, es ist wahnsinnig schwer, als Wissenschaftler heutzutage eine Studie zu machen, die sich jetzt speziell mit den Fähigkeiten von AI beschäftigt, im Sinne von, wie gut ist der Code, der ein spezielles Modell erzeugt, oder wie schnell ist das Modell dabei, den Code zu erzeugen.
Erzeugt es den richtigen Code, werde ich dadurch schneller mit diesem Modell, weil sich die Modelle so schnell verändern und so schnell weiterentwickeln.
Wenn ich heute eine Studie rausbringe über, keine Ahnung, ich lese immer noch Studien mit GPT 4.0 oder so was, kenn ich schon gar nicht mehr.
Schon wieder vergessen, dass es das mal gab.
Da verbindet uns das ja noch.
Also, Gesundkäse.
Also, heute ist ja mindestens das und das.
Und eigentlich ist das auch schon veraltet, weil da ist ja das neue Modell sowieso.
Und die Fähigkeiten entwickeln sich so stark weiter, dass das, finde ich, extrem schwer in so Studien zu greifen ist, wie ist der Produktivitätsfortschritt durch solche AI wirklich im täglichen Leben für mich oder für den Kontext, in dem ich bin, finde ich extrem.
Ich finde die Studien trotzdem spannend und auch interessant, gerade wenn man so ein bisschen so mal um die Ecke guckt und guckt, wie sind die aufgesetzt, wie sind die gemacht, was berücksichtigen die.
Es gibt Studien, die gucken, was ich erfahre, Entwickler im Open-Source-Projekten, die kennen vielleicht die Code-Basis sehr gut, arbeiten deswegen anders mit einer KI als jemand, der die Code-Basis vielleicht nicht so gut kennt.
Solche Fragen.
Oder gibt es vielleicht einen Incentive für möglichst lange damit zu arbeiten oder möglichst nicht so lange damit zu arbeiten.
Also vielleicht je länger die Studie läuft, desto vielleicht werde ich dafür bezahlt.
Also als Teilnehmer einfach so aufwärtsentscheidungsmäßig.
Dann entsteht auf einmal vielleicht so ein kleiner Incentive, sozusagen auch vielleicht ein bisschen länger dafür zu brauchen, weil ich dann so ein bisschen mehr für mein eigenes Portemonnaie aus der Studie sozusagen als Teilnehmer sozusagen ziehen kann.
Meine ich jetzt gar nicht böse, ganz normal.
Also es passiert dann sozusagen einfach durch so ein Studiendesign, dass das Setup auch das Ergebnis beeinträchtigen kann.
Deswegen finde ich es immer spannend, bei den Studien auch mal hinter die Kulissen zu gucken und zu sagen, wie ist das Setup eigentlich, wie funktioniert die Studie eigentlich und damit immer so ein bisschen das Ergebnis zu mischen und zu bewerten aus dieser Sichtweise raus.
Aber die Entwicklung ist natürlich wahnsinnig schnell.
Das sehe ich auch so.
Und deswegen finde ich es schwer zu beurteilen.
Ich kann es halt nur aus meiner eigenen Erfahrung so sehen, wie ich das so wahrnehme.
Und ich merke das schon, dass ich Features, die ich früher gebaut habe, für die ich vielleicht ein, zwei Tage gebraucht habe, um die so solide und dass ich damit zufrieden war, kann ich heute eigentlich auch in zwei Stunden mit einem guten Modell programmieren oder vielleicht auch in einer Stunde.
Das ist schon extrem sozusagen.
Ich bin da ein bisschen schneller, ein bisschen weniger schnell.
Ich glaube trotzdem nicht, dass alles, was ich in dem Projekt mache, ich mit der KI jetzt mache und deswegen zehnmal so schnell bin.
Also wenn ich natürlich auch andere Sachen mache als zu programmieren oder als ein Feature zu bauen, wo ich natürlich auch Fragen habe, welches Feature muss ich denn eigentlich bauen.
Also die Frage wird mir ja nicht zwangsweise abgenommen von der KI.
Vielleicht kann ich das Feature schneller bauen, aber ob das sinnvoll ist, das Feature zu bauen, ob das auch das Richtige ist, das wird mir natürlich nicht abgenommen in die Arbeit.
Wenn ich das jetzt auf einmal für zehnmal so viele Features machen soll wie vorher, weil ich die zehnmal so schnell bauen kann, also der Bottleneck sozusagen in der Entwicklung verschiebt sich, glaube ich, so ein bisschen.
Da gab es letztens einen interessanten LinkedIn-Post.
Da ging es auch darum, welches Feature mache ich eigentlich?
Früher hatten wir, Softwareentwicklung war aufwendig.
Egal welches Feature, wir mussten uns überlegen, was macht das Entwicklungsteam als nächstes?
Weil das war halt das Gate.
Wenn das Team auch nur vier Wochen braucht, dann muss ich mir überlegen, welches Feature ich reingebe.
Und jetzt macht die KI einfach alles so.
Ich merke das zum Beispiel auch bei mir mit Side-Projects.
Es werden auf einmal Sachen ermöglicht durch die KI.
Sachen, die ich vorher nie angefasst hätte, laufen auf einmal, kann ich machen.
Ich habe dadurch mehr Arbeit.
Auch so Wartezeiten gehen verloren, wo man eben im Team zusammengearbeitet hat, weil man die verschiedenen Skills gebraucht hat.
Und jetzt merke ich es halt häufig, dass ich ein Logo brauche.
Ich frage mal die KI, da brauche ich nicht den Designer zu fragen.
Und schon geht es sofort weiter.
Man bleibt im Flow, aber eben auch in der Belastung aus meiner Sicht.
Ich erlebe das aus ganz vielen verschiedenen Aspekten.
Du kannst ja zehnmal so viele Features bauen.
Ist das sinnvoll, zehnmal so viele Features zu bauen?
Ist ja nochmal eine andere Frage.
Welche zehn Features sind, anstatt welches denn als nächstes?
Die Frage wird sozusagen schwieriger.
Und ich mache jetzt einfach mal alles Mögliche querbeet.
Und dann habe ich auf einmal halt 20 angefangene Features da, die so halb rumliegen oder noch 30 Side-Projects.
Auf der anderen Seite merke ich auch, dass es Dinge gibt, die ich früher, glaube ich, gerne ausprobiert hätte oder gerne mal ein Prototyp dafür gebaut hätte oder gerne mal dachte, eigentlich ist es hier ein interessanter Punkt.
Das könnte man eigentlich mal anders lösen.
Das wäre eigentlich gut, aber ich habe nicht die Zeit dazu, das zu implementieren, weil es dauert lange.
Ich habe nicht die Zeit dafür oder das Wissen dafür, da tief reinzugucken, weil andere Sachen gerade wichtiger sind.
Und jetzt habe ich auf einmal die Möglichkeit dazu, das superschnell mithilfe der KI sozusagen ein Prototypen für irgendwas zu bauen und dieses Feedback zu kriegen.
Macht das Sinn, so ein Feature zu bauen?
Der Prototyp gibt mir sozusagen Feedback.
Also das Feedback, was ich vom Prototypen kriege, kriege ich halt superschnell.
Das heißt, ich kann schnell die Entscheidung tatsächlich fällen oder schnell Sachen ausprobieren.
Das eröffnet mir ganz neue Möglichkeiten, Sachen schnell mal auszuprobieren, um zu gucken, macht es Sinn, da technisch weiterzumachen oder macht es keinen Sinn, da technisch weiterzumachen?
Also auch super viele Möglichkeiten.
Ja, auf jeden Fall.
Ich meine, wenn man bereit ist, das, was man erstellt hat, wieder wegzuschmeißen, dann ist das total klasse, das alles auszuprobieren.
Jetzt, du sagst, du guckst dir den Code noch an und schaust, wie er funktioniert.
Ich sehe es öfters mal, dass Entwickler etwas ausprobieren, Herzblut reinstecken und es dann schwierig ist zu sagen, da war keine gute Idee, lass uns das wegschmeißen und was Neues probieren.
Wie geht es dir damit?
Trotzdem, du in den Code reinguckst, kannst du das jetzt so sagen?
Ich glaube, die Fragestellung gab es schon immer.
Die gab es auch vor KI schon.
Also ich baue einen Prototypen und frage mich, will ich den eigentlich jetzt wieder wegschmeißen oder ist mir der Code eigentlich so ans Herz gewachsen, dass ich den jetzt eigentlich weitermachen will?
Also die Sachen wegschmeißen, die man mal ausprobiert hat oder auch Code zu löschen, den man mal geschrieben hat.
Also diese Hürde, weil man das gut findet, was da passiert ist oder weil man vielleicht seine Energie da reingesteckt hat oder aus welchen Gründen auch immer.
Ich glaube, die Fragestellung gab es vorher auch schon.
Vielleicht stellt sich die jetzt häufiger, weil ich schneller was ausprobieren kann.
Aber ich finde es nicht schlimm, Sachen wegzuschmeißen persönlich.
Ich würde es eigentlich umdrehen wollen.
Also früher fand ich es schlimm, was wegzuschmeißen und deswegen jedes angefangene Side-Project liegt irgendwo noch in der Schublade für den Fall, dass man es irgendwie weitermachen will.
Aber jetzt, ich baue keinen Bezug mehr zu dem Code auf.
Die KI macht den Code für mich, er läuft, ich freue mich.
Wenn sie es blöd gemacht hat, dann schmeißt sie es weg und sagt, mach mal neu.
Hier hast du mehr Kontext.
Und das finde ich eigentlich ganz positiv.
Nimmt natürlich diesen menschlichen Faktor ein bisschen raus, aber den habe ich so ein bisschen als negativ in der Vergangenheit empfunden.
Wenn jemand an etwas hing, weil er sich in etwas reingearbeitet hat, weil er mit Herzblut etwas erzeugt hat, das ist bei mir jetzt mit der KI eigentlich weg.
Ja, interessant.
Das habe ich bei mir noch nicht so beobachtet, aber ich glaube auch noch nicht so aus der Perspektive darüber nachgedacht.
Spannend.
Ich glaube, es kommt halt bei mir wirklich, weil ich aufgegeben habe, das zu reviewen und ich eben eher versuche, die KI so zu steuern, dass ich ihr vertrauen kann.
Ich glaube, wir als Entwickler haben oftmals dieses Problem, dass wir immer nah am Code gearbeitet haben und uns das wichtig ist und wir es verstehen wollen.
Als Product Owner habe ich mir noch nie den Code angeguckt und ich glaube, wir müssen ein bisschen mehr in Richtung Product Owner gehen und die KI leiten.
Ich glaube, das ist eine ganz grundlegende Frage, die mir auch immer wieder, also ich glaube, es gibt immer wieder diese grundlegende Frage, will ich die KI mit ihrer Fähigkeit, Code zu produzieren, eher wie eine Black Box ansehen und sagen, das ist wie ein Compiler in Zukunft, also da stecke ich halt irgendwas rein und dann kommt was raus und das, was rauskommt, wird schon das Richtige sein.
So what?
Da vertraue ich drauf.
Oder nutze ich es eigentlich eher als sozusagen den Programmierpartner, das Per-Programming damit und eigentlich, ich bin noch der Code Owner von dem, was da rauskommt.
Und ich glaube, das sind zwei völlig unterschiedliche Sichtweisen auf das Thema, die immer wieder vorkommen und die auch immer wieder kontrovers diskutiert werden und wo es auch immer wieder, glaube ich, persönliche Präferenzen, die es ja in der anderen Richtung gibt, die sich auch beliebig verändern im Laufe der Zeit.
Aber ich glaube, es hängt stark an dieser Sichtweise, wie sich dann das Verhalten sozusagen daraus ableitet.
Also bei dir, wenn du jetzt eher darauf guckst, das ist wie ein Compiler, ist es total klar.
Also was soll ich mir in dem Kram angucken, der da rauskommt?
Entweder er tut das oder er tut das nicht.
Und wenn nicht, dann stecke ich halt oben einen anderen Input rein, dann kommt da unten ein Output raus.
Das wird dann schon passen.
Und eigentlich kümmerst du dich gar nicht, ist vielleicht böse gemeint, aber du kümmerst dich eigentlich gar nicht darum, was da genau für ein Code rauskommt und wie der genau strukturiert ist und so.
Das wird die KI schon machen.
Und ich gucke, glaube ich, immer noch oder vielleicht auch weiterhin, dass er als ein Partner für mich sozusagen, der mir hilft dabei, Sachen schneller zu machen, Sachen auch besser zu machen, auch mehr Sachen zu machen und auch Sachen zu machen, die vorher nicht möglich gewesen wären.
Aber ich gucke jedenfalls nicht in allen Bereichen, vielleicht in einigen, aber nicht in allen Bereichen als diese Blackbox, als diese Compiler, diese Compilerperspektive, glaube ich.
Die nehme ich, glaube ich, nicht ein.
Jedenfalls aktuell nicht oder nicht immer.
Und manchmal habe ich das Gefühl, hängt es bei mir damit zusammen, was ich mache.
Also manchmal, wenn ich halt, keine Ahnung, irgendwas mal schnell ausprobieren will oder ich brauche mal was, das das und das macht, baue mir mal ein Skript, was mal schnell so ist.
Das ist für mich total diesen Blackbox-Compiler, mach das Skript, Skript wird schon funktionieren, alles prima.
So, wenn ich jetzt denke, ich habe neulich zum Beispiel gerade ein Teil umgebaut, den wir in dem Tooling haben, weil ich sozusagen eine Source-Code-Kopie drin, die ein bisschen angepasst war, gefiel mir nicht, wie das gebaut war, müsste eigentlich ein bisschen umstrukturiert sein, müsste eigentlich eher von der Struktur her anders funktionieren, habe ich der KI auch gesagt, wie ich das haben will.
Die hat mir auch geholfen, den Code so umzubauen.
Aber da will ich sehen, ob das, was ich im Kopf habe, so grob, ob das da hinten auch rauskommt.
Weil ich eigentlich das als Hilfsmittel genutzt habe in dem Moment und nicht als Blackbox-Machmal und tschüss.
Das sind, glaube ich, einfach zwei unterschiedliche Sachen.
Ich glaube es auch nicht, dass dieses richtig-falsch-altertümlich-modern ist.
Du hast es ja schon gesagt, so ein Proof-of-Concept, das kann man einfach laufen lassen.
Wenn ich irgendwas ausliefern will, dann muss ich schon mal genauer drauf gucken.
Und dieser Traktionslevel, aus dem ich drauf gucke.
Jetzt hattest du mir gesagt, dir scheint die Struktur egal zu sein.
Ich lasse meine KI in meiner Architektur nach Arc 42 entwerfen und sehe dann da zum Beispiel die Module.
Das ist so mein Dashboard, was ich auch so ein bisschen brauche, um die KI zu steuern.
Um zu sagen, guck mal, wir haben hier ein neues Feature, das müssten wir in das Modul reinbauen.
Solche Geschichten, dass man sich noch auf einer fachlichen Ebene mit der KI darüber unterhalten kann.
Aber wie jetzt das CSS-Stylesheet genau aufgebaut ist, wenn es gut aussieht, dann passt das für mich.
Aber mit der Geschwindigkeit ist natürlich auch, wir haben es ja vorhin schon kurz angesprochen, dieser Druck, der irgendwie unter Umständen entsteht, der hoffentlich von der Firmenkultur abgefedert wird, aber eben teilweise auch von außen kommt.
Man muss schneller sein.
Bei Festfall war es, glaube ich, wo ich auf einen Kommentar geantwortet habe, jedes Feature ist nur zehn Minuten entfernt.
Und er so, da bist du aber langsam, bei mir sind es so zwei bis drei Minuten.
Und mit jedem Feature kickt das Dopamin ein.
Und ich merke halt auch, ich habe da einfach Bock auf die KI.
Also ich sage immer scherzhaft, ich setze mich abends um zehn nochmal hin, um fünf Minuten was mit der KI zu machen.
Fünf Minuten später ist es nachts um eins.
Weil einfach, hey, dieses Feature noch, jenes Feature noch, sonst was.
Das ist auch so ein Druck, der entsteht.
Es macht ja auch Spaß.
Also so geht es mir jedenfalls.
Also es macht einfach auch Spaß, das zu sehen, wie schnell das geht.
Ich merke aber auch, dass diese, wenn du sagst, dieser KI zu vertrauen, dass sie schon das Richtige macht, dass man auch immer schneller, also dass man sozusagen ein bisschen dahin, so unmerklich dahin schleicht.
Also im Sinne von, das erste Mal gucke ich mir das noch an, was die KI macht.
Und das zweite Mal gucke ich mir das auch noch genau an.
Und das dritte Mal reviewe ich das auch.
Und beim vierten Mal reviewe ich das schon nicht mehr so ganz genau.
So, weil ich das schon dreimal gemacht habe.
Und dreimal hat es so grob gepasst.
Und dann irgendwann sage ich, ja, ja, passt schon, passt schon, passt schon.
Das Interessante, was ich dabei finde, ist, dass es dazu auch so Forschungen gibt, dass eine interessante Folge davon sein kann, dass, wenn du sozusagen den KI-Output reviews und eigentlich nicht mehr Code selber schreibst, sondern nur noch damit beschäftigt bist, den Output zu reviewen und das auch immer weniger sozusagen machst, du automatisch auch die Fähigkeit verlierst, den Output zu bewerten im Laufe der Zeit.
Also du verlierst sozusagen die Fähigkeit, den Output zu bewerten und zu sagen, ob das richtig oder falsch ist, weil du keinen Code mehr selber schreibst.
Und da bin ich auch nicht so sicher, ob ich das will.
Ja, ja, ja.
Und das finde ich eine interessante Beobachtung.
Wenn du natürlich sagst, na ja, ist sowieso ein Compiler, ist mir ja wurscht, was da rauskommt, dann habe ich da ja erstmal keinen Stress mit, auf der anderen Seite.
Trotzdem setzen da halt so diese Effekte ein.
Das kann man halt auch so in so Studien, je nachdem, wie die so gebaut sind, so sehen, dass, wenn Leute Sachen lernen mit KI, also was weiß ich, eine neue Bibliothek lernen oder sowas.
Und die einen machen das mit KI, die anderen machen das ohne KI.
Dass natürlich das Verständnis darüber, wie sieht diese Bibliothek aus, wie funktioniert die oder ein Framework, ohne die KI eigentlich ein viel besseres Wissen erzeugt nachher.
Also das Vorgehen, das zu lernen, viel besseres und tieferes Wissen darüber als ohne die KI.
Dann kann man das auch benutzen, die Bibliothek, aber hat man ein viel flacheres, viel ungenaueres Verständnis.
Das finde ich halt auch eine spannende Frage.
Also will man sozusagen eigentlich, will man alles immer mehr und mehr an so eine Gen-AI abgeben und sich eher in so eine Abhängigkeitssituation begeben.
Und zwar gar nicht jetzt im Sinne von, ich bin zehnmal schneller als ohne, sondern ich kann das gar nicht mehr ohne.
Also ohne, selbst wenn ich zehnmal so langsam wäre, ich würde es gar nicht hinkriegen, weil ich habe die Fähigkeit eigentlich total verloren.
Das geht auch so ein bisschen in Richtung Daniel Kruger-Effekt.
Also wenn ich keine Ahnung habe, dann schätze ich das Ganze falsch ein, anders ein.
Und das ist ja, wenn ich den Code nicht mehr kenne, nicht mehr selbst erstellen kann, dann kann ich ihn eben auch nicht mehr so gut bewerten.
Wir haben hier einen Kommentar.
Der Entwickler versteht beziehungsweise interessiert sich für den Code nicht mehr.
Genial.
Ich nehme das mal jetzt so ein bisschen als negativ auf.
Wir haben nämlich auch noch einen zweiten Kommentar.
Ich versuche so weit wie möglich Ralfs Richtung anzugehen.
Dabei bin ich aktuell im Martins-Modus, aber versuche soweit es geht, die Planken und Harnes zu verbessern, um Ralfs Vertrauen zu gewinnen.
Das ist, finde ich, so, dass das resoniert mit mir, weil klar, ich habe halt einfach das Gefühl, die Zukunft ist, die KI macht das alles und ich muss lernen, wie das funktioniert.
Und ja, ich bin auch schon voll auf die Nase gefallen.
Die KI baut mir eine tolle Website und sie sieht toll aus.
Und ich merke gar nicht, dass sie für LLMs und für Google einfach eine leere Seite ist, weil sie einfach ein JavaScript ist, was die Seite dynamisch aufbaut.
Das war für mich so ein Learning, wo ich dann aber eben auch gesagt habe, hier Harnes, ich muss jetzt hier der KI irgendwie beibringen, dass sie diesen Mist nicht mehr macht.
Und da spielt dann wiederum es noch eine Rolle, dass mir sowas überhaupt aufhält, dass ich noch das Verständnis für die Technik, für die Softwareentwicklung habe, dass ich den Fehler sehe, der sehr versteckt ist und ihn eben auch in Worte fassen kann, um ihn zu korrigieren.
Unbedingt.
Eine spannende Frage finde ich halt, verlierst du diese Fähigkeit immer mehr, je mehr du die KI benutzt.
Das wird eine spannende Frage sein.
Also ich glaube, die können wir schon beantworten, weil ich kann halt vieles auch gar nicht mehr reviewen, weil ich war früher viel im Java und Groovy Ökosystem.
Da bin ich jetzt über die KI raus.
Ich mache jetzt Go und Python.
Und Python habe ich mal im Skript selbst aufgebaut.
Go, nein, ich könnte jetzt, wenn man mich in den Raum sperrt ohne KI, ich wüsste nicht, was für Tools ich brauche.
Ich wüsste nicht, wie ich den Compiler anschmeiße.
Ich wüsste gar nichts mehr.
Und ich habe jetzt die Fähigkeit gewonnen, eine beliebige Programmiersprache, je nachdem, was ich brauche, mit der KI einzusetzen.
Aber ich habe die Fähigkeit verloren, es selbst zu machen.
Review, ja, ich verstehe, ob das System Outprint Line ist oder ein Printfm oder sonst was.
Das kann ich noch lesen.
Aber ansonsten, ja, die Fähigkeit werden wir verlieren.
Das wird sich shiften, bin ich mir sicher.
Mal eine andere Frage.
Merkst du, dass mit der KI die Qualität, die Standards sich verändern?
Ich denke zum Beispiel daran, Test Driven Development.
Jeder hat immer die ganze Zeit von Test Driven Development gesprochen.
Richtig umgesetzt habe ich es nicht so häufig gesehen.
Ich selbst wusste immer, ja, muss ich eigentlich machen.
Aber den Code erzeugen war schneller.
Und guck mal, es läuft doch.
Und jetzt noch Test schreiben und jetzt mit der KI.
Das ist mein Harness.
Ich habe Behavioral Driven Development.
Ich formuliere in Gherkin die Anforderungen oder lasse sie formulieren.
Und die KI muss sie umsetzen und die entsprechenden Tests schreiben.
Das ist für mich zum Beispiel so ein Ding, wo ich das Gefühl habe, dass die Standards jetzt mit der KI höher werden.
Höher werden in welchem Sinne?
Ich glaube, das verstehe ich noch nicht.
In dem Sinne, dass tatsächlich auch die Qualität besser wird.
Wir hatten anfangs immer auch so Sachen wie, viele Leute haben die KI als stochastischen Papageien beschimpft und die macht mir den Code kaputt.
Das ist aber gedriftet, das ist so weit gedriftet, dass jetzt Babel verboten worden ist, weil Babel zu leicht Security Issues findet und die KI eben tatsächlich anscheinend besser geworden ist als ein menschliches Security Review.
Und dadurch können wir hoffentlich bessere Software erzeugen.
Oder würdest du sagen, es ist weiterhin nur ein Tool und es kommt auf den Entwickler drauf an?
Fühlst du, was ich denke?
Ja, ich habe, glaube ich, unterschiedliche Gedanken dazu.
Als du Test-Driven-Development erwähnt hast, habe ich mich natürlich gleich gefragt, Test-Driven-Development, wie war das eigentlich früher?
Wie habe ich das gemacht?
Und ich habe das immer gemischt gemacht, weil ich eigentlich ein großer Fan davon bin und ich viele Features in der IDE tatsächlich Test-Driven entwickelt habe.
Also als ich das noch ohne KI gemacht habe.
Nicht alles natürlich, aber doch vieles.
Und wo es ging, ich da eigentlich auch sehr viel Spaß daran hatte, das Test-Getrieben zu entwickeln.
Ich jetzt natürlich mit der KI, also so laut gedacht, die Tests auch generieren lasse.
Also gemeinsam.
Vorneweg oder hintendran?
Gemeinsam, zeitgleich eigentlich.
Vor dem Code oder nach dem Code?
Test-Driven-Development oder Development-Driven-Testing?
Also das unterscheidet sich für mich dann ja nicht mehr, wenn ich der KI sage, generier mal dieses Feature und mach die Tests gleich mit.
Dann wird das sozusagen in einem Rutsch für mich erzeugt.
Also ich sage nicht, er soll die Tests im Nachhinein erzeugen, als zweiten Schritt, oder er soll die Tests am Anfang schreiben, sondern er soll das alles in einem Rutsch machen.
Und dann iteriert der KI-Assistent natürlich so lange darüber, bis die Tests auch funktionieren.
Und manchmal hat das dann natürlich auch komische, treibt das komische Blüten.
Weil dann werden die Tests halt auch so lange umgebogen, bis sie dann doch grün sind.
Und nicht immer hat der Fehler im Code gefunden und umgekehrt.
Aber das wird halt auch besser natürlich.
Also jedes Modell, jeder Assistent wird da auch mal wieder besser.
War eigentlich ganz gut da drin.
Ich finde die Erzeugung von Tests mit der KI extrem nützlich, weil man relativ schnell relativ viele Corner Cases, Edge Cases damit generieren kann.
Finde ich extrem nützlich.
Wenn ich jetzt sozusagen den Shift mache zu, ich sage mal, wie gut wird die Software, die ich damit baue, so Richtung Security-Analysen, Fable, Mythos und so weiter, finde ich das natürlich auch extrem beeindruckend, wie gut und wie schnell die KIs heutzutage Code-Basen analysieren, Code-Basen sich angucken.
Ich merke das ja auch, wenn ich irgendwas bauen soll, oder ich will mal gestern zum Beispiel, wollte ich gerade mal rausfinden, wie in der Eclipse-IDE im Java-Editor ein bestimmtes Gutter-Icon, in einem bestimmten Fall, wie ist das eigentlich genau gebaut?
Wo kommt die Information eigentlich genau her?
Weil ich das wissen wollte, weil wir sowas ähnliches, einen ähnlichen Anwendungsfall irgendwo bei uns im Language-Java auch haben.
Ich schmeiße das Projekt in die KI rein, sage hier, erzähle mal, woher kommt das Icon her?
Fünf Minuten später habe ich eine genaueste Beschreibung, wo dieses Icon herkommt und wie das gebaut ist und wie die Struktur zusammenhängt und was aufruft.
Also gigantisch.
Also hätte ich selber wahrscheinlich einen halben Tag gebraucht, um das irgendwie wirklich so in diesem Detail rauszufinden.
Deswegen ist es, glaube ich, so dieses Code-Verständnis, Code-Basen-Analysieren.
Und deswegen finde ich das auch diesen Partner anzusehen, der mir solche Sachen ermöglicht, das super schnell zu machen und super schnell zu verstehen.
Extrem hilfreich, also unfassbar hilfreich eigentlich.
Und wenn ich jetzt den Schritt weitergehe hin zu Security-Analysen, ist es natürlich extrem beeindruckend, was die an Qualität inzwischen erzeugen.
Also gar keine Frage, wenn man sich die Blogposts von Cloudflare oder Mozilla oder sonst den Teams anguckt.
Ja, es gab eine Zeit, da haben die sozusagen, ich sage mal querbeet, irgendeinen Blödsinn reported, die KI-Tools.
So, da waren vielleicht neun von zehn Reports, waren irgendwie totaler Käse.
Ich glaube, heutzutage ist es, wenn man den Leuten glaubt, ganz andersrum.
Also es sind wahrscheinlich eher neun von zehn Reports on point und eigentlich genau das, was natürlich auch eine riesige Chance ist, wenn man diese Tools nutzen kann, seine eigene Software so gut zu machen, dass sie zum Beispiel die Sicherheitslücken, die Sicherheitsprobleme nicht mehr hat.
Jetzt mal unabhängig von der Frage, wann können sozusagen die Bösen die Modelle benutzen.
Und dann beginnt sozusagen das Race, das Rennen auf der Ebene.
Aber das ist natürlich extrem beeindruckend und ein extrem großartiges Werkzeug eigentlich.
Wobei es, wenn ich mir die Analysen angucke, ist ich immer noch, obwohl die ja teilweise auch schon den Fix für den, also den Exploit bauen und den Fix für den Exploit vorschlagen und ähnliches und das auch extrem gut ist, brauche ich trotzdem noch jemanden, der sich das anguckt.
Ich brauche trotzdem noch jemanden, der das Projekt kennt und der aus der Sicht des sozusagen Security Experten drauf guckt und sagt, wie ist das in diesem Fall eigentlich genau?
Stimmt das eigentlich, dass das sozusagen, wie ist, wenn der Exploit so gebaut wird?
Heißt das eigentlich auch, das andere ist eigentlich auch ein Problem?
Heißt das eigentlich so, wie das hier gebaut ist, ist das eigentlich auch schwierig?
Ist das eigentlich wirklich, weil man, das ist ja unter der Voraussetzung gebaut, da ist das und das und deswegen passiert das hier eigentlich nicht und ähnliches.
Also ich brauche trotzdem noch, jedenfalls aus meiner persönlichen Erfahrung, den menschlichen Reviewer dafür, der diese Security Fixes oder Security Reports analysiert, selbst wenn sie von den extrem, extrem guten Modellen kommen.
Könnte ich zum Beispiel noch nicht die Black Box sozusagen anwerfen und sagen, mach mal, wird schon passen.
Ja, aber du hast eigentlich zwei ganz gute Beispiele genannt, wo die KI für mehr Arbeit sorgt.
Also dieses in fremden Code mit dem Icon reinfuchsen, da hätte man früher wahrscheinlich gesagt, ach nee, jetzt Freitagnachmittag, nein, mache ich jetzt nicht.
Jetzt mit der KI, ach komm, das machen wir noch schnell.
Und auch mit den Security Reviews oder generellen Reviews, wo man früher gesagt hat, naja, okay, jetzt gebe ich das einem Kollegen und der wird nächste Woche schon Zeit finden, das zu reviewen.
Und jetzt macht es die KI und findet was und die Schlagzahl ist höher.
Und auch mit den Standards, wenn man das so richtig macht, dann wird die Code Qualität besser.
Wenn ich jetzt zum Beispiel auch sehe, ich lasse Issues immer von der KI generieren und die sind viel besser als das, was ich sonst gemacht habe.
Da steht eine Begründung, warum das wichtig ist und wie ich das reproduziere und vielleicht schon einen Hinweis, wo es gefixt werden muss.
Und ich muss mir jetzt nicht nehmen lassen, ich will Waschmaschine sagen in einem technischen Talk, weil es gibt eine Studie von 1983, die so ein Phänomen untersucht hat, dass nämlich Technologie meistens nicht die Arbeit abnimmt, sondern mehr Arbeit erzeugt durch ein Verspieden der Standards.
Ein prominentes Beispiel ist die Erfindung der Waschmaschine.
Früher gab es einmal im Monat den Waschtag, wo jeder mit zugreifen musste.
Und der Standard war, ein Hemd hat man eben die Woche über getragen und hat den Kragen vielleicht mal ausgewechselt.
Man konnte den Kragen wechseln.
Und jetzt jeden Tag ein frisches Hemd anziehen, ist ja ganz normal.
Aber die Workload ist dadurch nicht gesunken, sondern der Standard gestiegen.
Und ich glaube, das haben wir mit der KI auch.
Auch wenn wir sagen, die Schlagzahl ist ein sozialer Faktor und kommt auf die Kultur an, da kann man gegen anarbeiten.
Aber die Standards, ich glaube, da können wir uns nicht gegen wehren.
Ich finde das gerade aus dem Security-Bereich extrem nützlich.
Ich glaube, das ist …
Also ich glaube, in Zukunft wird es einfach so sein, dass man, wenn man Software baut, die sozusagen standardmäßig immer wieder von der KI sozusagen aus Security-Sicht analysieren lässt, bevor man irgendwas shiftet.
Das wird sozusagen Teil von der CI-Pipeline wahrscheinlich sein, wie die Tests ausführen oder sonst irgendetwas.
Und dass ich dann eigentlich solche Security-Probleme, die ich selber einbaue oder die vielleicht in der Software schon drin sind, eigentlich sofort finde, sofort sehe und sofort beheben kann.
Und das ist natürlich ein extremer Vorteil gegenüber früher, die Software wird ausgeliefert und dann muss eigentlich jemand gegen die Software, wenn man Glück hat, ich sag mal der Gute, der Forscher, der einem dann sagt, hier, da und da ist ein Problem, behebt das mal, wenn es nicht schon ausgenutzt wird von den bösen Hackern.
Und das finde ich jetzt natürlich, das ist ein Riesenfortschritt, glaube ich, riesige Möglichkeiten.
Zurzeit sieht man natürlich diese extreme Welle, weil jetzt sozusagen diese Modelle in der Lage sind, das zu tun.
Die werden jetzt quasi auf die Welt losgelassen, die die Softwarewelt noch nicht gesehen hatte vorher.
Deswegen finden die jetzt natürlich wahnsinnig viel.
Also wenn man sich die Zahlen anguckt, das ist natürlich gigantisch.
Also keine Ahnung, wenn man sich jetzt den Chrome Browser anguckt, da haben wir mal jeden Release immer 20 CVIs gefixt.
Und jetzt gab es einen Release, da haben sie halt 400 gefixt.
So das ist sozusagen so der Unterschied, den es da gibt.
Die Frage ist, bleibt das so?
Oder ist das jetzt sozusagen die Welle, die man bearbeiten muss?
Und danach ist das sozusagen eigentlich im täglichen Doing, wie in der CI-Pipeline drin.
Und man hat nicht mehr diese riesige Welle, die man einmal so vor sich her schiebt.
Weil jetzt diese Reports alle kommen gegen die Software, die eben nicht mit diesem Ding gebaut worden ist.
Wobei man glaube ich schon dadurch natürlich, ich glaube man kann die Welt schon sicherer machen.
Also das ist schon ganz gut, wenn man die Sachen alle findet und sieht.
Ich sehe natürlich auch, dass die Teams, die da dran arbeiten, natürlich auch massiv belastet sind davon.
Also wenn was ich, ich weiß nicht wie es bei Google Chrome ist oder sonst was, aber ich kann mir schon vorstellen, wenn die immer 20 CPIs gefixt haben im Monat und jetzt auf einmal 450 fixen müssen, dann…
Da setzt sich auch so eine Review-Müdigkeit ein.
Ich meine, du hast anfangs gesagt, dir macht es ja Spaß zu programmieren.
Ja, mir auch.
Deswegen bin ich in die IT gegangen, Probleme lösen und Code erzeugen, der Probleme löst.
Nicht Code Review, das war jetzt nicht so das, was mir Spaß gemacht hat.
Und man merkt es ja auch, dass es gibt ja diesen Joke, fünf Zeilen Code und ich finde zehn Sachen und 500 Zeilen Code und ich winke es durch.
Ist dir das jetzt eigentlich auch aufgefallen, dass jetzt die letzten Tage Claude unterteilt bei mir jetzt Issues in kleineres Häppchen, damit nur noch so vier Files geändert werden in jedem Häppchen und ich das besser reviewen kann?
Also ich glaube, die gehen da tatsächlich mit der Steuerung auch gegen diese Review-Müdigkeit vor.
Habe ich selbst noch nicht gesehen, aber der klingt irgendwie logisch.
Ich habe auch gemerkt, dass wenn die KI einfach sagt, lass es uns so machen, dann sage ich eher, ja, du wirst schon recht haben, als wenn die KI sagt, guck mal, ich habe drei Optionen, welchen Weg wollen wir gehen?
Wobei ich mittlerweile dann auch immer sage, was schlägst du vor?
Also diese Review-Müdigkeit, Review-Fatigue, die da einsetzt.
Absolut.
Und wir haben ja auch einen Kommentar mit den menschlichen Grenzen.
Was ist mit den menschlichen Grenzen?
Der kann kognitiv nicht mitskalieren, Stichwort AI-Brain-Fry.
Ich fand das interessant bei einem Talk, den ich habe, so Blick in die Glaskugel, in die Zukunft, hat sich eigentlich vorausgesehen, dass der Code immer komplexer wird, den die KI erzeugt und wir irgendwann diese Komplexität gar nicht mehr erfassen können.
Das ist anders gekommen.
Es ist einfach die schiere Menge an Code, die erzeugt wird, wo ich nicht mehr hinterherkomme mit dem Durchgucken.
Ja, also ich versuche das bei mir im Rahmen zu halten, weil ich ja stärker versuche, die KI eher als meinen Programmier-Buddy zu benutzen und weniger als die Blackbox.
Aber klar, ich merke persönlich bei mir auch, wenn ich jetzt zwei Stunden mit dem AI-Assistant was arbeite und ständig Code reviewe, also ich bin danach müder, als wenn ich zwei Stunden selber programmiert hätte.
Ich habe natürlich auch in den zwei Stunden zehnmal so viel wahrscheinlich gemacht und mir zehnmal so viel Code angeguckt, wie ich es sonst gemacht hätte.
Insofern wundert es mich auch nicht, dass ich müder bin oder geschaffter bin danach oder mich selber auch gestresster fühle oder gehetzter fühle.
Das ist irgendwie ganz erklärlich, aber es ist trotzdem so.
Also es geht dadurch nicht weg, weil ich weiß, warum es so ist.
Ich versuche, ich habe ja gesagt, ich mache nicht mehr so viele Reviews, ich versuche, den Reviews auszuweichen durch einen Korrektur-Loop, EICHOS-Prinzip, dass ich den nicht deterministischen Kanal des LLMs korrigiere, indem ich Tools einsetze, Pre-Commit-Hooks, aber auch teilweise dem LLM eigene Tools gebe.
Ich finde, am einfachsten ist es immer beim Compiler erklärt.
Wenn ich das, was die Maschine erzeugt, zum Schluss durch den Compiler jage und es kommt keine Fehlermeldung, dann ist der Code anscheinend Syntax-Error-frei.
Das ist natürlich bei irgendwelchen interpretierten Sprachen nicht ganz so einfach, deswegen sind natürlich kompilierte Sprachen für sowas besser.
Und das heißt, wenn ich den Loop einbaue, dann kann ich der KI schon mal vertrauen, Syntax-Fehler sind nicht mehr drin.
Und ich versuche, den Reviews auszuweichen, indem ich immer mehr solche Loops einbaue.
Aber dazu muss man eben auch die ganzen Aspekte kennen, die man eben so testen kann, testen will.
Und dann fällt da eben zum Beispiel auch die Funktionalen-Tests runter.
Und wo kommen die her, wie gut sind die und wie sehr kann ich denen schon vertrauen?
Ja, das ist zum Beispiel auch der Aspekt, den ich als Tool-Bauer, der ich ja auch bin, als derjenige, der IDEs baut, mir natürlich auch die Frage stellt, brauche ich überhaupt eine IDE in Zukunft?
Haben wir schon ein bisschen am Anfang mal kurz vorgesprochen.
Aber ich sehe da auch die Rolle der IDEs oder dieses Language-Tooling, das man so schön hat.
Als Tool-Bauer bin ich sozusagen, mein liebster Freund sind ja die Squidly-Lines im Editor, die immer schön sagen, was hier komisch ist und was hier falsch ist und wo ich noch einen Quick-Fix machen könnte und wo ich den Code noch verbessern könnte und was irgendwie merkwürdig ist oder sowas.
Dass der Kunde dafür, also früher war es sozusagen eigentlich der Entwickler, der vor der IDE saß und das Zeug benutzt hat, den wollte ich möglichst effizient machen, den wollte ich im Flow lassen, den wollte ich möglichst schnell, möglichst einfach, also dass der Editor so schnell wird wie seine Gedanken.
Und dass sich das sozusagen ändert, die Tools kriegen jetzt immer mehr diese Perspektive von, das LLM oder der Agent ist eigentlich mein Kunde.
Also eigentlich versuche ich jetzt quasi, was ich, wenn ich jetzt Spring-Tools zum Beispiel baue, wir bauen Spring-Tools für Cloud-Code jetzt auch.
Wow.
Dass ich sozusagen Cloud-Code im Laufe der Zeit sozusagen einfach sage, nicht mehr dem Editor sage, jetzt Squidly, hier ist irgendwie was komisch aus Spring-Sicht, also diese Annotation, hier fehlt eigentlich eine Annotation so und so und hier müsstest du eigentlich noch das machen, so dass ich das quasi dem LLM sage und sage, wie wird das eigentlich gefixt und wie kannst du hier besseren Code erzeugen, so dass das LLM das eben, wie du sagst, als ein Tool benutzen kann, um sich selber zu überprüfen, um den Output zu überprüfen und den Output gegebenenfalls zu verbessern.
Das wird, glaube ich, eine spannende Entwicklung aus der IDE-Sicht, wenn ich die Brille mal wieder kurz aufsetze.
Weil das natürlich immer so ein Katz-und-Maus-Spiel ist, sind die LLMs sowieso irgendwann so gut, dass sie das sowieso machen.
Aber ich finde halt diese Sichtweise, dass die Tools sozusagen in Zukunft den LLMs quasi helfen, besseren Code zu erzeugen und gar nicht mehr so sehr dem Entwickler, der vor der IDE sitzt.
Lars sagt ganz richtig, Syntax-Fehler waren noch nie das Problem im Gegensatz zu logischen Fehlern.
Da setze ich halt auf entsprechende Tests und tatsächlich teilweise die Intelligenz der KI, da ich sage, mach nochmal manuelle Tests.
Aber den Strang, den du gerade aufgemacht hast, dass wir jetzt Tools für die LLMs entwickeln, dass die LLMs damit umgehen sollen, wahrscheinlich auch, dass die Fehlermeldungen dem LLM einen besseren Hinweis geben, wo ich in der Java-Welt denke, das ist sicher auch für den Menschen gut.
Also die Stacktraces, die ich schon immer gehasst habe zu lesen, hört sich ja fast an wie eine Win-Win-Situation, oder?
Wenn ich denn das LLM benutze und das LLM quasi den technischen Kontext verstehe?
Ja, denkbar.
Und optimiert ihr auch die Dokumentation entsprechend für die LLMs?
Ich habe da einen Fall im Gedächtnis, wo jemand die Dokumentation für das Windows-Subsystem für Linux verbessern wollte und deswegen eine Vergleichstabelle eingebaut hat.
Und die Maintainer dann gesagt haben, schön und gut, aber Tabellen kann die KI schlecht lesen, deswegen nehmen wir den Pull-Request nicht an.
Habt ihr da irgendwelche Ansätze, wo ihr sagt, wir achten auf Folgendes, dass das LLM gut mit der Dokumentation umgehen kann?
Oder sagt ihr, das LLM kann noch prima mit der Dokumentation umgehen?
Spannende Frage, beschäftigen wir uns tatsächlich mit.
Da haben wir noch zu keinem Ergebnis gekommen.
Zurzeit sind, glaube ich, einfach gerade andere Themen wichtiger.
Aus der Tooling-Sicht ist das natürlich eine spannende Frage, was wir zum Beispiel für das Cloud Code Plugin gemacht haben.
Wir hatten ja früher Warnings und Validations in der IDE und einen Quick-Fix dazu.
Der Quick-Fix war so gebaut, dass er den Code entsprechend ändert, also den Abstract Syntax Tree modifiziert oder den Source Code modifiziert und Ähnliches.
Und wir haben das quasi übersetzt in Markdown.
Also in Zukunft ist sozusagen bei uns der Quick-Fix quasi das Markdown, was dem LLM sagt, was hier eigentlich genau zu tun ist, mit einem kleinen Code-Beispiel.
Und das LLM kann dann eigentlich den Code entsprechend modifizieren.
Das geht ein bisschen in die Richtung, dass sozusagen eigentlich die Information oder die Implementierung, die sonst für den Entwickler war, sei es die Dokumentation oder der Quick-Fix, stärker diesen Aspekt berücksichtigen muss.
Kann das LLM damit eigentlich vernünftig was anfangen?
Und wie muss ich die eigentlich bauen, damit das LLM das vernünftig macht?
Wobei es dabei auch eine wahnsinnige Schwierigkeit gibt.
Also eigentlich müsste man das gut testen.
Also eigentlich müsste ich mir sicher sein, wenn ich jetzt, keine Ahnung, ich mache jetzt statt die Dokumentation, mache ich die Dokumentation so, wird es dann wirklich besser?
Also außer ich sitze davor und probiere das mal aus mit Cloud Code.
Das ist ja ganz lustig und das ist so anekdotisch.
Aber ob es denn wirklich für alle besser wird, weiß ich nicht.
Also eigentlich bräuchte ich da sozusagen, ich sage mal, den automatisierten Test, wie die LLM Benchmarks, die es so gibt, die das im Prinzip prüft, ob das wirklich besser wird.
Das ist erst mal nicht so trivial zu tun.
Da gibt es natürlich auch tausend Ansätze für, aber erst mal nicht so trivial.
Und dann gibt es natürlich das Problem, welches Modell benutzen denn die Leute?
Also wenn ich jetzt mit dem Modell das benutze, dann brauche ich eigentlich die Dokumentation in der Form.
Wenn ich jetzt das Modell benutze, dann bräuchte ich eigentlich in der Form.
Und wenn ich das in das Modell, was morgen erscheint, dann bräuchte ich es wieder anders.
Weil sonst ist sozusagen der Benchmark mit dem Modell super, der Benchmark mit dem nächsten Modell geht in den Keller.
Das will ich halt auch nicht.
Deswegen geht, glaube ich, immer mehr sozusagen.
Benchmarks und Evaluations, ja.
Brauche ich eigentlich Benchmarks und Evaluations, wenn du sowas machen willst.
Und das ist halt, das erzeugt natürlich auch einen großen Aufwand.
Und dann natürlich die Sachen auch sozusagen entsprechend zu testen und zu pflegen.
Deswegen bin ich mir nicht sicher, ob das ein guter Ansatz ist oder ob du eigentlich ein bisschen darauf vertrauen musst, dass die LLMs in Zukunft immer besser werden damit.
Und du quasi deine Meinung oder das, was für dich sozusagen wichtig ist, zu denen du es dann immer mit auf den Weg geben musst im Sinne von, das sind hier meine 20 Guidelines, die berücksichtige ich mal.
Weil du natürlich auch das Problem hast, dass, ja, ich kann jetzt, was weiß ich, die Dokumentation in einer bestimmten Art und Weise auch polieren.
Aber in der Dokumentation steht zum Beispiel nicht drin, da gibt es natürlich drin, du kannst jetzt eine Passwortabfrage in fünf verschiedenen Arten machen, kannst mit so, so oder so.
Aber da steht erstmal nicht drin, welche soll ich denn davon jetzt nehmen.
Das ist vielleicht deine Meinung, nimm mal A.
Meine Meinung ist vielleicht, nimm mal C.
Deswegen könntest du diese Hilfestellung für das LLM dann eigentlich gar nicht wirklich in die Dokumentation gut reinpacken, weil du eigentlich in der Dokumentation die Option haben willst.
Und dann müsstest du eigentlich, dass man das LLM diese Option quasi abfragt beim Benutzer, welche Variante hättest du denn gerne, was ist denn dein Geschmäckle heute?
Lieber hier oder lieber da?
Oder im Unternehmen, ich solche Ahnenssätze habe oder irgendwas.
Deswegen ist das, glaube ich, keine trivial zu beantwortende Frage, wie ich die Dokumentation gut für ein LLM aufbereite, die dann für ein sehr breites Publikum funktioniert.
Und ein sehr breites Publikum mit sehr breiten Modellen.
Es ist vielleicht noch was anderes, wenn ich jetzt sage, ich habe die Dokumentation für meine Bibliothek in meinem Unternehmen, ich möchte, dass das alles homogen ist, ich möchte es eher gleichförmig haben.
Die Projekte, die bei mir gemacht werden, die sollen allen bestimmten Regeln folgen.
Da kann ich mir das total gut vorstellen, wie man das machen kann.
Wobei da das mit den Modellen natürlich auch wieder, da bräuchte ich eigentlich auch Benchmarking gegen die verschiedenen Modelle.
Und zu checken, ist das denn auch wirklich so, spucken die wirklich das aus, was ich jetzt ungefähr beabsichtigt habe.
Wobei da immer mitschwingt, dass natürlich es den Leuten auch wichtig ist, was dabei rauskommt.
Womit wir wieder ein bisschen bei unserer Anfangsthese sind.
Oder ist eigentlich egal, hauptsache es läuft.
Ja, es kommt halt wieder darauf an, was für Software man erzeugt.
Und jetzt ist mir gerade so das Licht aufgegangen, dass wenn du ja Software-Tools erstellst, dann bist du ja Cutting-Edge.
Also die Leute, die es verwenden, die können davon ausgehen, dass die Dokumentation noch nicht in den Trainingsdaten drin ist.
Ich bin ja immer meistens so, dass ich sage, naja, ich frage die KI, welche Version kennst du?
Ja, okay, dann nehmen wir die, noch Security-Fixes drauf.
Aber da hast du ja dann eben nochmal das spezielle Problem und auch den Frust der Anwender, die merken, Mensch, die KI macht mir hier alles kaputt, weil die kennt nicht die aktuelle Version, die ich gerade einsetze.
Die benutzt irgendwie die Schnittstellen der alten Version, die die aufrufe, die Signaturen.
Und hast du da eine gute Lösung?
Dokumentations-MCP-Server oder was ist da State-of-the-Art?
Was wir machen tatsächlich und womit wir auch experimentiert haben mit verschiedenen Sachen ist das eine, was wir jetzt schon tatsächlich eingebaut haben in die Spring-Tools, ist eine MCP-Server.
Das heißt, man kann immer, wenn man eine Language-Server hat, das heißt, man benutzt den Cloud-Code oder eine IDE, wenn man sozusagen eine AI-Assistant hat, in irgendeiner Form kann man die damit verbinden.
Und der MCP-Server sorgt dann zum Beispiel dafür, dass der AI-Assistant immer weiß, was ist die neueste Patch-Version davon, wo läuft irgendwas aus dem Support raus und ähnliches.
Wir haben uns auch mit der Frage beschäftigt, jetzt gibt es eine neue Version von der Bibliothek, die hat das LLM natürlich nie gesehen in den Trainingsdaten.
Woher soll es denn wissen, wie ich jetzt API-Versioning baue mit Spring Framework 7?
Das gab es halt früher nicht, das Feature.
Da fangen jetzt die LLMs natürlich an zu sagen, ja, API-Versioning, das baut man doch immer so und so.
Und dann machen die das halt und benutzen eigentlich gar nicht das Feature.
Oder benutzen es irgendwie wir oder sind irritiert davon.
Wir haben experimentiert damit zu sagen, okay, wenn du jetzt eine bestimmte Spring-Boot-Version hast, dann gebe ich dir quasi Markdown mit, was das sozusagen beschreibt.
Also im Sinne von, hey, wenn du API-Versioning machst, dann mach das mal bitte so.
Das ist das Delta zwischen den Trainingsdaten, die es wahrscheinlich gesehen hat und dem, wie wir glauben, dass eine bestimmte Version zu benutzen ist.
Weil natürlich die nächste Frage auch ist, du hast in deinem Projektportfolio jetzt 10 Projekte, die benutzen Version A und 10 Projekte benutzen Version B von irgendeiner Bibliothek, da willst du natürlich, dass wenn du mit einem LLM da drangehst, dass es eigentlich immer passend für das Projekt-Decode erzeugt und nicht immer das Gleiche für jede Version.
Und es ist ein wahnsinniger Aufwand, diese Dokumentation so passend zu erzeugen speziell dafür.
Und auf einmal, auch gesehen, das neue Modell anfängt zu sagen, nee, ich gucke mir das gar nicht an.
Ich gucke mir einfach die Bibliothek an, ich mache mal das JAR-File auf, entpacke das mal schnell, gucke mir mal den Code an, der da drin ist, und dann sehe ich, ach, so sieht das jetzt aus.
Ja, alles klar, dann mache ich doch das jetzt stattdessen.
Und alles, was wir vorher so an Markdown reingestopft haben, brauchen wir nicht mehr.
Das ist sozusagen auch eine Weiterentwicklung von den AI-Assistants oder den LLMs, da habe ich heute auch mit den Ohren geschlackert, als Claude angefangen hat zu debuggen und irgendwas von dem.
Ja, hier im Bytecode, da steht dies und jenes.
Ich so, was machst du im Bytecode?
Nicht, dass er den noch patcht.
Also die Modelle entwickeln sich weiter.
Das ist auf jeden Fall spannend.
Aber ich meine, mit diesen Ansätzen versucht ihr ja den Frust der Entwickler mit der KI zu lindern.
Und ich finde, das ist eigentlich ein guter Punkt.
Ja, wir sind jetzt auch schon am Ende der Zeit angekommen.
Oh, wow.
Ja, die Zeit ist so geflogen.
Also ich fand es super spannend.
Wir haben ganz, ganz viele Punkte angesprochen, viele Aspekte.
Ich hoffe, dass jeder irgendwie was für sich mitgenommen hat.
Ich finde es vor allem wichtig, dass man das Thema auf den Tisch bringt und jeder merkt, er steht nicht allein damit da.
Dass wenn er acht Stunden die KI benutzt und nach Hause geht, den Rechner ausmacht und merkt irgendwie, das war jetzt heftig, dass wir das Thema irgendwo als Industrie auch angehen und darüber sprechen.
Auf jeden Fall.
Vielen Dank für die Einladung.
Ja, schön, dass du da warst.
Hat sehr viel Spaß gemacht.
Gleichfalls.
Dann schönes Wochenende allen.
Vielen Dank für die Fragen und komm auch gerne auf uns zu.