GitLab erweitert seine Entwicklungsplattform in Version 19.2 um vier sogenannte agentische Funktionen. Agentisch bedeutet in diesem Zusammenhang, dass ein Sprachmodell nicht nur Vorschläge in einem Chatfenster ausgibt, sondern eigenständig mehrere Arbeitsschritte in der Plattform ausführt – etwa Code lesen, eine Änderung erzeugen und diese als Merge Request zur Prüfung einstellen. Zwei der vier Funktionen sind allgemein verfügbar, zwei stehen als Public Beta zum Ausprobieren bereit.

Was die vier Funktionen adressieren

Der Schwerpunkt liegt auf Aufgaben, die in Projekten regelmäßig anfallen, selten Priorität bekommen und trotzdem sicherheitsrelevant sind:

  • Verwundbare Abhängigkeiten aktualisieren: Bibliotheken von Drittanbietern, für die eine Sicherheitslücke gemeldet ist, sollen automatisch auf eine unkritische Version gehoben werden.
  • Codeänderungen auf Logikfehler prüfen: Die Analyse geht über formale Prüfungen wie Linting hinaus und sucht nach Fehlern in der Programmlogik selbst.
  • Automatisierte Abläufe im Terminal: Kommandozeilenschritte, die bisher manuell abgesetzt wurden, lassen sich an einen Agenten delegieren.
  • Automatisierte Workflows: Wiederkehrende Abläufe innerhalb der Plattform werden verkettet und selbstständig abgearbeitet.

Bemerkenswert ist weniger die einzelne Fähigkeit als der Ort: Die Funktionen sitzen in der Plattform, in der Repository, Pipeline, Merge Requests und Sicherheitsberichte ohnehin zusammenlaufen. Damit entfällt der Umweg über zusätzliche Werkzeuge, die erst Zugriff auf den Quellcode brauchen – ein Punkt, der in Ausschreibungen und Datenschutzprüfungen erfahrungsgemäß viel Zeit kostet.

Warum Dependency-Updates der interessanteste Fall sind

Veraltete Abhängigkeiten sind in vielen mittelständischen Projekten die größte offene Baustelle. Nicht, weil niemand davon weiß, sondern weil ein Update selten in ein Sprint-Budget passt: Version anheben, Änderungsprotokoll lesen, Tests laufen lassen, Folgefehler beheben. Genau diese Kette ist mechanisch genug, um sie an einen Agenten zu geben, und wichtig genug, um sie nicht liegen zu lassen.

Der Gewinn liegt dabei nicht in der reinen Geschwindigkeit, sondern in der Regelmäßigkeit. Ein Projekt, in dem Sicherheitsupdates kontinuierlich in kleinen Schritten eingespielt werden, bleibt aktualisierbar. Eines, in dem zwei Jahre nichts passiert, wird zum Migrationsprojekt mit eigenem Angebot.

Logikprüfung ersetzt kein Review

Bei der automatisierten Prüfung von Codeänderungen ist Zurückhaltung angebracht. Ein Modell kann auffällige Muster benennen, Randfälle ansprechen und Stellen markieren, die ein Mensch überlesen hätte. Ob eine Änderung fachlich das Richtige tut, entscheidet sich aber an Anforderungen, die nicht im Repository stehen. Der sinnvolle Einsatz ist deshalb der vorgeschaltete Durchgang: Der Agent räumt die offensichtlichen Punkte ab, das menschliche Review konzentriert sich auf Architektur und Fachlogik.

Dasselbe gilt für Terminal- und Workflow-Automatisierung. Wer Agenten Befehle ausführen lässt, verschiebt eine Frage von der Technik in die Organisation: Welche Rechte hat dieser Agent, welche Umgebungen darf er berühren, und wer bestätigt einen Schritt, bevor er in Produktion wirkt? Public-Beta-Funktionen gehören aus diesem Grund zunächst in Nebenprojekte oder in klar abgegrenzte Repositories, nicht in die Pipeline des umsatztragenden Systems.

Was Teams jetzt konkret tun können

  • Prüfen, welche der vier Funktionen im eigenen Lizenz- und Betriebsmodell überhaupt verfügbar sind, und die Beta-Funktionen von den allgemein verfügbaren trennen.
  • Ein Pilotprojekt mit überschaubarem Risiko auswählen und dort ausschließlich Dependency-Updates automatisieren.
  • Vorher klären, wie belastbar die Testabdeckung ist. Automatische Updates entfalten ihren Nutzen erst, wenn eine Pipeline zuverlässig sagt, ob etwas kaputtgegangen ist.
  • Festlegen, dass Agenten Vorschläge über Merge Requests einbringen und nicht direkt auf geschützte Branches schreiben.
  • Nach einigen Wochen messen, wie viele Vorschläge ohne Nacharbeit übernommen wurden – das ist die einzige belastbare Grundlage für eine Ausweitung.

Einordnung

Für Web- und Softwareprojekte verschiebt sich damit weniger die Frage, ob KI im Entwicklungsprozess mitarbeitet, als die Frage, wo die Kontrollpunkte liegen. Der praktische Hebel liegt in der Wartung: Wenn Sicherheitsupdates und Routineprüfungen verlässlich im Hintergrund laufen, bleibt mehr vom vereinbarten Budget für Funktionen übrig, die für das Geschäft sichtbar sind. Voraussetzung bleibt eine Pipeline mit aussagekräftigen Tests und klar definierten Freigaben – ohne sie automatisiert man nur die Geschwindigkeit, mit der Fehler ins System gelangen.

Quellen