Zum Hauptinhalt springen
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.
SzenarioZuverlässigkeitsaspektAufgabentyp
Devin beauftragen, komplexe, komplett neue Features zu entwickeln (selbst wenn sie repetitiv sind)Geringere Zuverlässigkeit bei großem UmfangSchmal & Tief
Devin einfache, klar definierte Aufgaben zuweisenSehr zuverlässig und effektivBreit & Flach

Tief & schmal vs. breit & flach

Vergleich schmal-tief vs. flach-breit
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. Diagramm horizontaler Änderungen
Je einfacher der Slice ist, desto zuverlässiger ist das Gesamtprojekt.

Was Sie slicen sollten

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. Slicing use cases illustration

Verifizierung

Ein Slice sollte die kleinste atomare Einheit des Projekts sein.
Beispiel-Slices
Datei
Notebook
Modul
AnforderungDetails
ZeitlimitJedes Slice darf höchstens 90 Minuten manuelle Entwicklungsarbeit erfordern.
VerifizierungMuss 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.
Backwards compatibility diagram

Parallele Ausführung

AnforderungBeschreibung
IsolationJedes Slice muss unabhängig und abwärtskompatibel sein.
Parallele AusführungVerwende die Parallelisierung von Devin, um Slices gleichzeitig auszuführen.
Menschliche ÜberprüfungNachdem jedes Slice abgeschlossen ist, sollte es vor dem Merge in main einer menschlichen Überprüfung unterzogen werden.
Visualisierung der parallelen Ausführung

Überlegungen zur Skalierung

Gesamtdiagramm des Modells
PrinzipBeschreibung
Zuverlässigkeit auf Slice-EbeneDevin ist für maximale Zuverlässigkeit auf der Ebene einzelner Slices optimiert.
Überlegungen zur SkalierungBeim Skalieren über tausende Slices hinweg ist die Aufrechterhaltung einer hohen Zuverlässigkeit entscheidend.
Auswirkungen von FehlernSelbst eine geringe Fehlerrate kann sich bei der Ausführung in großem Maßstab stark auswirken.

Best Practices für die Definition von Aufgaben

AnforderungBeschreibung
Klare Schritt-DetailsGib explizite Anweisungen für jede Teilaufgabe.
End-to-End-ReferenzEin detaillierter Leitfaden oder ein Video hilft, Konsistenz sicherzustellen.
Vorher/Nachher-BeispieleStelle mehrere Vorher/Nachher-Codebeispiele (Input/Output-Paare) bereit.
Zugriff auf AbhängigkeitenStelle 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