Ein Entwickler bittet einen Assistenten um eine Funktion, die prüft, ob ein Benutzer einen Bericht herunterladen darf. Der Code lässt sich kompilieren. Der Standardtest ist erfolgreich. Der Pull Request sieht übersichtlich aus. Zwei Wochen später bemerkt ein Kollege, dass die Funktion zwar prüft, ob der Benutzer angemeldet ist, aber nie, ob der Bericht ihm gehört.
Dies ist ein beispielhaftes Szenario, kein dokumentierter Vorfall. Es verdeutlicht die Lücke, die KI-generierte Code-Review-Schulungen schließen müssen: Generierter Code, der eine grundlegende Prüfung besteht, kann dennoch einen Autorisierungs- oder Parallelitätsfehler enthalten, und die prüfende Person muss diesen finden und seine Relevanz erläutern.
Dieser Leitfaden richtet sich an Verantwortliche für die technische Weiterbildung und an Führungskräfte im technischen Bereich. Er beschreibt, wie man Leistungsprobleme beschreibt, Lücken analysiert, Schulungen vorbereitet und durchführt, einen Fall bearbeitet und beurteilt, ob die erlernten Fähigkeiten auf reale Prüfungen übertragbar sind. Es geht um die Konzeption von Schulungen. Jeder Fehler, Test und jede Prüfregel in Ihrem Programm sollte von erfahrenen Ingenieuren und Ihrem Sicherheitsteam validiert werden.
Was ist KI-generiertes Code-Review-Training?
KI-gestütztes Code-Review-Training lehrt Entwickler, einen Assistenten präzise anzusprechen und die Ergebnisse anschließend zu bewerten: Ist der Code korrekt, sicher, verhält er sich unter Last zuverlässig und effizient? Es handelt sich nicht um einen Kurs für ein bestimmtes Tool, sondern um die Vermittlung einer Review-Gewohnheit, die auch bei einem Toolwechsel erhalten bleibt.
Schnelle Fakten
| Frage | Kurze Antwort |
|---|---|
| Was ist die Aufgabe? | Prüfen Sie den generierten Code und untermauern Sie jedes Risiko mit einem Test. |
| Welche Punktzahl erreichst du? | Überprüfung der Qualität der Prüfung und ob die relevanten Mängel gefunden wurden. |
| Reicht ein Quiz zu sicheren Programmierregeln aus? | Nein. Es bestätigt zwar die Voraussetzungen, aber nicht, ob ein Entwickler einen Fehler im Code erkennen kann, der plausibel erscheint. |
| Wer prüft die Inhalte? | Ein technischer Leiter und Ihr Sicherheitsteam. |
| Was kann Training nicht beheben? | Zeitdruck bei der Überprüfung, unzureichende Tools, unklare Zuständigkeiten und der Druck, schnell zu fusionieren. |
| Woran erkennt man, dass es funktioniert hat? | Eine neue, bisher unbekannte Programmierübung, die anhand vereinbarter Kriterien bewertet wird, mit anschließender Auswertung realer Rezensionen. |
1. Beschreiben Sie das Leistungsproblem
Beginnen Sie mit der Aufgabe: Prüfen Sie den generierten Code und untermauern Sie die Risiken durch Tests. Prüfen bedeutet, den Code kritisch zu lesen. Untermauern bedeutet, einen Verdacht in Beweise umzuwandeln, üblicherweise in einen fehlgeschlagenen Test oder eine Reproduktion, die den Fehler aufzeigt.
Die Forschungsergebnisse verdeutlichen, warum dies gezieltes Üben erfordert. In einer Studie mit GitHub Copilot generierten Pearce und Kollegen 1,689 Programme in 89 Szenarien, die aufgrund bekannter Schwachstellen ausgewählt wurden, und stellten fest, dass etwa 40 Prozent davon anfällig waren (Pearce und Kollegen, 2021Das war ein frühes Werkzeug und ein spezifischer Anwendungsfall, daher sollte die Zahl nicht als Richtwert für heutige Assistenten betrachtet werden. In einer separaten Nutzerstudie wurden die Teilnehmer gebeten, Code mit und ohne KI-Assistenten zu schreiben. Diejenigen, die den Assistenten nutzten, schrieben deutlich weniger sicheren Code und hielten ihren Code eher für sicher (Perry und Kollegen, 2023Dieselbe Studie ergab, dass Teilnehmer, die dem Assistenten weniger vertrauten und sich stärker mit seinen Anweisungen auseinandersetzten, weniger Schwachstellen aufwiesen.
Für die Trainingsgestaltung ergeben sich daraus zwei Lehren. Plausible Ergebnisse erfordern eine aktive Überprüfung. Und Selbstvertrauen ist kein Beweis, daher muss die Übung den Test und nicht die Meinungsbildung in den Vordergrund stellen.
Verfassen Sie die Leistungsbeschreibung in einem Satz und lassen Sie sie von einem Entwicklungsleiter überprüfen: „Angesichts einer generierten Änderung listet der Entwickler die von ihm erkannten Sicherheits-, Parallelitäts- und Effizienzrisiken auf und beschreibt oder schreibt für jedes Risiko einen Test, der dieses Risiko aufzeigen würde.“
2. Lern- und Kontextlücken diagnostizieren
Bevor Sie etwas entwickeln, vergleichen Sie die Aufgabe mit den Inhalten und Prüfungsformaten Ihres aktuellen Programms. Drei Fragen helfen in der Regel, eine Schulungslücke von anderen Problemen zu unterscheiden:
- Wird in der aktuellen Praxis die reale Aufgabe berücksichtigt? Wenn Schulungen zwar das Verfassen von Aufgabenstellungen umfassen, die Entwickler aber nie zur Überprüfung der Ergebnisse auffordern, hat niemand das Auditieren geübt. Wenn die Bewertung aus einem Multiple-Choice-Test zu sicheren Programmierregeln besteht, misst sie lediglich das Wissen auswendig.
- Welche kognitiven Anforderungen werden gestellt? In Blooms überarbeiteter Taxonomie gehören die Beurteilung der Codesicherheit und die Auswahl des entsprechenden Tests zu den Analyse- und Bewertungsebenen, während die Entwicklung einer besseren Eingabeaufforderung oder einer Fehlerbehebung der Erstellungsebene zugeordnet wird. Die Zuordnung von Aktivitäten zu diesen Ebenen wird in unserem Leitfaden erläutert. Zuordnung von Lernaktivitäten zu Blooms Taxonomie.
- Steht da etwas anderes als Können im Weg? Prüfen Sie die Prüfzeit, die Tools und die Zuständigkeiten. Stehen Prüfern nur fünf Minuten pro Pull Request zur Verfügung, führt auch ohne Schulung kein Audit durch. Fehlen statische Analysen oder Testumgebungen im Entwicklungsprozess, kann ein Entwickler zwar ein Risiko erkennen, es aber nicht belegen. Melden Sie Ursachen, die nicht auf Schulungen beruhen, an die zuständigen Personen.
3. Entwurfsvorbereitung und -durchführung
Sobald Sie wissen, welche Lücken durch Schulungen geschlossen werden können, weisen Sie jeder Phase eine klar definierte Aufgabe zu.
Vorbereitung. Prüfen Sie die Voraussetzungen mit einer kurzen Diagnose: Welche typischen Schwachstellen weist Ihr System auf? Wie sind Ihre Tests strukturiert? Welche Checkliste verwendet Ihr Team für die Überprüfung? Selbstgesteuertes Lernen eignet sich für diese Phase. Eine kurze Überprüfung des Wissensstands dient lediglich der Bestätigung der Voraussetzungen.
Praxis. Verwenden Sie Audit-Übungen mit realistisch generiertem Code. Jede Übung enthält einige wenige Fehler unterschiedlicher Art, z. B. fehlende Besitzprüfungen, Race Conditions und ineffiziente Schleifen, sowie fehlerfreien Code. Der Entwickler bespricht jedes Risiko, bewertet dessen Schweregrad und schlägt einen Test vor, der das Risiko aufdeckt. Fragen Sie nach der Begründung, nicht nach einer Liste von Zeilennummern.
Feedback bekommen. Verknüpfen Sie es mit Entscheidungen anstatt mit einer Gesamtpunktzahl. „Sie haben die Schleife, aber nicht das Wettrennen um den gemeinsamen Zähler gemeldet, und Ihr Test hätte es nicht erkannt, da er die Anfragen nacheinander ausführt“ ist aussagekräftiger als „2 von 3 gefunden“.
Live-Eingabe oder asynchrone Überprüfung? Live-Feedback ist besonders wertvoll, wenn ein Risiko unklar ist und Entwickler von den Erläuterungen eines erfahrenen Entwicklers profitieren, warum er den Merge blockieren würde. Eine asynchrone Überprüfung reicht aus, um die Ergebnisse eines Entwicklers mit einer kommentierten Expertenprüfung zu vergleichen. Viele Teams nutzen beides: zunächst selbstständige Vorbereitung, anschließend eine moderierte Sitzung zu schwierigen Fällen.
4. Arbeiten Sie ein realistisches Beispiel durch.
Beispielhaft. Ein technischer Leiter sollte den Anwendungsfall und die Antwortkriterien vor der Verwendung prüfen.
Der Fall. Ein generierter Endpunkt gibt die Rechnung eines Kunden anhand der Rechnungs-ID zurück. Er prüft, ob der Aufrufer über eine gültige Sitzung verfügt, verwendet eine parametrisierte Abfrage und besteht den Basistest. Dieselbe Funktion erhöht einen gemeinsam genutzten Downloadzähler ohne Sperre.
Die Aufgabe. Der Entwickler nennt jedes von ihm erkannte Risiko, ordnet es nach Priorität und beschreibt den Test, der jedes Risiko untermauern würde.
Ein erster Versuch. „Sieht gut aus. Die Abfrage ist parametrisiert und der Test ist erfolgreich.“ Der Entwickler hat den erfolgreichen Test als Beweis gewertet und nicht gefragt, was der Test nicht abdeckt.
Feedback geben und es erneut versuchen. Der Prüfer bittet den Entwickler, zu erläutern, was die Sitzungsprüfung beweist und was nicht. Die Wiederholungsprüfung fordert ihn auf, zwei verschiedene Kunden und zwei gleichzeitige Anfragen zu berücksichtigen.
Ein stärkerer Versuch. Die Sitzungsprüfung beweist, wer anruft, nicht, dass die Rechnung ihm gehört. Ich würde einen Test schreiben, bei dem Kunde A die Rechnungs-ID von Kunde B anfordert und eine Ablehnung erwartet. Der Zähler wird ohne Synchronisierung inkrementiert, sodass zwei gleichzeitige Anfragen eine Aktualisierung verpassen könnten. Ich würde einen parallelen Test durchführen und die Zählerstände vergleichen. Die Abfrage selbst ist parametrisiert, daher würde ich hier keine Zeit verschwenden. Beachten Sie, dass diese Antwort die Risiken priorisiert und jedes Risiko mit einem Test verknüpft.
Warum jede Antwort vertretbar oder unvollständig ist. Beurteilen Sie jeden Versuch anhand genehmigter Kriterien, nicht nach der Präferenz eines Gutachters. Der erste Versuch folgt einer Gewohnheit, lässt aber die Beweise außer Acht. Der überzeugendere Versuch ist spezifisch, priorisiert und überprüfbar.
5. Fähigkeiten einschätzen und Transfer planen
Der Nachweis der Kompetenz erfolgt durch die Bearbeitung einer neuen, dem Lernenden unbekannten Übung. Die Qualität der Bewertung und die Identifizierung relevanter Mängel werden überprüft. Ein einfacher Bewertungsbogen verwendet eine Skala von 0 bis 2 pro Kriterium.
| Kriterium | Sichtbare Beweise |
|---|---|
| Aufgabenausführung | Prüft den generierten Code und dokumentiert die Beweise hinter jedem Befund. |
| Argumentation | Erläutert die Einschränkungen, Alternativen und die verbleibenden Unsicherheiten und ordnet die Risiken ein. |
| Boundaries | Hält sich an die Prüfregeln des Teams und eskaliert an einen Sicherheitsspezialisten, wenn das Risiko außerhalb seines Zuständigkeitsbereichs liegt. |
Bewertungskriterien: 0 bedeutet fehlend oder nicht begründet, 1 bedeutet teilweise mit relevanten Auslassungen und 2 bedeutet vollständig und anhand der vereinbarten Kriterien begründet. Kritische Fehler, wie z. B. die Genehmigung von Code mit einem ungeschützten Zugriffspfad, müssen separat definiert werden, damit sie nicht in der Gesamtbewertung verborgen bleiben. Diese Bewertungsmatrix ist ein Vorschlag, kein validierter Bereitschaftsstandard: Passen Sie sie gemeinsam mit einem Entwicklungsleiter an und erproben Sie sie. Unser Leitfaden dazu Gestaltung interaktiver Übungen mit hilfreichem Feedback zeigt, wie man Feedback verfasst, das mit Entscheidungen verknüpft ist.
Planen Sie den Transfer bewusst. Nach der Übung sollte jedem Entwickler ein echter Pull Request mit generiertem Code zugewiesen werden. Anschließend können die Ergebnisse gemeinsam überprüft werden. Alternativ kann eine kurze Retrospektive zu einem kürzlich durchgeführten Review durchgeführt werden, bei dem etwas übersehen wurde.
Wo interaktive Bereitstellung hilft
Interaktive Formate sind hilfreich, da sich alle Beteiligten vor dem Treffen mit der Gruppe einbringen sollten. In einer Live-Sitzung kann ein Moderator einen generierten Codeausschnitt zeigen, jeden Entwickler bitten, die erkannten Risiken und die von ihm geschriebenen Tests zu notieren, und anschließend die Ergebnisse vor der Diskussion präsentieren. Dieselbe Übung kann zur Vorbereitung auch im Selbststudium durchgeführt werden. AhaSlides Es unterstützt interaktives Lernen und den Wechsel zwischen Live- und Selbstlernphasen. Es handelt sich um ein Präsentations- und Lernwerkzeug, nicht um eine Plattform zum Ausführen von Code. Führen Sie die Codeübungen daher in Ihrer eigenen Umgebung durch. Überprüfen Sie alle Funktionen zur Erstellung von Inhalten, Feedback oder Berichten, die Sie nutzen möchten, anhand Ihres eigenen Arbeitsablaufs. Hinweise zur Formatauswahl finden Sie in unserem Artikel zu diesem Thema. Wann sollte man adaptives, interaktives und Live-Lernen einsetzen?.
Messen Sie, was sich verändert hat
Legen Sie im Vorfeld fest, woran Sie erkennen, dass die Entwickler die Aufgabe bewältigen können. Vergleichen Sie die Qualität der Verifizierung und die Fehlererkennung anhand einer unvorbereiteten Übung mit einem Referenzwert. Definieren Sie die Teilnehmer, den Nenner und den Zeitraum. Verbessern sich die Ergebnisse, prüfen Sie, welche anderen Änderungen sich im selben Zeitraum ergeben haben, z. B. eine neue Regel für die statische Analyse, eine überarbeitete Checkliste oder einen Wechsel des Assistenten, bevor Sie die Schulung anrechnen.
Einschränkungen, die möglicherweise bestehen bleiben
- Zeit für eine Überprüfung. Eine Prüfung dauert länger als eine oberflächliche Durchsicht, und die Fristen drängen eher zur oberflächlichen Durchsicht.
- Werkzeug. Ohne einen Testaufbau oder eine Scan-Methode in der Pipeline lässt sich ein Risiko nur schwer begründen.
- Werkzeugwechsel. Assistenten wechseln schnell, daher sollten Übungen zur Gewohnheit der Bewertung durchgeführt werden, nicht zu einem einzelnen Produkt.
- Fallabdeckung. Eine Übung zeigt einige Fehlertypen auf. Eine Punktzahl beschreibt nicht generell das Urteilsvermögen eines Entwicklers.
- Übertragung. Die Leistung in einem Workshop ist nicht dasselbe wie die Leistung in einer stark ausgelasteten Review-Warteschlange.
Weisen Sie die Sponsoren frühzeitig auf diese Probleme hin und planen Sie separate Lösungen. Schulungen verbessern die Fähigkeiten von Entwicklern, Fehler zu finden und nachzuweisen. Sie schaffen jedoch weder die Zeit noch die notwendigen Werkzeuge.
Häufig gestellte Fragen
Was ist KI-generiertes Code-Review-Training?
Es lehrt Entwickler, von einem KI-Assistenten erzeugten Code anzustoßen, zu bewerten und zu prüfen, Sicherheits-, Parallelitäts- und Effizienzprobleme zu finden und jedes Problem mit einem Test zu untermauern.
Ist generierter Code weniger sicher als von Menschen geschriebener Code?
Studien weisen auf Risiken hin, doch die Ergebnisse hängen vom verwendeten Tool, der Aufgabe und dem Studiendesign ab. Eine Nutzerstudie ergab, dass Teilnehmer mit einem Assistenten weniger sicheren Code schrieben und sich dabei sicherer fühlten – ein Grund, das Überprüfen von Code zu trainieren.
Wie lässt sich beurteilen, ob Entwickler den generierten Code prüfen können?
Geben Sie eine neue Programmierübung und bewerten Sie die Verifizierungsqualität und die Fehlererkennung anhand vereinbarter Kriterien. Ein Quiz zu Regeln für sicheres Programmieren dient lediglich der Überprüfung der Voraussetzungen.
Benötigen Sie eine Code-Sandbox für die Schulung?
Sie benötigen eine Umgebung, in der Sie die Übungen ausführen können, üblicherweise Ihre eigene. Prüfen Sie, ob jedes von Ihnen verwendete Tool Ihre Anforderungen erfüllt, bevor Sie sich darauf verlassen.
Wo soll ich anfangen
Wählen Sie eine wiederkehrende Art von generierten Änderungen in Ihrer Codebasis. Verfassen Sie eine Performance-Beschreibung, lassen Sie einen Entwicklungsleiter die simulierten Fehler und die zugehörigen Tests validieren und erstellen Sie eine Bewertungsmatrix mit drei Kriterien (0 bis 2) und einer Liste kritischer Fehler. Testen Sie die Lösung zunächst mit einer kleinen Gruppe, bevor Sie sie flächendeckend einführen.
Um zu sehen, wie eine Auditübung live mit Ihrem eigenen Team durchgeführt und anschließend im eigenen Tempo wiederverwendet werden kann, erkunden Sie AhaSlides.
