Ein Controller, eingefügt „nur um den Bug zu finden“, ein vergessener Zugangsschlüssel in Zeile 12: Beim Code-Review mit KI fließt Code oft durch harmlose Handgriffe ab. Sechs häufige Fehler und wie Sie ohne sie arbeiten.
Dienstag, 16.30 Uhr. Seit dem Morgen schlägt ein Integrationstest fehl, das Release ist für Donnerstag geplant. Der Entwickler markiert den ganzen Controller, vierhundert Zeilen, fügt ihn in eine frei verfügbare KI ein und tippt: „Finde den Bug.“ Die Antwort kommt, und sie stimmt. Niemand bemerkt, dass Zeile 12 einen Zugangsschlüssel zur Testumgebung enthielt, dass die Kommentare den Kunden beim Namen nannten und dass die Rabattberechnung, an der das Team zwei Jahre gefeilt hat, jetzt bei einem Anbieter liegt, den niemand ausgewählt hat.
Das ist der Fehler, den man am häufigsten sieht: kein spektakulärer Leichtsinn, sondern ein Copy-and-paste unter Zeitdruck. Dabei ist die KI eine sehr gute Code-Reviewerin. Man muss nur wissen, was man ihr gibt, und wo.
Code, den Sie für einen Arbeitgeber oder einen Kunden schreiben, gehört in der Regel nicht Ihnen. Er fällt unter das Geschäftsgeheimnis, das in der Schweiz wie in Deutschland und Österreich rechtlich geschützt ist; oft deckt ihn eine Vertraulichkeitsklausel im Arbeits- oder Dienstleistungsvertrag ab; und die IT-Richtlinie des Unternehmens verbietet häufig, Code an einen nicht freigegebenen Dienst weiterzugeben. Bei einem Dienstleister gehört der Code manchmal dem Kunden, der nie erlaubt hat, dass er das Haus verlässt.
Hinzu kommen Personendaten, die sich in den Code einschleichen: aus der Produktion kopierte Testdaten, Fehlerprotokolle, Adressen in Fixtures. Für sie gelten die DSGVO oder das Schweizer Datenschutzgesetz (DSG), ganz gleich, um welche Art von Projekt es sich handelt.
Eine einzelne Datei wirkt harmlos. Aber oft ist es genau die Datei, auf die es ankommt: der Preisalgorithmus, die Logik einer Empfehlungs-Engine, der Workaround für eine Einschränkung einer Bibliothek. Einmal in eine frei verfügbare KI eingefügt, liegt sie bei einem Dritten, der den Verlauf aufbewahren kann und dessen Anbieter ausländischen Gesetzen unterliegen kann, die ihn zur Herausgabe dessen verpflichten, was er besitzt.
Die Abhilfe: das Review mit einem vertraulichen Modell machen. In IA Confidential sind die lokalen und spezialisierten Modelle offene Modelle auf Servern in der Schweiz, unter dem Schweizer Datenschutzgesetz und außerhalb der Reichweite des CLOUD Act; sie geben nichts an Dritte weiter. Die Wahl des Modells erfolgt automatisch oder von Hand, und für ein Code-Review ist ein vertrauliches Modell der richtige Ausgangspunkt.
Fest eingetragene Zugangsschlüssel, der Connection-String zur Datenbank, das Token eines Drittdienstes, eine Umgebungs-Konfigurationsdatei, „für den Kontext“ angehängt, ein Stacktrace mit der E-Mail-Adresse eines Nutzers. Man fügt sie ein, ohne sie zu sehen, weil man einen Bug sucht, kein Datenleck.
Die Abhilfe: Geheimnisse vor jedem Senden entfernen, auch an ein vertrauliches Werkzeug. Ein Review braucht nie den echten Wert eines Schlüssels: Ersetzen Sie ihn durch [API_SCHLÜSSEL] und echte Daten durch erfundene Werte. Ist ein Schlüssel bereits irgendwohin gelangt, ändern Sie ihn. Der Ratgeber zu den Daten, die nie in eine KI gehören behandelt den Fall der Zugangsgeheimnisse ausführlich. Die einfachste Anfrage zeigt, dass es ohne sie geht:
Hier ist ein PHP-Stacktrace und die Methode, die ihn auslöst. Ich habe Zugangsdaten und Daten durch fiktive Werte ersetzt. Erkläre mir die wahrscheinliche Ursache in drei Sätzen und schlage dann die kleinstmögliche Korrektur vor.
berechneRabattKundeX in f1 umbenennen, den Firmennamen aus den Kommentaren streichen: Man hat den Eindruck, den Code anonymisiert zu haben. Doch was den Wert von proprietärem Code ausmacht, ist seine Logik, und die bleibt unverändert. Tabellennamen, interne Domains und Fehlermeldungen reichen oft, um das Projekt zu erkennen.
Der Vertraulichkeitsfilter von IA Confidential behauptet nicht, mehr zu leisten. Wählen Sie ein externes Modell, erkennt er zuerst die sensiblen Angaben und lässt Sie entscheiden: mit einem vertraulichen Modell antworten, die Nachricht unverändert; eine anonymisierte Fassung senden, die Sie gegenlesen und korrigieren können; oder unverändert senden. Bei einem Anhang gehen nur die nützlichen Auszüge hinaus, pseudonymisiert. Was er ersetzt, sind jedoch identifizierende Angaben: ein Name, eine Adresse, eine Kennung. Kein Algorithmus.
Die Abhilfe: zwei Arten von Fragen unterscheiden. „Warum ist diese Sortierung langsam?“ zu Ihrem Fakturierungsmodul bleibt bei einem vertraulichen Modell. „Wie funktioniert optimistisches Locking im Allgemeinen?“ kann an ein externes Modell gehen, ohne Ihren Code. Die Namen, die nie hinausgehen sollen, also Kundenname, Codename des Projekts, interne Domain, tragen Sie im Fenster „Datenschutz“ in Ihre Anweisungen zur Anonymisierung ein: Genau diese Elemente kann keine Erkennung von sich aus erraten. Der Ratgeber Anonymisierung oder Pseudonymisierung erklärt den Unterschied.
Zwei gegensätzliche Extreme. Entweder hängt man eine einzige Datei an, und die KI erfindet das Verhalten der Klassen, die sie nicht sieht. Oder man vertraut ihr das Wurzelverzeichnis des Projekts an, „damit sie alles hat“, samt Produktionskonfiguration, Datenbank-Backups und Deployment-Skripten.
Die Abhilfe: den nützlichen Kontext geben, und nur ihn. Am Computer können Sie mit Chrome, Edge oder Opera einem Bereich bis zu zehn Ordner Ihres Geräts hinzufügen, mit Rechten pro Ordner: Suche, Lesen, Schreiben. Fügen Sie für ein Review über „Ordner hinzufügen“ den Ordner des betroffenen Moduls hinzu statt des Wurzelverzeichnisses, ohne das Recht zum Schreiben, und aktivieren Sie die Option „Vertrauliche Modelle“: Der Ordner wird dann nie an ein externes Modell gesendet. Mit einem angemeldeten Konto findet der Assistent darin automatisch die Stellen, die für Ihre Frage nützlich sind. In einem anderen Browser hängen Sie die nötigen Dateien an Ihre Nachricht an: Sie werden in Ihrem Browser gelesen, und keine davon wird auf unseren Servern aufbewahrt.
Ohne Kriterium bleibt das Review allgemein: Anmerkungen zum Stil, ein Rat zur Benennung, der Vorschlag, Kommentare hinzuzufügen. Die eigentliche Frage (ein Speicherleck, eine Abfrage in einer Schleife, eine Injection-Lücke) geht zwischen den Zeilen verloren.
Die Abhilfe: den Rahmen einmal festlegen und dann bei jeder Anfrage präzisieren. Legen Sie pro Projekt einen Bereich vom Typ „Entwicklung“ an: Er bietet Beispiele zum Lesen, Korrigieren und Schreiben von Code sowie ausführliche Antworten. Im Tab „Assistent“ legen die Anweisungen des Bereichs die Sprache und ihre Version fest, das Framework, Ihre Konventionen und was nicht zum Thema gehört; sie haben Vorrang vor Ihren allgemeinen Einstellungen. Die Anfrage sagt dann, was Sie suchen:
Prüfe die Importmethode unten, die mit Dateien von 50 000 Zeilen aufgerufen wird. Ich will keine Anmerkungen zum Stil. Suche ausschließlich nach: Abfragen, die in einer Schleife ausgeführt werden, vollständigem Laden in den Speicher und Fällen, in denen eine ungültige Zeile den ganzen Import abbricht. Nenne für jeden Punkt die Zeile und schätze die Auswirkung bei einer großen Datei ab.
Die KI irrt sich mit Überzeugung. Sie erfindet eine Methode, die es in Ihrer Version der Bibliothek nicht gibt, schlägt eine Korrektur vor, die den Test bestehen lässt, ohne die Ursache zu beheben, erklärt Code für „sicher“, obwohl ihr eine Lücke entgangen ist. Ein Code-Review mit KI ist kein Sicherheitsaudit, und ein hastig übernommener Fix landet am Donnerstag in der Produktion.
Die Abhilfe: verlangen, dass sie sich erklärt, und prüfen. Fordern Sie Zeilennummern, ausdrückliche Annahmen und das, was sie nicht sehen konnte. Lassen Sie dann jede Korrektur durch Ihre Tests und das übliche menschliche Review des Teams laufen. Die anspruchsvollste Anfrage sieht so aus:
Hier ist der Diff eines Merge-Requests, der unsere tokenbasierte Authentifizierung ändert, zusammen mit den beiden Dateien, die er betrifft. Mach ein Sicherheitsreview: Zugriffskontrolle, Eingabevalidierung, Fehlerbehandlung, Vergleich der Tokens. Gib für jedes Risiko die Zeile, ein konkretes Angriffsszenario und die minimale Korrektur an. Liste danach auf, was du nicht prüfen konntest, weil du den Rest des Codes nicht siehst, und schlage drei Tests vor, die belegen würden, dass die Korrektur funktioniert.
Die Verantwortung für gemergten Code trägt das Team, das ihn merged.
Mit einem vertraulichen Modell verlässt Ihr Code Ihren Rechner, um auf Servern in der Schweiz verarbeitet zu werden, danach wird auf unserer Seite nichts aufbewahrt. Ein Ordner, der mit der Option „Vertrauliche Modelle“ hinzugefügt wurde, wird nie an ein externes Modell gesendet, und der Index, mit dem darin die passenden Stellen gefunden werden, bleibt im Ordner, auf Ihrem Computer. Anhänge werden in Ihrem Browser gelesen.
Mit einem externen Modell entscheiden Sie, was hinausgeht, nachdem der Filter durchlaufen ist: anonymisierte Fassung, pseudonymisierte Auszüge oder die Nachricht unverändert, wenn Sie das bewusst so wollen. Ihr persönliches Profil wird nie an ein externes Modell gesendet. Behalten Sie im Hinterkopf, dass die Anonymisierung Namen maskiert, keine Logik: Code, dessen Algorithmus das Geheimnis ist, bleibt bei den vertraulichen Modellen.
Der Verlauf Ihrer Unterhaltungen, Codeauszüge eingeschlossen, liegt in Ihrem Browser und nirgendwo sonst. An einem gemeinsam genutzten Arbeitsplatz oder auf einem gemeinsamen Testrechner kann ihn jeder lesen, der dieselbe Sitzung verwendet: Arbeiten Sie in einer persönlichen Sitzung und melden Sie sich ab, bevor Sie gehen. Und ein aus der Nachricht entferntes Geheimnis ist nur geschützt, wenn es auch in Ihrem Repository geschützt ist.
Zögert Ihr Team noch, KI zuzulassen, gelten die Argumente aus dem Ratgeber, um KI am Arbeitsplatz sicher zu nutzen, auch für eine Entwicklungsabteilung. Um es an einem unkritischen Modul auszuprobieren, Geheimnisse entfernt: Öffnen Sie den Chat.
