Your First Session

Start your first session and see what Devin can do

Now that you’re all set up, kick off your first Devin session!

Start with tasks that are smaller in scope and remember to instruct Devin with the level of detail that you would give to a human junior engineer. We’ve seen users work with Devin on everything from fixing small bugs to targeted refactors to large scale migrations.

Start a run with Devin

We recommend starting sessions from Slack channels (make sure you tag @Devin after adding Devin to the channel, and link your Slack user to your Devin account).

You can also start from our web app, where you’ll find some first-time prompt suggestions.

First-time Prompt Ideas

Adding a new API endpoint

a new API endpoint

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.

Small frontend features

frontend features

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.

Write unit tests

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.

Migrating or refactoring existing code

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
3) checking that all existing logger method calls throughout the codebase still work without type errors.

Updating APIs or database queries

unit tests

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
3) validating that all CRUD operations still maintain data integrity by running `npm run test:e2e user-flows.test.js`

Create a quick PR (we recommend using this prompt in a Playbook)

Quick PR

## Overview
The task is to make a quick pull request to a repository.
Since this is a 'quick' PR, you will not need to run any code or test anything; simply make a PR and the user will handle the testing. Your only responsibility is reading and writing code.

## What's Needed From User
- The repository to create a pull request to

## Procedure
### Prepare your workspace
1. Navigate to the relevant repository on your machine (clarify with the user if you can't figure it out).
    - Check out the main branch and note down the name of the main branch.
    - Checkout to a new branch since you'll be making a pull request. The name of the branch has to be of the format `devin/<your-branch-name>/X` where X is a random number. For example `devin/fix-popup/3234`. Run `git remote -v && git pull && git checkout -b devin/{branch-name}/$RANDOM` and replace `{branch-name}` with the name of the branch you want to create.
2. Study the request, codebase, and plan out the changes
    - Review the most relevant files and code sections, identifying relevant snippets.
    - Inform the user of your plan
### Work on the PR itself
3. Make the code changes
    - Don't change anything that wasn't specifically requested by the user
4. Make the PR
    - Commit and push the changes and tell the user.
    - See advice section for the exact command to make the PR
    - Make a pull request & review the pr to make sure it looks OK.
    - Ensure all GitHub actions pass successfully & make necessary changes until they do
    - Send the PR link to the user and summarize what you changed.
5. Address any feedback from the review; send the PR link again every time you make any changes
    - If you need to make updates, just push more commits to the same branch; don't create a new one


## Task Specification
- PR link is included in your messages to the user
- PR was reviewed after creation
- PR does not include any stray changes
- PR does not change anything that wasn't specifically requested by the user
- PR description should include a summary of the changes, formatted as a checklist
- PR description should mention that the code was written without testing, and include - [ ] Test the changes as an item
- PR description should include the following footer: "This PR was written by [Devin](https://devin.ai/) :angel:"
- PR description should include any metadata that the user has provided (e.g. linear ticket tags in the appropriate syntax)
- PR description should not be malformatted (use --body-file instead of --body if the newlines are garbled!)

## Forbidden Actions
- Do NOT try to access github.com through the browser, you will not be authenticated.
- NEVER force push on branches! Prefer merging over rebasing so that you don't lose any work.
- Do NOT push directly to the main branch.

## Advice and Pointers
- Double check the name of the main branch (which could be `main` or `master`) using `git branch`.
- For repos with CI/CD on github actions, you can check build logs using the gh cli. if you're asked to fix a build/fix lint, you should start by looking at recent build logs
- Check `git status` before committing or adding files.
- Use `git diff` to see what changes you have made before committing.
- If you're updating an existing repo, use `gh cli` to make pull requests.
- Send the PR link to the user every time you update & ask them to re-review so that it's convenient for them
- You should already be authorized to access any repositories the user tells you about. If not, ask the user for access.

The first time you use Devin, we would recommend sitting and watching how Devin works for a few minutes using the Follow Devin tab or in our example session video below. In general, you don’t need to monitor Devin like this all the time, but it is a great starting point for understanding Devin’s capabilities.

Note: This video was sped up for demonstration purposes.

If you’d like to dig in to some more detailed examples of what Devin can do (and how), check out our introductory tutorials below.

Code Coverage

Devin can analyze your codebase’s test suite and write additional tests to increase code coverage for your team.

API Integration

Devin can integrate, configure, and test third party APIs in your applications.

Containerization

In this tutorial, we’ll show you how Devin can configure a Docker container to standardize your team’s dev environment.

Managing Frontend Components

Devin can work with frontend libraries and share visuals with you during its sessions.

Work With Your Existing Tools

You can invite Devin to work in many of the tools or applications you work in - it’s as simple as giving Devin the necessary credentials, API keys or tokens so it can work within those services through the Secrets Manager or when prompted to securely share the credential in the chat.

Here are some common tools Devin has used with our early users:

For more details on Devin’s integrations check out our GitHub and Slack integration guides:

GitHub

Connect your GitHub account to allow Devin to access, create pull requests and contribute to your existing repositories.

Slack

Connect Devin to your company Slack and kick off runs directly via Slack by tagging @Devin.

For automated workflows and integrations with your existing tools, you can also leverage our API Reference to programmatically create sessions and retrieve structured results.