Einleitung
Auf dem World Government Summit in Dubai sagte der CEO von NVIDIA, Jensen Huang: “Unsere Aufgabe ist es, Computertechnologie so zu entwickeln, dass niemand mehr programmieren muss. Und dass die Programmiersprache menschlich ist”.
Das haben wir auf die Probe gestellt: Ein Team von 70 Cloudflight-Entwickler:innen aus 5 Ländern hat GitHub Copilot einen Monat lang in rund 10 Kundenprojekten getestet – ein großes Dankeschön an sie, an Microsoft und GitHub für die wertvollen Einblicke und den Support, und an unsere teilnehmenden Kunden, die uns ihre Software anvertraut haben.
Darüber hinaus konnten wir unsere eigenen Ergebnisse mit den Leistungen von 1040 Teilnehmenden an unserem eigenen Cloudflight Coding Contest am 19.04.2024 vergleichen: 299 von ihnen gaben an, keine KI-Unterstützung zu wünschen, während 741 dem Einsatz von KI offen gegenüberstanden. Haftungsausschluss: Die Ergebnisse unseres GitHub Copilot-Tests basieren auf den subjektiven Antworten unserer teilnehmenden Entwickler:innen und Architekt:innen. Wir haben uns aus den folgenden Gründen gegen eine kontrollierte Langzeitstudie entschieden:
- KI-Assistenten werden häufig aktualisiert
- Kein Projekt und kein Sprint gleicht dem anderen
- Teamzusammensetzungen ändern sich
- Die Messung signifikanter Auswirkungen auf Metriken wie Story Points pro Sprint oder Deployments in die Produktionsumgebung innerhalb eines bestimmten Zeitrahmens würde mindestens 3 bis 6 Monate über mehrere Teams hinweg erfordern, um wirklich aussagekräftig zu sein.
Unsere CCC-Ergebnisse, die zur Überprüfung der Hypothesen des GitHub Copilot Trial verwendet werden, basieren auf den Ergebnissen unserer Teilnehmer während des Coding Contest.
Auswirkungen auf die Produktivität
Wir sehen die Ergebnisse von GitHub Copilot als positiv an. Wenn Sie mit realistischen Erwartungen an die Sache herangehen und wissen, wo und wie das Tool Ihnen am meisten helfen kann, erwarten wir, dass auch Sie die Nutzung von GitHub Copilot in ein positives Ergebnis verwandeln.
Nach einem Monat sahen unsere Testteilnehmer:innen GitHub Copilot als wertvolles Tool in ihrem Tool-Stack: Sie schätzten, dass sie im Durchschnitt etwa 40 Minuten pro Tag einsparen konnten, was bei einem typischen 8-Stunden-Arbeitstag etwa 8 % entspricht. Das entspricht etwa eineinhalb Tagen pro Monat. Ein Blick auf die Gesamtspanne zeigt zwei Extreme: 10 von 70 Teilnehmer:innen schätzten, dass sie bis zu einer Stunde einsparen konnten, während ein Kollege offenbar zu viel mit der künstlichen Intelligenz “spielte” und an manchen Tagen etwa eine Stunde produktiver Arbeit verlor. Im Folgenden werden die Stärken und Schwächen von KI-Assistenten näher beleuchtet.
Vergleich mit dem Status quo
Wir haben uns auch dafür interessiert, wie oft unsere Kolleg:innen mit der KI interagieren:
Eine Schätzung von Cloudflight, wie oft ein durchschnittlicher Entwickler die Dokumentation konsultiert (3 – 5 mal pro Tag) und im Internet sucht (5 – 10 mal pro Tag), zeigt ein ähnliches Nutzungsverhalten wie unsere KI-Unterstützung. Wir können uns vorstellen, dass die traditionelle Websuche in vielen Fällen durch die Interaktion mit KI ersetzt wird. Die Häufigkeit von Fehleinschätzungen, das Zitieren von Quellen zur manuellen Überprüfung von Antworten (wie bei Phind und Kagi) und die Verfügbarkeit der aktuellsten Dokumentation werden eine wichtige Rolle spielen, um das Rennen zu gewinnen.
Weitere Erkenntnisse
Die Nutzungsmuster zeigen, dass unsere Teilnehmer KI weiterhin regelmäßig einsetzen und keine besorgniserregenden Trends zu erkennen sind. Nur 8 von 50 Befragten haben ihre KI-Nutzung während des Testzeitraums reduziert.
Mehr als die Hälfte der Teilnehmer erwartet außerdem, dass der Nutzen von KI-Tools mit zunehmender Vertrautheit mit ihnen steigen wird:
Stärken und Schwächen
Insgesamt haben wir festgestellt, dass GitHub Copilot uns in sieben verschiedenen Bereichen geholfen hat, in zwei weiteren Bereichen hatten wir gemischte Gefühle und in drei Bereichen haben wir einen Mangel festgestellt.
Täglicher Begleiter
Erstellung der Dokumentation
Da es sich bei unseren KI-Assistenten um Sprachmodelle handelt, überrascht es nicht, dass sie in diesen Bereichen als hilfreich empfunden werden. Zusammen mit der Tatsache, dass einige Entwickler oft wenig Lust verspüren Dokumentation zu schreiben, und dass Dokumentation leicht veraltet und daher häufig aktualisiert werden sollte, ist dies ein großes Gewinnszenario. Während die Überprüfung der Ergebnisse für jedes LLM-generierte Produkt ein Muss ist, wiegen die generierten Texte und die Fähigkeit, Dokumentation auf mehreren Abstraktionsebenen blitzschnell bereitzustellen, diesen manuellen Zeitaufwand auf.
Generierung von Tests
Sowohl das erstmalige Generieren von Tests als auch das Erstellen von zusätzlichen Testfällen sind recht repetitive Aufgaben, bei denen Ihnen GitHub Copilot eine große Hilfe sein wird. Indem Sie Test-Setup-Klassen und andere bereits existierende Testklassen in Ihren LLM-Kontext einbinden, erreichen Sie ein gewisses Maß an Konsistenz zwischen den Testklassen. Achtung: Sie können sich nicht darauf verlassen, dass die Sprachmodelle alle wichtigen Testfälle für Sie im Alleingang erstellen oder perfekte Testdaten generieren. Einige Teile müssen manuell angepasst oder erstellt werden und sollten immer gut durchdacht sein.
Generierung der Datenbankschemata
Wenn Sie Ihr Datenmodell oder Ihre Entitätsklassen, die Zieldatenbank und die Datenbankversionierungstechnologie Ihrer Wahl angeben, erledigt GitHub Copilot den Großteil der Arbeit in wenigen Sekunden. Überprüfen Sie jedoch nochmals, ob alle benötigten Schlüssel und Indizes erstellt wurden, da es sonst später zu Problemen mit der Konsistenz und der Performance kommen kann.
Umschreiben / Refactoring von Code (z.B. von Java nach Kotlin)
Die Bereitstellung von existierendem Code als Kontext löst viele Unklarheiten und schlechte Wege auf, die Ihr LLM mit weniger Informationen einschlagen könnte. Da wir im Wesentlichen von einer (Programmier-)Sprache in eine andere übersetzen, haben wir festgestellt, dass dies recht gut funktioniert. Dies ist auch ein häufiger Anwendungsfall: Denken Sie an die Aktualisierung von Bibliotheksversionen, die Migration von z.B. JavaScript zu Typescript oder die Verwendung von bestehendem Java-Code in einem Kotlin-Projekt und andere Szenarien.
Generierung von Code, der bereits existierendem Code ähnelt
Wie im vorherigen Punkt geht es auch hier darum, neuen Code zu generieren und nicht nur alten Code zu modifizieren. Denken Sie an Ihren typischen CRUDL-Anwendungsfall: Sie haben einige Modelle, die von Ihrer Anwendung verwaltet werden müssen (Benutzer, Rechnungen, Bestellungen usw.), die einige gemeinsame Funktionen für die Erstellung, Aktualisierung usw. benötigen. Wenn Sie für diese Anwendungsfälle kein Framework verwenden, funktioniert das Mapping einer vertikalen Domäne und die Generierung der zweiten Domäne mit der ersten und einer Beschreibung der neuen Domäne sehr gut und erspart Ihnen viel wiederholte Arbeit.
Unterstützung bei Sprachen/Tools, mit denen man nicht vertraut ist
Ein Sprachmodell kann Ihnen als Leitstern dienen, wenn Sie mit Sprachen oder Frameworks zu tun haben, mit denen Sie nicht vertraut sind. Es generiert Beispiele, die zu Ihrem wachsenden Verständnis beitragen, es kann Fragen schneller und manchmal ausführlicher beantworten als die Dokumentation und liefert oft Puzzleteile, die nur noch richtig zusammengesteckt werden müssen. Nichtsdestotrotz ist ein solides Verständnis der zugrundeliegenden technischen Grundlagen derzeit hilfreich, wenn nicht sogar unerlässlich: Es verhindert, dass Sie die falschen Wege einschlagen, die zu Zeitverlust, schlechten Designentscheidungen und sinkender Softwarequalität führen.
Rubber duck debugging
Die meisten Entwickler:innen werden es wissen: Sobald Sie anfangen, Ihr Problem jemand anderem zu erklären (vielleicht Ihrem stets mitgeführtem Quietscheentchen) und das Problem sorgfältig Schritt für Schritt durchgehen, kommen Sie oft selbst auf die Lösung. Diese Technik wird Gummienten-Debugging (oder Rubberducking) genannt und ist zufälligerweise (oder auch nicht, vielleicht geht es ja doch um Intelligenz) eine etablierte Technik zur Abfrage von großen Sprachmodellen bei komplexeren Problemen: Chain-of-thought. Indem Sie Ihr Problem und die Lösung in mehrere Schritte aufteilen und jeden Schritt wiederholen, erhöhen Sie die Wahrscheinlichkeit eines positiven Ergebnisses – für das Sprachmodell und für Sie selbst.
Gemischte Gefühle
Nun ein paar Worte zu Szenarien, die ein gewisses Glücksspiel darstellen: Vielleicht sind Sie mit dem Ergebnis zufrieden, vielleicht verlieren Sie aber auch etwas Zeit.
Inline-Code-Vervollständigung
Dieses Szenario ist vielleicht nur vorübergehend und zum Teil ein Problem der Benutzerfreundlichkeit, aber wir haben einige Dinge beobachtet:
- KI-Assistenzvervollständigungen können Ihren IDE-Vervollständigungen in die Quere kommen
- Für einige Entwickler:innen erforderten die Standardeinstellungen und Shortcuts eine Änderung ihrer etablierten Arbeitsabläufe, was einige nicht ohne große Anreize tun wollen.
- IDE-Vervollständigungen sind schnell, und daran sind wir gewöhnt. KI-unterstützte Vervollständigungen brauchen mehr Zeit: Sie haben einen Hin- und Rückweg zum Server und benötigen deutlich mehr Rechenzeit. Für manche Menschen ist das schwierig. Wenn wir uns einen einzigen Tag aus den bereitgestellten GitHub Copilot-Statistiken ansehen, wurden etwa 20 % der inline Vorschläge von unseren Entwicklern angenommen. Dabei wird nicht berücksichtigt, ob sie anschließend beibehalten, geändert oder entfernt wurden, was bedeutet, dass die endgültige Menge des von der KI generierten Codes mit Sicherheit geringer ist. Dies führt zu einem Szenario, in dem man sich selbst aktiv ausbremst, nur um von dem Vorschlag enttäuscht zu sein, und in dem man schneller gewesen wäre, wenn man die Zeile oder den Block von vornherein selbst kodiert hätte.
Fehlersuche
Zum Teil ein Thema der Benutzerfreundlichkeit, zum Teil nicht: Die IDE-Terminal-Integration ist ein Muss, um Stack Traces nicht zu oft zu kopieren, und diese sind meist ziemlich neu und in Entwicklung. Aber Debugging erfordert auch sehr oft das Gesamtbild eines manchmal sehr komplexen Codes und erfordert, dass Sie – der Entwickler – den richtigen Kontext zur Verfügung stellen (die Dateien öffnen), was sehr schwierig sein kann, wenn Sie mit einem Fehler zu tun haben, den Sie nicht verstehen. Bei einfachen Fehlern wird Ihnen KI Assistenz also helfen, für komplexere Fehler sehen wir nicht, wie es in der jetzigen Form ohne automatischer Auswahl des Kontexts möglich sein kann.
Negative Fälle
Kreative Aufgaben (Generierung von Geschäftslogik, optimierter Code)
Zum Zeitpunkt der Erstellung dieses Artikels ist uns kein KI-Tool bekannt – weder GitHub Copilot noch andere – welches eigenständig größere funktionierende oder sogar produktionsreife Software generieren kann. Die Einschränkungen, Bugs im KI-Tooling, die Herausforderungen beim Verstehen größerer Mengen an Code und die gemischte Qualität des Outputs sind derzeit einfach zu große Blocker. Dazu gehört auch bereits die Generierung größerer Features welche eine Integration durch mehrere Schichten erfordern, einem bestimmten konsistenten Architekturstil folgen sollten, und sich nahtlos in andere Teile der Software integrieren müssen. Daher wurde die eigentliche Implementierung unserer Funktionen nach wie vor hauptsächlich von unseren großartigen Entwicklern durchgeführt. Die Hilfe der künstlichen Intelligenz beschränkte sich auf die Generierung kleiner Code-Bausteine.
Modernster Code
Das ist ganz einfach: Es ist nicht immer klar, welche Versionen der verwendeten Bibliotheken Ihr aktuelles Modell wirklich kennt, denn Sie erhalten widersprüchliche Antworten. Wenn Sie also mit aktuellen Versionen (welche z.B. innerhalb der letzten 3 – 6 Monate erschienen sind) arbeiten, erhalten Sie falsche Antworten, wenn sich die Schnittstellen oder Dokumentation geändert haben, Punkt. Wir verstehen, dass das Trainieren der Modelle Zeit und Ressourcen kostet, aber wenn Sie wie wir auf dem neuesten Stand bleiben wollen, wird Sie die KI-Unterstützung ziemlich behindern.
Weitere Überlegungen zu ganzen Softwaresystemen werden wir in einem späteren Beitrag anstellen.
Aufgaben, die einen großen Überblick erfordern
Wie bereits erwähnt, müssen Sie bei einigen Szenarien, wie z. B. der Suche nach schwerwiegenden Fehlern oder architektonischen Entscheidungen, wirklich viele Zusammenhänge auf einmal berücksichtigen. Und aufgrund technischer Beschränkungen (die berühmte Kontextgröße) bedeutet dies, dass einige Modelle einfach nicht genügend Informationen auf einmal verarbeiten können, um bestimmte Anfragen zu beantworten. Es gibt zwar Techniken zur Umgehung dieses Problems, aber sie sind zeit- und kostenintensiv. Zum Zeitpunkt der Erstellung dieses Artikels wurde vor einem Monat GPT-4o veröffentlicht, das eine Kontextgröße von 128k Token verwendet. Wir werden in einem zukünftigen Beitrag untersuchen, ob dies mehr Schlussfolgerungen über größere Softwaresysteme zulässt.
Gegenprobe mit unseren CCC-Ergebnissen
Und jetzt kommt’s: In unserem CCC 04/2024 hatten wir sage und schreibe 741 Teilnehmer, die angaben, dass sie oder ihr Team den Einsatz von KI-Assistenz während unseres Wettbewerbs in Erwägung ziehen, verglichen mit 299, die angaben, keine KI-Assistenztechnologien zu verwenden.
Wir sehen hier keine Ergebnisse, die im Widerspruch zu unseren früheren Aussagen stehen.
Beim CCC geht es darum, so schnell wie möglich die richtige Lösung zu finden
Personen, die KI-Assistenz verwenden, waren im Durchschnitt mehr als 10 % langsamer als Programmierer, die angaben, keine KI-Assistenz zu verwenden. Dies deckt sich mit unserer Annahme, dass eine vollständig ausgearbeitete Funktion oder eine größere Lösung ohne eigene Korrekturen und Fähigkeiten in vielen Fällen noch nicht von der KI allein erreicht werden kann. Beim Coding Contest geht es nicht um Qualität, Quantität, Dokumentation, Wartbarkeit und andere Faktoren, in denen die Effizienzgewinne zu finden sind. Es geht darum, so schnell wie möglich die richtige Lösung zu finden, oft unter Verwendung ausgefeilter Algorithmen. Hier gibt es noch Raum für Verbesserungen auf der KI-Seite.
Darüber hinaus nahmen 679 Nutzer:innen an einer optionalen Umfrage nach dem Wettbewerb teil und lieferten weitere wertvolle Erkenntnisse über ihre Erfahrungen mit KI im Allgemeinen und die Leistung derjenigen, die während des Wettbewerbs KI-Hilfe in Anspruch genommen haben. Nochmals vielen Dank an alle, die so freundlich waren, zu antworten. Wir konnten die folgenden zusätzlichen Erkenntnisse gewinnen:
Das Rennen um den ersten Platz in der KI-Welt ist noch offen: Während die aktuelle Landschaft von ChatGPT und GitHub Copilot dominiert wird, gaben unsere Teilnehmer an, 27 verschiedene Tools zu verwenden. Die meistgenutzten Tools nach Microsoft / OpenAI waren Googles Gemini/Bard, Blackbox AI und Claude, gefolgt von einigen Nutzern von Replit, Phind, Mistral und anderen. Es gibt noch eine ganze Reihe von Problemen zu lösen, die eines Tages einen neuen Champion krönen könnten.
KI-Assistenz ist leistungsstark, aber nicht für jeden geeignet – und ändert sich häufig
Abschließend möchten wir noch ein paar Worte zu den subjektiven Wahrnehmungen verlieren: Von den 287 Teilnehmern, die in unserer Umfrage nach dem Wettbewerb den Einsatz von KI erwähnten, gaben 65 an, dass sie das Gefühl haben, durch KI Zeit verloren zu haben, 132 sagten, sie hätten Zeit gespart, während 90 Teilnehmer unsicher sind. Hier gibt es keine eindeutige Antwort: Die Wahrheit ließe sich nur herausfinden, wenn dieselben Programmierer dieselbe Aufgabe (ohne sie vorher zu kennen) ohne KI wiederholen würden, oder wenn sie längere Versuche mit einer größeren Gruppe durchführen würden, um die meisten Unsicherheiten auszugleichen. Und dann wiederum wären bei der Veröffentlichungshäufigkeit neuerer Modelle alle Ergebnisse wahrscheinlich schon veraltet, bevor sie vollständig vorliegen. Unsere Empfehlung lautet daher wie folgt: Halten Sie hin und wieder inne und denken Sie nach: Wären Sie nicht schneller gewesen, wenn Sie eine Zeile getippt hätten, auch wenn es bequemer erscheint, sie automatisch generieren zu lassen? Halten Sie Ihre Programmierkenntnisse aufrecht? Denken Sie über Ihre Vorschläge nach, oder akzeptieren Sie blind, was Sie bekommen, und machen Feierabend?
Am Ende des Tages gibt Ihnen KI Unterstützung das wahrscheinlich leistungsfähigste Toolset seit dem Aufkommen moderner IDEs, Google / Stackoverflow und anderen. Wir können ehrlich zugeben, dass wir begeistert sind von Anfang an dabei zu sein, und wir sind gespannt, wohin die Reise gehen wird.
Fazit und nächste Schritte
Die Ergebnisse von GitHub Copilot sind für uns positiv. Daher können sich derzeit alle unsere Projektteams für die Nutzung von GitHub Copilot entscheiden, sofern die jeweiligen Kunden zustimmen. Dies hat rechtliche Gründe (der rechtliche Stand ist hier gänzlich unklar) und wird höchstwahrscheinlich in Zukunft angepasst werden, wenn sich die Dinge weiterentwickeln.
Der konkreteste nächste Schritt für Cloudflight ist die Ausweitung der KI-Unterstützung auf alle Rollen: Anforderungsentwicklung, Qualitätssicherung und UX/UI-Designer, um einige zu nennen. Derzeit befinden wir uns in einer geschlossenen Beta-Phase, in der wir unseren Mitarbeitern https://github.com/huggingface/chat-ui/ zur Verfügung stellen. „Chat-ui“ ist die HuggingFace Opensource Benutzeroberfläche für die Interaktion mit großen Sprachmodellen. Es ähnelt dem, was die meisten Leute kennen und benutzen: Die ChatGPT Benutzeroberfläche. Als Microsoft Solution Partner und Specialized Partner haben wir diese mit einer in Europa gehosteten Azure OpenAI Instanz verbunden. Bleiben Sie dran für weitere Updates zu diesen Bemühungen.
Nicht zuletzt evaluieren wir ständig Modellmodifikationen im Hinblick auf Kosten, Geschwindigkeit, Qualität und ihre Leistungsfähigkeit in neuen Bereichen (z.B. initiale Codegenerierung) – oder in Bereichen, die, wie oben erwähnt, nicht zu den Stärken der aktuellen Modelle gehören. Wir werden Sie über alle Entwicklungen auf dem Laufenden halten.
Alles Gute und danke für’s Lesen.
Vinci