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.
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}
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
Copy
Ask AI
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
Copy
Ask AI
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
Copy
Ask AI
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
Copy
Ask AI
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 errors2) running the test suite with `npm test LoggerTest.test.js` to ensure all tests pass3) checking that all existing logger method calls throughout the codebase still work without type errors.
Updating APIs or database queries
unit tests
Copy
Ask AI
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 pass2) confirming query performance hasn't degraded by checking execution time on a test dataset of 1000 users3) 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
Copy
Ask AI
## OverviewThe 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 workspace1. 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 itself3. Make the code changes - Don't change anything that wasn't specifically requested by the user4. 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.
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:
For automated workflows and integrations with your existing tools, you can also leverage our API Reference to programmatically create sessions and retrieve structured results.
Assistant
Responses are generated using AI and may contain mistakes.
