Stellen Sie sich vor, Ihre IT bekommt von einem Sicherheitsscanner eine Liste mit offenen Warnungen: eine mögliche SQL-Injection hier, ein unsicherer Dateizugriff dort, insgesamt 25 Meldungen. Niemand hat Lust, sich Nachmittage lang durch diese Liste zu arbeiten, und genau deshalb bleiben solche Meldungen in vielen Unternehmen wochenlang liegen. Am 15. Oktober 2026 hat GitHub in seinem offiziellen Changelog eine Funktion für allgemein verfügbar erklärt, die genau an dieser Stelle ansetzt: den „Agentic Autofix“ für Code-Scanning-Alerts.

Der Ablauf ist schnell erzählt. Eine Meldung wird dem KI-Agenten Copilot zugewiesen. Der Agent sucht die betroffenen Dateien, schlägt eine Korrektur vor, lässt den Scanner CodeQL erneut laufen, um zu prüfen, ob die Meldung damit tatsächlich verschwindet, und öffnet am Ende einen Pull Request als Entwurf. Ein Mensch liest diesen Entwurf und entscheidet. Dieser Artikel ordnet ein, was die Quelle belegt, welche Voraussetzungen gelten, was das für ein Unternehmen mit zehn bis zweihundertfünfzig Beschäftigten bedeutet und warum der eigentliche Wert dieser Meldung nicht im Code liegt, sondern im Muster dahinter.

Wer liest bei Ihnen, was ein Agent als „erledigt“ meldet?

Im kostenlosen Strategiegespräch (30 Minuten) gehen wir gemeinsam durch, an welchen Stellen Ihrer Abläufe ein Agent Vorschläge erzeugen würde und wo ein Mensch gegenlesen muss, bevor etwas wirksam wird. Kostenlos und unverbindlich.

Kostenloses Strategiegespräch buchen (30 Minuten, amazing-agents.com/booking)

Was GitHub am 15. Oktober 2026 veröffentlicht hat

Die Primärquelle ist der Eintrag „Agentic autofix for code scanning alerts general availability“ im GitHub-Changelog vom 15. Oktober 2026. Die zentralen Aussagen, soweit sie dort stehen:

Dazu kommen drei Voraussetzungen, die in der Quelle genannt werden. Erstens muss ein Enterprise-Administrator die Richtlinie „Agentic autofix“ in den Advanced-Security-Richtlinien aktivieren. Zweitens kann danach ein Organisations- oder Repository-Administrator die Funktion in den Code-Security-Einstellungen einschalten. Drittens muss eine Copilot-Abrechnungsmethode hinterlegt sein.

Und es gibt eine Kostenangabe: Die Nutzung verbraucht AI Credits aus dem Code-Security-Budget sowie GitHub-Actions-Minuten. Die AI-Credit-Nutzung erscheint in der Enterprise-Abrechnung im Bereich „AI usage“ als Produkt „Advanced Security“, und es lassen sich Budgets pro SKU festlegen. Wie viel ein einzelner Fix kostet, nennt die Quelle nicht. Diese Zahl sollten Sie deshalb auch nirgends als gegeben übernehmen.

Verfügbarkeit: Was „allgemein verfügbar“ hier wirklich heißt

„Allgemein verfügbar“ klingt nach einem Knopf, den jeder drücken kann. Das ist hier nicht der Fall. Der Status ist GA, aber die Funktion ist an Voraussetzungen gebunden, die viele Mittelständler nicht erfüllen: ein Enterprise-Cloud-Vertrag bei GitHub, dazu Code Security oder Advanced Security, dazu eine freigeschaltete Richtlinie und ein hinterlegtes Abrechnungsmodell. Wer seinen Code in einem kleineren Tarif verwaltet oder gar nicht bei GitHub, kann den Autofix heute nicht einfach einschalten.

Zur Region schreibt die Quelle: Enterprise Cloud mit Data Residency ist eingeschlossen. Eine Länderbeschränkung nennt der Eintrag nicht. Eine ausdrückliche Aussage zu Deutschland, Österreich oder der Schweiz enthält er allerdings ebenfalls nicht. Ehrlich formuliert: Für Kunden, die die genannten Pakete haben, gibt es keinen erkennbaren regionalen Ausschluss. Mehr als das lässt sich aus der Quelle nicht ableiten.

Für die Einordnung heißt das: Für Unternehmen mit passendem GitHub-Vertrag ist der Agentic Autofix jetzt eine Funktion, die ihre IT prüfen und einführen kann. Für alle anderen gilt: Das Muster kommt auf Sie zu, auch in anderen Werkzeugen, und Sie können sich schon jetzt darauf vorbereiten. Genau dazu kommen wir weiter unten.

Das Muster hinter der Meldung: Der Agent prüft sich selbst, der Mensch entscheidet

Auffällig ist an der Ankündigung nicht, dass eine KI Code schreibt. Das ist seit Längerem Alltag. Auffällig ist die Reihenfolge der Schritte: erst ein Vorschlag, dann eine unabhängige Prüfung gegen ein vorhandenes Werkzeug, dann Nachbessern, und erst am Ende ein Ergebnis, das für Menschen lesbar aufbereitet ist, mit Zusammenfassung, Begründung und Prüfschritten. Der Mensch bekommt nicht „Hier ist eine Änderung“, sondern „Hier ist eine Änderung, hier ist, warum, und hier ist, wie wir geprüft haben, dass sie wirkt“.

Ein Agent, der sein Ergebnis gegen ein unabhängiges Prüfwerkzeug testet und dem Menschen die Begründung mitliefert, ist deutlich leichter zu kontrollieren als einer, der nur „fertig“ meldet.

Dieses Muster ist nicht auf Software beschränkt. Denken Sie an einen Agenten, der Eingangsrechnungen vorsortiert, Angebotsentwürfe vorbereitet oder Kundenanfragen beantwortet. Die gleiche Frage stellt sich überall: Gibt es ein zweites, unabhängiges Prüfwerkzeug, gegen das der Agent sein eigenes Ergebnis testet, bevor es ein Mensch zu Gesicht bekommt? Und bekommt der Mensch genug Information, um schnell und sicher zu entscheiden, statt nur blind abzunicken?

Man muss dabei sauber unterscheiden. Dass CodeQL den Fix des Agenten erneut prüft, ist eine interne Qualitätsschleife. Es ist keine menschliche Freigabe. Die Quelle beschreibt den Pull Request ausdrücklich als Entwurf, der in einem Review landet. Das ist die Stelle, an der ein Mensch entscheidet, ob die Änderung in Ihr Produkt gelangt. Dieser Schritt bleibt unverzichtbar, gerade bei Code, der Kundendaten, Zahlungen oder Produktionssteuerung berührt.

Was das für ein Unternehmen mit 10 bis 250 Beschäftigten heißt

Drei Dinge sind aus Sicht der Geschäftsführung wichtig.

Erstens: Liegengebliebene Sicherheitsmeldungen sind ein Risiko, das sich verkleinern lässt. Wenn der erste Entwurf einer Korrektur nicht mehr von einem Entwickler von Hand geschrieben werden muss, sinkt die Hürde, Meldungen überhaupt anzufassen. Das ist ein plausibler Nutzen. Eine belastbare Zahl dazu, wie viele Stunden das spart, liefert die Quelle nicht, und wir erfinden hier keine. Wer eine Rechnung aufmachen will, sollte sie mit den eigenen Zahlen machen: Wie viele offene Meldungen liegen heute auf der Halde, und wie viel Zeit kostet eine Meldung im Schnitt?

Zweitens: Die Prüfarbeit verschwindet nicht, sie verschiebt sich. Statt Code zu schreiben, liest Ihr Entwickler jetzt Entwürfe. Das kann schneller gehen, setzt aber voraus, dass jemand die Zeit und die Kompetenz dafür hat. Ein Entwurf, den niemand ernsthaft liest, ist schlechter als gar keiner, weil er das Gefühl von Sicherheit erzeugt, ohne sie zu liefern.

Drittens: Die Kosten sind nutzungsabhängig. AI Credits und Actions-Minuten laufen mit. Das ist kein Argument gegen die Funktion, aber ein Grund, vorab ein Budget zu setzen. Die Quelle weist ausdrücklich darauf hin, dass sich Budgets pro SKU festlegen lassen.

Zuordnung: Der Code-Operator

Auf amazing-agents.com beschreiben wir unseren Code-Operator als den Agenten für Bugs, Fixes und Pull Requests mit Ihrer Freigabe. Das Muster der GitHub-Meldung passt genau in dieses Bild: Der Agent bereitet die Arbeit vor, ein Mensch gibt frei. Wir betonen die Zuordnung bewusst, weil sie den Kern dessen trifft, worauf es ankommt. Eine Funktion wie der Agentic Autofix von GitHub ist ein Beispiel dafür, wie ein Hersteller diese Arbeitsteilung in sein Produkt einbaut. Ob Sie sie nutzen oder einen eigenen Ablauf aufbauen, die Grundfrage bleibt dieselbe.

Lassen Sie uns Ihre Prüf- und Freigabe-Schritte durchgehen, bevor ein Agent produktiv arbeitet.

Im kostenlosen Strategiegespräch (30 Minuten) klären wir, welche Ergebnisse Ihrer Abläufe einen Freigabe-Schritt brauchen und wer ihn übernimmt. Kostenlos und unverbindlich.

Kostenloses Strategiegespräch buchen (30 Minuten, amazing-agents.com/booking)

Agent mit Grenzen und Freigabe-Schritt: Ohne und mit

Um den Unterschied greifbar zu machen, hilft ein Gedankenspiel mit zwei Varianten desselben Ablaufs.

Ohne Freigabe-Schritt: Der Agent erkennt eine Sicherheitsmeldung, schreibt eine Korrektur und übernimmt sie direkt in den produktiven Code. Die interne Prüfung durch den Scanner sagt, dass die Meldung verschwunden ist. Was sie nicht sagt: ob die Änderung an anderer Stelle etwas kaputt macht, ob sie fachlich sinnvoll ist oder ob sie Rechte berührt, die der Agent nie hätte anfassen sollen. Der Fehler fällt erst auf, wenn ein Kunde ihn meldet.

Mit Freigabe-Schritt: Der Agent erkennt die Meldung, bereitet den Vorschlag vor, prüft ihn gegen den Scanner und legt einen Entwurf mit Begründung und Prüfschritten vor. Ein Mensch liest, stellt gegebenenfalls Rückfragen im Kommentarfeld und entscheidet, ob die Änderung übernommen wird. Der Agent hat die Fleißarbeit erledigt, die Verantwortung bleibt bei Ihnen.

Genau dieser zweite Ablauf entspricht dem, was die Quelle beschreibt, und er entspricht dem, wie wir Agenten grundsätzlich auslegen: mit klar benannten Grenzen, also dem, was der Agent darf und was nicht, und einem Freigabe-Schritt vor allem, was nach außen wirkt oder nicht leicht rückgängig zu machen ist.

Wie wir im Audit vorgehen

Wir behaupten hier keine Zahlen aus Kundenprojekten, sondern beschreiben, wie wir an die Frage herangehen, wenn Sie einen Agenten für technische Abläufe einführen wollen. Im kostenlosen Strategiegespräch gehen wir typischerweise in fünf Schritten vor:

  1. Ablauf aufnehmen. Wir lassen uns zeigen, wie heute mit Sicherheitsmeldungen, Fehlermeldungen oder Änderungswünschen umgegangen wird: wer sie sieht, wer sie bearbeitet, wie lange es dauert.
  2. Aufgaben trennen. Wir unterscheiden, was ein Agent vorbereiten kann (Vorschlag, Zusammenfassung, Prüfung) und was ein Mensch entscheiden muss (Übernahme, Veröffentlichung, Zahlung).
  3. Prüfwerkzeug festlegen. Wir klären, gegen welches unabhängige Werkzeug der Agent sein Ergebnis testet. Im Fall von GitHub ist das CodeQL.
  4. Freigabe-Schritt benennen. Wir legen fest, wer freigibt, in welchem Format ihm das Ergebnis vorgelegt wird und was passiert, wenn niemand reagiert.
  5. Grenzen und Kosten festschreiben. Wir halten fest, worauf der Agent zugreifen darf, und setzen ein Budget für nutzungsabhängige Kosten.

Das Ergebnis ist kein fertiges Produkt von der Stange, sondern ein Ablaufplan, mit dem Sie selbst oder gemeinsam mit uns entscheiden können, ob und wo ein Agent sinnvoll ist.

Das sollten Sie jetzt vorbereiten

Auch wenn Ihr Unternehmen die Voraussetzungen für den GitHub-Autofix heute nicht erfüllt, lohnt sich Vorbereitung. Die folgenden Schritte funktionieren unabhängig vom Werkzeug.

  1. Bestandsaufnahme der offenen Meldungen. Lassen Sie Ihre IT zusammenstellen, wie viele Sicherheits- oder Fehlermeldungen heute offen sind und wie alt die ältesten sind. Ohne diese Zahl lässt sich kein Nutzen einschätzen.
  2. Vertragslage klären. Fragen Sie Ihre IT oder Ihren Dienstleister, welchen GitHub-Tarif Sie haben und ob Code Security oder Advanced Security enthalten ist. Wenn nicht, ist das eine Entscheidung mit Kostenfolge, die Sie bewusst treffen sollten.
  3. Review-Zuständigkeit festlegen. Benennen Sie eine Person und eine Vertretung, die Entwürfe von Agenten gegenliest. Legen Sie fest, wie viel Zeit dafür eingeplant ist.
  4. Kritische Bereiche markieren. Entscheiden Sie, bei welchem Code ein Agent höchstens Vorschläge machen darf, etwa bei Zahlungen, Zugangsdaten oder personenbezogenen Daten, und schreiben Sie das auf.
  5. Budget und Datenschutz klären. Setzen Sie eine Obergrenze für nutzungsabhängige Kosten und lassen Sie Ihren Datenschutzbeauftragten prüfen, welche Daten der Agent verarbeitet.

Was die Quelle nicht sagt

Zur sauberen Einordnung gehört auch, was nicht belegt ist. Die Quelle nennt keine Zahl dazu, wie oft der Agent einen Alert tatsächlich korrekt behebt. Sie nennt keine Zeitersparnis und keine Kosten pro Fix. Sie sagt nichts darüber, wie sich der Agent bei Code verhält, der nicht zu den von CodeQL unterstützten Sprachen gehört. Und sie sagt, wie oben erwähnt, nichts Ausdrückliches zu Deutschland, Österreich oder der Schweiz. Wer den Autofix einführt, sollte deshalb mit einem kleinen, überschaubaren Bereich beginnen und beobachten, wie viele Entwürfe tatsächlich ohne Nacharbeit übernommen werden können.

Fazit

Der Agentic Autofix ist für Unternehmen mit passendem GitHub-Vertrag eine reale, allgemein verfügbare Funktion. Für alle anderen ist er ein Vorgeschmack. Das Muster dahinter ist übertragbar und es lohnt sich, es zu verstehen: Der Agent erledigt die Vorarbeit, prüft sich gegen ein unabhängiges Werkzeug und legt dem Menschen ein nachvollziehbares Ergebnis vor. Die Entscheidung bleibt beim Menschen. Das ist der Unterschied zwischen einem Agenten mit Grenzen und Freigabe-Schritt und einem Automatismus, der im Zweifel auch Fehler schneller produziert als jeder Mensch.

Agent mit Grenzen und Freigabe-Schritt: So sieht das bei Ihnen aus.

Im kostenlosen Strategiegespräch (30 Minuten) besprechen wir, wie ein Agent mit klaren Grenzen und einem Freigabe-Schritt in Ihre Abläufe passt, bevor Sie eine neue Funktion einführen. Kostenlos und unverbindlich.

Kostenloses Strategiegespräch buchen (30 Minuten, amazing-agents.com/booking)

Quellen