Anforderungen rein, Infrastruktur raus: ein Managed Service wechselt zur agentischen Entwicklung

Anfang dieses Jahres haben wir einem Managed Service Provider (MSP) geholfen, die Entwicklung seiner Kernplattform, der Infrastructure as Code (IaC), die Cloud-Infrastruktur und Workloads seiner Kunden auf Azure bereitstellt und pflegt, von Azure DevOps zu GitHub Enterprise zu verlagern und die Arbeitsweise seines Teams rund um KI-Agenten neu aufzubauen. Teammitglieder liefern heute echte Infrastrukturänderungen, indem sie beschreiben, was sie brauchen. Senior Engineers behalten die Kontrolle über Review und Freigabe. Das hat sich verändert.

Wo es begann

Die Plattform begann als Azure-DevOps-Umgebung: in Terraform geschriebene Infrastruktur für die Managed-Services-Kunden, validiert und bereitgestellt über CI/CD-Pipelines in Azure DevOps. Es funktionierte, skalierte aber mit Menschen, nicht mit der Nachfrage. Ein Senior Engineer konnte nur eine begrenzte Zahl komplexer Aufgaben gleichzeitig übernehmen. Die Auslieferung lief über Hunderte Pipeline-Dateien, die meisten davon kundenspezifische Kopien, sodass jede übergreifende Änderung in allen wiederholt werden musste. Mitwirken hieß, Terraform zu kennen, die Namensregeln, die Repository-Struktur und ihre Logik. Das Wissen lebte in einem einzigen Kopf.

Der Umzug

Wir haben zunächst die GitHub Enterprise selbst unter Code gestellt, dann das Repository der Plattform mit seiner vollständigen Historie verschoben und alle Pipelines innerhalb einer einzigen Woche zu GitHub Actions migriert. Die Hunderte Pipeline-Dateien schrumpften zu einer wiederverwendbaren Bereitstellungsvorlage, die sich aus der Konfiguration heraus über jeden Kunden und jede Umgebung auffächert, plus ein schlanker Workflow je Funktion. Eine Änderung, die früher in jeder Kopie bearbeitet wurde, wird jetzt einmal bearbeitet. Das Onboarding eines Kunden wurde zu einer Konfigurationsdatei, und diese Datei erstellt ein KI-Agent aus einer Anfrage in natürlicher Sprache, die als GitHub-Issue gestellt wird.

Governance als Code

Identitäten, Teams und Berechtigungen kommen aus Microsoft Entra ID und werden per Code angelegt. Der Branch-Schutz ist auf Organisationsebene festgelegt und kann von keinem Repository-Administrator gelockert werden: Jede Änderung braucht ein genehmigendes Review, und Produktionsbereitstellungen durchlaufen eine menschliche Freigabe. Die Regeln sind für einen Menschen und für einen Agenten dieselben, und ein Mensch behält immer die Kontrolle.

Ein Regelwerk für Menschen und Agenten

Das Team pflegt einen zentralen Satz an Anweisungen, den jeder Agent für jede Aufgabe übernimmt, die er ausführt: wie das Repository aufgebaut ist, die Namenskonventionen, welche Werkzeuge zu verwenden sind, wie eine Änderung getestet und wie ein Pull Request geschrieben wird. Dieselben Regeln laufen als Prüfungen auf jedem Pull Request und als Hooks auf dem Rechner jedes Entwicklers, sodass eine Regel, die zählt, durchgesetzt und nicht nur aufgeschrieben wird.

Diese Leitplanken machen es sicher, dass weniger erfahrene Kolleginnen und Kollegen beitragen: Der Agent folgt dem Regelwerk, die Prüfungen fangen ab, was er falsch macht, und ein Senior Engineer hat das letzte Wort.

Die neue Arbeitsweise

Jeder im Team beschreibt seinen Bedarf als GitHub-Issue, oft mit GitHub Copilot entworfen, und weist ihn einem Coding-Agenten zu. Der Agent öffnet einen Pull Request. Die Prüfungen laufen. Ein Senior Engineer prüft, fordert wo nötig Änderungen an und gibt frei; der Agent iteriert im selben Pull Request. Der Merge löst die Bereitstellung aus, und die Produktion wartet weiterhin auf eine menschliche Freigabe. Im ersten Schritt fasst niemand Code an.

Die Senior Engineers nutzen KI-Assistenten interaktiv für Design, Debugging, Review und Betrieb, und diese Arbeit landet wie jede andere als geprüfte Pull Requests.

Was sich verändert hat

• Geschwindigkeit. Im ersten Monat nach dem Umzug lieferten die Agenten eigenständig Dutzende gemergte Änderungen, und sie liefern seitdem weiter. Heute wird rund ein Drittel aller gemergten Änderungen von Agenten geschrieben, und die meisten werden nach einer einzigen Review-Runde angenommen.
• Zeit bis zum Release. Eine gut beschriebene Anfrage geht in der Regel innerhalb eines Tages vom Issue zur gemergten Änderung, die Bereitstellung folgt automatisch, und viele dieser Anfragen sind noch am selben Tag erledigt.
• Komplexität. Hunderte Pipeline-Dateien wurden zu einer Vorlage. Formatierung, Dokumentation und Statusberichte erledigen Bots. Eine fehlgeschlagene nächtliche Bereitstellung eröffnet ihr eigenes Ticket, statt darauf zu warten, bemerkt zu werden. Die Senior Engineers hätten all das selbst bauen können; was die KI verändert hat, ist der Zeitrahmen: fertig in einem Zeitfenster, das kein menschliches Team hätte einhalten können.
• Qualität. Jede Änderung, von einem Menschen oder einem Agenten, durchläuft dieselben Prüfungen und dasselbe Review. Die Regeln leben im Repository, und der Prüfpfad reicht von der Anfrage bis zur Produktion.
• Teamkapazität. Der Engineer, der früher den Großteil des Codes schrieb, prüft und entscheidet jetzt. Der Beitrag eines zweiten Engineers wuchs um mehr als das Zehnfache. Zwei weitere Kollegen liefern Änderungen, indem sie sie beschreiben. Der Single Point of Failure ist verschwunden.

Was es eingespart hat

Als Schätzung entsprechen allein die von Agenten geschriebenen Änderungen in den ersten acht Monaten rund zwei bis drei Engineer-Monaten, nach Abzug der Review-Zeit, die sie brauchen. Der größere Gewinn ist schwerer zu zählen: Senior-Zeit für Design und Review statt für Routineänderungen, und ein Backlog, das nicht mehr auf eine einzelne Person wartet.

Was wir gelernt haben

• Agenten brauchen durchsetzbare Regeln, keine Prosa. Jede Richtlinie, die zählte, wurde zu einer Prüfung.
• Die Qualität der Anfrage entscheidet über die Qualität des Ergebnisses. Akzeptanzkriterien zu schreiben ist die neue Kernkompetenz.
• Im Review zahlt sich Seniorität aus. Das Team hat seine besten Leute an den Punkt mit der größten Hebelwirkung gesetzt.

Wir leben es vor

Unsere eigene Infrastruktur, Dokumentation, Website und GitHub-Organisation werden auf dieselbe Weise betrieben: Anfragen werden zu Issues, Agenten erledigen die Arbeit, jede Änderung ist ein geprüfter Pull Request hinter automatisierten Prüfungen, und ein Entscheidungsprotokoll und Runbooks halten den Prüfpfad fest. Die Seite, die Sie gerade lesen, ist so entstanden.

KI ersetzt Seniorität nicht und schließt sie auch nicht aus. Sie vervielfacht, was ein Team liefern kann, wenn die Regeln klar sind und die Senior Engineers das letzte Wort behalten. Sehen Sie, was wir in KI und agentischer KI und Team-Enablement anbieten.