Macht es Sinn, gelieferten Software-Code vor der Abnahme durch eine KI prüfen zu lassen?

Hier gibt es ein massives rechtliches Risiko. Was genau steht in Ihrem Vertrag bezüglich Vertraulichkeit (NDA) und geistigem Eigentum? Den individuellen Quellcode Ihres Unternehmens einfach in eine cloudbasierte KI hochzuladen, kann schnell eine handfeste Vertragsverletzung sein. Wenn die Daten auf Drittservern womöglich noch fürs Modelltraining verwendet werden, sitzen Sie im Streitfall ganz schnell am kürzeren Hebel.

Das größte technische Limit ist das Context Window. Ein Lagersystem für 26.000 EUR besteht vermutlich aus etlichen Services, Datenbankschemata und Schnittstellen. Die Modelle betrachten meist nur isolierte Dateien. Wenn eine Datenvalidierung drei Ordner weiter in einer Hilfsfunktion liegt, sieht das Modell das nicht und schlägt sofort grundlos Alarm wegen einer angeblichen Sicherheitslücke.

Nach deutschem Vertragsrecht müssen Mängel vor der Unterzeichnung des Abnahmeprotokolls konkret und nachvollziehbar gerügt werden. Der bloße Textoutput einer KI gilt nicht als wirksame Mängelrüge. Der Mangel muss am laufenden System reproduzierbar sein und es muss nachgewiesen werden, dass eine Anforderung aus dem Pflichtenheft nicht erfüllt ist.

Wir haben das letztes Jahr bei einem B2B-Portal für 18.000 EUR genauso ausprobiert. Das Modell spuckte eine Liste mit 47 Punkten aus. Bevor wir das an die Agentur gaben, haben wir einem Freelance-Senior 400 EUR gezahlt, damit er drüberschaut. Von den 47 Punkten waren gerade mal 4 echte Mängel, der Rest war Müll. Allerdings war einer dieser 4 Fehler so gravierend, dass er uns im Live-Betrieb das System zerschossen hätte. Als Filter also brauchbar, als Schiedsrichter absolut ungeeignet.

anstatt den ganzen code reinzuschmeißen und "find fehler" zu tippen lieber modul für modul vorgehen und gezielt nach abhängigkeiten oder exploits fragen, bringt viel sauberere ergebnisse. aber schickt der agentur bloß nicht 1:1 den ki-output, die nehmen euch sonst null ernst.

Macht es euch doch nicht so kompliziert. Macht die Abnahme rein über Nutzertests und Funktionen. Schreibt euch Testfälle: 1) Was passiert beim Scannen eines falschen Barcodes? 2) Geht der Bestandsabgleich flöten, wenn das WLAN kurz weg ist? 3) Friert die Kiste beim Rechnungsdruck ein? Eure Aufgabe ist zu testen, ob der Laden läuft, nicht ob der Code Prosa ist.

Gab es im Vertrag Vorgaben zu automatisierten Tests oder einer bestimmten Testabdeckung? Und enthält das übergebene Repository überhaupt Unit-Tests der Agentur? Falls Test-Suiten vorhanden sind, liefert deren Ausführung eine wesentlich handfestere und unstrittigere Abnahmebasis als jedes Auslesen durch eine KI.

Ein Kunde von uns hat genau das mal gebracht. Kam mit acht Seiten Prompt-Ausdruck ins Meeting und meinte, unser Code sei Müll. Ein Punkt war: "Datenbank-Passwort steht im Klartext im Code" – dabei war das nur eine Beispiel-Konfigurationsvorlage (template), das echte Passwort kam sauber aus den Umgebungsvariablen. Die Stimmung war komplett im Eimer und die Übergabe hat sich völlig unnötig um zwei Monate verzögert.

Das hier Beschriebene ist genau das, was wir erlebt haben. Der meiste Zeitverlust entsteht durch Arbeiten, die auf Freigaben warten.

Ich hoffe, das hilft dir weiter.

Ich habe mich lange damit beschäftigt. In den ersten drei Monaten läuft alles gut, die Probleme tauchen im vierten Monat auf.

Ich hoffe, das hilft dir weiter.

Wenn wir ins Detail gehen: Wer bei anleitung code review hetzt stolpert alle an derselben Stelle.

Bei uns war es so. Je schwerer es ist, eine Entscheidung rückgängig zu machen, desto langsamer solltet ihr sie treffen.

Korrigiert mich, falls ich falsch liege.

Dieser Rat passt meiner Meinung nach nicht auf jeden. Schreibe bei Entscheidungen auch das Worst-Case-Szenario auf, nicht nur das Beste.

Wenn deine Situation anders ist, ändert sich das natürlich.

Da verstehe ich etwas nicht ganz. Wenn du das nicht von Anfang an schriftlich festhältst, gibt es später Streit.

Der meiste Zeitverlust entsteht durch Arbeiten, die auf Freigaben warten. Wenn es jemand anders macht, würde mich das auch interessieren.

Ich schreibe das, damit ihr denselben Fehler nicht macht. Wenn du das nicht von Anfang an schriftlich festhältst gibt es später Streit.

Wenn ihr das Ergebnis hier postet, hilft es auch anderen.

Wie habt ihr das Problem gelöst? Jedes „schauen wir uns später an“ in Meetings bedeutet nicht kalkulierte Arbeit.

Das war's, entschuldige, wenn ich zu lang war.

Es gab drei verschiedene Ansichten, die sich alle ergänzen. Je schwerer es ist, eine Entscheidung rückgängig zu machen, desto langsamer solltet ihr sie treffen.

Überstürzte Entscheidungen sind oft solche, die man sechs Monate später korrigieren muss.

da hast du recht dann halt bei uns war der größte Zeitfresser die Unklarheit darüber wer entscheidet.

wenn deine Situation anders ist, ändert sich das natürlich.