Agentic Upgrades — wenn Automatisierung entscheidet
Wie wir mit KI-Agenten unsere automatisierten Projekt-Upgrades neu erfunden haben. Von der linearen Pipeline zum adaptiven System.
Das Problem klassischer Upgrade-Automatisierung
Automatisierte Updates sind nichts Neues. Seit Jahren setzen wir auf CI/CD-Pipelines, Dependency-Scanner und Infrastructure-as-Code, um Systeme aktuell zu halten. Trotzdem war da immer ein Problem: Automatisierung endet oft genau dort, wo echte Entscheidungen beginnen.
Typische Upgrade-Setups sehen heute so aus:
- Tools erkennen neue Versionen (z. B. Dependencies, Base Images).
- Pull Requests werden automatisch erstellt.
- Tests laufen durch (oder eben nicht).
- Ein Mensch entscheidet, ob gemerged wird.
Das funktioniert — aber nur bis zu einem gewissen Grad. Sobald es komplex wird, entstehen Reibungsverluste: Breaking Changes müssen interpretiert werden. Changelogs sind unstrukturiert oder unvollständig. Migrationsschritte sind nicht deterministisch. Security-Fixes konkurrieren mit Stabilitätsanforderungen. Das Ergebnis: Automatisierung erzeugt Arbeit, statt sie vollständig zu übernehmen.
Unser Ansatz: Agentic Upgrades
Wir haben begonnen, Upgrade-Prozesse nicht mehr als Pipeline, sondern als System aus kooperierenden KI-Agenten zu modellieren. Ein Agent übernimmt dabei nicht nur eine Aufgabe, sondern eine Rolle mit Verantwortung.
1. Analyse-Agent
- Bewertet neue Versionen semantisch (nicht nur Versionsnummern).
- Extrahiert relevante Änderungen aus Changelogs.
- Klassifiziert Risiken (Breaking / Minor / Security).
2. Migrations-Agent
- Leitet konkrete Code- oder Konfigurationsänderungen ab.
- Erstellt strukturierte Migrationspläne.
- Passt IaC, Dockerfiles oder Anwendungscode gezielt an.
3. Validierungs-Agent
- Führt Tests kontextbewusst aus.
- Erkennt nicht nur Fehler, sondern auch auffälliges Verhalten.
- Bewertet Ergebnisqualität, nicht nur Exit Codes.
4. Entscheidungs-Agent
- Aggregiert alle Signale.
- Trifft eine fundierte Merge- oder Rollback-Entscheidung.
- Dokumentiert die Entscheidung nachvollziehbar.
Der Unterschied: Von statischer Pipeline zu adaptivem System
Der zentrale Unterschied liegt nicht in der Technologie — sondern im Paradigma.
Vorher: Lineare Pipeline. Starre Regeln. Mensch als Engpass.
Heute: Dynamisches Zusammenspiel von Agenten. Kontextbasierte Entscheidungen. Mensch als Supervisor, nicht als Operator.
Das verändert die Qualität der Automatisierung fundamental.
Was sich konkret verbessert hat
Weniger manuelle Eingriffe. Upgrades laufen deutlich häufiger vollständig automatisiert durch — auch bei komplexeren Änderungen.
Bessere Risikoabwägung. Agenten bewerten Änderungen differenzierter als einfache Version-Bumps oder SemVer-Regeln.
Schnellere Security-Reaktionen. Kritische Updates werden priorisiert, eingeordnet und oft innerhalb kürzester Zeit produktiv gebracht.
Nachvollziehbarkeit. Jede Entscheidung ist dokumentiert — warum wurde gemerged, warum wurde ein Upgrade verworfen, welche Risiken wurden erkannt.
Technische Umsetzung (vereinfacht)
Unsere Agenten operieren typischerweise innerhalb bestehender DevSecOps-Strukturen:
- Integration in CI/CD (z. B. GitOps-Workflows).
- Nutzung von Repository-Kontext (Code, IaC, Historie).
- Zugriff auf Security-Datenquellen (CVEs, Advisories).
- Zustandsbasierte Kommunikation zwischen Agenten.
Wichtig dabei: die Agenten sind nicht isoliert, sondern teilen Kontext und bauen aufeinander auf.
Kein Ersatz für Engineering — sondern ein Multiplikator
Ein häufiger Irrtum ist die Annahme, KI würde Engineering ersetzen. Unsere Erfahrung ist eine andere: gute Agenten verstärken gutes Engineering — und scheitern an schlechtem. Ohne saubere Tests, klare Architektur und reproduzierbare Builds bringen auch die besten Agenten wenig.
Fazit
Mit Agentic Upgrades haben wir einen entscheidenden Schritt gemacht: von „Automatisierung, die vorbereitet“ zu „Automatisierung, die entscheidet“. Das Ergebnis sind stabilere Systeme, schnellere Reaktionszeiten und deutlich weniger operative Last. Und vielleicht am wichtigsten: wir können uns wieder stärker auf das konzentrieren, was wirklich zählt — das Bauen sinnvoller Systeme statt das Verwalten von Updates.
Eigene Upgrade-Pipeline überdenken?
Wenn eure Routine-Upgrades zu viel manuelle Arbeit erzeugen oder Security-Patches zu lange brauchen, schauen wir uns das in 30 Minuten an. Konkret, an eurem Setup. Kostenfrei, unverbindlich.
Häufige Fragen
Was uns Kundinnen und Kunden zu Agentic Upgrades am häufigsten fragen — offen beantwortet.
Brauchen wir dafür einen LLM-Vendor-Vertrag?+
Nicht zwingend. Die Agenten arbeiten modellanbieter-agnostisch — OpenAI, Anthropic, Mistral oder Self-Hosted. Wir bauen die Architektur so, dass ihr den Anbieter jederzeit wechseln könnt, ohne die Pipeline neu aufzusetzen.
Wie verhindert ihr, dass ein Agent etwas Falsches mergt?+
Jede Entscheidung läuft durch einen Validierungs-Schritt mit Tests, statischer Analyse und policy-basierten Gates. Bei kritischen Änderungen (Breaking, Security mit hohem Impact, fehlende Test-Coverage) eskaliert der Entscheidungs-Agent an den Menschen. Wir versprechen keine 100 % Autonomie — wir versprechen weniger Routine.
Funktioniert das auch bei Legacy-Code?+
Eingeschränkt. Ohne saubere Tests, klare Architektur und reproduzierbare Builds bringt der Ansatz wenig. Vor Agentic Upgrades steht oft erst eine Konsolidierungsphase: Tests stabilisieren, Builds reproduzierbar machen, Dependencies entwirren.
Was passiert, wenn ein Agent eine schlechte Entscheidung dokumentiert?+
Genau das ist der Punkt: weil jede Entscheidung dokumentiert ist, ist sie auch reviewbar. Wir auditieren regelmäßig die Entscheidungen unserer Agenten. Wenn Muster auftauchen, die nicht passen, justieren wir die Policies. Das ist näher an Engineering-Disziplin als an Magic.