Zum Hauptinhalt springen
Das Wichtigste, woran Sie beim Anweisen von Devin denken sollten, ist, so konkret wie möglich zu sein. So wie Sie einer Kollegin oder einem Kollegen eine detaillierte Spezifikation geben würden, wenn Sie jemanden bitten, etwas zu programmieren, sollten Sie es auch bei Devin tun. Dieser Leitfaden hilft Ihnen, Ihre Anweisungen bzw. Prompts so zu strukturieren, dass Sie Devin effektiv einsetzen können. Für umfassendere Strategien zur effektiven Zusammenarbeit mit Coding Agents lesen Sie auch unseren Leitfaden „Coding Agents 101“.

​
Effektive Prompts schreiben

Hier ein Beispiel-Prompt, der eine effektive Anweisung veranschaulicht:
Im Devin-Repository sollst du ein Tool bauen, das die RAM- und CPU-Auslastung der Remote-Maschinen überwacht, auf denen Devin läuft. Führe dazu bitte die folgenden Aufgaben aus:
  • Erstelle einen Hintergrundtask, der automatisch gestartet wird, wenn devin.rs startet.
  • Der Task soll eine Verbindung zu allen geforkten Remote-Maschinen herstellen, die in dieser Devin-Session verwendet werden, und deren RAM- und CPU-Auslastung überwachen.
  • Wenn die Auslastung 80 % der verfügbaren Ressource überschreitet, löse einen neuen Typ von Devin-Event aus, um dies zu signalisieren (sieh dir an, wie wir Kafka verwenden).
  • Entwirf die Architektur so, dass andere Operationen nicht blockiert werden. Du solltest verstehen, wie alle Container für die Devin-Sub-Agents miteinander interagieren.

​
Warum das gut funktioniert

Bietet hilfreichen Kontext

  • Detail: Gibt das Devin-Repository und den übergeordneten Zweck an (Überwachung der Ressourcenauslastung).
  • Vorteil: Devin kennt den Umfang und den Kontext genau.

Gibt Schritt-für-Schritt-Anweisungen

  • Detail: Aufgaben wie „create a background task“ und „emit an event at 80% usage“.
  • Vorteil: Zerlegt die Arbeit in logische Teile.

Definiert klare Erfolgskriterien

  • Detail: Definiert „success“ als das Auslösen eines bestimmten Events bei 80 % Auslastung.
  • Vorteil: Devin weiß genau, was erreicht werden soll.

Verweist auf bestehende Muster und Code

  • Detail: Erwähnt Kafka und Container-Interaktionen.
  • Vorteil: Fördert die Wiederverwendung etablierter Code- oder Designansätze.

​
Bewährte Vorgehensweisen: Was Sie tun und was Sie vermeiden sollten

Do: Klare Anweisungen geben
  • Warum: Devin kann stecken bleiben, wenn es keinen klaren Weg gibt oder zu viele Interpretationsmöglichkeiten bestehen.
  • Wie:
    • Triff wichtige Entscheidungen und Ermessensurteile für Devin.
    • Gib konkrete Designentscheidungen und Implementierungsstrategien vor.
    • Definiere klaren Umfang, Grenzen und Erfolgskriterien.
  • Beispiel: “Optimiere die getOrderDetails-Query in orderService.js, indem du einen zusammengesetzten Index auf den Spalten order_id und product_id der Tabelle order_items hinzufügst. Refaktoriere die Query, sodass die bestehende korrelierte Unterabfrage durch einen JOIN mit der Tabelle products zum Abrufen der Produktdetails ersetzt wird.”
Don’t: Entscheidungen offen lassen
  • Warum: Vage Anweisungen können dazu führen, dass Devin Lösungen implementiert, die nicht zu deinen tatsächlichen Anforderungen passen.
  • Wie:
    • Vermeide Formulierungen, bei denen Devin ohne Orientierung wesentliche Design- oder Implementierungsentscheidungen treffen muss. Das kann zu unerwarteten Ergebnissen führen.
  • Beispiel: Nicht so: “Verbessere die Performance unserer Datenbank.”
Do: Wähle Aufgaben, die zu Devins Stärken gehören
  • Warum:
    • Ergebnisse maximieren: Wenn du Aufgaben zuweist, die zu Devins Fähigkeiten passen, erzielst du die besten Ergebnisse mit minimalem Aufwand und ACU-Einsatz.
  • Wie:
    • Lies diese Anleitung: Wann du Devin einsetzen solltest
    • Gib Beispiele, Module, Ressourcen und Vorlagen an, denen Devin folgen kann.
      • Teile direkte Links zu Dokumentationsseiten, damit Devin Details wie API-Request-Bodies und Features nachlesen kann, die ihm eventuell noch nicht bekannt sind.
      • Teile konkrete Dateinamen, die Devin sich ansehen und von denen es lernen soll.
    • Verbinde MCP-Integrationen, um Devin Zugriff auf Figma-Designs, Datenbanken, Monitoring-Tools und mehr zu geben.
    • Beispiel: Do: “Refactor state management in the Header component to use React’s useReducer hook for better scalability and maintainability. Ensure that all existing functionality is preserved and add unit tests to cover the new state logic.”
    • Beispiel: Do: “Use authTemplate.rs as a reference to maintain consistency in error handling.”
    • Beispiel: Do: “Check out the official Sequelize docs at https://sequelize.org/docs/v6/getting-started/ for migration steps.”
Don’t: Kontext bei komplexen Aufgaben weglassen
  • Warum: Auch wenn Devin komplexe Aufgaben bewältigen kann, liefert es die besten Ergebnisse, wenn du Kontext und eine klare Richtung vorgibst.
  • Wie:
    • Für Aufgaben, die Domänenwissen erfordern, stelle relevante Dokumentation, Beispiele oder Referenzen bereit.
    • Für visuelle Aufgaben stelle Figma-Dateien über das Figma MCP, Referenzdesigns oder detaillierte Spezifikationen bereit – Devin kann darauf aufbauen, wird aber nicht eigenständig ein visuelles Erscheinungsbild entwerfen.
    • Für Mobile-Apps solltest du berücksichtigen, dass Devin keinen Zugriff auf einen Telefon-Emulator hat – definiere daher klare Testkriterien.
  • Beispiel: Nicht so: “Make the app look better” – gib stattdessen konkrete Design-Spezifikationen oder eine Figma-Datei an.
  • Beispiel: Nicht so: “Improve our database’s performance” – gib stattdessen an, welche Queries optimiert werden sollen und auf welche Metriken du abzielen möchtest.
Do: Richten Sie klare und regelmäßige Überprüfungen ein
  • Warum: Regelmäßiges Feedback (sowohl von Ihnen als auch von Tests/Checks/Lintern) stellt sicher, dass Devin Fehler effektiv korrigiert.
  • Wie:
    • Verwenden Sie Tests (Unit-/Integrationstests), um die Richtigkeit zu bestätigen.
    • Halten Sie Build-Validierungen, Lint-Checks und statische Analysen zur Sicherung der Codequalität aufrecht.
    • Aktivieren Sie Devin Review mit Auto-Fix, damit Devin automatisch auf Review-Kommentare und CI-Fehler reagiert – so entsteht ein geschlossener Kreislauf, in dem PRs schrittweise eine Merge-reife Qualität erreichen, ohne dass Sie ständig eingreifen müssen.
  • Beispiel: Do: “Führen Sie nach jeder Iteration npm test aus.”
  • Beispiel: Do: “Stellen Sie sicher, dass die Pipeline auf CircleCI nicht fehlschlägt.”
  • Beispiel: Do: “Stellen Sie sicher, dass alle ESLint-/Prettier-Checks bestanden werden, bevor Sie Commits pushen.”
Don’t: Verzichten Sie auf Feedback
  • Warum: Ohne Feedback weiß Devin nicht, ob seine Lösungen Ihren Anforderungen entsprechen.
  • Wie:
    • Vermeiden Sie es, Aufgaben zu vergeben, ohne zu definieren, wie Sie sie bewerten werden.
Do: Klare Checkpoints und Teilaufgaben definieren
  • Warum: Das Aufteilen komplexer Aufgaben in kleinere Checkpoints hilft Devin, fokussiert zu bleiben und reduziert Fehler.
  • Wie:
    • Unterteile Aufgaben in verifizierbare Teilaufgaben und starte eine Devin-Sitzung für jede Teilaufgabe.
    • Definiere, wie Erfolg für jede Teilaufgabe aussieht, und setze optional Checkpoints innerhalb jeder Teilaufgabe.
    • Bitte Devin, nach Abschluss jedes Checkpoints oder jeder Teilaufgabe zu berichten.
Beispiele:
  • Beispiel: Do: “Wenn du mit dem Datensatz arbeitest, überprüfe, dass er mindestens 500 Zeilen hat und die Spalten X, Y, Z enthält.”
  • Beispiel: Do: “Wenn du die API änderst, bestätige, dass der Endpunkt den Status 200 zurückgibt und alle erforderlichen Felder enthält.”
  • Beispiel: Do: “Wenn du das UI aktualisierst, prüfe, dass die Komponente ohne Konsolenfehler rendert und der Design-Spezifikation entspricht.”
Don’t: Konkrete Validierungsanforderungen weglassen
  • Warum: Ohne definierte Validierungsschritte kann Devin Aufgaben nicht zuverlässig abschließen.
  • Wie:
    • Vermeide vage Erfolgskriterien.
    • Lass Verifizierungsschritte nicht implizit oder undefiniert.
  • Beispiel: Don’t: “Stell einfach sicher, dass es funktioniert.”
Devin verfügt über eine vollständige Desktop-Umgebung – Shell, IDE und Browser. Weisen Sie Devin an, seine eigene Arbeit zu testen, bevor es einen Pull Request (PR) erstellt:
  • App starten: “Führe npm run dev aus und überprüfe, dass die neue Seite unter /settings angezeigt wird.”
  • Browser-Test: “Öffne den Browser, navigiere zur Login-Seite und bestätige, dass der OAuth-Flow erfolgreich abgeschlossen wird.”
  • Visuelle Überprüfung: “Mache Screenshots in Desktop-Breite (1440px) und in mobiler Breite (375px) und bestätige, dass das Layout dem Design entspricht.”
  • Screen-Recording: “Nimm dich dabei auf, wie du den Checkout-Flow End-to-End testest.”
So kann Devin seine Änderungen genauso einem QA-Prozess unterziehen, wie Sie es tun würden – noch bevor Sie sich den PR ansehen müssen.
Für wiederkehrende oder komplexe Aufgaben empfehlen wir, Playbooks zu nutzen und iterativ weiterzuentwickeln. Erfahren Sie mehr über den effektiven Einsatz von Playbooks. Playbooks sind wiederverwendbare und teilbare Prompts, die die Delegation von Aufgaben vereinfachen. Wenn Sie beispielsweise möchten, dass Devin wiederkehrende CI-Build-Fehler behebt, erstellen Sie ein Playbook, das die allgemeinen Schritte enthält, die Devin jedes Mal befolgen soll.Für dauerhaften Kontext, den sich Devin über alle Sitzungen hinweg merken soll – etwa Codestandards, typische Bugs und Fixes, Deployment-Workflows oder den Umgang mit internen Tools – verwenden Sie Knowledge. Knowledge-Einträge werden bei Relevanz automatisch herangezogen, sodass Sie dieselben Anweisungen nicht in jedem Prompt wiederholen müssen. Sie können Knowledge an bestimmte Repos anheften oder global anwenden.
Playbooks vs. Knowledge: Verwenden Sie Playbooks für Schritt-für-Schritt-Anleitungen, die an konkrete Aufgaben gebunden sind. Verwenden Sie Knowledge für allgemeine Tipps, Konventionen und Kontext, die sitzungsübergreifend gelten.