Neue GitHub-Copilot-Studie entdeckt „Abwärtsdruck auf die Codequalität“

 (visualstudiomagazine.com)
1 Punkte von GN⁺ 2024-01-29 | 1 Kommentare | Auf WhatsApp teilen
  • Das Whitepaper Coding on Copilot von GitClear analysiert anhand von Code-Änderungsdaten, ob KI-unterstützter Code zwar die Produktivität steigert, dafür aber Qualität und Wartbarkeit belastet
  • Code Churn, also Code, der innerhalb von zwei Wochen nach dem Schreiben zurückgesetzt oder geändert wird, wird 2024 voraussichtlich doppelt so hoch sein wie die Basislinie aus der Zeit vor KI im Jahr 2021
  • Seit der Verbreitung von Copilot ist der Anteil an hinzugefügtem Code und Copy-and-paste-Code gestiegen, während der Rückgang von verschobenem Code auf eine Schwächung von Refactoring und Wiederverwendung hindeutet
  • GitHubs Studie aus dem Jahr 2022 kam zu dem Ergebnis, dass Copilot-Nutzer Aufgaben 55 % schneller abschlossen, GitClear konzentriert sich jedoch stärker auf langfristige Wartungskosten als auf Produktivität
  • Die Analyse von 153 Millionen Zeilen geänderten Codes, geschrieben zwischen Januar 2020 und Dezember 2023, zeigt, dass technische Führungskräfte die Auswirkungen der KI-Einführung anhand von Kennzahlen zur Codequalität prüfen sollten

Wie das GitClear-Whitepaper KI-unterstützten Code einordnet

  • Das Whitepaper Coding on Copilot untersucht, welche Unterschiede KI-unterstützter Code bei Qualität und Wartbarkeit im Vergleich zu Code aufweist, den Menschen geschrieben hätten
  • Die zentrale Frage lautet, ob KI-unterstützter Code eher dem Beitrag eines sorgfältig arbeitenden Senior-Entwicklers ähnelt oder eher der bruchstückhaften Arbeit eines kurzfristigen Auftragnehmers
  • GitClear ist ein Unternehmen, das ein Cloud-basiertes Code-Review-Tool verkauft, und die Studie konzentriert sich darauf, wie sich die Zusammensetzung von Code-Änderungen nach der Nutzung von KI verändert

Negative Signale bei der Wartbarkeit

  • GitClear fand besorgniserregende Trends mit Blick auf die Wartbarkeit
  • Code Churn ist der Anteil von Codezeilen, die innerhalb von zwei Wochen nach dem Schreiben zurückgesetzt oder aktualisiert werden
    • Dieser Anteil wird 2024 im Vergleich zur Basislinie aus der Zeit vor KI im Jahr 2021 voraussichtlich doppelt so hoch sein
  • Der Anteil an hinzugefügtem Code und Copy-and-paste-Code steigt im Verhältnis zu geändertem, gelöschtem und verschobenem Code
  • Aufgrund dieser Veränderungen wird KI-generierter Code mit Gelegenheitsbeitragenden verglichen, die dazu neigen, gegen das DRY-Prinzip des jeweiligen Repositories zu verstoßen

Drei Veränderungen im Zusammenhang mit der Verbreitung von Copilot

  • GitClear nennt nach der Einführung von Copilot Churn, verschobenen Code und Copy-and-paste-Code als wichtige Veränderungen

  • Zunehmender Churn

    • Die „Nutzung von Copilot“ stehe in starker Korrelation damit, dass fehlerhafter Code in Repositories gepusht wird
    • Das wird mit einem Muster in Verbindung gebracht, bei dem KI-unterstützter Code schnell hinzugefügt und kurz darauf wieder zurückgesetzt oder geändert wird

  • Weniger verschobener Code

    • Der Rückgang von verschobenem Code deutet auf weniger Refactoring und Wiederverwendung hin
    • Zusammen mit dem Anstieg von Copy-and-paste-Code lässt sich das so interpretieren, dass aktuelle Implementierungen von KI-Assistenten die Wiederverwendung von Code nicht ausreichend fördern
    • Statt durch Refactoring DRY-Code zu erzeugen, entsteht die Versuchung, bestehenden Code mit einem einzigen Tastendruck zu wiederholen

  • Mehr Copy-and-paste-Code

    • Copy-and-paste-Code wird als Faktor bewertet, der die langfristige Wartbarkeit stark belastet
    • Wenn sich nicht Schlüsselwörter, sondern Codezeilen wiederholen, wird das als Signal interpretiert, dass keine Zeit blieb, die frühere Implementierung zu bewerten
    • Wird Code nicht wiederverwendet, sondern erneut hinzugefügt, müssen spätere Wartende parallele Codepfade mit redundanter Funktionalität zusammenführen

Kontrast zu Produktivitätsstudien

  • GitHubs Studie aus dem Jahr 2022 kam zu dem Ergebnis, dass Entwickler mit Copilot Aufgaben 55 % schneller abschlossen als Entwickler ohne Copilot
  • Dieselbe Studie maß neben der Produktivität auch positive Effekte bei Entwicklerzufriedenheit und dem Erhalt mentaler Energie
  • Im Unterschied zu diesen Produktivitätsergebnissen konzentriert sich das Whitepaper von GitClear auf Veränderungen in der Zusammensetzung von Code-Änderungen und auf Aspekte der Wartbarkeit bei der Nutzung von KI

Widersprüchliche Bewertungen in verwandten Studien

Umfang der Analyse und offene Fragen

  • GitClear sammelte und analysierte 153 Millionen Zeilen geänderten Codes, geschrieben zwischen Januar 2020 und Dezember 2023
  • Zugleich wird diagnostiziert, dass mit dem sprunghaften Popularitätsanstieg von KI ein Zeitalter begonnen hat, in dem Codezeilen schneller denn je hinzugefügt werden
  • Die Frage für 2024 ist weniger, wie Copilot die Bedeutung von Entwicklern verändert, sondern eher, wer die anschließende Aufräumarbeit übernimmt

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-01-29
Hacker-News-Kommentare

  • Nach 2 Monaten habe ich das Abo gekündigt. Die mentale Belastung, die Fehler in der Flut aus Code-Erbrochenem zu beheben, war zu groß, und bei nicht trivialen Aufgaben oder Aufgaben rund um SQL war es fast nutzlos, selbst wenn ich vorher das gesamte Schema hineingab.
    Da ich wusste, was ich schreiben wollte, war es viel weniger anstrengend, es direkt selbst zu schreiben, und es war einfacher, meine eigenen Fehler zu beheben als die des Bots. Ich mache mir Sorgen um Juniors, die unter diesem Müll begraben werden.

    • Wenn das stimmt, bin ich froh, denn es bedeutet, dass ich wirtschaftlich noch nützlich bin.
      Ich nutze ChatGPT statt Copilot, und es ist erstaunlich, was es alles kann, aber trotzdem würde ich es kaum als „guten Code“ bezeichnen. JavaScript kann ich zwar lesen, aber weil ich mich in den letzten 14 Jahren auf iOS spezialisiert habe und die Best Practices im Browser-Bereich nicht gut kenne, nutze ich es dafür. Selbst wenn ich Code bekomme, der im Großen und Ganzen funktioniert, sehe ich schlechte Entscheidungen oder Merkwürdigkeiten.
      Ich denke, bei aktueller AI ist die richtige Haltung, die beiden Extreme „es ist schon vorbei“ und „es ist gar nichts“ zu vermeiden. Für Letztere braucht es eine Analogie wie: „Der Hund jongliert, macht die Steuererklärung und backt einen Kuchen, aber statt darüber zu staunen, dass er das kann, beschwert man sich, dass er einen Ball fallen lässt, Zahlen falsch einträgt und das Rezept nicht besonders gut ist.“
    • Wie bei den meisten Dingen im Leben ist Maßhalten entscheidend.
      Copilot ist am nützlichsten als Autovervollständigungs-Tool, das beim Schreiben von vorhersagbarem, kontextbasiertem Code Tipparbeit spart. Wenn man in einem Fenster eine enum class schreibt, kann es die Verwendungsstellen in einem anderen Fenster anhand des Kontexts autovervollständigen, und beim Schreiben einer Reihe von Unit-Tests erzeugt ein Druck auf Tab das Gerüst für den nächsten Testfall.
      Besonders in dynamischen Sprachen ergänzt Copilot IntelliSense ziemlich gut.
    • Die wirkliche Gefahr entsteht in dem Moment, in dem solche Tools aus rein wirtschaftlichen Gründen „gut genug“ werden, um etwas deutlich Besseres zu ersetzen.
      Vor ein paar Monaten habe ich mit Beispielen aus Schriftsatz, Buchbinderei und Notensatz darüber geschrieben, dass die Voice-Acting-Branche zwangsläufig von Text-to-Speech-Modellen verdrängt werden könnte: https://news.ycombinator.com/item?id=38491203
      Wenn aber die Entwicklung selbst auf diese Weise ausgehöhlt wird, weiß ich nicht recht, wie der Endzustand aussieht. Denn es waren Entwickler, die auch frühere Ersetzungen vorangetrieben haben. Irgendeine Form von gesellschaftlichem Niedergang und Zusammenbruch wirkt nicht völlig abwegig.
    • Meine Erfahrung ist genau das Gegenteil. Copilot hat mir fast all die lästige, langweilige Arbeit abgenommen, besonders einfache SQL-Queries.
      „Parse dieses JSON und schreibe die entsprechenden Felder an die richtige Stelle in der Datenbank“ ist ein hervorragender Use Case, um mit Copilot SQL zu schreiben. Man könnte auch ein ORM-Plugin oder Middleware verwenden, aber für ein MVP oder ein Mockup wäre das übertriebene Voraboptimierung.
    • Als ich Tools der Codepilot-Art ausprobiert habe, war ich nicht besonders beeindruckt. Ich dachte, das liege daran, dass ich mir nicht die Zeit genommen hatte, zu lernen, wie man sie richtig nutzt, aber vielleicht sind sie einfach nicht besonders gut.
      Die ChatGPT API nutze ich dagegen häufig und finde sie ziemlich praktisch. Als ich ein SQL-Update schrieb, das Millionen von Zeilen betrifft, bat ich sie, es in Batches aufzuteilen und nach jedem Batch Statuslogs auszugeben. Und als ich beim Zugriff auf einen nuget feed in Azure DevOps einen 401 bekam, lieferte sie nicht nur die Ursache, sondern auch das yaml zur Behebung.
      Beides sind Dinge, die ich mit etwas Recherche auch selbst hinbekommen hätte, aber dass ich diese Recherchezeit nicht aufwenden muss, ist wirklich angenehm.

  • Dank GPT-4 ist meine Arbeitseffizienz stark gestiegen. Ich erstelle hauptsächlich einfache PHP-CRUD-Apps, die Probleme im Arbeitsalltag lösen, und weil ich keine Frameworks oder MVC-Strukturen verwende, ist der von GPT-4 auf Basis klarer Anweisungen generierte Code leicht zu verstehen und funktioniert meistens sofort.
    Meistens bitte ich darum, etwa 25 Zeilen Code so zu ändern, dass eine bestimmte Reporting-Funktion passt. Wenn ich zum Beispiel sage, diese Seite solle nach X gruppieren und Y aufsummieren, reagiert es genau richtig. Danach noch schnelles QA und Tests, und fertig. Bei Aufgaben mit geringer Komplexität und klaren Anweisungen ist es ein echter Gamechanger.
    Der Prozess ähnelt der Arbeitsweise, bei der ein Senior-Programmierer eine Aufgabe in Grundbausteine zerlegt und sie einem Junior übergibt. Hier übernimmt GPT-4 die Rolle eines Junior-Programmierers für 20 Dollar im Monat, und weil es mir Zeit spart, zahle ich das gern aus eigener Tasche.
    Allerdings verstehe ich jetzt, ähnlich wie bei der kindlichen Frage, warum man Mathe lernen soll, wenn es doch Taschenrechner gibt, warum man die Grundlagen lernen muss. Ohne Grundlagen kann man es nicht effektiv nutzen. Wenn es GPT-4 schon gegeben hätte, als ich PHP gelernt habe, hätte ich die Grundlagen heute nicht so gut verstanden. Ich profitiere davon, sie gelernt zu haben, bevor es dieses Tool gab.
    Auch die Codequalität fühlt sich für mich nicht wirklich niedriger an; manchmal liefert es sogar besser ausgearbeitete Ergebnisse.

    • In vielen Fällen wirkt die Codequalität besser, aber es gibt mehr subtile Bugs, als ich selbst vermutlich eingebaut hätte.
      Ich halte einen großen Teil der Kritik für verfrüht und sehe eher einen holprigen Fortschritt, der zusätzliche Infrastrukturunterstützung braucht. Wo ist die Linter-Integration, die verhindert, dass nicht kompilierbare Ergebnisse ausgegeben werden, und wo sind Funktionen, die einfache Fehler automatisch finden und beheben?
      Offen ist auch, wie Tests in einer Entwicklungsumgebung mit generativer AI aussehen und sich verändern sollten. Vielleicht gibt es bessere Wege, die Vorteile prozeduraler Ansätze wie TDD oder BDD zu maximieren und gleichzeitig ihre Kosten zu senken.
      Die letzten ein bis zwei Jahre waren eine Phase, in der eine große technische Veränderung einfach in bestehende Workflows hineingeworfen wurde. Bei jedem Tool entsteht das Ergebnis aus der Kombination der Fähigkeiten des Tools selbst und der Erfahrung der Person, die es nutzt.
      Die Branche muss noch deutlich mehr Erfahrung und Know-how bei der Integration von generativer AI in die Entwicklung sammeln, bevor wir den tatsächlichen Nettowert einschätzen können. Ich denke, es braucht mindestens noch 2 bis 3 Jahre, nicht wegen der technischen Anpassung, sondern wegen der Zeit, die Menschen zur Anpassung brauchen.
    • Ich bin froh, dass ChatGPT erst spät in unserer Karriere aufgetaucht ist. Wir konnten lernen, ohne in unserer Prägungsphase mit automatisch generiertem Code konkurrieren zu müssen.
    • Das gilt für dich, aber das neue Coding-Paradigma, das auf uns zukommt, birgt die Gefahr, dass es Komponenten gar nicht mehr zerlegt, sondern nach dem Muster „Code generieren, testen, scheitern, neu generieren, testen …“ funktioniert.
      Ich habe bereits gesehen, wie ein Team aus Zwanzigjährigen auf meinem grundlegenden CRUD-Framework Berge von Full-Stack-Spaghetti generiert hat. Wenn man in 60 Sekunden ein „MMO framework“ generieren kann, sinkt der Anreiz, eine TODO-App von Grund auf selbst zu bauen.
      Das erinnert daran, wie ich vor 12 Jahren zuerst Firebase nutzte, bevor ich relationale Grundlagen lernte, und dann Jahre brauchte, um bei den Grundlagen anzukommen.
    • Mich würde interessieren, wie du interagierst. Fügst du Codeblöcke in den Chat ein, beschreibst du den neu zu schreibenden Code und lässt ihn anhand von Feedback überarbeiten, oder machst du es anders?

  • Man kann die Zukunft nicht exakt vorhersehen, aber ich glaube, dass sich die Art, wie wir Qualität wahrnehmen, verändern wird.
    Es gibt eine Stimmung, als würde Technologie in allen Bereichen um uns herum – Elektroautos, Medizin, IT, Finanzen usw. – zum Retter für wichtige Probleme werden. Gleichzeitig wird immer deutlicher, dass Technologie vor allem dazu dient, Märkte, Regierungen, Staaten usw. wachsen zu lassen, und dass sie funktioniert, indem sie auf bereits undichten Abstraktionen noch eine weitere Schicht aufsetzt. Es fühlt sich eher so an, als würden Symptome aufgeweicht, statt Probleme gelöst.
    Qualität umfasst Langsamkeit, und diese Langsamkeit wird nötig werden, weil Symptomtherapie Grenzen hat und Menschen Herausforderungen nicht bewältigen können, indem sie immer mehr Abstraktionen übereinanderschichten.
    Ich halte die Vorstellung, dass wir schneller werden müssen, für falsch. Ich glaube nicht, dass Qualität entsteht, wenn man als Mensch die Grundlagen der Herausforderung nicht versteht und versucht, sie zugunsten oberflächlicher Gewinne zu lösen.
    LLMs sind eine Katastrophe für unsere Branche. Denn sie bedienen den Fehler des durchschnittlichen Menschen, ans Ziel kommen zu wollen, ohne echte Arbeit zu leisten. Echte Arbeit besteht darin, Annahmen über Korrektheit anzuwenden und zu verstehen, was man eigentlich wirklich zu lösen versucht.
    Glücklicherweise wollen nicht alle schneller werden; manche lernen die Grundlagen neu, treffen sorgfältige Entscheidungen und schärfen ihr Denken und ihre Werkzeuge, um Qualität zu schaffen, die lange Bestand hat.

    • Ich frage mich, in welchem Ausmaß du glaubst, dass LLMs das „Verstehen dessen, was man eigentlich wirklich zu lösen versucht“ behindern.
      Meine Erfahrung ist eher das Gegenteil. Statt dass das Durchforsten unordentlicher APIs oder Libraries den schwierigen Teil blockiert, machen LLMs schmerzhaft deutlich, wenn mein Denken bei sinnvoller Arbeit nicht solide ist.
      Um mit einem LLM etwas zu tun, muss man schreiben, und um zu schreiben, muss man denken. Oft ist es am nützlichsten, dass ich sorgfältig in Worte fasse, was ich tun möchte, vom LLM angestoßen werde und dabei Lücken in meinem Denken finde und kläre – und dass ich den Chatverlauf später erneut ansehen kann.
      Besonders in der frühen Phase einer App, wenn ihre Form entsteht, ist es sehr nützlich, nachzuverfolgen, was ich damals für nötig hielt, und später erneut zu prüfen, ob das immer noch gilt.
    • Der große Jazzpianist Bill Evans sagte in einem Interview mit seinem Bruder, ein häufiger Fehler von Amateurmusikern sei es, zu viel zu spielen.
      Sie hören in einem Club einen Profi spielen und gehen nach Hause, um es nachzuahmen, doch am Ende wird es ein chaotischer Haufen ohne Fundament. Er betonte, man müsse damit zufrieden sein, einfache Dinge zu tun, und schrittweise ein stärkeres Fundament aufbauen.
      Diese Einsicht lässt sich nahezu unverändert auf die Nutzung von KI-generiertem Code übertragen.
    • Man kann die Zukunft nicht exakt vorhersehen, aber ich glaube, dass sich die Art, wie wir Qualität wahrnehmen, verändern wird.
      IKEA-Möbel sind ein gutes Beispiel. Wenn man Möbel selbst baut, fühlt es sich in ihrer Umgebung viel besser an als bei diesem pappartigen Zeug von IKEA. In den Köpfen der Menschen scheinen jedoch Kosten, Geschwindigkeit und Bequemlichkeit am wichtigsten zu sein.
    • Der Sinn, ein Kunstwerk zu schaffen, entsteht zusammen mit der Geschichte des Künstlers: dem Ringen bis zur endgültigen Form, der geistigen Erfahrung und dem kreativen Ausdruck.
      KI-Modelle nehmen diese angeborene Erfahrung weg und liefern nur die Sahne des Endergebnisses. Es ist ähnlich, als würde man Pornografie schauen, statt eine echte Beziehung einzugehen und zum Sex zu kommen.
    • LLMs sind Werkzeuge. Es ergibt keinen Sinn, dem Werkzeug die Schuld zu geben. Man kann einem Schraubendreher nicht die Schuld geben, weil er als Hammer oder als Mordwerkzeug benutzt wurde.
      Intelligent eingesetzt sind Copilot-ähnliche Tools hilfreich. Sie übernehmen Boilerplate und langweilige Teile, sodass Menschen sich auf das schwere Denken konzentrieren können.
      Außerdem stehen wir noch am Anfang. Für ein Urteil ist es zu früh, und es sieht auch nicht so aus, als würden sie verschwinden.

  • Die Methodik scheint die Commit-Aktivität von 2023 mit früheren Jahren zu vergleichen und Veränderungen als Annahme zu interpretieren, ohne zu wissen, wie stark Copilot daran beteiligt war. Das ist ein ziemlich wackliger Ansatz.
    Außerdem heißt es, „die Prognose für 2024 wurde erstellt, indem mit OpenAIs gpt-4-1106-preview Assistant eine quadratische Regression auf den vorhandenen Daten ausgeführt wurde“. Ich frage mich, ob sie GPT statt eines einfachen Regressionstools wie sklearn, R oder Excel eine Regression mit vier Datenpunkten haben machen lassen. Selbst wenn es korrekt gemacht wurde: Bei vier Datenpunkten und unter Berücksichtigung der ersten Sorge ist die Aussagekraft schwach.

    • Wenn man nicht nur die Zusammenfassung liest, sondern das Paper anschaut, wird die Methodik erklärt. Dass die Ausgabe vier Datenpunkte sind, liegt daran, dass es eine Zusammenfassung ist; die Eingabe umfasst deutlich mehr Daten.
    • Nicht einmal das. Der im Anhang gezeigte Prompt lautet sinngemäß: „Wenn man nur 2022 und 2023 betrachtet, was würde eine quadratische Regression für 2024 vorhersagen?“
      Quadratische Regression klingt plausibel, aber bei zwei Datenpunkten ist es im Grunde nur „die Linie weiter verlängern“. Deshalb ist die Prognose für 2024 im Wesentlichen nahezu bedeutungslos.
    • Ich habe Ähnliches anekdotisch beobachtet und kann die Forschungsergebnisse nachvollziehen, aber es ist schwer zu sagen, dass die Daten die Schlussfolgerung stützen. Es könnte auch am Einstellungsboom während der Corona-Zeit und den anschließenden Entlassungen liegen.

  • Ich bin der Autor der ursprünglichen Studie. Es freut mich zu sehen, dass sich viele Menschen Gedanken über die langfristige Codequalität machen. Dass 2023 churned code und Duplikate, also Copy-and-paste-Code, zunahmen und moved code zurückging, war sogar stärker, als wir erwartet hatten.
    Ich hoffe, dass Entwicklungsteams und Hersteller von AI Assistants Metriken und Anreize einführen, die wiederverwendeten Code gegenüber neu hinzugefügtem Code fördern. Besonders gefährdet sind Teams unter Managern, die glauben, LoC müssten in die Leistungsbewertung einfließen. Laut einer GitHub-Studie trifft das auf etwa ein Drittel zu, und die aktuelle Generation von Coding-Assistants macht es viel zu einfach, Tab zu drücken, zu committen und damit künftige technische Schulden zu säen. Wie Adam Tornhill auf Twitter sagte: „Die zentrale Herausforderung von KI-gestützter Programmierung ist, dass es zu einfach wird, massenhaft Code zu erzeugen, den man von vornherein nicht hätte schreiben sollen.“
    Allerdings ist die Aussagekraft der aktuellen Studie dadurch begrenzt, dass sie von KI geschriebenen Code nicht direkt misst. Wir haben lediglich die Korrelation zwischen Codequalität und der Verbreitung von AI Assistants in den vergangenen vier Jahren aufgezeichnet. Es wäre gut, wenn GitHub oder andere AI-Assistant-Unternehmen bei Folgestudien mitarbeiten könnten, um die Qualitätsunterschiede zwischen „vollständig von KI vorgeschlagenem Code“, „von Menschen bearbeitetem KI-Vorschlag“ und „von Grund auf geschriebenem Code“ direkt zu messen.
    In der nächsten Studie möchte ich auch direkt messen, wie sich die Fehlerhäufigkeit je nach KI-Nutzung verändert. Wenn ihr weitere Ideen habt, was sich sinnvoll messen ließe, schlagt sie bitte vor. Ich versuche, etwa alle zwei Monate ein neues Forschungspaper zu veröffentlichen.

    • Die Idee, wiederverwendeten Code statt neu hinzugefügten Code zu fördern, wirkt wie der Austausch einer dummen Kennzahl durch eine andere.
      Code-Wiederverwendung kann innerhalb einer Codebasis mächtig sein, aber ich habe auch gesehen, dass sie über Codebasen hinweg Verwirrung stiftet. Sie kann nützlich sein, aber auch unpassend und verwirrend; das Ergebnis hängt meist vom Urteilsvermögen ab.
      Ich denke, es ist besser, Entwickler anhand der Ergebnisse der Software zu bewerten. Zum Beispiel nach organisatorischer Wirkung im Verhältnis zum Ressourceneinsatz oder nach Servicefehlern, die nicht aus abhängigen Diensten oder Infrastruktur abgeleitet sind.
      Der moderne Programmierer ist nicht mehr nur für Code verantwortlich, sondern eine bewusst vermischte Rolle aus Quality Engineer/Tester, technischem Produktmanager, Projektmanager, Programmierer, Performance Engineer und Infrastructure Engineer. Ich will die Studie selbst nicht schlechtreden; ich freue mich, dass es Menschen gibt, denen Codequalität wirklich wichtig ist, und denke, dass wir anders über Bewertungsmethoden nachdenken sollten.
    • Wenn von KI geschriebener Code nicht direkt gemessen wurde, wäre der genauere Titel wohl eher „Neue Studie zeigt, dass die Codequalität in den vergangenen vier Jahren gesunken ist“.
      Ich frage mich auch, ob andere mögliche Erklärungen wie die veränderte Tech-Ökonomie kontrolliert wurden.
    • Im Paper „Refactoring vs Refuctoring“ gibt es tatsächliche AI-Benchmarking-Daten: https://codescene.com/hubfs/whitepapers/Refactoring-vs-Refuc...
      Das Paper benchmarkte die Leistung der beliebtesten LLMs bei Refactoring-Aufgaben an echtem Code und kommt zu dem Ergebnis, dass KI nur in 37 % der Fälle funktional korrektes Refactoring lieferte.
      KI-gestütztes Coding ist tatsächlich nützlich, aber man muss erfahrene Menschen weiter in der Schleife halten und realistische Erwartungen jenseits des Marketing-Hypes setzen.

  • Mein Workflow sieht normalerweise so aus: Dokumentation überfliegen, einen Prototyp bauen, den Code etwas aufräumen, Tests hinzufügen, Dinge verschieben, etwas kaputtmachen, erneut daran arbeiten, die Dokumentation studieren, weiter refactoren, und erst dann verstehe ich das Problem gut genug, um 80 % des Codes zu entfernen und ihn richtig neu zu bauen.
    Wenn Copilot mir in der Prototyping-Phase Code gibt, der ausreichend funktioniert, sodass ich einfach weitermache, vertieft sich mein Verständnis nicht genug, um das Ganze korrekt zu strukturieren. Es lässt mich 90 % des Workflows überspringen, aber das hat seinen Preis. Natürlich kann Copilot in der letzten Phase der Entwicklung sehr hilfreich sein.
    Wenn die Studienergebnisse stimmen, überrascht mich das nicht. Schlechter Code entsteht aus mangelndem Verständnis, und Copilot kann kein Verständnis haben, das über das hinausgeht, was ich ihm liefere. Es kann zwar besseren Code schreiben als der durchschnittliche Programmierer, aber das Ergebnis kann nicht besser sein als der Input. Wenn sich alle so sehr auf „Prompt Engineering“ konzentrieren, verstehe ich nicht, warum sie überrascht sind, dass der schlechte „Prompt“ von VSCode schlechte Ergebnisse liefert.

    • Ich verstehe nicht, warum der Einsatz von Copilot bedeuten soll, die meisten der späteren Schritte zu überspringen. Am Ende entscheidest doch du selbst, diese Schritte auszulassen, oder?
      Meiner Erfahrung nach ist Copilot hervorragend darin, den Einstieg zu erleichtern. Der Code ist manchmal gut, manchmal mittelmäßig oder komplett kaputt.
      Trotzdem ist es wertvoll, weil es einen ins Denken bringt. Vorher habe ich viel mehr Zeit verschwendet. Vielleicht liegt das auch an meinen etwas ungewöhnlichen Gehirnschaltkreisen.

  • Ich bin Junior und habe Codeium in VSCode installiert, aber in den meisten Fällen ist es extrem ablenkend. Ich verstehe nicht so recht, warum so viele Leute solche Assistenztools verwenden.
    Dinge wie Phind sind nützlich. Wenn etwas passiert, das ich nicht verstehe, hilft es mir in etwa 60 % der Fälle, das Problem zu begreifen. Zum Beispiel findet es kleine Bugs, die ich übersehen habe, weil ich müde war oder mich dumm angestellt habe.
    Codeium dagegen kann vielleicht nützlich sein, wenn man Boilerplate für Frameworks ausspuckt. Aber bei meiner kleinen Erfahrung mit Scrapern, einfachen Daten-Pipelines und reinem JS+HTML/CSS ist es extrem nervig, sich durch Vorschläge zu klicken. Vor allem funktionieren sie oft nicht, und selbst wenn es nur Kleinigkeiten sind, etwa ein fehlendes Argument, muss man am Ende doch Zeit ins Debugging stecken.
    Außerdem gibt es in JavaScript diesen verbreiteten Stil, Methoden und anonyme Funktionen endlos wie eine Daisy Chain aneinanderzuhängen, und das fällt mir wirklich schwer. Ich bevorzuge es, Zeilen aufzuteilen und Funktionen sowie Variablen Namen zu geben. Codevorschläge folgen häufig ebenfalls diesem Stil; vermutlich liegt das an den Trainingsdaten. Codeium sagt zwar, dass es daraus lernt, und manchmal tut es das tatsächlich.
    Am meisten beunruhigt mich: Wie soll ich als Junior überhaupt lernen, wenn ich solchen Assistenztools den Code überlasse? Phind Kontext und Fragen zu geben hilft beim Lernen oder gibt mir eine Richtung, in der ich selbst im Internet weitersuchen kann. Aber ich weiß nicht, wie ich durch bloßes Drücken von Tab lernen soll.
    Vor ein paar Tagen wurde mir klar, dass viele Menschen, Entwickler eingeschlossen, LLMs nicht als Werkzeug nutzen, um besser zu werden, sondern als Ersatz für Anstrengung. Ich frage mich, ob das nicht auch aus Sicht der Selbstreflexion beängstigend ist, nicht nur wegen der Angst, von Firmen ersetzt zu werden.
    Coding ist nicht meine Lebensleidenschaft, aber ich mag es. Weil es einem ermöglicht, Dinge geschehen zu lassen und mit Komplexität umzugehen. Wenn man nicht versteht, was passiert, kann man weder etwas bauen noch erkennen, wann die Komplexität einen auffrisst.

    • Coding mag vielleicht nicht deine Lebensleidenschaft sein, aber ich habe in letzter Zeit kaum jemanden gesehen, der so gut ausdrückt, was er vom Programmieren haben will und wie er Tools bewertet.
      Mach genau so weiter und ändere das nicht, dann wirst du an einen guten Ort kommen. Du bist ganz klar auf dem richtigen Weg.
    • Am besten habe ich AI bisher eingesetzt, als ich sie anhand eines Controllers eine OpenAPI-Spezifikation erzeugen ließ. Sie war fast korrekt, ich musste nur einige Modelle an die Realität anpassen.
      Entscheidend war, dass ich in meiner Karriere schon so viele API-Spezifikationen von Hand geschrieben habe, dass ich 1) die Probleme sofort sehen und 2) sie ohne zusätzliche Hilfe beheben konnte. Die Modelle von Hand zu korrigieren war schneller, als den Prompt zu verfeinern.
      In einem Bereich, den man gut kennt, ist es erstaunlich zu sehen, wie etwas, das sonst den ganzen Vormittag gedauert hätte, in 30 Sekunden erledigt wird. Allerdings lasse ich AI nichts tun, was ich selbst nicht kann. Stattdessen spreche ich viel mit der AI über Trade-offs, potenzielle Sicherheitsprobleme usw. bei dem, woran ich gerade arbeite.
      Es fühlt sich an wie ein Junior Engineer mit einem Doktortitel in der Sprache, die ich benutze. Er versteht vieles nicht, aber das, was er versteht, scheint er tief zu verstehen.
    • Was diesen JavaScript-Stil angeht: Du bist auf dem richtigen Weg.
      Manche Entwickler, besonders JS-Entwickler, lieben Chaining, obwohl es keinen Vorteil hat, außer dass alles in einer Zeile bleibt. Das ist kein Vorteil. Mach weiter wie bisher und lass dir dieses dumme Idiom nicht den Kopf infizieren.
    • Codeium kenne ich nicht gut, aber es könnte sich lohnen, Copilot in einer reiferen Codebase auszuprobieren, in der dein eigener Strukturierungsstil klar erkennbar ist.
      Der magische Moment bei dieser Technik ist, wenn sie meinen Stil und meine Präferenzen trifft: Sie benennt Dinge so, wie ich es möchte, und nutzt die Methode, die ich gerade geschrieben habe, korrekt, statt sie erneut zu implementieren.
      In leeren oder kleinen Projekten habe ich es kaum genutzt, aber wenn es sich nicht stark an der umgebenden Umgebung orientiert und an der Art, wie ich ohnehin schon arbeite, würde es sich vermutlich viel weniger ideal anfühlen.
    • Tools und Tool-Design sind sehr wichtig. Ich habe Codeium in VSCode und GitHub Copilot in IntelliJ verwendet, und die Erfahrung sowie die Qualität der Kombination GitHub Copilot + IntelliJ waren deutlich besser als Codeium + VSCode.
      Der größte Nutzen von AI-Assistenten lag für mich beim Schreiben von Tests und beim schnellen Durchführen von wiederholten Änderungen nach dem Muster „so ähnlich wie das hier, aber etwas anders“. In IntelliJ + GitHub reicht es bei Aufgaben, bei denen ein neuer Parameter über mehrere Methoden und Dateien hinweg berücksichtigt werden muss, meist, die ersten zwei oder drei Varianten selbst einzugeben; danach geht der Rest normalerweise mit Enter + Tab. Der Kontext füllt den Rest aus.
      Codeium in VSCode wirkt sowohl als AI selbst weniger ausreichend, als auch das Plugin scheint so geschrieben zu sein, dass Vorschläge und Annahme-Tasten häufig im Weg sind. Für wiederholte Arbeit hilft es immer noch, aber weniger dabei, einen Weg zum Ziel vorzuschlagen.

  • Ich habe beschlossen, mit ChatGPT einen Yourls-Klon auf Basis von Django/Python zu bauen. Ich habe ausdrücklich angewiesen, benutzerdefinierte Kurz-URLs zu erlauben und auch Traffic zu tracken, aber in der Logik oder im Datenmodell wurde das nicht richtig berücksichtigt. Um es später zu korrigieren, musste ich wieder konkrete Anweisungen nachschieben.
    AI-Tools ähneln einem Junior-Entwickler, der Arbeit erledigt. Nur viel schneller.
    Wenn man nicht weiß, was man tut, beschleunigt man nur die Geschwindigkeit, mit der man Fehler macht.

    • Stimmt. Wenn man weiß, was man tut, beschleunigt es auch die Geschwindigkeit, mit der man Dinge baut.
    • „AI-Tools sind wie ein Junior-Entwickler, der Arbeit erledigt, nur viel schneller“ ist wirklich hervorragend formuliert.
      Kürzlich musste ich den Spalten-Aliases in einem SELECT-Statement den Tabellennamen als Präfix geben. Weil es dafür keine Funktion gab, habe ich ChatGPT die Schemadefinition und die Query gegeben und es gebeten, mir die etwa 40 Spalten in der Auswahlliste ausführlich hinzuschreiben.
      Ich habe über mehrere RDBMS hinweg keine gute Möglichkeit gefunden, so etwas zu automatisieren. Mit Regex oder anderer Textmanipulation wäre es zwar auch möglich gewesen, aber das Problem zu beschreiben und die gewünschte Ausgabe zu bekommen, war angenehm simpel.
      Ansonsten nutze ich LLMs wie Autocomplete. Es hat auch den Effekt, dass ich bessere Funktionsnamen vergeben muss, denn oft reicht genau diese Menge an Information aus, damit das LLM einen vernünftigen Ausgangspunkt liefert. Besonders nützlich ist das bei APIs oder Sprachen, die ich nicht oft benutzt habe, wenn das Problem, vor dem ich stehe, schon tausendfach gelöst wurde. StackOverflow nutze ich dadurch kaum noch.
      Deshalb habe ich Copilot gekauft und nutze auch ChatGPT viel. LLMs gehören für mich zusammen mit guter Autocomplete wie IntelliSense, OpenAPI-Spezifikationen oder EF/JPA-Codegenerierung, DB-Migrationen/Tabellenerstellung auf Basis von ER-Modellen, Containern und intelligenten IDEs wie JetBrains zu meinen Lieblingsdingen.
    • Ich frage mich, wie man ein Senior Developer werden soll, wenn einem ein Junior-Entwickler ständig „funktionierenden“ und „gut genug“ Code hinwirft.
      Unternehmen werden mehr Code in kürzerer Zeit wollen, und ich vermute, aus diesem Strudel werden immer weniger Menschen hervorgehen, die wirklich wissen, was sie tun.

  • Das vollständige Paper gibt es hier: https://gitclear-public.s3.us-west-2.amazonaws.com/Coding-on...

  • Schon bevor „AI“-Assistenztools auf den Markt kamen, gab es bereits Gegenwind gegen DRY-Code, und leider war das ein Trend, der sich 2019–2022, als ich Twitter nutzte, verstärkte
    Einige jüngere Entwickler haben eine sehr andere Haltung zu Code als die, die ich gelernt habe. Sie verachten die Gang of Four und Design Patterns enorm und scheinen nicht zu wissen, dass ihre Lieblings-Frameworks voll genau dieser Patterns sind. Prinzipien wie DRY und besonders SOLID werden spöttisch abgetan
    Auf Plattformen wie Twitter bekommt man umso mehr Engagement, je sarkastischer man ist und je stärker man die Gegenseite attackiert. Ein ziemlich beunruhigender Trend

    • Der Gegenwind richtet sich nicht gegen korrektes DRY, also eine Single Source of Truth, sondern gegen falsches DRY, das davon besessen ist, syntaktisch ähnlichen Code zu eliminieren
      Für das, was in Enterprise-Codebases passiert, empfinde ich ebenfalls enorme Verachtung. Egal was SOLID-Gurus sagen: Schichten über Schichten von Indirektion mit Klassen sind nicht in Ordnung. Best Practices, DRY und SOLID werden einfach als Ausrede benutzt
    • Ich bin kein junger Entwickler, aber auch ich spreche spöttisch über SOLID und DRY. Gleichzeitig ist mir Codequalität sehr wichtig
    • SOLID ist eher ein überbewerteter und übermäßig beworbener Marketingbegriff, der es irgendwie sogar in die Wissenschaft geschafft hat, und weit entfernt von den Grundlagen echter Informatik oder Softwaretechnik
      Ich kann es nicht ausstehen, wenn eine willkürliche Liste von Prinzipien aus dem Java-artigen objektorientierten Denken wie eine Wahrheit der Softwaremodellierung behandelt wird. Auch die zigste Diskussion darüber, wie SOLID zu verstehen sei, nervt
      Über das CAP-Theorem streiten die Leute nicht so, weil es eben kein willkürliches Bündel von Ideen ist, das ein hübsches Akronym ergibt
      Auch DRY kann missbraucht werden; die Gegenreaktion richtet sich nur gegen die Haltung, es als etwas Perfektes zu behandeln
    • Diese Person offenbar auch: https://twitter.com/ID_AA_Carmack/status/753745532619665408
    • Ich habe einen ähnlichen Trend gesehen. Mit der Zeit wurde mir klar, dass viele Kritiker die Prinzipien, die sie kritisieren, gar nicht richtig verstehen
      Ein wichtiges Prinzip von DRY war zum Beispiel nicht, keinen Code zu wiederholen, sondern keine Ideen zu wiederholen. Für jedes Konzept in einem System sollte es idealerweise eine Single Source of Truth geben, und beim Umgang mit diesem Konzept sollte es genau eine Stelle geben, die man verstehen oder ändern muss
      Deshalb ist es oft schlecht, statt einer sinnvollen Abstraktion nicht wenig Code einfach zu kopieren und einzufügen. Gleichzeitig ist es eine Warnung: Sobald man eine Idee wiederholt, entsteht eine dauerhafte Schuld, weil unterschiedliche Repräsentationen synchron gehalten werden müssen. Das gilt für DB-Migrationen, die ein Schema definieren, und separate ORM-Klassen, für Backend-APIs und Frontend-Clients, für Formularwerte und internen State in Retained-Mode-UIs sowie für Invarianten von Datenmodellen, die sowohl in Typen als auch in Unit-Tests ausgedrückt werden
      Leute, die einwenden, dass es später zum Wartungsrisiko wird, wenn man unterschiedliche Ideen nur deshalb zusammenzwingt, weil sie zufällig ähnliche Implementierungen haben, liegen nicht falsch. Nur greifen sie damit einen Strohmann an, der nie der eigentliche Punkt von DRY war
      Die Frage ist nun, wo und wann neue Entwickler solche Prinzipien richtig lernen. Manche haben einen entsprechenden Studienhintergrund, aber nicht alle, und akademische CS-Studiengänge müssen auch nicht unbedingt viele praktische Entwicklungstechniken vermitteln
      Als ich anfing, haben Seniors Juniors noch praktische und substanzielle Ausbildung gegeben, aber in der heutigen Kultur häufiger Jobwechsel und der Zurückhaltung, Juniors als langfristige Investition einzustellen, scheint das viel seltener geworden zu sein. Formale Kurse sind für Einzelpersonen teuer, aus Unternehmenssicht aber fast kein Kostenfaktor; trotzdem schicken Unternehmen vermutlich nur sehr wenige neue Entwickler tatsächlich dorthin
      Es gibt auch lesenswerte Bücher, aber ich weiß nicht, ob ein Mensch in den Zwanzigern im Jahr 2024 bereit ist, sich mit einem altmodischen Format zu beschäftigen, bei dem Tinte auf Stücke gefällter Bäume gedruckt wurde. Heranwachsende Entwickler lernen solche Ideen heute offenbar stark über Blogs und YouTube; auch dort gibt es hervorragendes Material, aber das Problem ist immer, es zwischen Müll zu finden, der schlecht verstanden oder fragwürdig verpackt ist
      Wenn also ein magisches Tool auftaucht, das innerhalb eines Herzschlags 12 Zeilen grob funktionierenden Code erzeugt, ist es nicht überraschend, dass junge Entwickler diesen Code für großartig halten, obwohl sie kaum etwas über seine tieferen Probleme wissen. Es ist schwer, jemandem die Schuld zu geben, aber es ist eindeutig ein Problem, und ich wünschte, ich wüsste, was man dagegen tun sollte