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.

​
Cattivi esempi

Revisione del codice senza specifiche

“Trova i problemi nella nostra base di codice e risolvili”
Perché è un cattivo esempio? La richiesta è troppo vaga e chiede a Devin di completare troppe attività in un’unica sessione. Devin può confondersi durante sessioni molto lunghe.

Attività di design visivo

“Crea esattamente ciò che è mostrato in questo mockup Figma”
Perché è un cattivo esempio? Si tratta di una richiesta visiva soggettiva. Devin non può “vedere” come gli esseri umani e non coglierà perfettamente tutti i dettagli. Non è ottimizzato per questi casi d’uso.

Progetti molto complessi e poco definiti

“Crea una nuova architettura a microservizi per la nostra app.”
Perché è un cattivo esempio? Si tratta di un compito molto ampio e non strutturato, che richiede decisioni architetturali e compromessi.Invece, suddividi i progetti complessi in fasi:
  1. Fai analizzare la tua base di codice da Devin
  2. Chiedi a Devin di proporre architetture specifiche
  3. Crea sessioni separate per implementare ogni parte