Laufendes Code Review oder Software-Wartung?
Timo Wevelsiep•Aktualisiert: 31.08.2026Hinweis zum Inhalt: Versionen, Befehle und Preise können sich ändern. Bitte prüfen Sie kritische Schritte vor dem produktiven Einsatz eigenständig. Dieser Leitfaden ersetzt keine individuelle Beratung.
Ihr Team entwickelt selbst weiter und braucht einen unabhängigen technischen Blick? Dafür ist der AI Code Review Retainer vorgesehen. Soll WZ-IT Updates, Korrekturen und Releases selbst umsetzen, passt Software-Wartung und laufende Betreuung.
Die Begriffe Code Review, Codepflege, Software-Wartung, Application Maintenance und technische Betreuung werden am Markt unterschiedlich verwendet. Für ein belastbares Angebot reicht die Bezeichnung deshalb nicht. Entscheidend ist, wer eine Änderung bewertet, wer sie programmiert, wer sie testet und wer sie produktiv veröffentlicht.
Die kürzeste Abgrenzung lautet:
- Code Review prüft und entscheidet.
- Software-Wartung verändert und veröffentlicht.
- Managed Operations betreibt und reagiert.
Alle drei Leistungen können zusammengehören, sollten aber im Angebot getrennt nachvollziehbar bleiben.
Verantwortungsmatrix
| Aufgabe | AI Code Review Retainer | Software-Wartung | Managed Operations |
|---|---|---|---|
| Neue Änderungen technisch prüfen | enthalten im vereinbarten Reviewkorridor | nur soweit für eigene Umsetzung nötig | nein |
| Auth, Rollen und Datenzugriff einordnen | ja, risikoorientiert | bei beauftragter Änderung | auf Betriebs- und Konfigurationsebene |
| Dependencies und CVEs bewerten | ja, für die Anwendung | ja, mit Blick auf Umsetzung | ja, für verantwortete Infrastruktur und Workloads |
| Code ändern oder Refactoring durchführen | nein | im vereinbarten Pflege- oder Engineering-Korridor | nein |
| Tests ergänzen oder anpassen | als Finding empfehlen | im vereinbarten Umfang umsetzen | Betriebsprüfungen, keine allgemeine Feature-Testentwicklung |
| Release vorbereiten und deployen | Risiko und Freigabekriterien einordnen | bei beauftragtem Releaseweg | Plattform und produktiven Betrieb nach Scope unterstützen |
| 24/7 auf Störungen reagieren | nein | nein | nur mit passendem Service Level |
| Backups und Restore verantworten | nur als Risiko prüfen | nicht automatisch | nach vereinbartem Recovery-Scope |
Die Matrix ist keine allgemeingültige Definition aller Anbieter. Sie beschreibt eine klare, prüfbare Trennung der WZ-IT-Angebote.
Was ein laufender Code-Review-Retainer leistet
Ein Review-Retainer ist eine technische Kontrollfunktion für Teams, die selbst entwickeln. Änderungen kommen beispielsweise von:
- einem internen Produktteam
- einer externen Softwareagentur
- einem Solo-Founder mit Cursor oder Claude Code
- Lovable, Bolt, Replit oder einem anderen KI-Builder
- mehreren Beteiligten in einem Co-Managed-Modell
WZ-IT betrachtet im vereinbarten Rhythmus die risikorelevanten Änderungen und ihre Wirkung auf das Gesamtsystem. Dazu können Quellcode, Authentifizierung, Autorisierung, Datenzugriffe, Dependencies, APIs, Migrationen und Releasefolgen gehören.
Das Ergebnis sind keine anonymen Scannerzahlen, sondern Entscheidungen:
- vor dem nächsten Release beheben
- kurzfristig korrigieren
- geplant als technische Schuld aufnehmen
- mit dokumentierter Begründung akzeptieren
Der Retainer reserviert Review- und Klärungskapazität. Er ist kein frei verwendbares Entwicklerstundenpaket. Diese Grenze schützt beide Seiten: Das Kundenteam weiß, dass unabhängige Prüfung tatsächlich stattfindet, und der Reviewer wird nicht vollständig von Umsetzungsaufgaben gebunden.
Was Software-Wartung zusätzlich übernimmt
Software-Wartung beginnt dort, wo aus einem Finding eine Änderung werden soll. Typische Aufgaben sind:
- Dependency-, Patch- und Minor-Updates vorbereiten
- kritische CVEs durch Patch, Update oder Mitigation behandeln
- technische Fehler analysieren und beheben
- Tests für veränderte oder kritische Pfade ergänzen
- Framework- und Runtime-Versionen planbar pflegen
- Datenbankmigrationen vorbereiten
- Releases auf Staging validieren und kontrolliert veröffentlichen
- kleinere technische Schulden im vereinbarten Korridor abbauen
Der Monatspreis kann trotzdem keine unbegrenzte Entwicklung abdecken. Der Leistungsumfang benötigt einen definierten Korridor nach Repository, Wartbarkeit, Testabdeckung, Releasefrequenz und erwarteter Änderungsmenge. Große Major-Upgrades, umfangreiche Refactorings oder neue Produktfunktionen werden separat geplant.
Bei unbekanntem Fremdcode ist vor laufender Softwarepflege regelmäßig eine Baseline nötig. Der Production Readiness Audit klärt, ob Build, Architektur, Tests und Deployment überhaupt ausreichend nachvollziehbar sind.
Beispiel: Eine kritische Dependency-Meldung
Eine neue CVE zeigt besonders gut, wie Review und Wartung zusammenwirken.
1. Signal erfassen
Dependabot, ein anderer Scanner oder ein Herstellerhinweis meldet eine betroffene Paketversion. Das Signal enthält häufig CVSS-Wert, Versionsbereich und eine allgemeine Beschreibung.
2. Betroffenheit einordnen
Im Review wird geprüft:
- Ist genau die eingesetzte Version betroffen?
- Wird die verwundbare Funktion in der Anwendung verwendet?
- Ist der Codepfad für externe oder nicht vertrauenswürdige Eingaben erreichbar?
- Welche Daten und Rechte wären betroffen?
- Gibt es eine sichere Zielversion oder nur eine Zwischenmaßnahme?
Diese Einordnung gehört zur technischen Kontrolle. Sie verhindert sowohl Alarmmüdigkeit als auch das Ignorieren realer Risiken.
3. Änderung umsetzen
Software-Wartung aktualisiert das Paket, passt bei Bedarf Code oder Konfiguration an und berücksichtigt inkompatible Änderungen. Ist kein Patch verfügbar, kann eine Mitigation wie Feature-Deaktivierung, Eingabebegrenzung oder zusätzliche Netzwerkgrenze erforderlich sein.
4. Testen und veröffentlichen
Build, relevante Tests und kritische Nutzerwege werden geprüft. Danach folgt der vereinbarte Staging- und Produktionsweg mit sichtbarer Version und Rückfallmöglichkeit.
5. Betrieb beobachten
Nach dem Release überwacht der verantwortliche Betreiber technische Fehler und Kernfunktionen. Eine garantierte Reaktion außerhalb der Geschäftszeiten entsteht nicht aus Review oder Software-Wartung, sondern aus dem gebuchten Managed-Operations-Service-Level.
Vier sinnvolle Zusammenarbeitsmodelle
1. Nur Review
Passt, wenn: Das Kundenteam kann Findings zuverlässig umsetzen, benötigt aber unabhängige Senior-Einordnung.
Grenze: Befunde bleiben offen, wenn intern keine Umsetzungskapazität vorhanden ist.
2. Nur Software-Wartung
Passt, wenn: WZ-IT einen bekannten Codebestand selbst pflegt und der Großteil der Änderungen aus diesem vereinbarten Umfang kommt.
Grenze: Entwickeln weitere Teams parallel, braucht es klare Branch-, Review- und Freigaberegeln.
3. Review plus getrennte Software Care
Passt, wenn: Das Kundenteam entwickelt, WZ-IT prüft unabhängig und übernimmt ausgewählte Findings anschließend selbst.
Grenze: Reviewkapazität und Implementierungskapazität müssen getrennt ausgewiesen werden. Wer einen Fix implementiert, sollte dessen Freigabe nicht ohne weitere Kontrolle allein bestätigen.
4. Review plus Software Care plus Managed Operations
Passt, wenn: Code, Releases und produktiver Betrieb als zusammenhängender Lifecycle betreut werden sollen.
Grenze: Auch bei einem Anbieter müssen Anwendung, Infrastruktur und Incident-Reaktion im Leistungsschein getrennt benannt bleiben.
Wie ein Co-Managed Prozess konkret aussehen kann
Ein kleines Team kann weiterhin mit KI entwickeln, ohne den produktiven Weg an WZ-IT abzugeben:
- Das Team erstellt Änderungen im eigenen Repository.
- Automatische Tests und Scanner laufen bei Pull Requests.
- Vereinbarte risikorelevante Änderungen gehen in das menschliche Review.
- Findings werden vom Team oder über Software Care behoben.
- Freigegebene Versionen werden automatisch nach Staging ausgerollt.
- Kritische Nutzerwege und Migrationen werden validiert.
- Der Release wird kontrolliert nach Produktion übernommen.
- Managed Operations überwacht die vereinbarten Systeme und reagiert nach Service Level.
Die Entwicklungsfreiheit bleibt erhalten. Gleichzeitig ist erkennbar, wer an welcher Stelle Verantwortung übernimmt.
Welche Leistung ist der richtige Einstieg?
Wählen Sie den Einstieg nach dem tatsächlichen Engpass:
- Unbekannter Ausgangsstand: einmaliger Production Readiness Audit
- Aktives Team, fehlende unabhängige Kontrolle: AI Code Review Retainer
- Fehlende Umsetzungskapazität: Software-Wartung oder Entwicklungsretainer
- Fehlender produktiver Betrieb: Managed Hosting oder Managed Operations
- Akute Sicherheitsprüfung von außen: gesondert abgegrenzter Penetrationstest
Ein Retainer ist dann sinnvoll produktisiert, wenn er nicht verspricht, alle fünf Probleme gleichzeitig zu einem niedrigen Pauschalpreis zu lösen.
Quellen
Anfrage
KI-generierte Software prüfen oder laufend begleiten
Beschreiben Sie Anwendung, Ausgangsstand und Arbeitsweise. Wir ordnen ein, ob ein einmaliger Audit, laufendes Code Review, Software-Wartung oder ein kombinierter Produktionsweg passt.
Häufig gestellte Fragen
Antworten auf die wichtigsten Fragen
Nein. Laufendes Code Review prüft Änderungen, ordnet Risiken ein und priorisiert Findings. Software-Wartung setzt vereinbarte technische Maßnahmen wie Dependency-Updates, Korrekturen, Tests und Releases tatsächlich um.
Ein Review-Retainer passt, wenn ein internes Team, eine Agentur oder KI-Werkzeuge die Anwendung weiterentwickeln und eine unabhängige technische Kontrollinstanz für relevante Änderungen, Dependencies und Release-Risiken benötigt wird.
Software-Wartung passt, wenn WZ-IT selbst Verantwortung für vereinbarte Updates, technische Korrekturen, Tests und Releases übernehmen soll. Ein Review ohne verfügbaren Umsetzungsweg würde Findings nur dokumentieren.
Ja. WZ-IT kann Änderungen des Kundenteams unabhängig prüfen und getrennt vereinbarte Findings anschließend umsetzen. Wichtig sind eine klare Übergabe, getrennte Kapazitäten und eine nachvollziehbare Freigabe, damit Review und Selbstkontrolle nicht unbemerkt vermischt werden.
Das hängt vom beauftragten Umfang ab. Der Review-Retainer kann eine Dependency-Meldung auf Betroffenheit und Priorität einordnen. Software-Wartung setzt den vereinbarten Patch oder eine andere Maßnahme um. 24/7 Incident-Reaktion ist ein eigener Betriebsumfang.
Nicht automatisch. Quellcodepflege und Infrastruktur sind unterschiedliche Ebenen. Hosting, Monitoring, Backups, Plattformupdates und Incident-Reaktion werden als Managed Operations oder Managed Hosting separat abgegrenzt.
Mehr zu KI-Code & Softwarequalität
- AI Code Audit, Code Review oder Pentest?
- KI-generierte Software vor Produktion prüfen
- Laufendes Code Review oder Software-Wartung?
