Vai al contenuto principale
La cosa più importante da ricordare quando istruisci Devin è essere il più specifico possibile. Così come forniresti una specifica dettagliata quando chiedi a un collega di scrivere del codice, dovresti fare lo stesso con Devin. Questa guida ti aiuterà a strutturare le tue istruzioni e i tuoi prompt per massimizzare l’utilità di Devin. Per strategie più generali su come lavorare in modo efficace con agenti di programmazione, consulta anche la nostra guida Coding Agents 101.

​
Esempio di prompt

Nel repo di Devin, voglio che tu crei uno strumento che monitori l’utilizzo di RAM e CPU delle macchine remote su cui viene eseguito Devin. Per farlo, svolgi le seguenti attività:
  • Crea un’attività in background che si avvii automaticamente all’avvio di devin.rs.
  • L’attività deve aprire una connessione a tutte le macchine remote derivate (forked) utilizzate in questa sessione di Devin e monitorarne l’utilizzo di RAM e CPU.
  • Se l’utilizzo supera l’80% della risorsa disponibile, emetti un nuovo tipo di evento Devin per segnalarlo (controlla come utilizziamo Kafka).
  • Progetta l’architettura in modo intelligente, in modo che non blocchi le altre operazioni. Dovresti capire come tutti i container dei sotto-agent di Devin interagiscono tra loro.

​
Perché questo funziona bene

Fornisce un contesto utile

  • Dettaglio: Specifica il repository di Devin e l’obiettivo più ampio (monitoraggio dell’utilizzo delle risorse).
  • Beneficio: Devin conosce chiaramente l’ambito e il dominio.

Fornisce istruzioni passo-passo

  • Dettaglio: Attività come “crea un’attività in background” e “emetti un evento all’80% di utilizzo”.
  • Beneficio: Scompone il lavoro in parti logiche.

Definisce criteri di successo chiari

  • Dettaglio: Definisce il “successo” come l’emissione di uno specifico evento al raggiungimento dell’80% di utilizzo.
  • Beneficio: Devin sa esattamente cosa deve ottenere.

Fa riferimento a pattern e codice esistenti

  • Dettaglio: Menziona Kafka e le interazioni con i container.
  • Beneficio: Incoraggia il riutilizzo di codice o approcci di design consolidati.
Prova il pulsante di miglioramento del prompt quando crei una sessione (fai clic sul cerchio giallo di avviso per visualizzare il feedback)
Pulsante di miglioramento del prompt

​
Best Practices: cosa fare e cosa non fare

Da fare: fornire direttive chiare
  • Perché: Devin può bloccarsi senza un percorso chiaro o quando si trova di fronte a troppe possibili interpretazioni.
  • Come:
    • Prendere decisioni importanti e assumere i giudizi critici al posto di Devin.
    • Fornire scelte di design specifiche e strategie di implementazione.
    • Definire in modo chiaro ambito, confini e criteri di successo.
  • Esempio: “Ottimizza la query getOrderDetails in orderService.js aggiungendo un indice composito sulle colonne order_id e product_id nella tabella order_items. Refattorizza la query per sostituire la subquery correlata esistente con una JOIN alla tabella products per recuperare i dettagli dei prodotti.”
Da non fare: lasciare le decisioni aperte
  • Perché: Istruzioni vaghe possono portare Devin a implementare soluzioni che non sono allineate alle tue reali esigenze.
  • Come:
    • Evitare indicazioni che richiedono a Devin di prendere decisioni significative di design o implementazione senza un chiaro orientamento. Questo può portare a risultati inaspettati.
  • Esempio: Non fare: “Migliora le prestazioni del nostro database.”
Da fare: scegli task in cui Devin è bravo
  • Perché:
    • Massimizza i risultati: Assegnando task che si allineano alle capacità di Devin, puoi ottenere i risultati migliori con il minimo sforzo e il minor numero di ACU. Chiedere a Devin di svolgere task molto al di fuori delle sue capacità attuali spesso porta a risultati scadenti.
  • Come:
    • Leggi questa guida: Quando usare Devin
    • Soprattutto per task avanzati, fornisci esempi, moduli, risorse e template che Devin possa seguire.
      • Condividi link diretti ai siti di documentazione, così che Devin possa leggere dettagli come i body delle richieste API e funzionalità che potrebbe non conoscere.
      • Condividi nomi di file specifici che vuoi che Devin analizzi e da cui impari
    • Esempio: Da fare: “Refattorizza la gestione dello state nel componente Header per usare l’hook useReducer di React e migliorarne scalabilità e manutenibilità. Assicurati che tutta la funzionalità esistente venga preservata e aggiungi unit test per coprire la nuova logica di state.”
    • Esempio: Da fare: “Usa authTemplate.rs come riferimento per mantenere la coerenza nella gestione degli errori.”
    • Esempio: Da fare: “Consulta la documentazione ufficiale di Sequelize su https://sequelize.org/docs/v6/getting-started/ per i passaggi di migrazione.”
Da non fare: assegnare task al di fuori delle competenze core di Devin
  • Perché: Assegnare task che richiedono conoscenze di dominio avanzate o decisioni di design complesse senza una guida adeguata può portare a inefficienze e spreco di ACU.
  • Come:
    • Evita task che richiedono un apporto creativo significativo o input strategici di alto livello senza istruzioni o riferimenti chiari.
    • Evita task che richiedono forti capacità visive, ad esempio implementare design da Figma, dato che, sebbene Devin possa vedere le pagine web, non ha una vista perfetta.
    • Evita di chiedere a Devin di creare app mobile, dato che non ha accesso a un telefono e non può testare facilmente il proprio lavoro.
  • Esempio: Da non fare: “Crea da zero un nuovo sistema di autenticazione per il mio sito web.”
  • Esempio: Da non fare: “Trasforma questo mockup Figma in un componente React.”
  • Esempio: Da non fare: “Costruisci un’app di shopping basata su AI.”
Da fare: collaborare completando attività parziali
  • Perché: A volte è più veloce per te completare l’ultimo 20% di un’attività.
  • Come:
    • Lascia che Devin gestisca la maggior parte dell’implementazione, poi intervieni per rifinire il risultato.
    • Usa Devin per accelerare le parti del flusso di lavoro che sono ripetitive, mentre tu ti concentri sugli aspetti più critici.
  • Esempio: Da fare: “Genera il codice boilerplate iniziale per il nuovo endpoint API, poi lo integrerò con il sistema di autenticazione esistente.”
Da non fare: fare affidamento esclusivamente su Devin per interi progetti complessi
  • Perché: Fare eccessivo affidamento su Devin per attività che richiedono una comprensione approfondita e sfumata o capacità di problem solving creativo può causare ritardi e risultati subottimali.
  • Come:
    • Evita di assegnare a Devin attività che sai richiederanno un intervento umano significativo per essere completate in modo efficace.
  • Esempio: Da non fare: “Sviluppa l’intera infrastruttura backend per la nostra nuova funzionalità di AI generativa”
Da fare: stabilire verifiche chiare e frequenti
  • Perché: feedback frequenti (sia da parte tua che da test/verifiche/linters) garantiscono che Devin corregga gli errori in modo efficace.
  • Come:
    • Usa test (unitari/di integrazione) per confermare la correttezza.
    • Mantieni verifiche di build, controlli di linting e analisi statica per la qualità del codice.
  • Esempio: Da fare: “Esegui npm test dopo ogni iterazione.”
  • Esempio: Da fare: “Assicurati che la pipeline su CircleCI non fallisca.”
  • Esempio: Da fare: “Supera i controlli ESLint/Prettier prima di effettuare qualsiasi commit.”
Da non fare: trascurare di fornire feedback
  • Perché: senza feedback, Devin non saprà se le sue soluzioni soddisfano i tuoi standard.
  • Come:
    • Evita di assegnare task senza definire come li valuterai.
Da fare: definire checkpoint e sotto-attività chiari
  • Perché: Suddividere attività complesse in checkpoint più piccoli aiuta Devin a rimanere concentrato e riduce gli errori.
  • Come:
    • Suddividi le attività in sotto-attività verificabili e avvia una sessione Devin per ciascuna sotto-attività.
    • Definisci cosa significa successo per ciascuna sotto-attività e, facoltativamente, imposta dei checkpoint all’interno di ogni sotto-attività.
    • Chiedi a Devin di fornire un resoconto al termine di ogni checkpoint o sotto-attività.
Esempi:
  • Esempio: Da fare: “Quando lavori con il dataset, verifica che contenga almeno 500 righe e includa le colonne X, Y, Z.”
  • Esempio: Da fare: “Quando modifichi l’API, conferma che l’endpoint restituisca lo status 200 e includa tutti i campi richiesti.”
  • Esempio: Da fare: “Quando aggiorni la UI, controlla che il componente venga renderizzato senza errori in console e che corrisponda alle specifiche di design.”
Da non fare: saltare requisiti di validazione specifici
  • Perché: Senza passaggi di validazione definiti, Devin non può completare le attività in modo affidabile.
  • Come:
    • Evita criteri di successo vaghi.
    • Non lasciare che i passaggi di verifica siano impliciti o non definiti.
  • Esempio: Da non fare: “Assicurati che funzioni.”
Per attività ripetitive o complesse, consigliamo di usare e perfezionare i Playbooks. Scopri di più su come usare i playbook in modo efficace. I playbook sono prompt riutilizzabili e condivisibili che semplificano l’assegnazione dei task. Ad esempio, se vuoi che Devin gestisca i continui errori nei build CI, crea un playbook che includa i passaggi generali che Devin dovrebbe seguire ogni volta.

​
Conclusione

Definisci i task con sufficiente struttura e chiarezza per ottenere risultati affidabili e soddisfacenti.