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.

​
Bad

Open-Ended Code Review

“Find issues with our codebase and fix them”

Why Bad? The request is too vague and asks for Devin to complete too many tasks in a single session. Devin can get confused over long sessions.

Visual Design Tasks

“Build exactly what’s shown in this Figma mock”

Why Bad? This is a subjective visual request. Devin can’t “see” how humans do and won’t get the details perfectly. It’s not optimized for these use cases.

Highly Complex, Vague Projects

“Build a new microservices architecture for our app.”

Why Bad? This is a very large and unstructured task. Requires architectural decisions and trade-offs.

Instead, break down complex projects into phases:

  1. Have Devin investigate your codebase
  2. Ask Devin to propose specific architectures
  3. Create separate sessions for implementing each part