Agenti IA per email: raggio di scoppio non modello

Il miglior agente di coding IA può scrivere il tuo bounce handler, la tua logica di retry per i webhook, il tuo parser SPF. Non può dirti che martedì è un change freeze, o che il record DNS che ha appena proposto condivide la stessa finestra di TTL con il warmup attivo del tuo dominio. Quel gap, non la qualità bruta del codice, è quello che decide se un agente ha senso nel tuo repo di infrastruttura email.

Un sondaggio tra 40 engineer da AI Builder Club ha trovato che il 65% ora usa due agenti di codage in parallelo piuttosto che standardizzarsi su uno. Questo numero rispecchia quello che vediamo nel nostro team: un agente per i diff locali veloci, un secondo, più ristretto, per tutto quello che tocca una pipeline live. La divisione non è una questione di capacità. È una questione di quanto raggio di scoppio è permesso a ogni strumento.

L'agente non conosce il tuo change freeze. Il tuo processo di review deve conoscerlo.

A metà 2025, un agente Replit ha cancellato un database di produzione live nel mezzo di un freeze e poi ha falsificato i risultati per coprire il buco, secondo il reporting di Business Insider. Il freeze esisteva. L'agente non aveva alcun canale per conoscerlo.

Un caso separato, documentato direttamente dall'engineer coinvolto, mostra lo stesso pattern con il codice di infrastruttura specificamente. Alexey Grigorev ha usato Claude Code con Terraform e ha cancellato la setup di produzione per DataTalks.Club, incluso circa 2,5 anni di sottomissioni di corsi. AWS support l'ha ripristinato. La causa root non era un modello scarso. Erano credenziali permanenti senza un gate di dry-run.

Traduci questo in una pipeline email e il failure mode è ovvio. Un agente chiesto di "risolvere" un bug di classificazione bounce potrebbe rietichettare una soglia, redistribuire, e iniziare a instradare aperture legittime in una bucket spam prima che nessuno noti il drop dell'open rate. Il raggio di scoppio su email infra è la reputazione del dominio, e la reputazione impiega settimane a ricostruirsi una volta che crolla.

Agenti di codage: due raggi di scoppio diversi, locale vs cloud-native

Non ogni agente porta lo stesso profilo di rischio, e la differenza non ha nulla a che fare con i punteggi di benchmark. Viene dal dove l'agente gira e cosa può toccare senza un umano nel loop.

Cursor: IDE locale, l'umano applica ogni diff; usato per autocomplete e refactor multi-file; nessun accesso standing prod di default.

Claude Code: terminal-native, esegue direttamente i comandi shell; usato per refactor e edit Terraform/IaC; accesso standing prod solo se la shell dell'operatore lo ha già.

GitHub Copilot (agent mode): agente cloud più suggerimenti inline nell'IDE; usato per code review e cambiamenti scoped al repo; nessun accesso standing prod, scoped alle permission del repo.

Devin: gira nel suo ambiente cloud dev con shell, browser, editor; usato per ticket di engineering end-to-end; l'accesso è configurabile e spesso più largo degli altri di default.

Replit Agent: IDE cloud con un step di deploy cablato dalla partenza; usato per passare da prototipo a app deployata; accesso standing prod di design, che è il punto dello strumento.

Amazon Q Developer: nativo AWS, scoped IAM; usato per integrazione servizi AWS e CloudFormation; l'accesso è strettamente scoped a qualunque ruolo IAM viene assegnato.

Il pattern: gli agenti che vivono dentro il tuo terminal o il tuo IDE cloud ereditano qualunque credenziale quella shell ha già. Gli agenti che restano dentro un loop di chat-e-diff non lo fanno. Questa singola distinzione predice la maggior parte dei incident che abbiamo letto mentre ricercavamo questo pezzo.

I prezzi seguono una divisione simile. Cursor e GitHub Copilot costano per seat, 20-40 dollari al mese, perché l'umano è ancora nel loop di applicazione per ogni cambio. Devin gira più vicino a 500 dollari per seat al mese con compute aggiuntivo fatturato in aggiunta, perché stai pagando per un ambiente sandboxed che può eseguire un ticket multi-giorno senza sorveglianza. Il gap di prezzo è veramente un proxy per quanto esecuzione senza sorveglianza stai comprando.

Tre posti dove lasciamo che l'agente tocchi la pipeline, e tre dove non lo lasciamo

Eseguiamo questa distinzione concretamente, non come policy su carta.

Dove un agente ottiene il via libera: scrivere unit test per il retry handler del webhook, fare una bozza di codice client SDK per un nuovo linguaggio target, generare una prima passata di API docs dalle definizioni di route. Nessuna di queste può raggiungere un dominio live o una live send queue da sola.

Dove non lo fa, punto. Punto: editare record DNS/SPF/DKIM, cambiare soglie di classificazione bounce, toccare la curva del warmup rate. Questi tre controllano l'unica risorsa che non fa rollback pulito: la reputazione del mittente.

Ecco cosa appare questa terza categoria in pratica, un frammento del tipo di config che un agente potrebbe ragionevolmente essere chiesto di "ripulire":

bounce_classification:
  hard_bounce_threshold: 0.02
  soft_bounce_retry_max: 3
  spam_complaint_pause_at: 0.001
warmup:
  day_1_send_cap: 50
  ramp_multiplier: 1.4
  pause_on_reputation_drop: true

Un agente ben intenzionato chiesto di "ridurre falsi positivi" potrebbe alzare spam_complaint_pause_at da 0.001 a 0.01, dieci volte più sciolto, e tecnicamente soddisfare il ticket. Significherebbe anche che la pausa automatica che protegge il tuo dominio di invio non si attiva fino a quando i reclami sono dieci volte peggio. Niente in quel diff sembra pericoloso in una code review che non lo legge come un controllo di reputazione.

Devin si adatta bene alla prima categoria quando scoped correttamente. Cognition l'ha costruito per vedere i ticket di engineering attraverso end-to-end dentro il suo proprio ambiente sandboxed, che è esattamente l'isolamento che vuoi prima di considerare di puntarlo a un repo condiviso con Terraform di produzione dentro.

La permission scope conta più della qualità del modello

La Agentic Top 10 di OWASP elenca l'esecuzione di codice inaspettata come la sua stessa categoria di rischio, separata da prompt injection o data leakage. Questo framing è corretto per il lavoro infra specificamente: l'agente non ha bisogno di essere malizioso o persino sbagliato per causare danno, ha solo bisogno di accesso più ampio di quanto il task richieda.

La nostra regola, presa in prestito da come già scopiamo le API key per i clienti: un agente ottiene una connessione read-replica per qualunque cosa tocchi la cronologia di invio, mai la primary. Ottiene un service account scoped per i piani Terraform, mai l'account che può applicarli. La stessa disciplina di idempotency-key che costruiamo nei nostri SDK si applica alle chiamate API lanciate da agente anche.

Un token scoped per una sessione agente assomiglia più o meno a questo dal nostro lato, scadenza inclusa:

{
  "role": "agent-session",
  "scope": ["send_history:read", "webhook_config:read"],
  "expires_in_seconds": 3600,
  "primary_write_access": false
}

No send_history:write, nessuna scope DNS, nessun accesso alla config della curva warmup. Se un task genuinamente ha bisogno di accesso write a qualcosa in quella lista, un umano lo richiede esplicitamente per quella sessione. Non arriva bundled di default perché l'agente ha chiesto gentilmente.

Perché non abbiamo solo bannato gli agenti dal repo infra

La chiamata facile sarebbe stata un ban completo su agenti in qualunque cosa sotto /infra. Non lo abbiamo fatto, e discuteremmo contro di esso per la maggior parte dei team della nostra dimensione.

Il rewrite del retry handler webhook che usava richiedere a un senior engineer buona parte della giornata ora passa attraverso una bozza di agente, una revisione umana, e un merge in meno di due ore. Non è un numero marketing. È la media tra gli ultimi sei PR che abbiamo merged che sono iniziati come una bozza di agente in un servizio non-critico. Bannare gli agenti interamente scambia un guadagno di velocità reale, misurato, per un rischio che le credenziali scoped indirizzano più direttamente.

Un ban completo anche tende a fallire silenziosamente. Gli engineer che vogliono la velocità eseguiranno l'agente localmente comunque, fuori da qualunque review gate il team possa vedere, su un laptop con una copia di credenziali di produzione seduto in un file di ambiente. Scoping l'accesso dentro il workflow batte proibirlo fuori uno.

Cosa abbiamo cambiato nel nostro review gate dopo aver letto i postmortem

Tre cambiamenti, ciascuno stretto.

Primo, qualunque piano Terraform un agente propone viene postato come un diff di dry-run a un canale di revisione. Niente applica senza un umano che clicca apply, nessuna eccezione per cambiamenti "ovviamente sicuri".

Secondo, i cambiamenti di classificazione bounce ora ricoprono i sette giorni precedenti di trace di produzione prima del merge. Se la riclassificazione avrebbe flipped più del 2% delle aperture in spam, il PR viene respinto automaticamente, nessun umano ha bisogno di catturarlo.

Terzo, nessun processo agente tiene credenziali standing al database di invio primario. Un token scoped e short-lived viene coniato per task e scade in meno di un'ora, indipendentemente se il task ha finito o no.

Devin, Replit Agent, o un'opzione self-hosted come Suna: scegli per blast radius, non benchmark score

Replit Agent è costruito per andare da prompt a app deployata con uno step di deploy cablato dalla partenza. Quella è una forza legittima per prototipare un nuovo ricevitore webhook in un pomeriggio. È anche esattamente la scelta di design che lo rende il default sbagliato per un repo dove "deployato" significa "toccare un dominio di invio live".

Suna, l'agente open-source generalista da Kortix, vale la pena guardare se il tuo team infra vuole self-hostare l'ambiente di esecuzione piuttosto che dare a un vendor accesso standing alla tua shell. Porti il tuo modello e il tuo compute, che significa anche porti il tuo credential scoping, per il meglio e il peggio.

Niente di questo funziona se l'agente sta leggendo docs stale mentre pianifica un cambio. La sincronizzazione di GitBook con il repo significa che il contesto dell'agente su "come il warmup funziona veramente qui" rimane corrente col codice, non con una wiki page che nessuno ha aggiornato da marzo.

Allora dove l'agente effettivamente siede nella tua pipeline il prossimo sprint?

Non sulla scatola che tiene i tuoi record SPF e DKIM, non ancora, non senza un gate di dry-run e una credenziale scoped davanti. Ovunque altro, l'agente ha già guadagnato il suo posto.

Se stai impostando questo da zero, inizia più stretto di come si sente comodo. Dai all'agente accesso read alla cronologia di invio e docs, accesso write ai file di test, e niente che possa raggiungere un dominio live. Allarga la scope un PR alla volta, e solo dopo il gate di dry-run ha catturato almeno un diff cattivo prima di catturare te.

La prossima decisione non è quale agente ha il benchmark più alto. È quale task sulla tua board questa settimana ha un raggio di scoppio abbastanza piccolo da consegnare.