Skip to main content
Make sure to read When to Use Devin and Instructing Devin Effectively for more essential tips.

Adding a New API Endpoint

Good Approach
“Create a new endpoint /users/stats that returns a JSON object with user count and average signup age. Use our existing users table in PostgreSQL. You can reference the /orders/stats endpoint in statsController.js for how we structure responses. Ensure the new endpoint is covered by the StatsController.test.js suite.”
Why This Works:
  • Clearly specifies the route and expected response format
  • References existing code as a template
  • Defines data source (users table)
  • Includes test coverage requirements


Bad Approach
“Add a user stats endpoint.”
Why This Fails:
  • Unspecific about what stats to include
  • No mention of data sources
  • No reference to existing patterns
  • Missing test requirements

Frontend Feature for Displaying Data

Good Approach
“In UserProfileComponent, add a dropdown that shows a list of user roles (admin, editor, viewer). Use the styling from DropdownBase. When a role is selected, call the existing API to set the user role. Validate by checking that the selection updates the user role in the DB. Refer to your Knowledge for how to test properly.”
Why This Works:
  • Names specific components
  • Lists exact roles to include
  • References existing styling component
  • Defines the user interaction flow
  • Includes validation steps


Bad Approach
“Make the user profile page more user-friendly. Add some way for them to change roles and confirm it’s working.”
Why This Fails:
  • “User-friendly” is subjective
  • No specific UI components mentioned
  • Unclear user interaction flow
  • Vague validation criteria

​
More Examples

​
Good

Writing Unit Tests

“Add Jest tests for the AuthService methods: login and logout. Ensure test coverage for these two functions is at least 80%. Use UserService.test.js as an example. After implementation, run npm test -- --coverage and verify the coverage report shows >80% for both functions. Also confirm that tests pass with both valid and invalid credentials, and that logout properly clears session data.”
Why Good? Clear success metric (80% coverage), references to guide Devin (UserService.test.js), and a well-defined scope with specific verification steps.

Migrating or Refactoring Existing Code

“Migrate logger.js from JavaScript to TypeScript. We already have a tsconfig.json and a LoggerTest.test.js suite for validation. Make sure it compiles without errors and make sure not to change the existing config! After migration, verify by: 1) running tsc to confirm no type errors, 2) running the test suite with npm test LoggerTest.test.js to ensure all tests pass, and 3) checking that all existing logger method calls throughout the codebase still work without type errors.”
Why Good? There’s a clear template (tsconfig.json) and test suite for immediate feedback, plus specific compilation and validation steps.

Updating APIs or Database Queries

“We’re switching from pg to sequelize (read https://sequelize.org/api/v6/identifiers). Please update the UserModel queries to use Sequelize methods. Refer to OrderModel for how we do it in this codebase. After implementation, verify by: 1) running npm run test:integration UserModel.test.js to check all integration tests pass, 2) confirming query performance hasn’t degraded by checking execution time on a test dataset of 1000 users, and 3) validating that all CRUD operations still maintain data integrity by running npm run test:e2e user-flows.test.js.”
Why Good? Devin can mimic a known pattern and there are explicit references (OrderModel.js). Provides a link to docs so Devin knows to reference them, and includes specific performance and functionality verification steps with exact test commands.

Implementing a Feature from a Design

“Implement the pricing page from this Figma file: https://figma.com/file/abc123/Pricing-Page. Focus on the ‘Pricing Section’ frame. Use our Tailwind config in tailwind.config.ts for colors and spacing. Reuse the existing Card and Button components from src/components/ui/. After implementing, spin up the dev server and take screenshots at desktop (1440px) and mobile (375px) widths. Do not open a PR until it matches the design.”
Why Good? Links the specific Figma file, names the exact frame, references the project’s design system and existing components, and tells Devin to visually verify its work before opening a PR. With the Figma MCP connected, Devin can read design tokens directly from the file.

Investigating a Production Bug

“Users are reporting 500 errors on the checkout page. Use the Sentry MCP to pull the latest stack traces for the payments-api project. Check the database for any related data issues. Find the root cause, fix it, and add a regression test. Link the Sentry issue in the PR description.”
Why Good? Points Devin to the right tools (MCP integrations), gives a clear investigation path, and defines the expected deliverable (fix + regression test + PR).

​
Bad

Open-Ended Code Review

“Find issues with our codebase and fix them”
Why Bad? The request is too vague and open-ended. There are no success criteria and no way for Devin to know when it’s done.Instead: Use Devin Review for automated code review on specific PRs, or give Devin a targeted task like “Find and fix all uses of the deprecated oldLogger API in src/services/.”

Purely Subjective Visual Requests

“Make the landing page look better”
Why Bad? “Better” is subjective and Devin has no criteria to aim for. Devin can build functional UIs and implement designs from specs, but it can’t make aesthetic judgment calls on its own.Instead: Provide a Figma design, a reference site, or specific changes: “Increase the hero section font size to 48px, add 32px padding, and use the indigo-500 color from our Tailwind config.”

Highly Complex, Vague Projects

“Build a new microservices architecture for our app.”
Why Bad? This is a very large and unstructured task. It requires many architectural decisions, trade-offs, and context that isn’t in the prompt.Instead, break it down:
  1. Use Ask Devin to investigate your codebase and map dependencies
  2. Ask Devin to propose specific architectures with trade-offs
  3. Create separate sessions for implementing each service — run them in parallel with batch sessions