Agentic Development Platform

Ein einzelner KI-Agent im Terminal ist ein Werkzeug. Sobald ein ganzes Team, mehrere Projekte und echte Compliance-Anforderungen dazukommen, braucht es mehr: eine Agentic Development Platform. Sie bündelt alles, was Agenten für verlässliche Arbeit benötigen – Aufträge, isolierte Umgebungen, Kontext, Zugriffsrechte, Prüfungen und Kostenkontrolle – und macht aus einzelnen Experimenten einen steuerbaren Entwicklungsprozess. Dieser Beitrag erklärt, was das ist, wie sie aufgebaut ist, was sie leistet, welche Herausforderungen es gibt und wer davon profitiert.

Inhaltsverzeichnis

• Was ist eine Agentic Development Platform? 🧩
• Warum reicht ein einzelner Agent nicht aus? 🤔
• Grundlagen: Die Schichten einer Plattform 🏗️
• Funktionen im Überblick ⚙️
  • Aufträge annehmen und verteilen 🎫
  • Sichere Ausführung in Sandboxes 🏖️
  • Kontext und Wissen bereitstellen 📚
  • Qualitätssicherung und Freigaben ✅
  • Beobachtbarkeit, Kosten und Audit 📊
• Selbst bauen, kaufen oder kombinieren? 🛒
• Herausforderungen beim Aufbau 🚧
• Herausforderungen in der Nutzung ⚠️
• Fortlaufende Pflege: Eine Plattform ist nie fertig 🔄
• Für wen eignet sich eine Plattform? 🎯
• Wie Kunden profitieren 🤝
• Der Einstieg in kleinen Schritten 🪜
• Häufige Fragen (FAQ) ❓
• Fazit: Von der Spielerei zum Prozess 🏁

Was ist eine Agentic Development Platform? 🧩

Eine Agentic Development Platform ist die gemeinsame Infrastruktur, auf der KI-Agenten Softwareaufgaben verlässlich, sicher und nachvollziehbar erledigen. Sie sorgt dafür, dass Agenten Aufträge bekommen, in abgesicherten Umgebungen arbeiten, den richtigen Kontext erhalten und ihre Ergebnisse geprüft werden, bevor sie in den Code gelangen.

Man kann sie mit einer CI/CD-Plattform vergleichen: Auch dort läuft nicht jeder Build auf dem Laptop eines Entwicklers, sondern in einer zentral gepflegten, abgesicherten und protokollierten Umgebung. Eine Agentic Platform macht dasselbe für Agenten als Mitarbeiter.

Die Kurzformel:

Plattform = Aufträge + Sandboxes + Kontext + Berechtigungen + Qualitätsprüfung + Beobachtbarkeit

Wie ein einzelner Agent funktioniert, beschreibt der Beitrag Agentic Development einfach erklärt. Hier geht es um das, was darum herum gebaut wird.

Warum reicht ein einzelner Agent nicht aus? 🤔

Für einen Entwickler an einem Projekt genügt ein Agent auf dem eigenen Rechner oft völlig. Im Unternehmen entstehen jedoch typische Probleme:

• Wildwuchs: Jeder nutzt andere Werkzeuge, Modelle und Einstellungen – niemand weiß, was wo läuft
• Sicherheitslücken: Agenten arbeiten mit den Zugangsdaten einzelner Personen und haben unnötig weitreichende Rechte
• Keine Nachvollziehbarkeit: Wer hat was wann von einem Agenten ändern lassen – und mit welchem Ergebnis?
• Unkontrollierte Kosten: Tokenverbrauch und Laufzeiten sind erst auf der Rechnung sichtbar
• Doppelte Arbeit: Jedes Team schreibt seine eigenen Regeln, Anleitungen und Integrationen neu
• Keine Skalierung: Der Agent läuft nur, solange der Rechner offen ist, und blockiert den Entwickler

Eine Plattform löst diese Probleme einmal zentral, statt sie in jedem Projekt neu zu lösen.

Grundlagen: Die Schichten einer Plattform 🏗️

Eine Plattform besteht aus mehreren Schichten, die aufeinander aufbauen:

Die Schichten im Einzelnen:

• Eingang: Hier entstehen Aufträge – meist im Ticketsystem, per Chat oder automatisch durch Ereignisse (z. B. fehlgeschlagene Pipeline, neue Sicherheitsmeldung)
• Steuerung: Der Orchestrator nimmt Aufträge an, begrenzt Parallelität und Kosten und weist sie geeigneten Agenten zu. Richtlinien legen fest, was ein Agent in welchem Projekt darf
• Ausführung: Die Agent-Runtime (Harness) führt die Schleife aus Modellaufruf und Werkzeugnutzung aus – in einer Sandbox, die pro Aufgabe frisch entsteht. Das Modell ist austauschbar angebunden
• Wissen: Projektregeln, wiederverwendbare Skills, externe Werkzeuge über MCP und durchsuchbare Dokumentation versorgen den Agenten mit dem, was er über das Projekt wissen muss
• Ergebnis: Alles landet als Merge Request im Repository und durchläuft dieselben Pipelines wie menschlicher Code
• Betrieb: Logs, Bewertungen, Kosten und Audit-Trails machen das Verhalten messbar und prüfbar

Funktionen im Überblick ⚙️

Aufträge annehmen und verteilen 🎫

• Annahme über Ticketsysteme wie Forgejo, GitLab, GitHub oder Jira, per Label oder Kommentar
• Warteschlange mit Prioritäten, Parallelitätsgrenzen und Wiederaufnahme bei Abbruch
• Zuweisung an spezialisierte Agenten: Code-Änderung, Review, Dokumentation, Dependency-Updates, Testerstellung
• Rückfragen des Agenten erscheinen als Kommentar im Ticket – Menschen antworten asynchron

Sichere Ausführung in Sandboxes 🏖️

• Pro Aufgabe eine frische, isolierte Umgebung (Container oder MicroVM), danach verworfen
• Netzwerkzugriff nur auf freigegebene Ziele (Allowlist)
• Kurzlebige, eng geschnittene Zugangsdaten statt der Schlüssel einzelner Personen
• Eigene Identität des Agenten, damit jede Aktion zuordenbar ist

Kontext und Wissen bereitstellen 📚

• Zentral gepflegte Projektregeln (AGENTS.md), Konventionen und Verbote
• Skills: wiederverwendbare Anleitungen für wiederkehrende Abläufe, etwa Release oder Migration
• MCP-Server als standardisierte Schnittstelle zu Ticketsystem, Wiki, Datenbankschema oder Monitoring – siehe agents.md zu groß? MCP als Lösung
• Spezifikationen als Auftragsgrundlage, wie im Beitrag Spec-Driven Development erklärt beschrieben

Qualitätssicherung und Freigaben ✅

• Jede Änderung läuft durch Tests, Linting, Security-Scans und SBOM-Erzeugung in der CI
• Review-Agenten als erste Prüfinstanz, der Mensch bleibt letzte Instanz
• Freigabe-Regeln: sensible Bereiche (Datenbankmigrationen, Infrastruktur, Authentifizierung) verlangen immer menschliche Zustimmung
• Deployments laufen nie automatisch, sondern werden bewusst ausgelöst

Beobachtbarkeit, Kosten und Audit 📊

• Traces aller Schritte: Was hat der Agent gelesen, ausgeführt, geändert?
• Kostenübersicht pro Projekt, Team und Aufgabentyp, mit Limits und Alarmen
• Kennzahlen: Erfolgsquote, Nacharbeit, Durchlaufzeit, Pipeline-Ergebnis beim ersten Versuch
• Audit-Trail für Compliance-Nachweise, etwa im Rahmen von NIS2 oder dem EU AI Act
• Evaluation: Testaufgaben mit bekannter guter Lösung, die bei jeder Änderung an Harness oder Modell erneut laufen

Selbst bauen, kaufen oder kombinieren? 🛒

Für viele Unternehmen im DACH-Raum ist die Kombination der pragmatische Weg: bestehende Werkzeuge (Git-Server, CI, Kubernetes) nutzen, Agenten-Runtime und Sandboxes darauf betreiben und Modelle über austauschbare Schnittstellen anbinden – bei Bedarf auch selbst gehostete Modelle. Als Grundlage bietet sich häufig ein vorhandener Kubernetes-Cluster an.

Herausforderungen beim Aufbau 🚧

• Sandbox-Design: Zu strenge Isolation macht Agenten nutzlos, zu lockere ist ein Sicherheitsrisiko. Der richtige Zuschnitt braucht Erfahrung
• Identität und Berechtigungen: Agenten brauchen eigene Identitäten mit minimalen, zeitlich begrenzten Rechten – in vielen Altumgebungen ist das nicht vorgesehen
• Integration: Ticketsystem, Git, CI, Wiki und Monitoring müssen sauber angebunden werden, oft mit historisch gewachsenen Besonderheiten
• Kontext-Qualität: Unvollständige oder widersprüchliche Projektdokumentation führt zu schlechten Ergebnissen. Die Plattform deckt Wissenslücken schonungslos auf
• Modellwahl und Abhängigkeit: Modelle entwickeln sich rasant. Die Plattform muss Wechsel erlauben, ohne alles umzubauen
• Datenschutz und Compliance: Wohin fließen Code und Daten? Wer darf was sehen? Auftragsverarbeitung, Datenresidenz und Aufbewahrungsfristen sind zu klären
• Kosten: Parallele, langlaufende Agenten verbrauchen viele Tokens. Ohne Limits und Transparenz drohen Überraschungen
• Zu früh zu groß: Wer sofort „die perfekte Plattform“ baut, verliert sich in Infrastruktur, bevor ein Agent echten Nutzen gebracht hat

Herausforderungen in der Nutzung ⚠️

• Review-Engpass: Agenten erzeugen schneller Änderungen, als Menschen sie prüfen können. Kleine, klar zugeschnittene Aufgaben und gute automatische Prüfungen sind Pflicht
• Aufgabenzuschnitt: Gute Tickets mit Akzeptanzkriterien werden zum zentralen Hebel. Vage Aufträge liefern vage Ergebnisse
• Vertrauen kalibrieren: Weder blindes Vertrauen noch pauschales Misstrauen helfen. Man braucht Kennzahlen, welche Aufgabentypen zuverlässig funktionieren
• Akzeptanz im Team: Entwickler müssen ihre Rolle neu verstehen – weniger Tippen, mehr Formulieren, Prüfen und Entscheiden
• Schatten-Nutzung: Ist die Plattform umständlich, weichen Teams auf unkontrollierte Einzelwerkzeuge aus
• Verantwortung: Auch bei agentenerzeugtem Code bleibt das Team verantwortlich. Prozesse und Freigaben müssen das abbilden

Fortlaufende Pflege: Eine Plattform ist nie fertig 🔄

Eine Agentic Platform ist ein Produkt, kein Projekt. Sie braucht Eigentümer, Roadmap und regelmäßige Pflege:

Im Mittelpunkt steht der Harness – Anweisungen, Werkzeuge, Berechtigungen, Kontextregeln und Prüfschritte. Er ist die Stellschraube, nicht das Modell. Das gilt für jeden Agententyp einzeln, etwa Code-Änderung, Review, Dokumentation oder Dependency-Updates.

Was man messen sollte:

• Erfolgsquote: Wie viele Merge Requests werden ohne Nacharbeit übernommen?
• Nacharbeit: Wie viele Feedback-Runden sind nötig?
• Pipeline-Ergebnis: Besteht der Code Tests und Security-Scans beim ersten Versuch?
• Kosten und Dauer pro Aufgabe: Token-Verbrauch, Laufzeit, Abbrüche
• Sicherheitsvorfälle: Versuchte Zugriffe außerhalb der erlaubten Grenzen

Wie man systematisch besser wird:

1. Fehler sammeln: Jeder abgelehnte Merge Request ist eine Lernquelle
2. Muster erkennen: Wiederholen sich Fehler? („Agent vergisst immer, Tests zu ergänzen“)
3. Ursache im Harness beheben: Fehlende Regel, fehlendes Werkzeug oder unklare Fertig-Definition? Meist liegt es nicht am Modell
4. Regressionstest anlegen: Typische Aufgaben mit bekannter guter Lösung („Evals“) laufen bei jeder Harness-Änderung erneut
5. Spezialisieren: Mehrere Agenten mit klarem Auftrag, eigenem Kontext und eigenen Rechten statt eines Alleskönners – ein Review-Agent braucht keinen Schreibzugriff
6. Modellwechsel mit Evals absichern: Ein neues Modell ist erst dann besser, wenn die eigenen Aufgaben es belegen

Laufende Aufgaben:

• Harness und Kontext pflegen: Projektregeln aktuell halten, wiederkehrende Korrekturen in Regeln oder Skills überführen
• Evaluationen betreiben: Eine Sammlung typischer Aufgaben läuft bei jeder Änderung erneut, um Verschlechterungen früh zu erkennen
• Modelle bewerten und wechseln: Neue Modelle erst nach Test an eigenen Aufgaben produktiv nehmen
• Sicherheit prüfen: Sandbox-Konfiguration, Netzwerkregeln und Berechtigungen regelmäßig überprüfen, Abhängigkeiten aktuell halten
• Kosten steuern: Verbrauch je Aufgabentyp auswerten, Limits anpassen, günstigere Modelle für einfache Aufgaben einsetzen
• Agententypen weiterentwickeln: Spezialisierte Agenten nach Messdaten schärfen, schwache Aufgabenarten bewusst beim Menschen lassen
• Nutzer einbinden: Feedback aus den Teams sammeln, Schulungen anbieten, Vorlagen für gute Tickets bereitstellen

Ein praktischer Richtwert: Die Plattform wird nach den Ergebnissen beurteilt, nicht nach der Zahl der Funktionen – etwa Durchlaufzeit pro Ticket, Anteil ohne Nacharbeit übernommener Merge Requests und Kosten pro erledigter Aufgabe.

Abbildung: Blick auf das Dashboard einer Agentic Plattform Eigenentwicklung

Für wen eignet sich eine Plattform? 🎯

Weniger geeignet ist eine Plattform für sehr kleine Teams mit nur einem Projekt – hier genügt oft ein gut konfigurierter Agent mit lokaler Sandbox.

Wie Kunden profitieren 🤝

Auftraggeber sehen die Plattform nicht direkt, spüren aber ihre Wirkung:

• Schnellere Lieferung: Routineaufgaben laufen parallel und im Hintergrund, Änderungen erreichen den Kunden früher
• Planbare Qualität: Jede Änderung durchläuft dieselben Tests und Security-Prüfungen – unabhängig davon, wer oder was sie geschrieben hat
• Transparenz: Nachvollziehbare Tickets, Merge Requests und Prüfergebnisse statt „das Team arbeitet daran“
• Bessere Sicherheit: Isolierte Umgebungen, minimale Rechte und SBOMs reduzieren Risiken in der Software-Lieferkette
• Geringere Kosten bei Wartung und Modernisierung: Tests, Dokumentation und Migrationen, die sonst liegen bleiben, werden erledigt
• Datenhoheit: Bei selbst betriebener Plattform bleiben Code und Daten in der gewünschten Umgebung
• Weniger Abhängigkeit von Einzelpersonen: Wissen steckt in Regeln, Spezifikationen und Skills statt in Köpfen
• Nachweisbarkeit: Audit-Trails unterstützen Anforderungen aus Regulierung und Kundenaudits
• Mehr Fokus der Fachleute: Entwickler beschäftigen sich mit Architektur, Fachlichkeit und Beratung statt mit Fleißarbeit

Der Einstieg in kleinen Schritten 🪜

Ein bewährter Reifegrad-Pfad:

1. Ein Agent, lokale Sandbox, kurze Projektregeln – Erfahrung sammeln
2. Aufträge über Tickets – Agent legt Branch und Merge Request an
3. Automatische Prüfung ausbauen – Tests, Security-Scans und SBOM als Pflicht
4. Remote-Sandboxes – frische Umgebung pro Aufgabe, kurzlebige Zugangsdaten
5. Orchestrierung und Spezialisierung – mehrere Agententypen, Limits, Kostenübersicht
6. Evaluation und Audit – kontinuierliche Messung, Nachweise, geregelte Pflege

Jede Stufe bringt für sich Nutzen. Man muss nicht auf die vollständige Plattform warten.

Häufige Fragen (FAQ) ❓

Was ist der Unterschied zwischen einem KI-Coding-Tool und einer Plattform? Ein Coding-Tool unterstützt eine Person bei der Arbeit. Eine Plattform organisiert, begrenzt und überwacht die Arbeit vieler Agenten für viele Personen und Projekte.

Brauche ich dafür eigene Modelle? Nein. Die Plattform kann Cloud-Modelle anbinden. Bei hohen Datenschutzanforderungen lassen sich auch selbst gehostete Modelle einsetzen. Entscheidend ist, dass man sie austauschen kann.

Ersetzt die Plattform Entwickler? Nein. Sie übernimmt klar umrissene Aufgaben. Anforderungen klären, Architektur entscheiden und Ergebnisse verantworten bleibt Aufgabe von Menschen.

Wie sicher ist das? So sicher, wie sie gestaltet ist. Isolierte Sandboxes, minimale und kurzlebige Rechte, Netzwerk-Allowlists, Pflicht-Pipelines und menschliche Freigabe für kritische Bereiche sind die wichtigsten Maßnahmen.

Wie lange dauert der Aufbau? Ein erster nutzbarer Stand mit Ticket-Anbindung und Sandbox ist oft in wenigen Wochen möglich. Der Ausbau zur ausgereiften Plattform ist ein fortlaufender Prozess.

Was kostet das? Die Kosten bestehen aus Infrastruktur, Modellnutzung und vor allem Betrieb und Pflege. Eine Kostenübersicht pro Aufgabe gehört deshalb von Anfang an dazu.

Wie misst man den Erfolg? Anhand von Durchlaufzeit, Anteil ohne Nacharbeit übernommener Änderungen, Kosten pro Aufgabe und Qualitätskennzahlen aus der Pipeline.

Fazit: Von der Spielerei zum Prozess 🏁

Eine Agentic Development Platform macht KI-Agenten zu einem verlässlichen Teil des Entwicklungsprozesses: Aufträge kommen über bekannte Kanäle, die Arbeit läuft isoliert und protokolliert, Ergebnisse durchlaufen dieselben Prüfungen wie jeder andere Code, und der Mensch entscheidet. Der Aufbau ist anspruchsvoll, doch der Weg lässt sich in kleinen Schritten gehen. Wer Sicherheit, Kontext und Messbarkeit von Anfang an mitdenkt, schafft die Grundlage, damit Agenten dauerhaft Nutzen bringen – für das eigene Team und für die Kunden.

Wer eine Agentic Development Platform im eigenen Unternehmen planen, aufbauen oder bewerten möchte, findet in einem unverbindlichen Gespräch den passenden Einstieg – hier Kontakt aufnehmen.