GitHub hat in der zweiten Septemberwoche 2026 zwei Funktionen live geschaltet, die den Alltag vieler Entwicklungsteams direkt verändern: Am 9. September ging die agentische Autofix-Funktion für Code-Quality-Funde live, einen Tag später folgte die AI-Scan-API für Pull Requests im Public Preview. Beide Neuerungen zielen auf dasselbe Problem ab, nämlich die riesigen Backlogs an offenen Findings, die sich in wachsenden Codebasen ansammeln. Statt Entwicklerinnen und Entwickler einzeln durch jede Warnung klicken zu lassen, übernimmt Copilot jetzt ganze Batches auf einmal.
Für Teams in Österreich und im gesamten DACH-Raum ist das mehr als eine Randnotiz. Viele mittelständische Softwarehäuser nutzen GitHub Enterprise Cloud bereits als zentrale Codeplattform, und die neuen Automatisierungen verändern sowohl die Lizenzkosten als auch die Frage, wie viel Vertrauen man einem Agenten beim Anfassen von Produktionscode entgegenbringt. Dieser Artikel ordnet ein, was genau geliefert wurde, was es kostet, wie es im Vergleich zu GitLab Duo, Amazon Q Developer und Snyk Agent Fix abschneidet und wohin sich automatisierte Codepflege bis 2027 bewegen dürfte.
Was GitHub am 9. und 10. September 2026 wirklich geändert hat
Der erste Baustein betrifft GitHub Code Quality, das statische Analyseergebnisse zu Wartbarkeit, Performance und Stilverstößen sammelt. Bisher konnten Teams pro Fund höchstens einen einzelnen Fix generieren lassen. Seit dem 9. September lässt sich eine Seite mit bis zu 25 Standardfunden markieren und in einem einzigen Klick komplett an Copilot übergeben. Der Agent legt daraufhin einen eigenen Branch an, bearbeitet die Funde der Reihe nach, validiert seine eigenen Änderungen und öffnet am Ende einen fertigen Pull Request zur menschlichen Prüfung.
Der zweite Baustein, AI Scan für Pull-Request-APIs, geht einen Schritt weiter in Richtung Governance. Statt AI Scan pro Repository manuell in der Weboberfläche einzuschalten, können Sicherheitsteams jetzt über zwei REST-Endpunkte steuern, welche Repositories die KI-gestützte Sicherheitsprüfung bei Pull Requests nutzen dürfen. Organisationsweite Einstellungen stehen dabei über den einzelnen Repository-Einstellungen, ein deaktiviertes Organisations-Flag kann also nicht von einem einzelnen Team umgangen werden.
Beide Features sind bewusst getrennt positioniert: Code Quality plus Autofix kümmert sich um Wartbarkeit, AI Scan um Sicherheitslücken im Pull-Request-Fluss. GitHub verknüpft sie aber über dieselbe Abrechnungslogik, nämlich AI-Credits, die auf ein bestehendes Copilot-Abonnement aufsetzen.
Agentic Autofix für Code Quality: So funktioniert die Massenbehebung
Technisch ersetzt die neue Funktion den alten Ein-Klick-Button “Generate fix” durch einen einheitlichen Workflow namens “Assign to Copilot”, der sowohl für einzelne als auch für gebündelte Funde gilt. Wählt eine Entwicklerin 25 Findings gleichzeitig aus, arbeitet der Agent sie nicht parallel, sondern sequenziell auf einem gemeinsamen Branch ab und prüft nach jeder Änderung, ob der Code weiterhin kompiliert beziehungsweise die bestehenden Tests besteht. Erst danach entsteht der Pull Request, den ein Mensch freigeben muss, bevor er in den Hauptzweig gelangt.
Wichtig für Enterprise-Kunden: Die bereits bestehenden Governance-Regeln für Code Quality gelten unverändert weiter. GitHub hat bewusst keinen separaten Schalter für Bulk-Autofix eingeführt, sodass Administratorinnen und Administratoren nicht zusätzlich nachjustieren müssen. Die Funktion ist verfügbar für Repositories mit aktiviertem GitHub Code Quality auf den Stufen GitHub Team und GitHub Enterprise Cloud, inklusive Bereitstellungen mit Datenresidenz-Option. Auf GitHub Free oder Pro taucht die Massenbehebung bislang nicht auf.
Von “Generate Fix” zu “Assign to Copilot”: Der neue Workflow im Detail
Der alte Ansatz, ein Fix pro Klick, wirkte bei kleinen Repositories praktikabel, skalierte aber schlecht. Wer nach einem größeren Refactoring plötzlich 200 offene Quality-Findings vor sich hatte, musste den Button 200 Mal drücken oder die Warnungen ignorieren. Genau dieses Skalierungsproblem adressiert GitHub jetzt mit der Batch-Grenze von 25 Funden pro Seite. Das ist kein zufällig gewählter Wert, sondern orientiert sich erkennbar an der Kapazität eines einzelnen Pull Requests, den ein menschlicher Reviewer noch in vertretbarer Zeit durchsehen kann.
Aus Sicht eines Tech Leads verändert das die Reviewpraxis. Ein Pull Request mit 25 automatisiert behobenen Findings lässt sich nicht mehr Zeile für Zeile lesen wie ein handgeschriebener Commit, sondern muss stichprobenartig und diff-fokussiert geprüft werden. Teams, die bislang jede Änderung vollständig nachvollzogen haben, müssen ihre Review-Checkliste anpassen, etwa indem sie automatisch erzeugte Pull Requests klar kennzeichnen und getrennte Freigabe-Regeln dafür definieren.
AI Scan für Pull Requests: Sicherheitsprüfung per API steuern
AI Scan ist die neuere, KI-basierte Ergänzung zu GitHubs etabliertem CodeQL-Scanner. Während CodeQL auf handgeschriebenen Abfrageregeln basiert und eine explizite Konfiguration (“Default Setup”) verlangt, kann AI Scan laut einem separaten Changelog-Eintrag vom 16. September 2026 inzwischen auch ganz ohne CodeQL-Default-Setup laufen. Das erweitert die Abdeckung auf Repositories, die bislang gar nicht für klassisches Code-Scanning konfiguriert waren.
Die neuen API-Endpunkte lauten /orgs/{org}/code-scanning/ai-scan für die Organisationsebene und /repos/{owner}/{repo}/code-scanning/ai-scan für einzelne Repositories. Sicherheitsteams können damit einen gestuften Rollout fahren, etwa zunächst nur bei fünf Pilot-Repositories aktivieren, Ergebnisse auswerten und erst danach organisationsweit ausrollen, statt jedes Repository manuell in der Weboberfläche umzustellen. Verfügbar ist die Funktion aktuell ausschließlich auf github.com für Kunden mit GitHub Advanced Security, GitHub Enterprise Server wird in diesem Preview noch nicht unterstützt.
Voraussetzungen, Lizenzen und AI-Credits: Was die Automatisierung kostet
Beide Funktionen sind an ein bestehendes Copilot-Abonnement gekoppelt und verbrauchen AI-Credits, sobald der Agent tatsächlich Code anfasst. Für den älteren, aber verwandten Copilot Autofix für CodeQL-Findings gilt laut Drittanbieter-Analysen ein Umrechnungskurs von einem AI-Credit pro US-Cent, mit einem monatlichen Grundkontingent von 3.900 Credits pro Nutzer, das GitHub bis 1. September 2026 temporär auf 7.000 angehoben hatte. Für die neue Code-Quality-Autofix-Funktion nennt GitHub selbst keine exakten Credit-Kosten pro Fund, bestätigt aber, dass jede Zuweisung an Copilot Credits verbraucht.
Zugriff auf die Grundfunktionen setzt mindestens einen kostenpflichtigen Copilot-Plan voraus. Die aktuelle Preisstruktur bewegt sich zwischen einem kostenlosen Hobby-Tarif und einem Enterprise-Modell für große Organisationen, AI Scan zusätzlich noch GitHub Advanced Security. Für kleinere österreichische Softwarefirmen bedeutet das in der Praxis: Wer nur den günstigsten Copilot-Plan gebucht hat, sieht die neuen Autofix-Buttons zwar in der Oberfläche, kann sie aber ohne Advanced-Security-Lizenz beziehungsweise ohne Team/Enterprise-Cloud-Vertrag nicht nutzen.
Tabelle: GitHub-Copilot-Preisstufen und Zugriff auf Autofix-Funktionen
| Plan | Preis | Code-Quality-Autofix | AI Scan für PRs |
|---|---|---|---|
| Hobby | Kostenlos | Nein | Nein |
| Pro | 20 $/Monat | Nein (Code Quality nicht verfügbar) | Nein |
| Pro+ | 60 $/Monat | Nein (Code Quality nicht verfügbar) | Nein |
| Teams | 40 $/Nutzer/Monat | Ja, mit Code Quality | Nein (github.com only, siehe Enterprise) |
| Ultra | 200 $/Monat | Ja, mit Code Quality | Nein (Einzelplan, keine Org-Steuerung) |
| Enterprise | Individuell | Ja, inkl. Data Residency | Ja, mit GitHub Advanced Security |
Die Tabelle zeigt deutlich, dass die eigentliche Automatisierungstiefe den größeren Organisationsplänen vorbehalten bleibt. Für Einzelentwickler oder kleine Teams ohne Enterprise-Cloud-Vertrag bleiben viele der neuen Governance-Werkzeuge vorerst unerreichbar.
Von CodeQL bis Agentic Autofix: Wie GitHub Code-Automatisierung seit 2024 ausbaut
Die September-Updates stehen nicht isoliert da, sondern sind der vorläufige Endpunkt einer Entwicklung, die im März 2024 begann. Damals startete Copilot Autofix für CodeQL-Scan-Alerts als öffentliche Beta, die Kombination aus CodeQL-Scan-Engine und einem großen Sprachmodell. Nach einer mehrmonatigen Betaphase zwischen Mai und Juli 2024 erreichte die Funktion am 14. August 2024 die allgemeine Verfügbarkeit für alle GitHub-Advanced-Security-Kunden auf github.com.
Die damals veröffentlichten Betadaten waren beachtlich: Laut GitHubs eigener Auswertung wurden Schwachstellen mit Fix-Vorschlag im Schnitt dreimal schneller behoben als ohne, bei Cross-Site-Scripting sogar siebenmal, bei SQL-Injection zwölfmal schneller. Die mittlere Zeit von der Alert-Meldung bis zur automatisierten Behebung sank auf 28 Minuten, verglichen mit 90 Minuten bei manueller Bearbeitung. Im Juli 2026 folgte dann eine agentische Version des Autofix für Code-Scanning-Alerts im Public Preview, mit einer Erfolgsquote von rund zwei Dritteln bei minimaler Nacharbeit durch Entwicklerinnen und Entwickler, laut unabhängigen Auswertungen der Betaphase.
Die September-2026-Updates bringen diese Logik nun auf zwei neue Bereiche: Code Quality statt reiner Sicherheitslücken, und API-gesteuerte Governance statt Klick-Konfiguration. Der rote Faden über alle drei Ausbaustufen hinweg ist derselbe: GitHub verschiebt die Verantwortung vom Erkennen einer Schwachstelle zum tatsächlichen Schließen der Lücke, und bepreist genau diesen letzten Schritt separat über AI-Credits.
Marktvergleich: GitHub Copilot Autofix gegen GitLab Duo, Amazon Q und Snyk
GitHub ist mit automatisierter Fund-Behebung nicht allein am Markt. GitLab Duo bietet mit der Vulnerability Resolution eine ähnliche Funktion: Erkennt ein CI/CD-Sicherheitsscan eine Schwachstelle, erklärt Duo das Risiko und erzeugt direkt eine Merge Request mit dem passenden Patch, etwa parametrisierte Abfragen zur Entschärfung von SQL-Injection. Der strukturelle Unterschied liegt im Datenmodell: Duo kann auf CI/CD-Kontext, Sicherheitsfunde und Deployment-Historie zugreifen, weil all das innerhalb derselben GitLab-Plattform liegt. Copilot hingegen bezieht sich primär auf den Pull-Request-Kontext, da CI/CD-Daten bei vielen GitHub-Nutzern in externen Systemen wie Jenkins oder CircleCI liegen.
Amazon Q Developer automatisiert Code-Reviews direkt in der IDE, kommentiert verdächtige Codemuster, liefert wo möglich Patches und bewertet das Deployment-Risiko. Die Stärke liegt in der tiefen AWS-Integration, etwa bei automatisierten Code-Upgrades für ältere Java-Versionen, die im AWS-Ökosystem als besonders ausgereift gelten. Wer allerdings nicht überwiegend auf AWS-Infrastruktur setzt, profitiert von diesem Vorteil kaum.
Der dritte relevante Player ist der spezialisierte Sicherheitsanbieter Snyk, der im Februar 2026 seine “AI Security Fabric” vorstellte und sich damit vom reinen Scanner-Anbieter zur Plattform für KI-generierten Code weiterentwickelt. Die zugehörige Autofix-Funktion Snyk Agent Fix wurde im Mai 2026 auf eine agentische Architektur umgestellt und erreicht laut unabhängigen Feldtests eine Autofix-Genauigkeit von rund 80 Prozent bei einer Reduktion der mittleren Behebungszeit um 84 Prozent. Snyk stützt sich dabei auf eine eigene Datenbank mit mehr als 35.000 von Experten geschriebenen Fixes, die dem Sprachmodell als Kontext dient, und bietet seit 2026 auch MCP-Server-Unterstützung für Claude Code und Cursor.
Tabelle: Autofix-Systeme im direkten Vergleich
| Anbieter | Fokus | Kontextquelle | Batch-Fähigkeit | Kernkennzahl |
|---|---|---|---|---|
| GitHub Copilot Autofix | Code Quality + Sicherheitslücken (CodeQL/AI Scan) | Pull Request, Code-Scanning-Alerts | Bis zu 25 Funde pro Batch | 3x schnellere Behebung (CodeQL-Beta 2024) |
| GitLab Duo Vulnerability Resolution | Sicherheitslücken aus CI/CD-Scans | CI/CD-Pipeline, Deployment-Historie | Einzelfund pro Merge Request | Root-Cause-Analyse in Duo Enterprise |
| Amazon Q Developer | Code-Review, Upgrades, Sicherheitsmuster | IDE, AWS-Infrastruktur | Review pro Pull Request | Automatisierte Java-Versions-Upgrades |
| Snyk Agent Fix | Schwachstellen in Code, Modellen, Agent-Workflows | Snyk-Datenbank mit 35.000+ Fixes | Agentische Einzelbehebung | 80 % Autofix-Genauigkeit, -84 % MTTR |
Im direkten Vergleich zeigt sich, dass GitHub bei der reinen Batch-Größe (25 Funde auf einmal) derzeit vorn liegt, während Snyk bei der reinen Fix-Genauigkeit die konkreteren, extern validierten Zahlen liefert. GitLab Duo punktet dort, wo Teams bereits vollständig auf GitLab als CI/CD-Plattform setzen, weil der zusätzliche Pipeline-Kontext echte Vorteile bei der Root-Cause-Analyse bringt.
Was das für Entwicklerteams in Österreich bedeutet
Für heimische IT-Abteilungen, von Banken in Wien bis zu Softwaredienstleistern in Linz oder Graz, verschiebt sich mit den neuen Funktionen eine Kostenfrage, die bislang eher im Hintergrund lief. Bisher kalkulierten viele Teams Copilot-Kosten primär über die Zahl der Sitzplätze. Mit AI-Credits als zusätzlicher Verbrauchsgröße wird die Rechnung variabler, ähnlich wie bei Cloud-Rechenzeit. Ein Team, das plötzlich hunderte Code-Quality-Findings in einem Legacy-Repository automatisiert beheben lässt, kann damit einen spürbaren Ausschlag im monatlichen Credit-Verbrauch auslösen, den Finanzabteilungen im Auge behalten sollten.
Gleichzeitig verstärkt die neue API-Steuerung für AI Scan genau die Governance-Anforderungen, die durch das österreichische NIS-2-Umsetzungsgesetz ohnehin schon auf viele Unternehmen zukommen. Wer als NIS2-pflichtiger Betrieb nachweisen muss, wie Sicherheitsprüfungen im Softwareentwicklungsprozess verankert sind, kann die neuen Org-Level-Endpunkte nutzen, um einen dokumentierten, gestuften Rollout über alle Repositories hinweg zu belegen, statt sich auf Einzelkonfigurationen pro Team zu verlassen.
Risiken und Kritik: Warum menschliche Reviews weiterhin nötig bleiben
So praktisch die Massenbehebung klingt, sie verschiebt auch Risiko. Ein Pull Request mit 25 automatisiert erzeugten Änderungen verführt dazu, die Freigabe pauschal zu erteilen, statt jede einzelne Änderung zu prüfen. Genau das ist der Punkt, an dem unabhängige Analysen zur Vorsicht raten: Bei einem akademischen Test über 117 überprüfte Dateien identifizierte Copilot in einem konkreten Testszenario null Sicherheitslücken, obwohl bekannte Schwachstellen im Code vorhanden waren. Das betraf zwar primär die Review-Funktion und nicht direkt den neuen Bulk-Autofix, zeigt aber, dass die Erkennungsrate je nach Szenario stark schwanken kann und keine Garantie für Vollständigkeit besteht.
Hinzu kommt eine strukturelle Einschränkung: Copilot arbeitet im Wesentlichen mit dem Kontext des einzelnen Pull Requests und kann geteilte Bibliotheken oder Abhängigkeiten über Repository-Grenzen hinweg nur eingeschränkt einbeziehen, ein Problem, das bei sehr großen Monorepos mit mehreren hunderttausend Dateien besonders sichtbar wird. Teams sollten automatisiert erzeugte Pull Requests deshalb weiterhin durch mindestens eine menschliche Prüfung schleusen, insbesondere wenn Änderungen an sicherheitsrelevantem Code wie Authentifizierung oder Zahlungsabwicklung betroffen sind.
Wie Teams die Umstellung jetzt konkret angehen sollten
Wer die neuen Funktionen produktiv nutzen will, sollte nicht sofort den gesamten Backlog an Code-Quality-Findings auf einmal an Copilot übergeben. Sinnvoller ist ein stufenweiser Einstieg: zuerst ein einzelnes, gut getestetes Repository auswählen, dort einen kleinen Batch von fünf bis zehn Funden automatisiert beheben lassen und die entstandenen Pull Requests vollständig durchsehen. Erst wenn sich zeigt, dass die Fixes zuverlässig sind und keine Tests brechen, lohnt sich die Ausweitung auf größere Batches bis zur 25er-Grenze und auf weitere Repositories.
Parallel dazu sollten Engineering-Leads die Review-Prozesse anpassen. Ein separates Label oder eine eigene Pull-Request-Vorlage für automatisiert erzeugte Änderungen hilft, diese im Review-Alltag von handgeschriebenen Beiträgen zu unterscheiden. Sicherheitsteams wiederum sollten die neuen AI-Scan-Endpunkte nutzen, um zunächst in einer Testorganisation zu prüfen, wie sich aktivierte und deaktivierte Repository-Einstellungen im Zusammenspiel mit der Organisationsebene verhalten, bevor ein produktiver Rollout über hunderte Repositories hinweg gestartet wird. Wichtig ist außerdem, den Credit-Verbrauch von Anfang an zu monitoren, etwa über die von GitHub bereitgestellten Nutzungsmetriken, damit ein unerwartet hoher Autofix-Einsatz nicht erst auf der nächsten Rechnung auffällt.
Für Unternehmen, die noch keinen Enterprise-Cloud-Vertrag mit GitHub haben, lohnt sich zudem ein Blick auf die tatsächliche Größe des eigenen Quality-Backlogs, bevor ein Upgrade der Lizenzstufe verhandelt wird. Bei wenigen Dutzend offenen Findings dürfte der manuelle Aufwand geringer bleiben als die Mehrkosten eines Team- oder Enterprise-Plans. Bei mehreren Hundert bis Tausend Findings, wie sie in gewachsenen Legacy-Codebasen häufig vorkommen, kehrt sich diese Rechnung erfahrungsgemäß schnell um.
Beispiel: So sieht ein automatisiert erzeugter Fix-Branch aus
Um die Funktionsweise greifbarer zu machen, folgt ein vereinfachtes Beispiel dafür, wie ein von Agentic Autofix erzeugter Diff für ein typisches Code-Quality-Finding aussehen kann, in diesem Fall eine ungenutzte Variable und ein fehlender Null-Check in einer JavaScript-Funktion:
// Vorher: von Code Quality als Fund markiert
function getUserName(user) {
const unusedFlag = true;
return user.profile.name;
}
// Nachher: von Copilot Agentic Autofix erzeugt und validiert
function getUserName(user) {
return user?.profile?.name ?? "Unbekannt";
}
Der Agent entfernt die ungenutzte Variable und ergänzt sichere Zugriffsoperatoren, um einen möglichen Laufzeitfehler bei fehlendem Profil abzufangen. Genau solche kleinteiligen, aber zahlreichen Änderungen sind der Anwendungsfall, für den die 25er-Batch-Grenze gedacht ist, größere architektonische Refactorings bleiben weiterhin Aufgabe von Menschen.
Prognosen: Wohin sich automatisierte Codepflege bis 2027 entwickelt
Erstens dürfte GitHub die Batch-Grenze von aktuell 25 Funden in den kommenden Versionen erhöhen, sobald genug Telemetriedaten zur Erfolgsquote vorliegen, ähnlich wie sich auch die Credit-Kontingente beim älteren CodeQL-Autofix bereits einmal temporär verändert haben. Zweitens ist zu erwarten, dass AI Scan noch 2026 auch für GitHub Enterprise Server geöffnet wird, da die aktuelle Beschränkung auf github.com vor allem an der Preview-Phase liegt und nicht an einer technischen Notwendigkeit. Drittens werden Wettbewerber wie GitLab und Snyk ihrerseits stärker in Richtung Batch-Verarbeitung nachziehen, weil Kundinnen und Kunden nach den GitHub-Updates diese Fähigkeit zunehmend als Standardanforderung erwarten werden.
Viertens rechnen Marktbeobachter damit, dass Compliance-Anforderungen wie das österreichische NIS-2-Umsetzungsgesetz oder vergleichbare EU-Regeln dazu führen, dass Organisationen verstärkt auf API-steuerbare, auditierbare Sicherheitsprüfungen wie AI Scan umsteigen, statt auf manuell konfigurierte Einzellösungen. Fünftens dürfte sich die Preislogik über AI-Credits als Branchenstandard etablieren, weil sowohl GitHub als auch Snyk bereits nutzungsbasierte Komponenten in ihre Preismodelle eingebaut haben und reine Sitzplatzlizenzen bei stark schwankendem Agenteneinsatz zunehmend unpassend wirken.
Häufig gestellte Fragen zu GitHub Copilot Agentic Autofix und AI Scan
Was ist der Unterschied zwischen Agentic Autofix für Code Quality und dem älteren Copilot Autofix?
Der ältere Copilot Autofix aus 2024 behebt primär CodeQL-Sicherheitsfunde einzeln. Die neue, am 9. September 2026 gestartete Version adressiert stattdessen Code-Quality-Findings wie Wartbarkeits- oder Stilprobleme und kann bis zu 25 davon in einem einzigen Batch abarbeiten.
Brauche ich GitHub Advanced Security für Agentic Autofix?
Für die Code-Quality-Autofix-Funktion nicht zwingend, hier reicht ein Team- oder Enterprise-Cloud-Plan mit aktiviertem GitHub Code Quality. Für AI Scan bei Pull Requests ist GitHub Advanced Security dagegen Voraussetzung.
Funktioniert AI Scan auch auf GitHub Enterprise Server?
Nein, im aktuellen Public Preview vom 10. September 2026 ist AI Scan für Pull-Request-APIs ausschließlich auf github.com verfügbar. GitHub Enterprise Server wird in dieser Version noch nicht unterstützt.
Wie viele Findings kann Copilot auf einmal beheben?
Bei der Code-Quality-Autofix-Funktion lassen sich bis zu 25 Standardfunde pro Seite markieren und in einem Vorgang an Copilot übergeben, der daraus einen einzigen Pull Request erzeugt.
Kostet die automatische Behebung zusätzlich zum Copilot-Abo?
Ja, jede Zuweisung an Copilot verbraucht AI-Credits, die zusätzlich zum jeweiligen Abonnement anfallen. Der genaue Umrechnungskurs für die neue Code-Quality-Funktion wurde von GitHub bislang nicht im Detail veröffentlicht.
Wie unterscheidet sich GitHub Copilot Autofix von GitLab Duo Vulnerability Resolution?
GitLab Duo kann auf CI/CD-Kontext und Deployment-Historie innerhalb derselben Plattform zugreifen, was bei komplexeren Root-Cause-Analysen hilft. Copilot bezieht sich primär auf den Pull-Request-Kontext, bietet dafür aber mit der 25er-Batch-Funktion aktuell eine höhere Verarbeitungsmenge pro Vorgang.
Muss ich automatisierte Pull Requests trotzdem manuell prüfen?
Ja. GitHub selbst weist darauf hin, dass jeder von Copilot erzeugte Pull Request vor dem Merge von einem Menschen überprüft werden muss. Unabhängige Tests zeigen zudem, dass die Erkennungsrate je nach Codebasis stark schwanken kann.
Gilt die neue Autofix-Funktion auch für kleine Repositories außerhalb von Unternehmen?
Nein, die Bulk-Funktion ist an GitHub Team oder GitHub Enterprise Cloud mit aktiviertem Code Quality gebunden. Auf den Einzelplänen Pro und Pro+ steht Code Quality in dieser Form derzeit nicht zur Verfügung.




