Ex-Meta-Entwickler: KI-Code macht Codebasen zu einem Kartenhaus

Ich denke, KI-Nutzung für Code und Entwicklung aus einer ingenieurmäßigen Perspektive zu betrachten, wird eine frustrierende Übung werden. Ich bin seit über 20 Jahren Softwareentwickler und habe mich komplett darauf verlegt, KI für meinen Code zu nutzen, zu 100 %. Ich finde es unschätzbar wertvoll – praktisch die einzige Möglichkeit, heutzutage relevant zu bleiben und ein Geschäft zu führen. Ich freue mich, wenn mir jemand widerspricht, denn ich möchte nicht zum ersten Mal in meinem Leben recht haben.

Davon abgesehen sagt mir meine Erfahrung, dass es beim Enterprise- und Business-Coding selten wirklich um stabile oder robuste Codebasen ging. Wir Entwickler und ein Bruchteil kompetenter Engineering-Manager und eine verschwindend kleine Zahl von Direktoren haben gegen Geschäftsinteressen gekämpft, um sicherzustellen, dass Qualität beim Code Priorität hatte, aber es war immer ein Kampf bergauf, und wir wurden oft dafür gemaßregelt, zu viel Zeit auf Qualität und Design zu verwenden.

Ein getakteter Release-Rhythmus ist ein Gräuel für qualitativen Code, weil man ihn nicht in ein Zeitfenster pressen kann.

Also ist KI nur die Fortsetzung davon. Versuche ich sicherzustellen, dass meine Agenten Code entwerfen, den ich als gut bezeichnen würde? Ja, absolut! Aber ich habe es vollständig ausgelagert, und ich stelle fest, dass es auch vollkommen in der Lage ist, seine eigenen Fehler zu beheben. Ich bin mit KI-Unterstützung weit über alles hinausgegangen, was ich allein oder auch mit einem Team je geschafft habe, also glaube ich, dass ich einfach meine Erfahrung und Fähigkeiten auf Management und Architektur anwenden muss statt auf tatsächliche Codezeilen.

Nur die Zeit wird zeigen, wie sich das entwickelt.

Wallaahu aʿlam.

Codequalität ist kein Problem ... bis sie es ist. Alle werden zufrieden sein, wenn die Dinge zu funktionieren und schnell voranzugehen scheinen; erst wenn man Symptome sieht wie die Unfähigkeit, Dinge zu ändern, ohne bestehende Funktionen zu brechen, oder sogar einen Anstieg der verbrauchten Tokens beim Lesen komplexer Codebasen, wird man anfangen, sich um Codequalität zu kümmern (wobei ich mir vorstelle, dass die Leute jetzt einfach die KI versuchen lassen, ihr eigenes Chaos zu reparieren).

Diese Regeln sind so wahr, dass sie offensichtlich klingen. Es ist Zeit, die Führungsebene unter Druck zu setzen, damit sie sich dieser bewusst wird.

Ich bin mir nicht sicher, ob Artikel der Art „KI generiert ...“ gut altern werden.

Meine unmittelbare Frage wäre, welche Art von adversarialen Reviews und deterministischen Gates der Autor geschrieben hat, um die Dimensionen der Wartbarkeit (Mangel an DRY, zyklomatische Komplexität, unklare Benennung, schlecht architektierte Abläufe usw.) zu erfassen, die ihm wichtig waren.

Versteht mich nicht falsch. Als ich mit 200 PRs pro Tag durchgerast bin (persönliche Projekte – ich hätte sie anderen nicht zugemutet), habe ich ziemlich schnell einen großen Schlammklumpen zusammengekleistert, aber während ich mein Reich neu aufbaue, (a) sind die Modelle etwas besser, aber (b) füge ich viel mehr Rigorosität rund um Verifikation hinzu (Korrektheit, Performance, Sicherheit, Betriebskosten und Wartbarkeit). Es ist kein leicht zu lösendes Problem, aber für mich fühlt es sich wie eine ingenieurmäßige Anstrengung an, nicht wie spekulative Raketenwissenschaft.

Ich verstehe vollkommen, dass viele KI-generierte Codebasen tatsächlich unter mehr Vorfällen und geringerer Wartbarkeit leiden, aber ich denke, es ist wichtig, zwischen dem zu unterscheiden, was üblich ist, und dem, was möglich ist, denn die Lösung für das eine ist die Verbesserung der Rigorosität deiner Verifikation, während die Lösung für das andere darin bestünde, entweder schlechten Code zu akzeptieren oder LLMs aufzugeben.

Reine Spekulation hier, aber das ist ein Gedanke, der mir kommt. Ich habe oft gesehen, dass Möbel als Analogie dafür verwendet werden, wie schnell ein automatisierter Prozess Handwerker verdrängen kann, aber ich denke, in einer Hinsicht könnte es tatsächlich eine Analogie dafür sein, wie Handwerk auch nach der Automatisierung überleben und gedeihen kann. Sicher, Ikea verkauft VIEL mehr Möbel als Ethan Allen; aber Ethan Allens handgefertigte Möbel sind von viel höherer Qualität und verkaufen sich zu einem Premiumpreis.

Die Verbraucher profitieren rundum. Wer es sich leisten kann, kann das hochwertige handgefertigte Produkt kaufen; die Mehrheit, die das nicht kann, bekommt günstigen Zugang zu Möbeln akzeptabler Qualität.

Das ist reine Spekulation, aber ich frage mich, ob sich Software mit der Verfügbarkeit von KI allmählich in diese Richtung entwickeln wird. Für viele grundlegende Aufgaben werden Verbraucher im Grunde ihre eigene Software mit irgendeinem KI-Tool schreiben können; sie mag nicht von hoher Qualität sein, aber zumindest wird sie billig und schnell herzustellen sein, und sie wird die Zugangshürde für den durchschnittlichen Computerbenutzer, das zu tun, was er auf seiner Maschine tun möchte, stark senken. Unterdessen wird ein viel kleinerer Nischenmarkt für hochwertige Tools, die zumindest teilweise von Experten handgefertigt wurden, um einen besonderen Bedarf zu decken, bei dem Performance oder ein qualitativ hochwertiges Erlebnis entscheidend sind, weiter gedeihen. In jedem Fall würde ich in diesem Szenario vermuten, dass die Bedeutung und Prominenz von SaaS langsam abnehmen wird.

Ich denke nicht, dass das noch eine Rolle spielt. Software wird zu einer Blackbox, und Agenten bringen sie zum Laufen, solange man eine einigermaßen vernünftige Spezifikation dessen liefern kann, was man tun möchte, plus ein bisschen Aufsicht und Anleitung.

Im Moment sind sie nicht großartig darin, gute Software-Engineering-Prinzipien zu befolgen. Sie erledigen die Arbeit, mit verbose Code, viel Duplikation, Abstraktionslecks, nutzlosen Unit-Tests und so weiter.

Ist das ein Problem? Man könnte denken, dass es langfristig eines sein wird, dass KI nicht mit der Komplexität umgehen kann, die sie eingeführt hat, aber ich mache mir nicht wirklich Sorgen. Die meiste Software ist nicht so groß, und Agenten werden von Tag zu Tag besser. Und wenn dir Design wirklich wichtig ist, ist es nicht allzu schwer, deinem Agenten anzuweisen, deine Standards zu befolgen.

Ich wünschte, es wäre nicht so und ich könnte meine Erfahrung und Expertise noch ein paar Jahre rechtfertigen, aber die Fakten liegen auf dem Tisch.

An diesem Punkt finde ich diese Art von Verallgemeinerungen sehr nervig

Ich widerspreche dem Artikel nicht, aber er könnte bei manchen Lesern den Eindruck erwecken, dass vor KI handgeschriebener Code nicht fragil war.

Hier ist der berühmte Kommentar zur Oracle-RDBMS-Codebasis mit 25 Millionen Zeilen: https://news.ycombinator.com/item?id=18442941

Jede große Unternehmenscodebasis mit Millionen von Zeilen verfällt in einen ähnlichen Zustand. Die kleine Codebasis beginnt mit sauberer konzeptioneller Integrität. Dann verfällt sie unweigerlich zu unverständlichem Spaghetti-Code, je mehr Leute hinzukommen. Verschiedene Gründe dafür, darunter dass die späteren Entwickler sich weniger um den Code kümmern als das ursprüngliche Entwicklerteam, Deadlines, das Vermeiden von Refactoring aus Angst, etwas kaputtzumachen, usw.

Wenn du nicht willst, dass KI fragilen Code erzeugt, musst du dieselben Qualitätsgates anwenden, die auf vor-KI handgeschriebenen Code angewendet worden wären, um alles sauber zu halten. Die meisten Unternehmen tun das nicht.

Eines der Dinge, die KI reduziert, sind neugierige Entwickler, die in der Codebasis herumstöbern, was eine großartige Methode ist, toten Code, suboptimale Strukturen usw. zu finden. Mit KI ist das alles weg.