Skip to main content
Per una guida più dettagliata sull’integrazione con Sentry, clicca qui.
1

Connetti l'MCP di Sentry

Prima di creare il tuo programma, Devin ha bisogno di accedere ai dati di Sentry.
  1. Vai su Settings > MCP Marketplace e cerca Sentry
  2. Fai clic su Enable e autenticati tramite OAuth — in questo modo concedi a Devin accesso in sola lettura alle tue issue, agli eventi e agli stack trace di Sentry
  3. Fai clic su Test listing tools per verificare che la connessione funzioni correttamente
Una volta connesso, Devin può interrogare i tuoi progetti Sentry, recuperare i dettagli delle issue e gli stack trace e leggere i breadcrumb, tutto all’interno di una sessione. Scopri di più sulla configurazione dei server MCP.
2

Crea la pianificazione

Vai su Settings > Schedules e fai clic su Create schedule.
  • Name: Daily Sentry remediation — payments-api
  • Frequency: Tutti i giorni alle 6:00 AM (così le pull request (PR) con le correzioni sono pronte prima del daily standup)
  • Agent: Devin — permette a Devin di avviare una sessione separata per ogni errore, così le correzioni vengono eseguite in parallelo
  • Slack channel: Seleziona un canale (ad es. #sentry-fixes) così il tuo team riceve una notifica quando l’esecuzione è completata e le PR sono pronte per la revisione
  • Prompt:
3

Popola Knowledge a partire dalla tua codebase e dalle correzioni precedenti

Devin scrive correzioni migliori quando comprende gli schemi di errore della tua app. Invece di scrivere manualmente le voci di Knowledge, chiedi a Devin in qualsiasi sessione di analizzare la base di codice e le correzioni passate, quindi lascia che sia Devin a creare la Knowledge:Queste voci vengono richiamate automaticamente quando Devin rileva errori corrispondenti durante le esecuzioni pianificate — e il prompt pianificato sopra indica a Devin di aggiornare Knowledge sulla base del feedback sulle tue PR, così migliora nel tempo.
4

Risultato di un'esecuzione tipica

Ogni mattina, Devin elabora la coda degli errori accumulati durante la notte e apre PR mirate. Ecco un esempio di output di una sessione reale:
Processed 5 Sentry errors from payments-api (past 24h):

1. TypeError: Cannot read property 'last4' of null (1,892 events)
   Root cause: Stripe webhook delivers `payment_method: null` for
   bank transfer payments. CheckoutReceipt.tsx:34 destructures
   without a null check.
   PR #612: Add null safety to CheckoutReceipt, show "Bank Transfer"
   fallback for non-card payments.

2. TimeoutError: Query timeout after 30s on /api/invoices (743 events)
   Root cause: N+1 query in InvoiceService.getMonthly() — each
   line item triggers a separate product lookup.
   PR #613: Add eager loading for invoice line items with
   Sequelize `include`.

3. RangeError: Maximum call stack size exceeded (412 events)
   Root cause: Circular reference in refund.toJSON() when a
   refund references its parent transaction which references
   the refund.
   PR #614: Break circular ref with a custom serializer,
   add max-depth test.

4-5. Two lower-frequency validation errors — PRs #615, #616.
Ogni pull request (PR) include il link all’issue Sentry, una descrizione della causa principale, la correzione e un test che avrebbe individuato l’errore originale.
5

Ottimizza e itera

Dopo una settimana di esecuzioni, rivedi cosa funziona e adegua:Definisci l’ambito del conteggio degli errori. Inizia con i top 5 errori per esecuzione. Se Devin produce costantemente PR pronti al merge, aumenta a 8-10. Se le correzioni richiedono revisioni significative, riduci a 3.Filtra per progetto o tag. Restringi il prompt a specifici progetti Sentry (payments-api, web-frontend) o escludi i tag rumorosi. Puoi creare schedulazioni separate per progetto se i volumi di errori sono diversi.Impara dai risultati. Dopo un paio di settimane, chiedi a Devin di analizzare quali correzioni sono effettivamente arrivate in produzione e trasformarle in Knowledge: