KI-Sanierung wird nicht dadurch vertrauenswürdig, dass sie selbstbewusst klingt. Es wird vertrauenswürdig, wenn es die Teile der technischen Arbeit beibehält, die Produktionsänderungen bereits sicher machen: Beweise, Eigentum, Überprüfung, Tests und eine klare Entscheidung zur Zusammenführung.
Diese Unterscheidung ist wichtig. Ein Tool, das eine Pull-Anfrage mit dem richtigen Kontext öffnet, kann Stunden sparen. Ein Tool, das den Produktionscode stillschweigend ändert, fordert das Team auf, ein neues Betriebsrisiko zu akzeptieren.
Beginnen Sie mit der Grenze
Die erste Designentscheidung ist nicht, welches Modell verwendet werden soll. Es ist das, was das Modell tun darf.
Für die meisten Teams sieht die sichere Grenze so aus:
- KI kann Produktionssignale prüfen.
- KI kann diese Signale in Code umwandeln.
- KI kann einen Patch entwerfen.
- KI kann ihre Argumentation erklären.
- Ingenieure genehmigen, bearbeiten, lehnen ab oder führen zusammen.
Das ist immer noch ein leistungsstarker Workflow. Dadurch entfällt der langweilige Teil der Reaktion auf Vorfälle, ohne dass die Verantwortung von den Personen, denen das System gehört, entzogen wird.
Warum „einfach reparieren“ die falsche Standardeinstellung ist
Produktionsausfälle sind chaotisch. Derselbe Fehler kann auf eine fehlerhafte Bereitstellung, eine fehlende Leitplanke, eine Warteschlange, die Gegendruck benötigt, einen Kundendaten-Edge-Fall oder ein anders als erwartetes Verhalten eines Upstream-Anbieters hinweisen.
Wenn ein System direkt vom Symptom zur Codeänderung übergeht, erhalten Prüfer einen Patch ohne die Untersuchung. Sie müssen nachvollziehen, warum der Patch existiert. Das verlangsamt die Überprüfung und lässt die Automatisierung riskant erscheinen, selbst wenn der Code angemessen ist.
Der bessere Standard ist der Beweis zuerst:
Zeigen Sie das Produktionsverhalten, den vermuteten Codepfad, die vorgeschlagene Änderung und zeigen Sie, was möglicherweise falsch ist.
Der letzte Teil ist wichtig. Ein Sanierungssystem sollte keine Gewissheit vortäuschen, wenn die Beweise unvollständig sind. Es soll Unsicherheit sichtbar machen.
Kontrollpunkte, die menschlich bleiben sollten
Es gibt ein paar Entscheidungen, die Teams in ihrem normalen Arbeitsablauf berücksichtigen sollten.
Eigentum und Umfang
Der richtige Codeeigentümer sollte entscheiden, ob ein vorgeschlagener Fix zur Dienstgrenze passt. Dadurch wird verhindert, dass aus einem kleinen Vorfall eine umfassende architektonische Veränderung wird.
Produktbeurteilung
Einige Fehler sind technisch leicht zu beheben, aber produktabhängig. Bei einem Zahlungswiederholungsfehler, einem Berechtigungsrandfall oder einer Nichtübereinstimmung des Abrechnungsstatus ist möglicherweise ein Produktkontext erforderlich, bevor sich der Code ändert.
Testen Sie das Selbstvertrauen
KI kann Tests vorschlagen, aber Ingenieure sollten entscheiden, was Vertrauen bedeutet. Ein Fix erfordert einen Unit-Test. Ein anderer benötigt ein wiederholtes Ereignis. Ein anderer benötigt eine Migrationsprüfung und einen Rollback-Pfad.
Genehmigung zusammenführen
Die Zusammenführungsentscheidung sollte im bestehenden Pull-Request-Prozess des Teams sichtbar bleiben. Dadurch bleiben die Sicherheits-, Compliance- und Eigentumsrichtlinien erhalten.
Was KI unbedingt tun sollte
Eine menschliche Genehmigung bedeutet nicht, dass der Arbeitsablauf zaghaft ist. KI sollte die Arbeit übernehmen, die Menschen zu oft wiederholen:
- Gruppieren Sie ähnliche Fehlerereignisse, anstatt fünf separate Untersuchungen einzuleiten
- Zusammenfassung von Stack-Traces und verrauschten Protokollen in einer lesbaren Vorfallnotiz
- Finden des relevantesten Repositorys, der Datei, der Funktion und des Eigentümers
- Vergleichen des Fehlers mit aktuellen Bereitstellungen und Codeänderungen
- Entwurf eines minimalen Patches mit einer Erklärung in einfachem Englisch
- Hinzufügen vorgeschlagener Tests oder Überprüfungsprüfungen
- Weiterleitung von Nicht-Code-Nachverfolgungen zu Jira-, Linear- oder GitHub-Problemen
Daraus ergibt sich die Zeitersparnis. Der Prüfer beginnt mit einer vorbereiteten Fallakte und nicht mit einem Stapel unzusammenhängender Signale.
Der Pull Request ist die Schnittstelle
Für Engineering-Teams ist der Pull-Request bereits der Ort, an dem Risiken ausgehandelt werden. Es enthält den Unterschied, Kommentare, CI, Besitz und Genehmigungsverlauf. Die KI-Sanierung sollte diese Oberfläche nutzen, anstatt eine neue zu erstellen.
Eine nützliche Sanierungs-PR sollte Folgendes umfassen:
- Das Produktionssignal, das die Untersuchung auslöste.
- Der Codepfad, den das System für verantwortlich hält.
- Der vorgeschlagene Patch.
- Die Gründe für den Patch.
- Die Tests, die ausgeführt wurden oder ausgeführt werden sollten.
- Das Konfidenzniveau und etwaige Annahmen.
Diese Struktur gibt den Rezensenten etwas Konkretes zur Bewertung. Sie können mit der Diagnose nicht einverstanden sein, das Pflaster verbessern oder es schnell zusammenführen, wenn die Beweise überzeugend sind.
Ein einfaches Politikmodell
Teams können mit drei Richtlinienebenen beginnen.
Nur Entwurf
Das System kann Pull-Requests erstellen, aber nicht automatisch eine Überprüfung anfordern. Dies ist ein guter erster Schritt für Teams, die die Signalqualität bewerten.
Rezensionsbereit
Das System kann eine Pull-Anfrage öffnen, Eigentümer zuweisen und eine Überprüfung anfordern, wenn die Beweise überzeugend sind. Dies ist der Standardwert, den die meisten Teams anstreben sollten.
Eingeschränkte Änderungen automatisch zusammenführen
Das System kann nur begrenzte, umkehrbare Änderungen zusammenführen, die einer strengen Richtlinie entsprechen. Dies sollte selten, protokolliert und leicht zu deaktivieren sein.
Die meisten Organisationen müssen nicht auf Stufe drei beginnen. Auf Stufe zwei erhalten sie einen sinnvollen Wert, da der kostspielige Teil oft die Diagnose und der erste Entwurf ist.
Achten Sie auf falsches Vertrauen
Der Fehlermodus ist abstrakt gesehen nicht „KI schreibt fehlerhaften Code“. Der schärfere Fehlermodus ist ein polierter Fleck mit dünnen Anzeichen.
Prüfer sollten erkennen können, ob das System die Grundursache gefunden hat oder einfach eine Datei in der Nähe gefunden hat. Ein guter Workflow legt die Kette vom Produktionssignal bis zur Codeänderung offen. Ein schwacher Workflow verbirgt diese Kette hinter einer sicheren Zusammenfassung.
Wenn die Beweise schwach sind, sollte das Tool dies sagen und das Problem als Untersuchung und nicht als Lösung weiterleiten.
Wie gut sieht aus
Eine gute KI-Sanierung fühlt sich an, als ob ein leitender Ingenieur die Vorbereitungsarbeit vor der Überprüfung erledigt hätte. Der Pull-Request ist keine Zauberei. Es ist einfach ungewöhnlich gut zusammengebaut:
- Das Problem ist dedupliziert
- Die relevanten Protokolle werden zusammengefasst
- Der Codepfad wird benannt
- Der Patch ist klein
- Die Begründung ist sichtbar
- Der Rezensent ist weiterhin verantwortlich
Das ist das Gleichgewicht. Lassen Sie die KI die Ermittlungen komprimieren. Lassen Sie nicht zu, dass dadurch das technische Urteilsvermögen ausgelöscht wird.
