Blog
LLM-gestützte Codierung führt zu einer massenhaften Anhäufung technischer Schulden.
LLM-gestützte Codierung ist leistungsstark, aber nicht jeder profitiert davon.
Ein Entwickler, der so sehr in das Programmieren vertieft war, dass er vergaß, LLM-gestützte Programmierassistenten zu verwenden…?
Die Erwartungen an LLM-gestützte Programmierassistenten sind enorm hoch, aber viele Unternehmen geraten dadurch ins Hintertreffen.
WARUM DAS WICHTIG IST? CTOs beklagen Verlangsamungen und Produktionsprobleme, die auf die unternehmensweite Einführung von LLM-gestützten Kodierassistenten zurückzuführen sind. Das KI-Versprechen kollidiert mit der Realität von technischen Schulden und Sicherheitsproblemen.
WIE BEHEBEN SIE ES? Setzen Sie diese Tools strategisch ein: breit verfügbar, wenn Fehler billig sind, aber eingeschränkt, wenn viel auf dem Spiel steht.
Ein großes Versprechen
Das Versprechen der KI für Ingenieure ist, Ingenieure loszuwerden.
Tools wie Copilot von GitHub schreiben Code, Specs, Überprüfungen und erstellen Pull-Anfragen. Sie erstellen und führen Tests aus, und zwar im Hintergrund, während die Entwickler produktiveren Tätigkeiten nachgehen, z. B. Meetings.
Is productivity lagging because we're all waiting on ChatGPT? Credit Reddit, remixing Randall Munroe https://xebia.ai/waiting-on-chatgpt
However, if this is all real, which companies are racing ahead?
Eine Umfrage von DX, einer Plattform für Entwickler-Intelligenz, befragte 20.000 Entwickler und fand heraus, dass die Produktivitätssteigerung bei den Mitarbeitern etwa 10% beträgt: nicht schlecht, aber kaum revolutionär.
Ich glaube, es gibt noch einen anderen Grund: Der Anstieg ist ungleichmäßig verteilt, weil diese Tools wie eine Meereswelle sind: Spaß für erfahrene Surfer, aber Ärger für die Neulinge.
Simon Willison, einunabhängiger KI-Forscher und Mitglied des Vorstands der Python Software Foundation, erwähnte kürzlich im Podcast Last Week in AWS, dass die LLM-gestützte Kodierung ein Multiplikator für seine Produktivität ist, aber nur, weil er sie mit 20 Jahren Erfahrung leitet.
Wenn er zum Beispiel eine Webanwendung erstellt, bittet er das Modell, auf CSRF-Schwachstellen (Cross-Site Request Forgery) zu prüfen, weil er sich der Gefahr bewusst ist. Jemand mit wenig oder gar keiner Web-Erfahrung würde nicht einmal danach fragen. Die Anleitung von Modellen (und die Überprüfung ihrer Ergebnisse) trennt also Erfolg von (Sicherheits-)Katastrophen.
Willisons Fähigkeiten wecken Neid. Einige seiner Projekte, die von LLMs mitgeschrieben wurden, umfassen Tools für die OCR von PDFs im Browser, die Erstellung kommentierter Präsentationen, Bild-Resizerund einen Social Media Card Cropper, um nur einige zu nennen (Sie finden sie alle auf seiner Website). Das ist das erfüllte Versprechen der KI: ein Verstärker von Expertenwissen.
Die andere Seite der Medaille
Weniger erfahrene Entwickler wecken keinen Neid, wenn sie mit den gleichen Tools ausgestattet sind, und erschreckende Geschichten gibt es zuhauf.
Und es gehen auch Dinge kaputt. Claude kann alles Wertvolle von Ihrem Computer löschen (einschließlich Fotos und Dokumente), während Sie eine nicht verwandte Aufgabe ausführen.
Die Chefetage stimmt dem zu. In einer kürzlich durchgeführten Umfrage haben 90 % der CTOs Produktionskatastrophen auf LLM-gestützte Kodierung zurückgeführt, und sie sind damit nicht allein:
- Der CEO von Sonar sagte, dass die Ausfallzeiten mit der Einführung von LLM-gestützter Kodierung zunahmen.
- Veracode fand heraus, dass KI-generierter Code in der Hälfte der Fälle funktional, aber unsicher ist.
- Die Universität Neapel hat bestätigt, dass die KI-Ausgabe mit subtilen Fehlern und Sicherheitslücken behaftet ist.
Das Kernproblem besteht darin, das Handwerk nicht zu beherrschen. Mangelnde Steuerung oder Qualitätssicherung ermöglichen es LLM-gestützten Programmierassistenten, die technischen Schulden mit jeder Eingabeaufforderung zu erhöhen.
Vermeidung von Ermüdung der Ingenieure
Process ain't the answer
Können QA und Code-Reviews das Problem lindern? Können Prozesse Bugs, technische Schulden oder Sicherheitsprobleme beheben oder vermeiden?
Erstens: Diese Prozesse halten nicht alles auf. Andernfalls würde die Implementierung dieser Prozesse eine fehlerfreie Software bedeuten.
Zweitens ist die Geschwindigkeit, mit der Ingenieure ein Modell erneut auffordern können, um zu versuchen, die QAzu bestehen - und damit die Last auf den Prüfer zu verlagern - beispiellos.
Daniel Stenberg, der Schöpfer des allgegenwärtigen cURL, schrieb, dass das Durchkämmen jedes von der KI generierten Schwachstellenberichts bis zu 3 Stunden dauert. Er muss den bereitgestellten Code verstehen, die Beispiele ausprobieren, antworten, usw.
Sobald er antwortet, schiebt der Einsender die Antwort in einen LLM und fügt ein, was immer wieder herauskommt, und verschwendet damit noch mehr wertvolle Zeit.
Daniel verbietet den Einreicher, aber was ist mit den Kollegen? Werden sie versetzt, nur um den nächsten Ingenieur zu versumpfen?
Einheitsgröße für alle
Sind Erfolg für die einen und Unglück für die anderen zwei Seiten derselben Medaille?
Als ich mit mehreren CTOs und technischen Leitern über das Thema diskutierte, kam ich auf dieses Modell: Wenn Sie das Handwerk nicht beherrschen, häufen Sie mit jeder neuen Anfrage technische Schulden an.
Wenn Ingenieure Fehler und Schwächen erkennen, sind LLM-gestützte Codierassistenten ein Verbündeter. Für Ingenieure, die ihr Handwerk nicht beherrschen, bedeuten diese Assistenten Ärger.
Das bedeutet, dass diese Tools nicht jedem standardmäßig zur Verfügung stehen sollten (es sei denn, sie sind zum Lernen gedacht und können mit einem Mentor sehr leistungsfähig sein), um zu vermeiden, dass Sie sich schneller technisch verschulden, als Sie es verkraften können.
Das ist leichter gesagt als getan, denn die Unternehmen sollten wissen, wer die Fähigkeiten hat, LLM-gestützte Programmierassistenten effektiv einzusetzen und wer nicht.
Verfasst von
Giovanni Lanzani
Unsere Ideen
Weitere Blogs
KI als Kraftmultiplikator: Wie Unternehmen und ISVs mit weniger mehr erreichen...
Kiran Madhunapantula, COO
Contact