KI liefert Code, wir liefern Ordnung, warum Review Pflicht ist
Ein viraler LinkedIn Beitrag darüber, wie KI funktionierenden Code erzeugt, aber ohne Ordnung, mit Locale Beispiel und Refactoring als Pflicht.
KI kann funktionierenden Code, aber KI hinterlässt Chaos und Unordnung.
Hier etwas Quelltext, wie ich in meinem Projekt vorgefunden habe, nachdem ich ein neues Feature mit KI implementiert habe.
Beides funktioniert, aber ich habe z.B. im Projekt ein Enum für alle Sprachen/Locales, die es im Projekt geben kann. Damit validiere ich User-Input und stelle sicher, dass auch nur diese Werte in der DB vorkommen.
KI hat das ignoriert und kommt zwar zum gleichen Ergebnis, aber ich finde es rechts besser lesbar und rechts ist sichergestellt, dass Werte wie
XX_XX oder DE_FR
nicht funktionieren und zum Default werden.
Außerdem habe ich die Funktionalität der linken Seite mehrfach im Projekt gefunden und jetzt eine eigene Klasse daraus gemacht und es gibt nur noch eine Stelle für die Logik im Quellcode, wo ich das Verhalten anpassen kann, wenn sich etwas ändert.
Es ist nicht die Welt, aber wenn ich das linke Beispiel einfach so weiter laufen lasse, dann habe ich bald Quelltext, den niemand (auch ich) mehr versteht. Wenn ich alle Stellen finden muss, wo die Locale auf einen Markt gemappt wird, kann es lustig werden, weil ich vielleicht zwei übersehe.
Das bedeutet, KI generieren lassen ist gut, Code reviewen und aufräumen ist Pflicht.
(Ja, wir könnten härter mit einer Exception reagieren. Es war aber verschmerzbar, dass der Default hier DE_de ist, weil es "nur" eine Suche ist und das System dadurch trotzdem weiter laufen soll.)
Weitere Gedanken aus den Kommentaren
Natürlich ist es wichtig, beide Seiten zu betrachten, denn die Wahrheit liegt nicht nur auf einer Seite. Dabei habe ich nicht ganz so ernst gemeint die Aussage getroffen, dass KI eher eine "Wahrscheinlichste-Wort-Abfolge-Maschine" ist und der Begriff Künstliche Intelligenz ein Marketing-Begriff ist.
Beide Aussagen sind überspitzt und dazwischen liegt die Wirklichkeit, denn intelligent wird das Ganze nur, weil wir etwas Menschliches reininterpretieren, was nicht da ist, aber es ist auch komplexer als ein paar Wahrscheinlichkeiten.
Gleichzeitig bleibt der Realitätscheck wichtig. Wenn ich KI als Denken verkaufe, falle ich auf Marketing rein und überschätze die Ergebnisse. Der Nachteil zeigt sich dann im Projektkontext, denn ich übernehme Lösungen, die technisch funktionieren, aber die Konventionen ignorieren oder Logik verdoppeln.
Viele Kommentare haben den Punkt Kontext betont, und das nehme ich mit. Wenn ich Regeln, Validatoren und Spezifikationen sauber vorgebe, wird die Qualität deutlich besser. Ohne diese Leitplanken erfindet die KI eigene Wege. Das Ergebnis sind Stilbrüche, doppelte Logik und schwer wartbarer Code.
Ein fairer Einwand war der Vergleich selbst. Eine zweite KI-Runde mit einem Refactoring-Prompt wäre ein guter Test und wäre ein guter Test und würde zeigen, wie nah die Maschine an gute Qualität herankommt. Trotzdem bleibt die Verantwortung bei mir, denn Code, den ich nur im Fehlerfall verstehe, ist keine Grundlage für Wartbarkeit und Planbarkeit.
Hier eine Liste an Technologien, die genannt wurden, um Spec-Driven Development zu verbessern und ein klares Regelwerk aufzusetzen.