원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
Log in to leave a comment
아직 작성된 글이 없습니다
Seitdem KI-Tools in den Produktionscode Einzug gehalten haben, hat sich das Bild von Repositories verändert. Laut einer Studie von GitClear, einem Unternehmen für Software-Repository-Datenanalysen, das über 211 Millionen Zeilen Produktionscode zwischen 2020 und 2024 analysierte, stieg die Code Churn – der Prozentsatz des Codes, der innerhalb von zwei Wochen nach dem Mergen geändert oder vollständig gelöscht wird – von ehemals 3,1 % auf bis zu 7,1 % an. Auch die empirische Analyse der Code-Review-Plattform CodeRabbit zeigt, dass von künstlicher Intelligenz generierter Code pro Pull Request 1,7-mal mehr Mängel aufweist als von Menschen geschriebener Code. Mängel in der Geschäftslogik treten 75 Prozent, fehlende Fehlerbehandlungen 2-mal und Sicherheitslücken 2,74-mal häufiger auf. Einer Studie von SmartBear zufolge sinkt die Fehlererkennungsrate von Reviewern unter 70 Prozent, sobald die Änderungsgröße eines einzelnen Pull Requests 400 Zeilen überschreitet. Hunderte von Zeilen, die von Junioren eingereicht werden, zeilenweise zu lesen wie bisher, führt zu kognitiver Überlastung und führt letztendlich dazu, dass kritische strukturelle Mängel unentdeckt bleiben.
Um manuelle Review-Engpässe zu durchbrechen, müssen Senior Engineering Leads aufhören, sich wie Syntax-Inspektoren zu verhalten, und stattdessen als Systemarchitekten agieren. Betrachten Sie den Pull Request als eine vom Compiler ausgespuckte, unvalidierte Binärdatei und starten Sie ein Architekturprüfungsprotokoll, das die strukturelle Integrität in nur 10 Minuten beurteilt. In den ersten 3 Minuten gleichen Sie die zu lösenden Aufgaben des Textes mit der Diff Delta ab, der Liste der tatsächlich geänderten Dateien. Wenn Module oder Konfigurationsdateien beigemischt sind, die in der Erklärung nicht erwähnt werden, sollten Sie den Detailcode gar nicht erst lesen, sondern ihn sofort ablehnen. In den folgenden 4 Minuten prüfen Sie, ob die Präsentationsschicht die Geschäftsdienste umgeht und direkt auf die Datenbank zugreift, d. h., ob Domänengrenzen verletzt wurden. In den verbleibenden 3 Minuten überwachen Sie das System im Hinblick auf die Zusicherung von Idempotenzschlüsseln und Rollbacks verteilter Transaktionen, um festzustellen, ob es Ausfällen externer APIs oder Parallelitätskonflikten standhält. Erstellen Sie im Repository unter .github/pull_request_template.md ein Feld für Architektur-Entscheidungsprotokolle und ursprüngliche Prompts, und öffnen Sie nicht einmal den Diff für Code, der keine alternativen Entwürfe enthält.
Bevor ein Mensch den gesamten Code liest, müssen alle durch Maschinen erkennbaren Fehler aussortiert werden. Nachdem das japanische Fintech-Unternehmen freee das semantische Code-Review-Tool CodeRabbit in 285 Repositories integriert hatte, sparte es innerhalb von 6 Monaten 32,8 Wochen an Ressourcen von Senior-Reviewern und erreichte eine Akzeptanzrate von 54 Prozent bei wichtigen Fehlermeldungen. Review-Benachrichtigungen werden nur für Pull Requests an den Senior gesendet, die die dreistufigen automatisierten Filter passiert haben, wodurch der Zeitaufwand für die manuelle Prüfung halbiert wird.
Serielle Validierungsfilter müssen in die CI-Pipeline eingebaut werden. In der ersten Phase, der deterministischen statischen Analyse, werden ESLint, Biome und Ruff ausgeführt, um Linter-Warnungen zu Fehlern hochzustufen und die zyklomatische Komplexität pro Funktion auf maximal 15 zu begrenzen. In der zweiten Phase, der strengen Typ- und Architekturenvarianten-Prüfung, wird strict: true in tsconfig.json aktiviert und die Umgehung nicht autorisierter Schichten durch dependency-cruiser verhindert. In der dritten Phase, dem semantischen LLM-Code-Review, werden CodeRabbit oder Qodo angebunden, um P1- und P2-Fehler sowie fehlende Tests abzufangen. Wenn die vorherige Phase nicht zu 100 Prozent bestanden wird, wird die nächste Phase oder die Zuweisung menschlicher Reviewer strikt blockiert.
Wenn KI-Agenten in monolithische Strukturen oder Legacy-Codebases eingesetzt werden, kommt es zu einer Kontextkontamination, bei der das Modell die bestehenden gemeinsamen Dienstprogramme ignoriert und eigenständige Implementierungen kopiert und generiert. Da .cursorrules im Single-Root-Dateiformat den Kontext des Modells mit zunehmender Projektgröße übermäßig beansprucht, sollte die modularisierte Struktur .cursor/rules/*.mdc verwendet werden. Da MDC-Dateien nur dann bedingt injiziert werden, wenn ein bestimmtes Dateimuster Ziel der Arbeit ist, wird der Token-Verbrauch um über 40 Prozent reduziert und gleichzeitig die Einhaltung der Regeln maximiert.
Um die Integrität der Kerndomäne zu wahren, müssen Verzeichnisse zwangsweise gesperrt werden. Erstellen Sie im Stammverzeichnis eine Datei namens .cursor/rules/core-boundaries.mdc und definieren Sie Kernverzeichnisse wie src/core/ledger/** zusammen mit der Einstellung alwaysApply: true als schreibgeschützt. Fügen Sie .cursor/rules/api-contracts.mdc hinzu, um das Löschen von Feldern des bestehenden Antwortschemas bei Arbeiten an der API-Schicht zu verbieten und die Verwendung von Domänen-Ausnahmeklassen zu erzwingen. Registrieren Sie .env* und den Migrationsverlauf in .cursorignore, um zu verhindern, dass das Modell sensible Informationen scannt. Das redundante Erstellen von Dienstprogrammen durch den Agenten sinkt um über 90 Prozent.
Wenn ein Junior die Erstellung von Unit-Tests an die künstliche Intelligenz delegiert, übersteigt die Zeilenabdeckung zwar 90 Prozent, jedoch treten Fehler in der Geschäftslogik auf, die nicht abgefangen werden – sogenannte „schweigende Fehler“. Der einzige Weg zu überprüfen, ob Tests ordnungsgemäß funktionieren, ist der Mutationswert, der misst, ob die Tests absichtlich injizierte Codefehler erkennen und fehlschlagen lassen.
Integrieren Sie das Stryker-Mutationstest-Framework in die CI-Pipeline. Erstellen Sie stryker.config.json im Stammverzeichnis, fügen Sie src/domains/**/*.ts zum Eintrag mutate hinzu und setzen Sie den Wert von thresholds.break auf 70. Fügen Sie den Befehl npx stryker run --since origin/main zum GitHub-Actions-Workflow .github/workflows/mutation-gate.yml hinzu, um nur geänderten Code inkrementell zu überprüfen. Von Freitag, 15:00 Uhr bis 18:00 Uhr, wird die Entwicklung neuer Funktionen eingestellt und stattdessen der Fokus auf die Beseitigung überlebender Mutanten und die Konsolidierung von dupliziertem Code gelegt. Liegt der Mutationswert von neuem Code unter 70 Prozent, gibt die Pipeline sofort einen Fehler aus und blockiert das Mergen.
Das größte Problem bei der Einführung von KI ist die Kluft zwischen der Passivität des Seniors und der blinden Abhängigkeit des Juniors. Shopify vertritt den Grundsatz, dass selbst dann, wenn 95 Prozent des Codes von einem Sprachmodell verfasst wurden, der Ingenieur, dessen Name im Pull Request steht, die volle Verantwortung für jede einzelne Zeile trägt. Leads müssen eine Routine etablieren, um den blinden Glauben der Junioren zu brechen und Know-how zur Kontextinjektion zu vermitteln.
Um die Prompt-Manipulationsfähigkeiten der Junioren anzupassen, wird wöchentlich eine 30-minütige Intensivklinik abgehalten. In den ersten 10 Minuten, in denen der Junior ein Sprint-Ticket mitbringt, den Bildschirm mit dem Senior teilt und Anweisungen an den Agenten erteilt, wird beobachtet, ob er vage Anforderungen stellt. In den mittleren 10 Minuten demonstriert der Senior beispielhaft Context Engineering, bei dem die Fehlerbehandlungsregeln und das Transaktionsisolationsniveau des Projekts zum Zeitpunkt der Prompt-Eingabe als Einschränkungen vorgegeben werden. In den letzten 10 Minuten wird dem Junior beigebracht, sich von der künstlichen Intelligenz nicht nur eine einzige richtige Antwort geben zu lassen, sondern mehrere Architekturmuster zu vergleichen und fehlende Randbedingungen als Testfälle zu hinterfragen. Durch diesen Prozess sinkt die Prompt-Fehlerrate von Junioren um über 60 Prozent.
