La riparazione basata sull'intelligenza artificiale non diventa affidabile se sembra sicura. Diventa affidabile quando preserva le parti del lavoro di ingegneria che già rendono sicure le modifiche alla produzione: prove, proprietà, revisione, test e una chiara decisione di fusione.
Questa distinzione è importante. Uno strumento che apre una richiesta pull con il giusto contesto può far risparmiare ore. Uno strumento che modifica silenziosamente il codice di produzione chiede al team di accettare un nuovo rischio operativo.
Cominciamo dal confine
La prima decisione progettuale non è quale modello utilizzare. È ciò che il modello può fare.
Per la maggior parte dei team, il confine sicuro è simile al seguente:
- L’intelligenza artificiale può ispezionare i segnali di produzione.
- L’intelligenza artificiale può mappare questi segnali in codice.
- L'intelligenza artificiale può redigere una patch.
- L’intelligenza artificiale può spiegare il suo ragionamento.
- Gli ingegneri approvano, modificano, rifiutano o uniscono.
Questo è ancora un flusso di lavoro potente. Rimuove la parte noiosa della risposta agli incidenti senza allontanare la responsabilità dalle persone che possiedono il sistema.
Perché "aggiustalo e basta" è l'impostazione predefinita sbagliata
I fallimenti nella produzione sono complicati. Lo stesso errore può significare una distribuzione errata, un guardrail mancante, una coda che necessita di contropressione, un caso limite dei dati del cliente o un fornitore a monte che agisce in modo diverso dal previsto.
Quando un sistema passa direttamente dal sintomo alla modifica del codice, i revisori ricevono una patch senza alcuna indagine. Devono decodificare il motivo per cui esiste la patch. Ciò rallenta la revisione e rende l’automazione rischiosa anche quando il codice è ragionevole.
Il valore predefinito migliore è innanzitutto la prova:
Mostra il comportamento di produzione, mostra il percorso del codice sospetto, mostra la modifica proposta e mostra cosa potrebbe essere sbagliato.
Quest'ultima parte è importante. Un sistema di riparazione non dovrebbe pretendere certezza quando le prove sono parziali. Dovrebbe rendere visibile l’incertezza.
Punti di controllo che dovrebbero rimanere umani
Ci sono alcune decisioni che i team dovrebbero mantenere nel loro normale flusso di lavoro.
Proprietà e ambito
Il proprietario del codice corretto dovrebbe decidere se una correzione proposta si adatta ai limiti del servizio. Ciò impedisce che un incidente ristretto si trasformi in un cambiamento architettonico più ampio.
Giudizio del prodotto
Alcuni errori sono tecnicamente facili da correggere ma dipendono dal prodotto. Un bug relativo ai tentativi di pagamento, un caso limite di autorizzazioni o una mancata corrispondenza dello stato di fatturazione potrebbe richiedere il contesto del prodotto prima che il codice venga modificato.
Metti alla prova la fiducia
L’intelligenza artificiale può suggerire test, ma gli ingegneri dovrebbero decidere cosa significa fiducia. Una correzione richiede un test unitario. Un altro ha bisogno di un evento riprodotto. Un altro necessita di un controllo di migrazione e di un percorso di rollback.
Unisci l'approvazione
La decisione di fusione dovrebbe rimanere visibile nel processo di richiesta pull esistente del team. Ciò mantiene intatte le policy di sicurezza, conformità e proprietà.
Cosa dovrebbe assolutamente fare l’intelligenza artificiale
Mantenere l'approvazione umana non significa che il flusso di lavoro sia timido. L’intelligenza artificiale dovrebbe farsi carico del lavoro che gli esseri umani ripetono troppo spesso:
- raggruppando eventi di errore simili invece di aprire cinque indagini separate
- riepilogando le tracce dello stack e i log rumorosi in una nota incidente leggibile
- trovare il repository, il file, la funzione e il proprietario più rilevanti
- confrontando l'errore con le distribuzioni recenti e le modifiche al codice
- redigere una patch minima con una spiegazione in inglese semplice
- aggiungendo test suggeriti o controlli di revisione
- instradamento del follow-up non di codice ai problemi Jira, Linear o GitHub
Ecco da dove viene il risparmio di tempo. Il revisore inizia con un fascicolo del caso preparato invece che con una pila di segnali sconnessi.
La richiesta pull è l'interfaccia
Per i team di ingegneri, la richiesta pull è già il luogo in cui viene negoziato il rischio. Contiene differenze, commenti, CI, proprietà e cronologia delle approvazioni. La riparazione dell’intelligenza artificiale dovrebbe utilizzare quella superficie invece di crearne una nuova.
Un'utile PR di riparazione dovrebbe includere:
- Il segnale di produzione che ha dato il via alle indagini.
- Il percorso del codice che il sistema ritiene responsabile.
- La patch proposta.
- Il ragionamento dietro la patch.
- I test che sono stati eseguiti o dovrebbero essere eseguiti.
- Il livello di confidenza ed eventuali ipotesi.
Questa struttura offre ai revisori qualcosa di concreto da valutare. Possono non essere d'accordo con la diagnosi, migliorare la patch o unirla rapidamente quando le prove sono forti.
Un modello politico semplice
I team possono iniziare con tre livelli di policy.
Solo bozza
Il sistema può creare richieste pull ma non può richiedere la revisione automaticamente. Questo è un buon primo passo per i team che valutano la qualità del segnale.
Pronto per la revisione
Il sistema può aprire una richiesta pull, assegnare proprietari e richiedere una revisione quando le prove sono solide. Questa è l'impostazione predefinita a cui la maggior parte delle squadre dovrebbe puntare.
Unisci automaticamente le modifiche vincolate
Il sistema può unire solo cambiamenti limitati e reversibili che corrispondono a una politica rigorosa. Questo dovrebbe essere raro, registrato e facile da disabilitare.
Per la maggior parte delle organizzazioni non è necessario iniziare dal livello tre. Ottengono un valore significativo al livello due perché la parte costosa è spesso la diagnosi e la prima bozza.
Fai attenzione alla falsa fiducia
La modalità di errore non è "L'intelligenza artificiale scrive codice errato" in astratto. La modalità di fallimento più nitida è una macchia lucida con prove sottili.
I revisori dovrebbero essere in grado di dire se il sistema ha trovato la causa principale o ha semplicemente trovato un file nelle vicinanze. Un buon flusso di lavoro espone la catena dal segnale di produzione alla modifica del codice. Un flusso di lavoro debole nasconde quella catena dietro un riepilogo sicuro.
Se le prove sono deboli, lo strumento dovrebbe dirlo e instradare il problema come un’indagine, non come una soluzione.
Che bell'aspetto
Una buona correzione dell'intelligenza artificiale sembra come se un ingegnere senior avesse svolto il lavoro di preparazione prima della revisione. La richiesta pull non è magica. È semplicemente insolitamente ben assemblato:
- il problema viene deduplicato
- vengono riepilogati i log pertinenti
- il percorso del codice è denominato
- la toppa è piccola
- il ragionamento è visibile
- il revisore è ancora in carica
Questo è l'equilibrio. Lasciamo che l’IA comprima le indagini. Non lasciare che cancelli il giudizio ingegneristico.
