> ## 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.

# Istruzioni efficaci vs. inefficaci

> Cosa funziona e cosa no

<Note>Assicurati di leggere [Quando usare Devin](/it/essential-guidelines/when-to-use-devin) e [Istruire Devin in modo efficace](/it/essential-guidelines/instructing-devin-effectively) per altri suggerimenti essenziali.</Note>

<CardGroup cols={1}>
  <Card title="Aggiungere un nuovo endpoint API" icon="server">
    **Approccio corretto**

    <Check>
      "Create a new endpoint `/users/stats` that returns a JSON object with user count and average signup age. Use our existing users table in PostgreSQL. You can reference the `/orders/stats` endpoint in `statsController.js` for how we structure responses. Ensure the new endpoint is covered by the `StatsController.test.js` suite."
    </Check>

    **Perché funziona:**

    * Specifica chiaramente la route e il formato di risposta atteso
    * Fa riferimento a codice esistente come modello
    * Definisce la fonte dati (tabella users)
    * Include i requisiti di copertura dei test

    <br />

    ***

    <br />

    **Approccio errato**

    <Warning>
      "Add a user stats endpoint."
    </Warning>

    **Perché non funziona:**

    * Non è specificato quali statistiche includere
    * Nessun riferimento alle fonti dati
    * Nessun riferimento a pattern esistenti
    * Mancano i requisiti relativi ai test
  </Card>

  <Card title="Funzionalità frontend per la visualizzazione dei dati" icon="window">
    **Approccio corretto**

    <Check>
      "In `UserProfileComponent`, add a dropdown that shows a list of user roles (admin, editor, viewer). Use the styling from `DropdownBase`. When a role is selected, call the existing API to set the user role. Validate by checking that the selection updates the user role in the DB. Refer to your Knowledge for how to test properly."
    </Check>

    **Perché funziona:**

    * Indica componenti specifici
    * Elenca esattamente i ruoli da includere
    * Fa riferimento al componente di stile esistente
    * Definisce il flusso di interazione dell’utente
    * Include i passaggi di validazione

    <br />

    ***

    <br />

    **Approccio errato**

    <Warning>
      "Make the user profile page more user-friendly. Add some way for them to change roles and confirm it's working."
    </Warning>

    **Perché non funziona:**

    * "User-friendly" è soggettivo
    * Nessun componente di UI specifico menzionato
    * Flusso di interazione dell’utente non chiaro
    * Criteri di validazione vaghi
  </Card>
</CardGroup>

<div id="more-examples">
  ## Altri esempi
</div>

<div id="good">
  ### Buoni esempi
</div>

<CardGroup cols={1}>
  <Card title="Scrivere test unitari" icon="vial">
    <Check>
      "Aggiungi test Jest per i metodi di AuthService: login e logout. Assicurati che la copertura dei test per queste due funzioni sia almeno dell'80%. Usa `UserService.test.js` come esempio. Dopo l'implementazione, esegui `npm test -- --coverage` e verifica che il report di copertura mostri >80% per entrambe le funzioni. Conferma inoltre che i test passino sia con credenziali valide che non valide e che il logout svuoti correttamente i dati di sessione."
    </Check>

    **Perché è un buon esempio?** Metrica di successo chiara (copertura all'80%), riferimenti per guidare Devin (`UserService.test.js`) e ambito ben definito con passaggi di verifica specifici.
  </Card>

  <Card title="Migrazione o refactoring del codice esistente" icon="code-branch">
    <Check>
      "Migra `logger.js` da JavaScript a TypeScript. Abbiamo già un `tsconfig.json` e una suite di test `LoggerTest.test.js` per la validazione. Assicurati che compili senza errori e non modificare la configurazione esistente! Dopo la migrazione, verifica: 1) eseguendo `tsc` per confermare che non ci siano errori di tipo, 2) eseguendo la test suite con `npm test LoggerTest.test.js` per verificare che tutti i test passino e 3) controllando che tutte le chiamate esistenti ai metodi del logger in tutta la codebase funzionino ancora senza errori di tipo."
    </Check>

    **Perché è un buon esempio?** C'è un chiaro template (`tsconfig.json`) e una test suite per un feedback immediato, oltre a passaggi specifici di compilazione e validazione.
  </Card>

  <Card title="Aggiornare API o query del database" icon="database">
    <Check>
      "Stiamo passando da pg a Sequelize (leggi [https://sequelize.org/api/v6/identifiers](https://sequelize.org/api/v6/identifiers)). Aggiorna le query di UserModel per usare i metodi Sequelize. Fai riferimento a `OrderModel` per vedere come lo facciamo in questa codebase. Dopo l'implementazione, verifica: 1) eseguendo `npm run test:integration UserModel.test.js` per controllare che tutti i test di integrazione passino, 2) confermando che le prestazioni delle query non siano peggiorate controllando il tempo di esecuzione su un dataset di test di 1000 utenti e 3) verificando che tutte le operazioni CRUD mantengano l'integrità dei dati eseguendo `npm run test:e2e user-flows.test.js`."
    </Check>

    **Perché è un buon esempio?** Devin può imitare un pattern noto e ci sono riferimenti espliciti (`OrderModel.js`). Fornisce un link alla documentazione così che Devin sappia di consultarla e include passaggi specifici di verifica delle prestazioni e della funzionalità con comandi di test esatti.
  </Card>

  <Card title="Implementare una funzionalità partendo da un design" icon="paintbrush">
    <Check>
      "Implementa la pagina dei prezzi partendo da questo file Figma: [https://figma.com/file/abc123/Pricing-Page](https://figma.com/file/abc123/Pricing-Page). Concentrati sul frame 'Pricing Section'. Usa la nostra configurazione di Tailwind in tailwind.config.ts per colori e spaziature. Riutilizza i componenti Card e Button esistenti da src/components/ui/. Dopo l'implementazione, avvia il dev server e cattura screenshot alle larghezze desktop (1440px) e mobile (375px). Non aprire una PR finché non corrisponde al design."
    </Check>

    **Perché è un buon esempio?** Collega lo specifico file Figma, indica il frame esatto, fa riferimento al design system del progetto e ai componenti esistenti e indica a Devin di verificare visivamente il proprio lavoro prima di aprire una PR. Con il [Figma MCP](/it/work-with-devin/mcp) connesso, Devin può leggere direttamente i design token dal file.
  </Card>

  <Card title="Indagare su un bug in produzione" icon="bug">
    <Check>
      "Gli utenti segnalano errori 500 sulla pagina di checkout. Usa il Sentry MCP per recuperare gli ultimi stack trace per il progetto payments-api. Controlla il database per eventuali problemi di dati correlati. Trova la causa principale, correggila e aggiungi un test di regressione. Inserisci il link alla issue di Sentry nella descrizione della PR."
    </Check>

    **Perché è un buon esempio?** Indirizza Devin verso gli strumenti giusti ([integrazioni MCP](/it/work-with-devin/mcp)), fornisce un chiaro percorso di indagine e definisce il deliverable atteso (fix + test di regressione + PR).
  </Card>
</CardGroup>

<div id="bad">
  ### Non consigliato
</div>

<CardGroup cols={1}>
  <Card title="Revisione del codice open-ended" icon="magnifying-glass">
    <Warning>
      "Trova i problemi nel nostro codebase e risolvili"
    </Warning>

    **Perché non va bene?** La richiesta è troppo vaga e non strutturata. Non ci sono criteri di successo e Devin non ha modo di sapere quando ha finito.

    **Invece:** Usa [Devin Review](/it/work-with-devin/devin-review) per la revisione automatica del codice su specifiche PR, oppure assegna a Devin un'attività mirata come "Trova e correggi tutti gli utilizzi della API `oldLogger` deprecata in `src/services/`."
  </Card>

  <Card title="Richieste visive puramente soggettive" icon="palette">
    <Warning>
      "Rendi la landing page più bella"
    </Warning>

    **Perché non va bene?** "Più bella" è soggettivo e Devin non ha criteri a cui mirare. Devin può costruire interfacce utente funzionali e implementare design a partire da specifiche, ma non può prendere decisioni estetiche in autonomia.

    **Invece:** Fornisci un design Figma, un sito di riferimento o modifiche specifiche: "Aumenta la dimensione del font della sezione hero a 48px, aggiungi 32px di padding e usa il colore `indigo-500` dalla nostra configurazione di Tailwind."
  </Card>

  <Card title="Progetti molto complessi e vaghi" icon="sitemap">
    <Warning>
      "Crea una nuova architettura a microservizi per la nostra app."
    </Warning>

    **Perché non va bene?** Si tratta di un task molto grande e non strutturato. Richiede molte decisioni architetturali, compromessi e contesto che non sono inclusi nel prompt.

    **Invece, suddividilo:**

    1. Usa [Ask Devin](/it/work-with-devin/ask-devin) per analizzare il tuo codebase e mappare le dipendenze
    2. Chiedi a Devin di proporre architetture specifiche con relativi compromessi
    3. Crea sessioni separate per implementare ciascun servizio — eseguili in parallelo con i [Devin gestiti](/it/work-with-devin/advanced-capabilities#managed-devins)
  </Card>
</CardGroup>