Vai al contenuto principale
Assicurati di leggere Quando usare Devin e Istruire Devin in modo efficace per altri suggerimenti essenziali.

Aggiungere un nuovo endpoint API

Approccio corretto
“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.”
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


Approccio errato
“Add a user stats endpoint.”
Perché non funziona:
  • Non è specificato quali statistiche includere
  • Nessun riferimento alle fonti dati
  • Nessun riferimento a pattern esistenti
  • Mancano i requisiti relativi ai test

Funzionalità frontend per la visualizzazione dei dati

Approccio corretto
“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.”
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


Approccio errato
“Make the user profile page more user-friendly. Add some way for them to change roles and confirm it’s working.”
Perché non funziona:
  • “User-friendly” è soggettivo
  • Nessun componente di UI specifico menzionato
  • Flusso di interazione dell’utente non chiaro
  • Criteri di validazione vaghi

​
Altri esempi

​
Buoni esempi

Scrivere test unitari

“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.”
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.

Migrazione o refactoring del codice esistente

“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.”
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.

Aggiornare API o query del database

“Stiamo passando da pg a Sequelize (leggi 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.”
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.

Implementare una funzionalità partendo da un design

“Implementa la pagina dei prezzi partendo da questo file Figma: 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.”
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 connesso, Devin può leggere direttamente i design token dal file.

Indagare su un bug in produzione

“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.”
Perché è un buon esempio? Indirizza Devin verso gli strumenti giusti (integrazioni MCP), fornisce un chiaro percorso di indagine e definisce il deliverable atteso (fix + test di regressione + PR).

​
Non consigliato

Revisione del codice open-ended

“Trova i problemi nel nostro codebase e risolvili”
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 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/.”

Richieste visive puramente soggettive

“Rendi la landing page più bella”
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.”

Progetti molto complessi e vaghi

“Crea una nuova architettura a microservizi per la nostra app.”
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 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 ed eseguirle in parallelo con le sessioni batch