KI wird Ihre Web Component nicht refactoren

10 Min. Lesezeit

Die Verzweigungen hören nie auf zu wachsen

Das Setup war nicht exotisch.

Kein riesiges Framework. Kein Abhängigkeits-Karussell. Nur Web Components, bewusst gewählt, um die Angriffsfläche klein zu halten und nicht das halbe JavaScript-Ökosystem für ein Problem mitzuschleppen, das es nicht brauchte.

Diese Entscheidung ist gut gealtert. Die Komponente nicht.

Je mehr Features ich verlangte, desto mehr taten die Modelle das, worin diese Tools sehr gut sind: das lokale Muster vor ihnen zu erweitern. Ein neuer Modus? Füge eine weitere Verzweigung hinzu. Eine neue Option? Noch eine Bedingung. Ein neuer Workflow? Fädle einen weiteren Zustand durch dieselbe Komponente und hoffe, dass der Geruch niemandem auffällt.

Sie waren nicht dumm. Sie waren statistisch gehorsam.

Das ist der Teil, den viele Leute immer noch nicht verstehen wollen. Claude Code, Codex und ähnliche Tools sind stark darin, die Arbeit fortzusetzen. Sie sind viel schwächer darin, zu entscheiden, dass die aktuelle Form der Arbeit falsch ist.

Lokaler Erfolg ist kein Systemdesign

Eine wachsende Komponente kann eine ganze Weile lang produktiv aussehen.

Jede Änderung funktioniert lokal. Die Demo überlebt. Der neue Button erscheint. Der neue Modus tut sein Ding. Das Diff sieht plausibel aus. Die Anzahl der Verzweigungen steigt im Hintergrund höflich an.

Dann ist die Komponente eines Tages keine Komponente mehr. Sie ist eine Geiselnahme.

Das passierte mit neo-chat-box. Die Komponente war zu dem Ort geworden, an dem zu viele Entscheidungen aufeinandertrafen:

• Modusauswahl
• Prompt-Verarbeitung
• Rendering von Optionen
• Feature-spezifische UI
• Workflow-Verzweigungen
• Gemeinsames Chat-Verhalten
• Sonderfallverhalten für Bild-, Video- und E-Mail-Aufgaben

Keines dieser Anliegen ist für sich genommen absurd. Sie alle in denselben Körper zu stopfen, ist die Art und Weise, wie man ein sehr modernes Monster züchtet.

Die Modelle protestierten nicht. Warum sollten sie? Das Repository zeigte ihnen eine Komponente, die bereits mehrere Modi verarbeitete, also verstärkten sie diese Form weiter. Wenn Sie in einer Multi-Modus-Chatbox nach Bildsteuerungen fragen, fragt das Tool nicht von Natur aus, ob diese Steuerungen in eine spezialisierte untergeordnete Komponente gehören. Es fragt normalerweise, wie schnell es die nächste Bedingung hinzufügen kann.

Das ist Fortsetzung. Kein Design.

Das Refactoring begann mit Fragen

Der Ausweg war keine weitere große Spezifikation. Es war eine Reihe gezielter Fragen.

Was wird wirklich über alle Modi hinweg geteilt?

Was ändert sich nur, weil der Benutzer ein Bild erstellt, anstatt eine einfache Nachricht zu senden?

Welche Teile repräsentieren stabiles Chat-Verhalten und welche Teile sind in Wirklichkeit modusspezifische Konfigurations-UIs, die vorgeben, Chat-Verhalten zu sein?

Wo verzweigt sich die Komponente, weil das Geschäftskonzept anders ist, und nicht, weil das Rendering-Detail abweicht?

Welche Entscheidungen sollten in der Benutzeroberfläche als explizite Komposition sichtbar sein, anstatt in Bedingungen versteckt zu werden?

Diese Untersuchung führte zu der offensichtlichen Antwort, die die Modelle nicht von sich aus angeboten hatten. Die generische Chat-Hülle sollte generisch bleiben. Das modusspezifische Verhalten sollte in spezifische Komponenten verlagert werden. Der Benutzer sollte modusspezifische Optionen über dedizierte UI-Elemente auswählen, anstatt eine einzige aufgeblähte Komponente zu zwingen, vier Produkte schlecht zu imitieren.

Die Refactoring-Richtung wurde also Komposition.

Ein normaler Chat kann ein normaler Chat bleiben.

Ein Bild-Workflow kann bildspezifische Optionen über eine fokussierte Komponente bereitstellen.

Ein Video-Workflow kann dasselbe für Video tun.

Ein E-Mail-Workflow kann die Steuerungen und Einschränkungen sichtbar machen, die zur E-Mail-Arbeit gehören, anstatt so zu tun, als wären diese nur ein weiterer Zweig einer generischen Konversationsbox.

Gleiche App. Weniger Lügen.

Warum die Demos die Leute in die Irre führen

Viele Leute schauen sich jetzt Demo-Videos an und kommen zu dem Schluss, dass menschliches Design-Urteilsvermögen nur noch auf geliehener Zeit lebt.

Die Demos sind überzeugend, weil die Tools real sind. Sie können ein Repository inspizieren, schnell Code generieren, Änderungen durch mehrere Dateien fädeln und sich von offensichtlichen Fehlern erholen. Dieser Teil ist nicht mehr hypothetisch.

Der falsche Gedankensprung kommt direkt danach.

Die Leute sehen den fließenden Output und folgern, dass die Maschine auch erkennen wird, wann sich die Struktur selbst ändern muss. Sie gehen davon aus, dass sie das unbequeme Refactoring freiwillig anbietet, die bequeme Verzweigung ablehnt und das Design vereinfacht, bevor sich die Komplexität zu Wartungskosten verhärtet.

Normalerweise tut sie das nicht.

Anthropics eigener Leitfaden zum Thema building effective agents ist viel nüchterner als die öffentliche Fantasie. Sie plädieren für einfache, komponierbare Muster statt unnötiger Framework-Komplexität, warnen vor sich verstärkenden Fehlern in autonomen Agenten und sagen, dass programmierende Agenten besonders gut funktionieren, wo Lösungen durch automatisierte Tests verifizierbar sind. Sie fügen den Satz hinzu, der hier am meisten zählt: Menschliche Überprüfung bleibt entscheidend, um sicherzustellen, dass Lösungen mit breiteren Systemanforderungen übereinstimmen.

Das ist keine kleine Fußnote. Das ist das gesamte Argument.

Genau bei den breiteren Systemanforderungen liegt das Problem:

• Welche Abstraktion sollte existieren?
• Welche Verantwortung sollte verschoben werden?
• Welche Verzweigung ist ein Signal dafür, dass die Grenze falsch ist?
• Welche scheinbare Bequemlichkeit wird die nächsten zehn Änderungen verschlimmern?

Das sind keine Autocomplete-Probleme.

Die Modelle sind darauf optimiert, fortzufahren

OpenAIs Artikel darüber, why language models hallucinate, bringt den angrenzenden Punkt von der Modellseite her auf den Punkt. Diese Systeme werden immer noch zu oft für selbstbewusstes Raten belohnt, anstatt für kalibrierte Zurückhaltung. Die praktische Konsequenz beim Programmieren ist bekannt: Wenn man die Tür für eine plausible Fortsetzung offen lässt, wählt das Modell oft die Fortsetzung statt des Zögerns.

Das zeigt sich nicht immer als erfundener API-Aufruf. Manchmal zeigt es sich als fabrikierte Zuversicht in eine Designrichtung.

Die Komponente hat bereits vier Modi? Gut, lassen Sie uns eine fünfte Verzweigung hinzufügen.

Die Klasse besitzt bereits das UI-Rendering, Zustandsübergänge, Workflow-Optionen und modusspezifisches Verhalten? Gut, lassen Sie uns das alles an einem Ort behalten und die Namen länger machen.

Das Tool ist nicht böse. Es ist nicht faul. Es trägt nur nicht die Kosten der zukünftigen Struktur, wie es ein erfahrener Entwickler tut.

Wenn Sie Jahre damit verbracht haben, Systeme aufzuräumen, denen zwei Quartale lang „nur noch eine weitere Verzweigung“ hinzugefügt wurde, können Sie den Schaden frühzeitig spüren. Das Tool kann das normalerweise nicht. Oder genauer gesagt, es wird nicht nach diesem Gefühl handeln, es sei denn, Sie zwingen die Unterhaltung dorthin.

Die Daten sind nicht freundlich zu naivem Optimismus

Der Glaube, dass Codegenerierung von Natur aus zu saubereren Systemen führt, war schon immer faul. Externe Beweise haben weniger Geduld damit.

Der Bericht von GitClear, Coding on Copilot: 2023 Data Suggests Downward Pressure on Code Quality, analysierte rund 153 Millionen geänderte Codezeilen und fand zunehmenden Churn, mehr hinzugefügten und kopierten Code und weniger Beweise für Wiederverwendung. Ihre Zusammenfassung ist für sich genommen unverblümt genug: KI-lastige Codeänderungen ähnelten zunehmend der Arbeit eines umherziehenden Beitragsleistenden und nicht der eines sorgfältigen, langfristigen Maintainers.

Das bedeutet nicht, dass KI-Coding-Tools nutzlos sind. Es bedeutet, dass die Geschwindigkeit real ist und Designdisziplin weiterhin erforderlich ist.

Die chaotische Wahrheit ist interessanter als der Hype.

Diese Tools können erfahrenen Entwicklern helfen, sich viel schneller zu bewegen. Sie können auch mittelmäßige Struktur in schockierender Geschwindigkeit industrialisieren, wenn niemand aktiv Architektur, Grenzen und Tests steuert.

Mein Beispiel mit der neo-chat-box ist genau das im Miniaturformat. Der Assistent war nützlich, um Änderungen zu implementieren. Er schützte die Komponente nicht spontan vor angehäuften Designschulden.

Achten Sie auf die Einstellungen, nicht auf den Hype

Dieser Teil ist sehenswert, weil er den Marketingnebel durchschneidet.

Die Labore, die Coding-Magie verkaufen, stellen auch in großer Zahl Softwareentwickler für zutiefst urteilsschwere Geschäfts- und Unternehmensarbeiten ein.

Anthropic hat eine Stelle als Software Engineer, Enterprise Foundations für seine Claude-for-Work-Initiative ausgeschrieben. In der Beschreibung geht es nicht um Tippgeschwindigkeit. Es geht um unternehmensgerechte Features, Sicherheit, Compliance, Skalierbarkeit, Identitätsmanagement, Führung, rollenbasierte Zugriffskontrolle und branchenspezifische Lösungen für das Gesundheitswesen, das Finanzwesen und die Bildung.

Die Karriereseiten von OpenAI lesen sich mittlerweile genauso. Ihre öffentlichen Stellenangebote umfassen Rollen in den Bereichen Forward Deployed Engineering, B2B Applications, Internal Applications, Finance, and enterprise deployment work. Eine veröffentlichte Stelle als Backend Software Engineer, Enterprise AI Platform beschrieb die Arbeit an sicheren und konformen Systemen, Unternehmensdatenzugriff, Authentifizierung, Zuverlässigkeit und kundenverwalteter Infrastruktur, damit große Organisationen Agenten tatsächlich sicher in der Produktion einsetzen können.

Das ist das verräterische Zeichen.

Die führenden Labore stellen kein Personal so ein, als ob die Softwareentwicklung auf Prompting zusammengeschrumpft wäre. Sie stellen so ein, als ob sich die wertvolle Arbeit in die harte Mitte verlagert, wo geschäftliche Einschränkungen, Sicherheit, Unternehmensidentität, Deployment-Realität, Compliance und Produkturteil aufeinanderprallen.

Denn genau das passiert.

Was ich eigentlich von der KI brauchte

Ich brauchte das Modell nicht, um mein Urteilsvermögen zu ersetzen. Ich brauchte es, um mir zu helfen, mein Urteilsvermögen schneller anzuwenden.

Das ist eine viel vernünftigere Erwartung.

Sobald die Designfragen klar waren, wurde das Tool wieder nützlich:

• Vergleichen der aktuellen Verantwortlichkeiten innerhalb der Komponente
• Isolieren dessen, was wirklich geteilt wird
• Identifizieren der Nahtstellen für spezialisierte untergeordnete Komponenten
• Skizzieren alternativer Kompositionen
• Helfen beim Verschieben von Rendering-Logik in fokussierte Elemente
• Das Refactoring in Bewegung halten, ohne die gesamte App von Hand neu zu schreiben

Das ist ein starker Hebel.

Aber beachten Sie die Reihenfolge.

Der Hebel wirkte nach dem Design-Urteil, nicht an dessen Stelle.

Der wertvolle menschliche Beitrag bestand darin, zu erkennen, dass das Problem nicht mehr lautete „füge ein weiteres Feature hinzu“, sondern „halte eine Komponente davon ab, vier verschiedene Produkte zu imitieren“. Sobald diese Entscheidung einen Eigentümer hatte, konnte die KI die Ausführung beschleunigen.

Ohne diese Entscheidung hätte sie weiter gelächelt und Verzweigungen hinzugefügt.

Bessere Fragen für agentisches Programmieren

Wenn eine Komponente unter KI-gestützter Entwicklung anfängt aufzuquellen, helfen diese Fragen mehr als ein weiterer heldenhafter Prompt:

• Welche Verantwortlichkeiten werden geteilt und welche existieren nur zusammen, weil die Geschichte sie zusammengeschoben hat?
• Welche Verzweigungen repräsentieren unterschiedliche Geschäftskonzepte und nicht nur kleine UI-Variationen?
• Wie würde die kleinste stabile Hüllen-Komponente aussehen?
• Welche modusspezifischen Optionen verdienen ihre eigene fokussierte Komponente?
• Welcher Zustand gehört zur Hülle und welcher Zustand sollte hinter eine spezialisierte Schnittstelle verschoben werden?
• Welches zukünftige Feature wird einfacher, wenn wir das jetzt aufteilen?
• Welcher Test würde fehlschlagen, wenn wir die falsche Grenze beibehalten würden?

Die letzte Frage ist wichtig, weil sie Designgeschmack in Beweise verwandelt.

Ein gutes Refactoring ist nicht nur schöner. Es sollte spätere Änderungen billiger, Tests klarer und modusspezifisches Verhalten weniger verflochten machen.

Der schwierige Teil hat immer noch einen Eigentümer

Der schädlichste KI-Mythos in der Softwareentwicklung ist derzeit nicht, dass die Modelle nutzlos sind.

Es ist die Annahme, dass gute Demos und frühe Erfolge beweisen, dass menschliches Urteilsvermögen optional wird.

Das beweisen sie nicht.

Sie beweisen, dass die bürokratischen Teile der Softwareentwicklung billiger werden. Sie beweisen, dass die Fortsetzung schneller ist. Sie beweisen, dass ein fähiger Entwickler jetzt viel schneller von der Idee zur Implementierung gelangen kann.

Sie beweisen nicht, dass die Maschine entscheiden wird, wann die Architektur angefangen hat zu lügen.

Meine Web Component brauchte keinen enthusiastischeren Assistenten. Sie brauchte jemanden, der bereit war zu sagen, dass die aktuelle Form falsch war, gezielte Fragen zu stellen und sich für Komposition statt für Verzweigungsanhäufung zu entscheiden.

Deshalb sind Claude Code und Codex mächtige Tools und dennoch kein Ersatz für Urteilsvermögen.

Sie können helfen, das Ding zu bauen.

Jemand muss immer noch entscheiden, was das Ding sein soll.