Immer mehr Code in Ihrem Repository wird von einem Agenten geschrieben als noch vor einem Jahr, und dieser Anteil wird weiter steigen. Agenten sind gut darin, etwas zum Laufen zu bringen. Sie sind gut darin, sich selbst zu entblocken. Was sie nicht können, ist zu wissen, welche Compliance-Rahmenbedingungen Ihr Unternehmen erfüllen muss, weil diese Informationen in einem Richtliniendokument stehen, das sich weit außerhalb ihres Kontextfensters befindet.
Das Ergebnis ist eine neue und wachsende Quelle für Compliance-Risiken: Code, der korrekt ist, gemergt wurde und leise nicht mehr mit einer Kontrolle übereinstimmt, von der niemand dem Agenten erzählt hat.
Der praktische Wildcard
Ein Agent verbindet einen neuen internen Dienst, und eine Cross-Origin-Anfrage schlägt fehl. Der schnellste Weg, den Aufruf zu entblocken, besteht darin, jeden Ursprung zuzulassen. Der Agent tut dies, die Anfrage ist erfolgreich, die Aufgabe wird als erledigt markiert. Es ist ein nachvollziehbarer Schritt für etwas, dessen Aufgabe es ist, den Code zum Laufen zu bringen.
app.use(cors({- origin: ["https://app.example.com"],+ origin: true, // reflect any origin credentials: true,}))Warum dies die neue Grenze ist
Von Menschen verursachte Kontrollabweichungen passieren durch einen nachlässigen PR nach dem anderen. Von Agenten verursachte Kontrollabweichungen passieren mit der Geschwindigkeit und dem Volumen, mit denen Agenten arbeiten, und ohne das implizite Urteilsvermögen eines erfahrenen Ingenieurs ('sollte ich das wirklich für alle öffnen?'). Der Agent optimiert für die vor ihm liegende Aufgabe, und 'SOC 2 CC6.1 erfüllen' ist nicht die vor ihm liegende Aufgabe.
Je größer der Anteil des von Agenten geschriebenen Codes wird, desto größer wird auch der Anteil der Änderungen, die kein Mensch sorgfältig auf Compliance überprüft hat. Das ist die Abweichung, und sie summiert sich.
Der Pull Request ist der einzige Kontrollpunkt
Sie können das Richtlinien-PDF nicht in den Kontext jedes Agenten legen und darauf vertrauen, dass er es einhält. Aber die Arbeit des Agenten kommt trotzdem als Pull Request an, und der Pull Request ist der einzige Ort im Workflow, an dem eine Änderung vor dem Deployment überprüft werden kann, unabhängig davon, ob sie von einer Person oder einem Agenten stammt.
heygrc ist darauf ausgelegt, jeden PR gegen Ihre Rahmenbedingungen zu prüfen und die Kontrolle zu benennen, die eine Änderung betrifft, unabhängig davon, ob sie von einem Agenten oder einem Menschen stammt, sodass der praktische Wildcard als CC6.1-Problem direkt im Diff markiert wird.