Ogni disciplina di ambiente che il tuo team ha costruito per gli umani si applica anche agli agenti di coding, e la maggior parte dei team l'ha silenziosamente abbandonata nel momento in cui l'agente è diventato bravo. La stessa organizzazione che non lascerebbe un nuovo assunto vicino alla produzione il primo giorno consegna a un agente una credenziale di lunga durata e una descrizione del compito, per poi stupirsi quando qualcosa che non doveva succedere succede.

La tesi è noiosa di proposito: un agente è un contributor insolitamente veloce ma senza giudizio istituzionale, e la scala degli ambienti esiste esattamente per contributor di questo tipo. Dev, staging, produzione, con un gate tra ciascuno. Non è mai stata una questione legata all'umano. È sempre stata una questione di raggio d'esplosione.

Perché la scala è stata saltata

Nessuno ha deciso di saltarla. Si è eroso tutto, in una sequenza che vale la pena riconoscere perché il tuo team probabilmente si trova da qualche parte dentro di essa.

L'agente inizia come autocomplete, e nessuno mette in staging l'autocomplete. Poi inizia a eseguire la suite di test in locale, il che va bene. Poi ha bisogno di colpire un servizio reale per riprodurre un bug, quindi qualcuno gli dà accesso in lettura allo staging. Poi i dati di staging sono vecchi, quindi qualcuno lo punta su una replica di produzione. Poi un compito richiede una scrittura, e la credenziale già presente nell'ambiente si dà il caso che ce l'abbia. In nessun momento qualcuno ha deciso che l'agente dovesse poter scrivere in produzione. Ci è arrivato attraverso una serie di passi singolarmente ragionevoli, che è come arriva la maggior parte degli incidenti, ovunque.

Cosa fa diversamente un agente

La scala conta di più per gli agenti che per le persone, per ragioni strutturali e non per un giudizio sulla competenza del modello.

  • La velocità elimina la pausa. Un umano che sta per fare qualcosa di distruttivo di solito esita prima. Quell'esitazione è un controllo di sicurezza non scritto, ed è gran parte del motivo per cui la scala ha retto per gli umani nonostante venga applicata in modo blando. Un agente esegue con piena sicurezza in due secondi. Non c'è nessuna pausa in cui intercettarlo.
  • Nessun senso delle conseguenze. Un ingegnere sa che questa tabella è la tabella di fatturazione e che giovedì è il giorno delle fatture. Quella conoscenza non è nel repository, quindi non è nel contesto dell'agente. Conosce lo schema. Non conosce la posta in gioco.
  • Obiettivi letterali. Se gli si dice di far passare un test di integrazione, un agente considererà l'opzione di modificare i dati su cui il test fa asserzioni. È una soluzione legittima al problema dichiarato. È sbagliata solo per un contesto che l'agente non possiede.
  • Volume. Un ingegnere apre tre pull request al giorno. Una flotta di agenti ne apre trenta. La probabilità per singola modifica che sia una modifica cattiva può calare, eppure il numero assoluto di modifiche cattive continua a salire.

La scala, riformulata per gli agenti

Gli stessi tre gradini, con la parte specifica per gli agenti messa in evidenza.

  • Dev: usa e getta e isolato. Un agente, un workspace, nessuno stato condiviso. Se due agenti lavorano sullo stesso checkout finiranno per contendersi gli stessi file e passerai il pomeriggio a leggere un merge conflict che nessuno dei due capisce. Branch effimeri e worktree costano poco; lo stato mutabile condiviso costa caro.
  • Staging: forma reale, posta in gioco finta. Lo staging si guadagna il suo posto solo se assomiglia strutturalmente alla produzione, stesso schema, stessa topologia dei servizi, stesso comportamento in caso di guasto, pur non contenendo nulla la cui perdita conti davvero. Dati seminati o sintetici, mai una copia di produzione. Una replica di produzione in staging è produzione con un monitoraggio peggiore.
  • Produzione: solo umani e gate. L'output dell'agente raggiunge la produzione nello stesso modo di qualsiasi altra modifica, attraverso una pull request revisionata e il tuo gate di deploy esistente. Nessuna porta laterale, nessun service account con corsia preferenziale.

L'isolamento è la credenziale, non l'URL

Ed è qui che i team si illudono. Puntare l'agente su staging.internal non è isolamento se la credenziale nel suo ambiente è valida anche contro la produzione. Il confine dell'ambiente è definito da cosa può raggiungere l'identità, non da quale hostname menziona il compito. Un agente con un ruolo ampio è a una sola chiamata di tool confusa dal conto sbagliato, e farà quella chiamata educatamente e immediatamente.

La versione di questo principio che regge è pratica AWS del tutto ordinaria, applicata con coerenza:

  • Account separati per ambiente, così un errore tra ambienti richiede un'assunzione di ruolo che non esiste, invece di un typo che esiste.
  • Un ruolo dedicato per ogni compito dell'agente, delimitato alle risorse che quel compito richiede, assunto per la durata dell'esecuzione e non oltre.
  • Nessuna chiave di lunga durata nell'ambiente dell'agente. Credenziali a breve durata significano che un contesto trapelato è un problema con una data di scadenza.
  • Deny-by-default sui verbi distruttivi. Un agente che non ha mai bisogno di DeleteObject dovrebbe essere strutturalmente incapace di chiamarlo, non semplicemente poco incline a farlo.
  • Approvazione umana su tutto ciò che attraversa il confine verso un account con dati reali, come controllo che l'agente non può soddisfare da solo.

I gate di review sono il punto, non l'attrito

L'obiezione è prevedibile: questo rallenta l'agente, e tutto il fascino dell'agente stava nella velocità. Quell'obiezione merita di essere presa sul serio e poi respinta, perché valuta male lo scambio.

Il vantaggio di velocità dell'agente sta nella generazione, non nella verifica. Scrive un fix plausibile in novanta secondi invece che in un'ora, ed è un guadagno genuino e grande. La verifica non è mai stata il collo di bottiglia che rimuove. Rimuovere il gate di review non rende l'agente più veloce in ciò in cui è già veloce, elimina soltanto il meccanismo che intercetta il dieci percento dell'output sicuro di sé ma sbagliato. Tieni il fix in novanta secondi. Tieni il reviewer. Questo è l'intero accordo, ed è un buon accordo.

Il punto

Niente di tutto questo è ingegneria nuova. Separazione degli ambienti, credenziali delimitate, review prima della produzione: il tuo team ha scritto queste regole per gli umani e in gran parte le segue. L'errore è trattare un agente come tooling anziché come un contributor, perché il tooling non ha bisogno di una scala di ambienti e i contributor sì. Dai all'agente una sandbox che assomiglia alla produzione e non contiene nulla che conti, un'identità che scade e non può attraversare il confine, e un reviewer tra lui e il deploy. Poi lascialo andare veloce dentro quella scatola.

Leggi questo dopo

Per i controlli a livello di account dietro tutto questo, multi-party approval in AWS Organizations copre il gate per le operazioni che nessuno dovrebbe eseguire da solo, su ercan.cloud. L'hub è su ercanermis.com.