Good vs. Bad Instructions
What works and what doesn’t
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.”
Why Good? Clear success metric (80% coverage), references to guide Devin (UserService.test.js), and a well-defined scope.
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!”
Why Good? There’s a clear template (tsconfig.json) and test suite for immediate feedback.
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.”
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.
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:
- Have Devin investigate your codebase
- Ask Devin to propose specific architectures
- Create separate sessions for implementing each part