Zum Hauptinhalt springen
Stellen Sie sicher, dass Sie When to Use Devin und Instructing Devin Effectively für weitere wichtige Tipps lesen.

Hinzufügen eines neuen API-Endpunkts

Gute Vorgehensweise
“Erstelle einen neuen Endpunkt /users/stats, der ein JSON-Objekt mit der Anzahl der Benutzer und dem durchschnittlichen Registrierungsalter zurückgibt. Verwende dazu unsere bestehende users-Tabelle in PostgreSQL. Du kannst den Endpunkt /orders/stats in statsController.js als Vorlage für die Struktur der Responses verwenden. Stelle sicher, dass der neue Endpunkt in der Test-Suite StatsController.test.js abgedeckt ist.”
Warum das funktioniert:
  • Gibt Route und erwartetes Antwortformat klar an
  • Verweist auf bestehenden Code als Vorlage
  • Definiert die Datenquelle (users-Tabelle)
  • Enthält Anforderungen an die Testabdeckung


Schlechte Vorgehensweise
“Füge einen Endpunkt für Benutzerstatistiken hinzu.”
Warum das fehlschlägt:
  • Unspezifisch, welche Statistiken enthalten sein sollen
  • Keine Erwähnung von Datenquellen
  • Kein Verweis auf bestehende Muster/Konventionen
  • Fehlende Testanforderungen

Frontend-Feature zur Datenanzeige

Gute Vorgehensweise
“Füge in UserProfileComponent ein Dropdown hinzu, das eine Liste von Benutzerrollen (admin, editor, viewer) anzeigt. Verwende das Styling von DropdownBase. Wenn eine Rolle ausgewählt wird, rufe die bestehende API auf, um die Benutzerrolle zu setzen. Überprüfe, ob die Auswahl die Benutzerrolle in der DB aktualisiert. Sieh in deinem Knowledge nach, wie du das korrekt testest.”
Warum das funktioniert:
  • Benennt konkrete Komponenten
  • Listet die exakten Rollen auf, die enthalten sein sollen
  • Verweist auf eine bestehende Styling-Komponente
  • Definiert den Ablauf der Benutzerinteraktion
  • Enthält Validierungsschritte


Schlechte Vorgehensweise
“Mache die Benutzerprofilseite benutzerfreundlicher. Füge irgendeine Möglichkeit hinzu, Rollen zu ändern, und bestätige, dass es funktioniert.”
Warum das fehlschlägt:
  • „Benutzerfreundlich“ ist subjektiv
  • Keine spezifischen UI-Komponenten erwähnt
  • Unklarer Ablauf der Benutzerinteraktion
  • Vage Validierungskriterien

​
Weitere Beispiele

​
Gut

Schreiben von Unit-Tests

“Füge Jest-Tests für die AuthService-Methoden login und logout hinzu. Stelle sicher, dass die Testabdeckung für diese beiden Funktionen mindestens 80 % beträgt. Verwende UserService.test.js als Beispiel. Führe nach der Implementierung npm test -- --coverage aus und überprüfe, dass der Coverage-Bericht >80 % für beide Funktionen anzeigt. Bestätige außerdem, dass die Tests sowohl mit gültigen als auch mit ungültigen Anmeldedaten erfolgreich sind und dass logout die Sitzungsdaten ordnungsgemäß löscht.”
Warum gut? Klare Erfolgsmetrik (80 % Abdeckung), Referenzen, an denen sich Devin orientieren kann (UserService.test.js), und ein klar abgegrenzter Umfang mit konkreten Überprüfungsschritten.

Migration oder Refactoring von bestehendem Code

“Migriere logger.js von JavaScript zu TypeScript. Wir haben bereits eine tsconfig.json und eine Test-Suite LoggerTest.test.js zur Validierung. Stelle sicher, dass der Code ohne Fehler kompiliert, und ändere auf keinen Fall die bestehende Konfiguration! Überprüfe die Migration anschließend, indem du: 1) tsc ausführst, um sicherzustellen, dass keine Typfehler auftreten, 2) die Test-Suite mit npm test LoggerTest.test.js ausführst, um sicherzustellen, dass alle Tests erfolgreich sind, und 3) kontrollierst, dass alle bestehenden Logger-Methodenaufrufe in der gesamten Codebasis weiterhin ohne Typfehler funktionieren.”
Warum gut? Es gibt eine klare Vorlage (tsconfig.json) und eine Test-Suite für direktes Feedback, plus konkrete Schritte für Kompilierung und Validierung.

Aktualisieren von APIs oder Datenbankabfragen

“Wir wechseln von pg zu sequelize (siehe https://sequelize.org/api/v6/identifiers). Bitte aktualisiere die UserModel-Abfragen so, dass sie Sequelize-Methoden verwenden. Sieh dir dafür OrderModel an, um zu verstehen, wie wir das in dieser Codebasis handhaben. Überprüfe nach der Implementierung, indem du: 1) npm run test:integration UserModel.test.js ausführst, um sicherzustellen, dass alle Integrationstests erfolgreich sind, 2) bestätigst, dass sich die Abfrageperformance nicht verschlechtert hat, indem du die Ausführungszeit auf einem Testdatensatz mit 1000 Usern prüfst, und 3) validierst, dass alle CRUD-Operationen weiterhin die Datenintegrität sicherstellen, indem du npm run test:e2e user-flows.test.js ausführst.”
Warum gut? Devin kann ein bekanntes Muster nachahmen, und es gibt explizite Referenzen (OrderModel.js). Es wird ein Link zur Dokumentation bereitgestellt, damit Devin weiß, dass er diese heranziehen soll, und es sind konkrete Schritte zur Überprüfung von Performance und Funktionalität mit exakten Testbefehlen enthalten.

Implementieren eines Features anhand eines Designs

“Implementiere die Pricing-Seite aus dieser Figma-Datei: https://figma.com/file/abc123/Pricing-Page. Konzentriere dich auf den Frame ‘Pricing Section’. Verwende unsere Tailwind-Konfiguration in tailwind.config.ts für Farben und Abstände. Verwende die bestehenden Card- und Button-Komponenten aus src/components/ui/ wieder. Starte nach der Implementierung den Dev-Server und mache Screenshots bei Desktop- (1440px) und Mobile-Breite (375px). Öffne keine PR, bevor die Implementierung dem Design entspricht.”
Warum gut? Verweist auf die konkrete Figma-Datei, benennt den exakten Frame, verweist auf das Designsystem des Projekts und bestehende Komponenten und weist Devin an, die Implementierung visuell zu überprüfen, bevor eine PR geöffnet wird. Mit dem Figma MCP verbunden kann Devin Design-Tokens direkt aus der Datei auslesen.

Untersuchen eines Produktionsbugs

“User melden 500-Fehler auf der Checkout-Seite. Verwende den Sentry MCP, um die neuesten Stacktraces für das payments-api-Projekt abzurufen. Überprüfe die Datenbank auf zugehörige Datenprobleme. Finde die eigentliche Ursache, behebe sie und füge einen Regressionstest hinzu. Verlinke das Sentry-Issue in der PR-Beschreibung.”
Warum gut? Verweist Devin auf die richtigen Tools (MCP-Integrationen), gibt einen klaren Untersuchungsablauf vor und definiert das erwartete Ergebnis (Fix + Regressionstest + PR).

​
Schlecht

Offenes Code-Review

“Finde Probleme in unserer Codebase und behebe sie”
Warum schlecht? Die Anfrage ist zu vage und offen formuliert. Es gibt keine Erfolgskriterien und keine Möglichkeit für Devin zu wissen, wann die Aufgabe erledigt ist.Stattdessen: Verwende Devin Review für automatisierte Code-Reviews für bestimmte PRs oder gib Devin eine gezielte Aufgabe wie: “Finde und behebe alle Verwendungen der veralteten oldLogger API in src/services/.”

Rein subjektive visuelle Anforderungen

“Mach die Landingpage besser”
Warum schlecht? “Besser” ist subjektiv und Devin hat keine Kriterien, auf die es hinarbeiten kann. Devin kann funktionale UIs erstellen und Designs nach Spezifikationen umsetzen, aber es kann keine ästhetischen Entscheidungen eigenständig treffen.Stattdessen: Stelle ein Figma-Design, eine Referenzseite oder konkrete Änderungen bereit: “Erhöhe die Schriftgröße im Hero-Bereich auf 48px, füge 32px Padding hinzu und verwende die Farbe indigo-500 aus unserer Tailwind-Konfiguration.”

Sehr komplexe, vage Projekte

“Baue eine neue Microservices-Architektur für unsere App.”
Warum schlecht? Dies ist eine sehr große und unstrukturierte Aufgabe. Sie erfordert viele Architekturentscheidungen, Abwägungen und Kontext, der nicht im Prompt enthalten ist.Stattdessen: Teile es auf:
  1. Verwende Ask Devin, um deine Codebase zu untersuchen und Abhängigkeiten zu erfassen
  2. Bitte Devin, konkrete Architekturen mit jeweiligen Trade-offs vorzuschlagen
  3. Erstelle separate Sessions für die Implementierung jedes Services — führe sie parallel mit batch sessions aus