Skip to main content
Strategische Use Cases sind große Projekte mit hohem geschäftlichem Mehrwert, die in isolierte, wiederkehrende Teilaufgaben aufgeteilt werden können. Jeder Slice ist die Arbeit eines Devin und sollte daher überschaubar (unter 90 Minuten menschlicher Engineering-Arbeit) und inkrementell sein.
Kurzfassung — Anforderungen an Devin Use Cases:
  1. Hoher Umfang wiederkehrender Teilaufgaben (Slices)
  2. Teilaufgaben mit dem Schwierigkeitsgrad eines Junior-Engineers
  3. Teilaufgaben, die isoliert und inkrementell bearbeitbar sind
  4. Teilaufgaben mit einer objektiven Verifikationsschleife
  5. (Empfohlen): Minimale Projektabhängigkeiten

Notwendige Eigenschaften

Ein optimaler strategischer Devin-Anwendungsfall ist flach und breit statt schmal und tief. Komplexe, komplett neue Features (selbst wenn sie repetitiv sind) werden in großem Maßstab voraussichtlich nicht zuverlässig genug sein.
Vergleich schmal-tief vs. flach-breit
Ein großer Backlog einfacher, horizontaler Änderungen (z. B. SonarQube-Issues) erzeugt einen enormen ROI, wenn er horizontal skaliert wird. Diagramm zu horizontalen Änderungen
Je einfacher die einzelne Arbeitseinheit, desto zuverlässiger das Gesamtprojekt.

Anwendungsfälle für Slicing [WICHTIG]

Migrationen, Refactorings, Modernisierungen und Backlogs technischer Schulden sind hervorragende Einsatzszenarien. Zum Beispiel eine Code-Migration. Teilen Sie die Migration in voneinander unabhängige Slices auf, bei denen jede Aufgabe in einer eigenen Devin-Session bearbeitet wird. Slicing use cases illustration

Überprüfung

Ein Slice sollte die kleinste atomare Einheit des Projekts sein (Datei, Notebook oder Modul) mit:
  1. Weniger als 90 Minuten manuellem Engineering-Aufwand
  2. Einer Möglichkeit, Codeänderungen zu überprüfen (Tests, Build, CI-Checks oder benutzerdefiniertes Überprüfungsskript)
Jede Devin-Instanz muss objektiv feststellen können, ob sie ihre Aufgabe erfolgreich abgeschlossen hat. Solange die Überprüfung nicht abgeschlossen ist, sollte sie mithilfe detaillierter Stacktraces oder Fehlerprotokolle weiter iterieren.
Jedes Slice sollte vermeiden, zu viele Abhängigkeiten oder Plattformen einzubinden, mit denen interagiert werden muss. Richten Sie Devin konsequent auf die Codeänderungen aus! Diagramm zur Abwärtskompatibilität Jedes Slice muss isoliert und inkrementell sein. Nutzen Sie die Parallelität von Devin und führen Sie die Migration Slice für Slice durch. Nach der manuellen Überprüfung werden die einzelnen PRs nacheinander in master gemergt. Visualisierung der parallelen Ausführung Das Gesamtmodell für einen Devin-Use-Case: Diagramm des Gesamtmodells Devin muss auf der Ebene des einzelnen Slices maximal zuverlässig sein, damit wir bei der Parallelisierung über Tausende von Slices hinweg eine hohe Zuverlässigkeit in großem Maßstab beibehalten. Selbst eine kleine Fehlermarge kann bei Skalierung zu vielen fehlerhaften Änderungen führen.

Vom Kunden bereitzustellen

  • Klare Details zu jedem Schritt in jedem Slice (eine ausführliche Beschreibung oder ein Video des End-to-End-Prozesses ist dabei äußerst hilfreich)
  • Mehrere Beispiele für Codeänderungen vorher/nachher (Input-/Output-Paare)
  • Gewährter Zugriff für Devin auf alle erforderlichen Abhängigkeiten in jedem Slice

Beispiele

Laufende Aufgaben im Bereich technischer Schulden (z. B. PR-Reviews oder QA-Tests) sind ebenfalls sehr gute Anwendungsfälle, vorausgesetzt, sie lassen sich in einzelne Schritte aufteilen.
Migrationen, Modernisierungen und Refactorings sind starke Anwendungsfälle für Devin, wenn sie inkrementell umgesetzt werden. Eine Migration, bei der das gesamte Repository gleichzeitig auf das neue System umgestellt werden muss, statt schrittweise, wird nicht empfohlen.
Weiterführende Informationen: Nubank Migration Case Study