Getting Started with Devin

This article explains how a member of your organization can run a Devin session. Devin helps your organization with tasks. To maximize effectiveness, start with smaller tasks and provide detailed instructions, as you would for a junior engineer.

Installing Repositories

An enterprise consists of multiple organizations, each requiring access to specific repositories. You must install repositories for each organization that needs access. Installing a repository allows Devin’s workspace to complete tasks, as Devin is properly set up to build, lint, and test the code. Before using Devin, a member from each organization must complete the following setup.

Onboarding Step 1 - Connecting Git

Onboarding Step 2 - Connecting Slack

if your enterprise is not on Slack, you will use the web app.

Onboarding Step 3 - Select a Repository

You can add additional repositories later.

Onboarding Step 4 - Setting up Devin's Workspace

Onboarding Step 5 - Setting up repository dependencies

For example this could look like apt-get {your-package}

Onboarding Step 6 - Setting up Lint

For example this could look like npm run lint

Onboarding Step 7 - Setting up Tests

For example this could look like npm run test

Onboarding Step 8 - Completing Setup

Start a Devin Session

Once installed, Devin can operate on the configured repository. Additional repositories can be installed later. There’s no limitations on amount or size of repositories.

Devin sessions are isolated — different concurrent member sessions do not impact each other.

To observe Devin’s workflow, use the “Follow” tab. The example session video below provides insights into Devin’s capabilities.

Note: This video was sped up for demonstration purposes.

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.

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.

Enterprise Catalog

Enterprise use-cases

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.

Enterprise

Security & Access

Virtual Private Cloud

Enterprise API

Getting Started with Devin

Installing Repositories

Start a Devin Session

Code Coverage

API Integration

Enterprise Catalog

Managing Frontend Components

Work With Your Existing Tools

GitHub

Slack

Enterprise

Security & Access

Virtual Private Cloud

Enterprise API

​Installing Repositories

​Start a Devin Session

Code Coverage

API Integration

Enterprise Catalog

Managing Frontend Components

​Work With Your Existing Tools

GitHub

Slack

Installing Repositories

Start a Devin Session

Work With Your Existing Tools