Agentisches Coding ist nur so gut wie sein Kontext

Jede Woche zeigt eine neue Demo eines Coding-Agenten, wie ein Prompt in unter fünf Minuten zu einem Pull Request wird. Diese Demos konzentrieren sich oft auf einen engen Anwendungsfall, der noch nicht in der Produktion ist, und überspringen alles, was nach dem Commit passiert.

Der Pull Request enthält keinen Link zu dem Issue, das er lösen sollte. Die CI/CD-Pipeline schlägt fehl, weil der Agent nichts von einer kürzlich hinzugefügten Linter-Regel wusste. Ein Security-Scan markiert eine Abhängigkeit, die der Agent eingezogen hat, ohne die genehmigte Liste des Projekts zu prüfen.

Das sind Kontextfehler – und sie entscheiden darüber, ob agentisches Coding die Auslieferung beschleunigt oder Nacharbeit erzeugt. Wenn Entwicklungsteams Coding-Agenten mit GitLab einsetzen, greifen die Agenten auf die Issues, Pipelines und Security-Policies zurück, die bereits in der Plattform vorhanden sind, erkennen Probleme und beheben sie im Developer-Flow.

Dieser Artikel zeigt, was sich ändert, wenn einem Coding-Agenten schrittweise mehr Lifecycle-Kontext gegeben wird – vom reinen Repository bis zur vollständigen Plattform-Sichtbarkeit – anhand zweier aktueller GitLab-Tutorials. Dabei wird deutlich, wie Plattform-Kontext Code-Qualität, Security-Bewertungen und Review-Zyklen verbessert und was Platform-Teams heute tun können, um die Lücke zu schließen.

Kontext in der Praxis

Die GitLab-Tutorials zeigen, was passiert, wenn einem externen Coding-Agenten schrittweise mehr vollständiger Plattform-Kontext gegeben wird. Das erste Tutorial illustriert drei Workflows mit Claude Code: das Beheben eines C++-Sensor-Absturzes, das Anreichern der Session mit dem GitLab-MCP-Server und den Einsatz von Claude Code als externem Agenten innerhalb eines Merge Requests zur Bearbeitung von Review-Feedback. Das zweite Tutorial folgt derselben Progression mit Codex und GitLab – diesmal beim Beheben eines Rust-WebSocket-Filterbugs in denselben drei Szenarien.

Szenario 1: Der Agent sieht nur das Repository Der Agent wird auf die Codebase gerichtet, das Problem im Prompt beschrieben. Der Agent liest Dateien, schlägt einen Fix vor und führt den Build aus. Der Fix funktioniert, basiert aber nur auf dem, was der Agent aus lokalen Dateien und dem Prompt ableitet. Er kennt den organisationalen Kontext nicht: die Abnahmekriterien des Issues, die nicht-funktionalen Anforderungen oder die Review-Standards in der CI-Konfiguration. Der Code compiliert – ist aber möglicherweise nicht das, was das Team braucht.

Szenario 2: Der Agent sieht Repository und GitLab-Issue Mit dem verbundenen GitLab-MCP-Server kann der Agent das Issue abrufen, bevor er Code schreibt. Jetzt liest er die funktionalen Anforderungen, Implementierungsnotizen, Labels und Milestones. Im Codex-und-GitLab-Tutorial fügt der Agent Closes #32 in die Merge-Request-Beschreibung ein, weil er die Beziehung zwischen Code-Änderung und Issue versteht. Im Claude-Code-Tutorial verwendet der Agent get_issue, um den Bug-Report abzurufen, dann create_merge_request, um den MR mit den richtigen Referenzen zu erstellen. Diesmal ist der Fix das, was das Team geplant hat.

Szenario 3: Der Agent arbeitet innerhalb des Merge Requests Sobald der MR existiert, läuft der GitLab Code Review Flow automatisch und postet Feedback. In beiden Tutorials wird der Coding-Agent als externer Agent innerhalb des MR aufgerufen, um das Review-Feedback zu adressieren. Er fügt fehlende Tests hinzu, aktualisiert Dokumentationskommentare und behebt Validierungslücken, die das Review gefunden hat. Der Agent committed direkt in den MR-Branch, CI/CD-Pipelines laufen automatisch auf dem neuen Commit, und ein Reviewer kann das Ergebnis prüfen, ohne das Werkzeug zu wechseln.

In diesem Szenario demonstrieren beide Tutorials weniger Review-Runden und kürzere Zeit bis zum Merge.

Die Bedeutung von Plattform-Sichtbarkeit für agentisches Coding

Platform-Teams entscheiden, wie KI-gestützte Entwicklung über die gesamte Organisation funktioniert: welche Agenten erlaubt sind, auf welche Werkzeuge sie zugreifen dürfen, wie Ausgaben verifiziert werden und wo menschliche Entscheidungen im Prozess getroffen werden.

Der Agent braucht Kontext, um Änderungen zu produzieren, denen die Organisation vertrauen kann – und dieser Kontext lebt in der DevSecOps-Plattform. Der Issue-Tracker listet Anforderungen auf. Die CI/CD-Konfiguration setzt den Qualitätsstandard. Code-Review-Anweisungen kodifizieren Style und Standards des Teams. Security-Scanner setzen Schwachstellen-Richtlinien durch. Und der Merge Request ist der Ort, wo alles zusammenkommt – das finale menschliche Gate.

Ein Agent mit Plattform-Kontext folgt demselben Workflow, den Entwicklungsteams verwenden – und innerhalb derselben Leitplanken. Der Unterschied zeigt sich in Review-Zyklen, Pipeline-Erfolgsquoten und Zeit bis zum Merge.

Ein IDE- oder Terminal-basierter Agent, so leistungsfähig er auch sein mag, sieht nur die Dateien, die ihm übergeben werden. Die Plattform hat Zugriff auf den vollständigen Lifecycle: vom Issue, der Pipeline und der Security-Policy bis zum Deployment-Ziel und den Freigabe-Regeln. Diese Sichtbarkeitslücke ist der Grund, warum die Plattform – nicht der Agent – bestimmt, was sicher ausgeliefert wird.

Die Auswirkungen auf die Sicherheit, wenn Agenten mehr Code produzieren

In allen Tutorials laufen CI/CD-Pipelines und Code-Review automatisch bei jedem Merge Request, den der Coding-Agent erstellt. Security Scanning ist Teil der Pipelines, auch wenn die Tutorials sich auf Code-Qualität und nicht auf Security-Findings konzentrieren. Für Platform-Teams wird Kontext noch entscheidender, wenn Security im Spiel ist.

Coding-Agenten produzieren mehr Code, schneller. Mehr Code bedeutet mehr eingeführte Schwachstellen, mehr von Scannern markierte Findings und mehr Fix-MRs.

• Früher: Vor dem Einzug von KI-Coding-Agenten in den Workflow lag der Engpass auf der Seite derApplication-Security: scannen, Findings priorisieren, wichtige an Entwickler eskalieren, auf einen Fix warten.
• Heute: Dank Agenten, die Code-Produktion und Remediation beschleunigen, verschiebt sich der Engpass. Der Workflow entwickelt sich weiter von „Welche Schwachstelle sollten wir zuerst beheben?" zu „Welchen KI-generierten Fix-MR sollte ein Mensch zuerst prüfen und freigeben?"

Diese Entscheidung erfordert Kontext, den der Coding-Agent nicht hat: den umgebenden Projektcode, den vollständigen Datenfluss, das Deployment-Ziel und die Security-Policies, die über die gesamte Organisation gelten.

• Mit Kontext schärft sich die Priorisierung: Ein Agent, der im umgebenden Code, Datenfluss und anwendbaren Policies verankert ist, kann Findings nach realer Exposition in der eigenen Umgebung einordnen – statt nach generischen Schweregrad-Scores – und zeigt, was wichtig ist, bevor Reviewer Zyklen darauf verwenden.

Genau wie der Coding-Agent im zweiten Szenario besseren Code produzierte, als er das GitLab-Issue lesen konnte, liefert die Security-Schicht bessere Bewertungen, wenn sie den vollständigen Anwendungskontext lesen kann statt einer einzelnen Datei.

GitLabs Security-Schicht analysiert Findings mit vollständigem Projektkontext, filtert erkannte False Positives und markiert bestätigte Schwachstellen. Wenn eine Schwachstelle bestätigt ist, liest die agentische SAST-Schwachstellenbehebung den verwundbaren Code und umgebenden Kontext aus dem Repository und erstellt automatisch einen Merge Request mit einem vorgeschlagenen Fix. Die Pipeline läuft zur Validierung. Ein Reviewer prüft und trifft die finale Merge-Entscheidung. Der Agent übernimmt die Remediation – das Governance-Modell bleibt intakt.

CI/CD-Quality-Gates, Code-Review-Anweisungen und Security Scanning laufen alle im Merge Request – und dort arbeiten Coding-Agenten. Je effektiver diese Kontrollen am Punkt der Code-Erstellung sind, desto weniger Schwachstellen erreichen die Produktion.

Benutzerdefinierte Anweisungen mit AGENTS.md

Beide Tutorials nutzen AGENTS.md-Dateien im Repository. Das sind benutzerdefinierte Anweisungen für Agenten: wie das Projekt strukturiert ist, welche Befehle ausgeführt werden sollen und wie die Code-Qualitätsanforderungen aussehen – einschließlich was nicht angefasst werden soll.

Im Codex-und-GitLab-Tutorial definierte die AGENTS.md-Datei alles von der Rust-Edition bis zum asynchronen Nebenläufigkeitsmuster und der CI-Image-Pinning-Policy. Der Agent brauchte keinen im Prompt wiederholten Kontext. Er las die Datei und folgte den Regeln.

Diese einmalige Investition zahlt sich bei jeder Agenten-Interaktion aus – ob der Agent lokal im Terminal läuft, via MCP verbunden ist oder als externer Agent innerhalb eines Merge Requests arbeitet. Die Standardisierung von AGENTS.md über Projekte hinweg verbessert die Qualität der Agenten-Ausgaben, da jede Agenten-Session – lokal oder remote – dieselben Regeln liest.

Grenzen des Kontextfensters

Große Sprachmodelle haben begrenzte Kontextfenster, und Forschungsergebnisse zeigen, dass die Modellleistung abnimmt, wenn die Kontextauslastung 30–40 % übersteigt. Je mehr Werkzeuge, Dateien und Anweisungen in eine Session gepackt werden, desto weniger zuverlässig reasoning der Agent.

Reichhaltiger Lifecycle-Kontext ist wertvoll: Issue, Review-Anweisungen, Pipeline-Historie und Security-Policy. Entscheidend ist aber, dass dieser Kontext strukturiert, relevant und effizient bereitgestellt wird.

Statt jede Agenten-Session Kontext von Grund auf rekonstruieren zu lassen – durch das Lesen von Dateien und unnötige API-Aufrufe, die das Kontextfenster verwässern und Token verbrauchen –, kann eine Plattform, die die Beziehungen zwischen Code, Issues, Pipelines und Deployments versteht, den richtigen Kontext zum richtigen Zeitpunkt liefern. GitLab erfasst viele dieser Beziehungen über den gesamten Lifecycle und ist damit in der Position, Kontext strukturierter bereitzustellen. Wenn die Plattform weiß, welches Issue ein Merge Request adressiert, welche Services eine Code-Änderung betrifft und welche Pipelines das Ergebnis validieren, kann sie dieses Wissen als strukturierten Kontext liefern – statt es aus Fragmenten zusammenzusetzen.

Die Effizienz KI-gestützter Entwicklungsworkflows hängt davon ab, wie gut die Plattform strukturierten Kontext liefert – nicht von der Größe des Modell-Kontextfensters.

Agenten verkürzen den Loop

Wenn ein Coding-Agent Review-Feedback innerhalb eines Merge Requests adressiert, handelt er auf das Review hin. Der Agent liest das Feedback, nimmt die gewünschten Änderungen vor, committed sie und lässt CI/CD das Ergebnis validieren. Der Reviewer prüft das Ergebnis, genehmigt oder fordert weitere Änderungen und trifft die finale Merge-Entscheidung.

Freigabe-Regeln, Code-Owner, Security-Policies und Audit-Trails bleiben alle erhalten. Der Agent beschleunigt den Revisions-Zyklus, ohne die Kontrollen drumherum zu umgehen.

Externe Agenten in GitLab Duo Agent Platform lassen sich über Event-Trigger und Custom Flows weiter integrieren und geben Platform-Teams Kontrolle darüber, wann und wie Agenten im Workflow agieren.

Erste Schritte mit agentischem Coding

Wer evaluiert, wie Coding-Agenten in den Entwicklungsworkflow der Organisation passen:

Einen sichtbaren Bug in einem echten Projekt wählen: Das erwartete Verhalten in einem GitLab-Issue mit klaren Anforderungen definieren. Dieselbe Progression wie in den Tutorials durchlaufen: lokal mit dem Agenten aus dem Repository beheben, GitLab MCP verbinden, damit der Agent vom Issue aus arbeitet, und den Agenten als externen Reviewer einsetzen, um Feedback im Merge Request zu adressieren.

In AGENTS.md investieren: Dokumentieren, wie das Repository funktioniert, welche Befehle relevant sind und wie die Code-Qualitätsanforderungen aussehen. Diese Anweisungen sorgen für höhere Qualität der Agenten-Ausgaben, die sich über Zeit summiert, je mehr Agenten und Entwickler mit dem Projekt interagieren.

Kontextverbrauch beobachten: Wenn Agenten-Sessions langsam, teuer oder oberflächlich sind, liegt das Problem wahrscheinlich am bereitgestellten Kontext – nicht am Modell selbst. Strukturierter, relevanter Kontext über Plattform-Integrationen schlägt rohe Datei-Dumps.

Security-Abdeckung prüfen: Mit steigender Anzahl von Merge Requests durch Coding-Agenten über Projekte hinweg sicherstellen, dass jedes Projekt gescannt wird. Security Configuration Profiles auf Group-Ebene anwenden, damit Scanner automatisch aktiviert sind, dann mit dem Security Inventory die Abdeckung bestätigen und verstehen, wo sich Schwachstellen konzentrieren.

Jetzt mit agentischem Coding loslegen

Die Organisationen, die das Meiste aus agentischem Coding herausholen, werden diejenigen sein, die über DevSecOps-Plattformen verfügen, die Agenten den richtigen Kontext und die richtigen Kontrollen geben, um sicher auszuliefern.

GitLab Duo Agent Platform noch nicht im Einsatz? Mit einer kostenlosen Testversion starten.

Wer GitLab bereits im Free Tier nutzt, kann GitLab Duo Agent Platform in wenigen einfachen Schritten einrichten.

Für bestehende GitLab Premium- oder Ultimate-Abonnenten genügt es, Duo Agent Platform zu aktivieren und die enthaltenen GitLab-Promotional-Credits zu nutzen.