Den richtigen Use Case für Devin zu finden, ist entscheidend, um Effizienz und Return on Investment (ROI) zu maximieren. Im Folgenden finden Sie Best Practices für die Auswahl eines Use Cases, der zu den Stärken von Devin passt.
Optimale Enterprise-Anwendungsfälle
| Kriterien für ideale Anwendungsfälle |
|---|
| Große Projekte mit hohem geschäftlichem Mehrwert, die in isolierte und wiederholbare Teilaufgaben zerlegt werden können. |
| Aufgaben, die weniger als 90 Minuten manuelle Entwicklungszeit erfordern. |
| Abwärtskompatible Aufgaben, die unabhängig validiert und integriert werden können. |
Devins ideale Anforderungen
| Anforderung |
|---|
| Hohe Anzahl wiederkehrender Unteraufgaben („Slices“) |
| Aufgaben mit Komplexität auf Junior-Engineer-Niveau |
| Isolierte und schrittweise Aufgaben |
| Objektive und überprüfbare Unteraufgaben |
| (Empfohlen) Geringe Projektabhängigkeiten |
Wenn Ihre Aufgabe die meisten oder alle dieser Anforderungen erfüllt, ist sie ein idealer Kandidat für Devin.
Die Arbeit mit Devin gestalten
Die Wahl des richtigen Aufgabentyps ist entscheidend, um die Zuverlässigkeit von Devin zu maximieren.
| Szenario | Zuverlässigkeitsaspekt | Aufgabentyp |
|---|
| Devin beauftragen, komplexe, komplett neue Features zu entwickeln (selbst wenn sie repetitiv sind) | Geringere Zuverlässigkeit bei großem Umfang | Schmal & Tief |
| Devin einfache, klar definierte Aufgaben zuweisen | Sehr zuverlässig und effektiv | Breit & Flach |
Tief & schmal vs. breit & flach
Ein großer Backlog aus einfachen, horizontal skalierbaren Aufgaben (z. B. dem Beheben von SonarQube-Issues) kann einen erheblichen ROI erzielen, wenn er über Tausende von Iterationen skaliert wird.
Je einfacher der Slice ist, desto zuverlässiger ist das Gesamtprojekt.
Gute Kandidaten für Devin:
- Migrationen
- Refactorings
- Modernisierungen
- Backlogs technischer Schulden
Wenn Sie zum Beispiel an einer Code-Migration arbeiten, muss diese in isolierte Slices aufgeteilt werden, die jeweils in einer eigenen Devin-Session bearbeitet werden.
Ein Slice sollte die kleinste atomare Einheit des Projekts sein.
| Beispiel-Slices |
|---|
| Datei |
| Notebook |
| Modul |
| Anforderung | Details |
|---|
| Zeitlimit | Jedes Slice darf höchstens 90 Minuten manuelle Entwicklungsarbeit erfordern. |
| Verifizierung | Muss eine Möglichkeit beinhalten, Codeänderungen zu überprüfen, zum Beispiel: - Ausführen von Tests - Build des Codes - CI-Checks - Ein benutzerdefiniertes Verifizierungsskript |
Devin muss über einen klaren Verifizierungsmechanismus für Erfolg/Misserfolg verfügen.
Vermeiden Sie Aufgaben mit übermäßigen Abhängigkeiten oder externen Systemen. Devin ist besonders gut für Programmieraufgaben geeignet.
| Anforderung | Beschreibung |
|---|
| Isolation | Jedes Slice muss unabhängig und abwärtskompatibel sein. |
| Parallele Ausführung | Verwende die Parallelisierung von Devin, um Slices gleichzeitig auszuführen. |
| Menschliche Überprüfung | Nachdem jedes Slice abgeschlossen ist, sollte es vor dem Merge in main einer menschlichen Überprüfung unterzogen werden. |
Überlegungen zur Skalierung
| Prinzip | Beschreibung |
|---|
| Zuverlässigkeit auf Slice-Ebene | Devin ist für maximale Zuverlässigkeit auf der Ebene einzelner Slices optimiert. |
| Überlegungen zur Skalierung | Beim Skalieren über tausende Slices hinweg ist die Aufrechterhaltung einer hohen Zuverlässigkeit entscheidend. |
| Auswirkungen von Fehlern | Selbst eine geringe Fehlerrate kann sich bei der Ausführung in großem Maßstab stark auswirken. |
Best Practices für die Definition von Aufgaben
| Anforderung | Beschreibung |
|---|
| Klare Schritt-Details | Gib explizite Anweisungen für jede Teilaufgabe. |
| End-to-End-Referenz | Ein detaillierter Leitfaden oder ein Video hilft, Konsistenz sicherzustellen. |
| Vorher/Nachher-Beispiele | Stelle mehrere Vorher/Nachher-Codebeispiele (Input/Output-Paare) bereit. |
| Zugriff auf Abhängigkeiten | Stelle sicher, dass Devin alle erforderlichen Abhängigkeiten für die Aufgabe hat. |
Devin eignet sich besonders gut für fortlaufende Aufgaben im Bereich der Technical Debt (z. B. PR-Reviews, QA-Automatisierung), wenn sie sinnvoll in Teilaufgaben zerlegt und strukturiert sind.
Migrationen, Modernisierungen und Refactorings sind starke Anwendungsfälle, wenn sie schrittweise bearbeitet werden können.
Eine vollständige Repository-Migration, die alle Änderungen auf einmal erfordert, ist beispielsweise nicht zu empfehlen.
Fallstudie: Fallstudie zur Nubank-Migration