Identificare il caso d’uso giusto per Devin è fondamentale per massimizzare l’efficienza e il ritorno sull’investimento (ROI). Di seguito sono riportate le pratiche consigliate per selezionare un caso d’uso che sia in linea con i punti di forza di Devin.
Casi d’uso Enterprise ideali
| Criteri ideali per i casi d’uso |
|---|
| Progetti di grandi dimensioni e ad elevato valore per il business che possono essere suddivisi in sottoattività isolate e ripetitive. |
| Attività che richiedono meno di 90 minuti di lavoro manuale di ingegneria. |
| Attività retrocompatibili che possono essere validate e unite in modo indipendente. |
Requisiti ideali per Devin
| Requisito |
|---|
| Alto volume di sottoattività ripetitive (slices) |
| Attività con complessità da junior engineer |
| Attività isolate e incrementali |
| Sottoattività oggettive e verificabili |
| (Consigliato) Dipendenze di progetto minime |
Progettare il lavoro di Devin
| Scenario | Considerazione sull’affidabilità | Tipo di task |
|---|
| Chiedere a Devin di creare nuove funzionalità complesse da zero (anche se ripetitive) | Affidabilità inferiore su larga scala | Tall & Deep |
| Assegnare a Devin task semplici e ben definiti | Altamente affidabile ed efficace | Wide & Shallow |
Stretto & profondo vs. ampio & superficiale
Più semplice è lo slice, più l’intero progetto risulta affidabile.
Cosa suddividere in slice
- Migrazioni
- Refactoring
- Modernizzazioni
- Backlog di debito tecnico
Ad esempio, quando si lavora a una migrazione di codice, questa deve essere suddivisa in slice isolate, ciascuna gestita da una singola sessione Devin.
Una slice dovrebbe essere la più piccola unità atomica del progetto.
| Esempi di slice |
|---|
| File |
| Notebook |
| Modulo |
| Requisito | Dettagli |
|---|
| Time Limit | Ogni slice deve richiedere meno di 90 minuti di lavoro manuale di sviluppo. |
| Verifica | Deve includere un modo per validare le modifiche al codice, ad esempio:
- Esecuzione dei test
- Build del codice
- Verifiche CI
- Uno script di verifica personalizzato |
Devin deve avere un chiaro meccanismo di verifica dell’esito (successo/fallimento).
Evita attività con dipendenze eccessive o sistemi esterni. Devin eccelle nelle attività di programmazione.
| Requisito | Descrizione |
|---|
| Isolamento | Ogni slice deve essere indipendente e retrocompatibile. |
| Esecuzione parallela | Sfrutta il parallelismo di Devin per eseguire le slice simultaneamente. |
| Revisione umana | Una volta completato ciascun slice, deve essere sottoposto a revisione umana prima di effettuare il merge in main. |
Considerazioni sulla scalabilità
| Principio | Descrizione |
|---|
| Affidabilità a livello di slice | Devin è ottimizzato per la massima affidabilità a livello di singolo slice. |
| Considerazione sulla scalabilità | Quando si opera su migliaia di slice, mantenere un’elevata affidabilità è fondamentale. |
| Impatto degli errori | Anche un tasso di errore ridotto può avere un effetto cumulativo quando si lavora su larga scala. |
Best practice per la definizione dei task
| Requisito | Descrizione |
|---|
| Dettagli chiari dei passaggi | Fornisci istruzioni esplicite per ogni slice. |
| Riferimento end-to-end | Una guida dettagliata o un video aiuta a garantire coerenza. |
| Esempi Before/After | Offri più esempi di codice before/after (coppie input/output). |
| Accesso alle dipendenze | Assicurati che Devin abbia tutte le dipendenze necessarie per il task. |
Migrazioni, modernizzazioni e refactoring sono ottimi casi d’uso se possono essere affrontati in modo incrementale.
Ad esempio, una migrazione dell’intero repository che richiede tutte le modifiche in una volta sola non è consigliata.
