> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devinenterprise.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Istruire Devin in modo efficace

> Come ottenere risultati ottimali.

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 utilizzare Devin in modo efficace. Per strategie più generali su come lavorare in modo efficace con agenti di programmazione, consulta anche la nostra [guida Coding Agents 101](https://devin.ai/agents101).

<div id="how-to-write-effective-prompts">
  ## Come scrivere prompt efficaci
</div>

Ecco un esempio di prompt che dimostra istruzioni efficaci:

<Note type="info">
  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.
</Note>

<div id="why-this-works-well">
  ### Perché questo funziona bene
</div>

<CardGroup cols={2}>
  <Card title="Fornisce un contesto utile" icon="circle-info">
    * **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.
  </Card>

  <Card title="Fornisce istruzioni passo-passo" icon="list-ol">
    * **Dettaglio:** Attività come "crea un'attività in background" e "emetti un evento all’80% di utilizzo".
    * **Beneficio:** Scompone il lavoro in parti logiche.
  </Card>

  <Card title="Definisce criteri di successo chiari" icon="check">
    * **Dettaglio:** Definisce il "successo" come l’emissione di uno specifico evento al raggiungimento dell’80% di utilizzo.
    * **Beneficio:** Devin sa esattamente cosa deve ottenere.
  </Card>

  <Card title="Fa riferimento a pattern e codice esistenti" icon="code">
    * **Dettaglio:** Menziona Kafka e le interazioni con i container.
    * **Beneficio:** Incoraggia il riutilizzo di codice o approcci di design consolidati.
  </Card>
</CardGroup>

<div id="best-practices-dos-and-donts">
  ## Best Practices: cosa fare e cosa non fare
</div>

<AccordionGroup>
  <Accordion title="Sii deciso e specifico" icon="bullseye">
    **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."
  </Accordion>

  <Accordion title="Sfrutta al massimo i punti di forza di Devin" icon="rocket">
    **Da fare: scegli [task in cui Devin è bravo](when-to-use-devin#evaluating-tasks-for-devin)**

    * **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.
    * **Come:**
      * Leggi questa guida: [Quando usare Devin](when-to-use-devin)
      * 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.
      * Collega le [integrazioni MCP](/it/work-with-devin/mcp) per dare a Devin accesso a design Figma, database, strumenti di monitoraggio e altro ancora.
      * **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/](https://sequelize.org/docs/v6/getting-started/) per i passaggi di migrazione."

    **Da non fare: omettere il contesto per task complessi**

    * **Perché:** Anche se Devin può gestire attività complesse, dà il meglio quando gli fornisci contesto e una direzione chiara.
    * **Come:**
      * Per task che richiedono conoscenze di dominio, fornisci documentazione, esempi o riferimenti pertinenti.
      * Per task visivi, fornisci file Figma tramite il [Figma MCP](/it/work-with-devin/mcp), design di riferimento o specifiche dettagliate — Devin può costruire a partire da questi ma non inventerà l'estetica da solo.
      * Per le app Android, Devin può eseguire build e test su un [emulatore Android](/it/onboard-devin/environment/android-emulation). Per le app iOS, Devin non ha accesso a un emulatore per telefono, quindi fornisci criteri di test chiari.
    * **Esempio:** Da non fare: "Migliora l'aspetto dell'app" — invece, fornisci specifiche di design precise o un file Figma.
    * **Esempio:** Da non fare: "Migliora le prestazioni del nostro database" — invece, specifica quali query ottimizzare e quali metriche prendere di mira.
  </Accordion>

  <Accordion title="Usa cicli di feedback" icon="rotate">
    **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.
      * Abilita [Devin Review](/it/work-with-devin/devin-review) con [Auto-Fix](/it/work-with-devin/devin-review#auto-fix) in modo che Devin risponda automaticamente ai commenti di review e agli errori della CI — creando un ciclo chiuso in cui le PR iterano fino a raggiungere una qualità pronta per il merge senza che tu debba intervenire.
    * **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.
  </Accordion>

  <Accordion title="Imposta checkpoint" icon="check-double">
    **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."
  </Accordion>

  <Accordion title="Consenti a Devin di testare il proprio lavoro" icon="desktop">
    Devin dispone di un ambiente desktop completo — shell, IDE e browser. Chiedi a Devin di testare il proprio lavoro prima di aprire una PR:

    * **Avvia l'app:** "Esegui `npm run dev` e verifica che la nuova pagina venga visualizzata su `/settings`."
    * **Test nel browser:** "Apri il browser, vai alla pagina di login e conferma che il flusso OAuth si completi correttamente."
    * **Verifica visiva:** "Acquisisci screenshot alle larghezze desktop (1440px) e mobile (375px) e conferma che il layout corrisponda al design."
    * **Registrazione schermo:** "Effettua una registrazione dello schermo mentre testi l'intero flusso di checkout end‑to‑end."

    Questo permette a Devin di eseguire il QA sulle proprie modifiche nello stesso modo in cui lo faresti tu — prima che tu debba guardare la PR.
  </Accordion>

  <Accordion title="Usa Playbooks e Knowledge" icon="book">
    Per attività ripetitive o complesse, consigliamo di usare e perfezionare i [Playbooks](/it/product-guides/creating-playbooks). Scopri di più su [come usare i playbook in modo efficace](/it/product-guides/using-playbooks). 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.

    Per il contesto persistente che Devin deve ricordare in tutte le sessioni — come standard di coding, bug comuni e relative correzioni, workflow di deployment o il modo in cui usare gli strumenti interni — usa [Knowledge](/it/product-guides/knowledge). Gli elementi di Knowledge vengono richiamati automaticamente quando sono pertinenti, così non devi ripetere le stesse istruzioni in ogni prompt. Puoi associare elementi di Knowledge a repo specifici oppure applicarli a livello globale.

    <Tip>**Playbooks vs. Knowledge:** Usa i Playbooks per procedure passo-passo legate a task specifici. Usa Knowledge per suggerimenti generali, convenzioni e contesto che si applicano in modo trasversale alle varie sessioni.</Tip>
  </Accordion>
</AccordionGroup>