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 den Nutzen von Devin maximieren. Für umfassendere Strategien zur effektiven Zusammenarbeit mit Coding Agents lesen Sie auch unseren Leitfaden „Coding Agents 101“.

​
Beispiel-Prompt

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.
Probiere die Prompt-Verbesserungs-Schaltfläche aus, wenn du eine Sitzung erstellst (klicke auf das gelbe Warnsymbol, um Feedback zu sehen)
Prompt-Verbesserungs-Schaltfläche

​
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. Wenn du Devin Aufgaben gibst, die weit außerhalb seiner aktuellen Fähigkeiten liegen, führt das häufig zu schlechten Ergebnissen.
  • Wie:
    • Lies diese Anleitung: Wann du Devin einsetzen solltest
    • Gib insbesondere für anspruchsvolle Aufgaben 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.
    • 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: Weise Devin keine Aufgaben außerhalb seiner Kernkompetenzen zu
  • Warum: Aufgaben zuzuweisen, die fortgeschrittenes Fachwissen oder weitreichende Designentscheidungen ohne ausreichende Anleitung erfordern, kann zu Ineffizienz und verschwendeten ACUs führen.
  • Wie:
    • Vermeide Aufgaben, die ohne klare Anweisungen oder Referenzen erheblichen kreativen oder strategischen Input auf hoher Ebene verlangen.
    • Vermeide Aufgaben, die starke visuelle Fähigkeiten erfordern, z. B. das Umsetzen von Figma-Designs, da Devin zwar Webseiten sehen kann, aber kein perfektes Sehvermögen hat.
    • Vermeide es, Devin zu bitten, Mobile-Apps zu erstellen, da es keinen Zugriff auf ein Telefon hat und seine Arbeit nicht einfach testen kann.
  • Beispiel: Don’t: “Create a new authentication system for my website from scratch.”
  • Beispiel: Don’t: “Turn this Figma mockup into a React component.”
  • Beispiel: Don’t: “Build an AI-powered shopping app.”
Tun Sie: Arbeiten Sie gemeinsam, indem Sie Teilaufgaben übernehmen
  • Warum: Manchmal ist es schneller, wenn Sie die letzten 20 % einer Aufgabe selbst erledigen.
  • Wie:
    • Lassen Sie Devin den Großteil der Implementierung übernehmen und verfeinern Sie das Ergebnis anschließend.
    • Nutzen Sie Devin, um die sich wiederholenden Teile des Workflows zu beschleunigen, während Sie sich auf kritischere Aspekte konzentrieren.
  • Beispiel: Tun Sie: „Generiere den initialen Boilerplate-Code für den neuen API-Endpunkt, dann integriere ich ihn in das bestehende Authentifizierungssystem.“
Tun Sie nicht: Verlassen Sie sich nicht ausschließlich auf Devin für ganze komplexe Projekte
  • Warum: Eine zu starke Abhängigkeit von Devin bei Aufgaben, die ein differenziertes Verständnis oder kreatives Problemlösen erfordern, kann zu Verzögerungen und suboptimalen Ergebnissen führen.
  • Wie:
    • Vermeiden Sie es, Devin Aufgaben zuzuweisen, von denen Sie wissen, dass sie erhebliche menschliche Mitwirkung für eine effektive Umsetzung erfordern.
  • Beispiel: Tun Sie nicht: „Entwickle die gesamte Backend-Infrastruktur für unser neues Gen-AI-Feature.“
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 Korrektheit zu bestätigen.
    • Halten Sie Build-Validierungen, Lint-Checks und statische Analysen zur Sicherung der Codequalität aufrecht.
  • 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.”
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.

​
Fazit

Formuliere Aufgaben mit ausreichend Struktur und Klarheit, um zuverlässige und zufriedenstellende Ergebnisse zu erzielen.